An Architecture for IP in Deep Space
draft-many-deepspace-ip-architecture-01
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) | |
|---|---|---|---|
| Authors | Marc Blanchet , Wesley Eddy , Tony Li | ||
| Last updated | 2024-11-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing List |
||
| 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-many-deepspace-ip-architecture-01
Internet Engineering Task Force M. Blanchet
Internet-Draft Viagenie
Intended status: Informational W. Eddy
Expires: 7 May 2025 MTI Systems
T. Li
Juniper Networks
3 November 2024
An Architecture for IP in Deep Space
draft-many-deepspace-ip-architecture-01
Abstract
Deep space communications involve long delays (e.g., Earth to Mars is
4-20 minutes) and intermittent communications, because of orbital
dynamics. The IP protocol stack used on Internet is based on
assumptions of shorter delays and mostly uninterrupted
communications. This document describes the architecture of the IP
protocol stack tailored for its use in deep space. It involves
buffering IP packets in IP forwarders facing intermittent links,
signaling buffer storage near capacity, adjusting transport protocols
configuration and application protocols timers. This architecture
applies to Moon, Mars or in general interplanetary networking.
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 7 May 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Blanchet, et al. Expires 7 May 2025 [Page 1]
Internet-Draft IP in Deep Space November 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document and Discussion location . . . . . . . . . . . . 4
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Examplary Network . . . . . . . . . . . . . . . . . . . . 5
2.2. Current situation on Mars . . . . . . . . . . . . . . . . 6
3. Layer 2 in Deep Space . . . . . . . . . . . . . . . . . . . . 6
3.1. Celestial Body Surface . . . . . . . . . . . . . . . . . 6
3.2. Deep Space Links . . . . . . . . . . . . . . . . . . . . 7
3.3. Celestial Body Orbits . . . . . . . . . . . . . . . . . . 7
4. Internet Protocol . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IP Forwarding and Store-and-Forward . . . . . . . . . . . 7
4.2. Header Compression . . . . . . . . . . . . . . . . . . . 8
5. IP Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . 9
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Other Transports . . . . . . . . . . . . . . . . . . . . 10
6.4. Explicit Congestion Notification(ECN) . . . . . . . . . . 10
7. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Network services . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Network Management . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Blanchet, et al. Expires 7 May 2025 [Page 2]
Internet-Draft IP in Deep Space November 2024
1. Introduction
Deep space communications involve long delays (e.g., Earth to Mars is
4-20 minutes) and intermittent communications, because of orbital
dynamics. Up to now, communications have been done on a layer-2
point to point basis, with sometimes the use of relays, but no
layer-3 networking has been in use. [RFC4838] reports an assessment
done around 25 years ago concluding that the IP protocol stack was
not suitable for deep space networking. This result lead to the
definition of a completly new protocol stack 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].
More recently, space agencies are planning to deploy IP networks on
celestial bodies, such as Moon[ioag] or Mars[ioag-mars], surface, and
orbital vicinity, using layer2 technologies such as WIFI or 5G. On
the surface, it is planned to have high density of network nodes of
space stations and habitats.
Mission concepts are also based on a cluster of multiple network
nodes in close proximity at Langrange points.
A previous document[I-D.many-deepspace-ip-assessment] revisited the
initial assessment of not using IP and concluded that the IP stack is
in fact viable in deep space, given the IP stack evolution that
happened since the initial assessment. This document defines an
architecture to use IP in deep space networking. IP in deep space
means running IP over deep space layer-2 links, a reliable transport
over IP, applications protocols over that transport and applying
proper routing, security and network management on that IP network.
Reusing the whole IP stack in deep space enables the reuse of all
protocols, tools and software currently used on Internet. However,
as one might already argue, many components of the IP stack can not
be used as is and therefore requires careful configuration and
deployment considerations that are discussed in this document.
The keyword Delay-Tolerant Networking (DTN), also expanded to Delay
and Disruption-Tolerant Networking, has been used to identify the
problem space and given that up to now, the solution was based on the
Bundle protocol, DTN was also associated with Bundle protocol. This
document tries to solve the DTN problem using the Internet Protocol
stack. Therefore, in this document, the DTN keyword is used to name
the problem space, not the Bundle protocol solution.
Since Moon is a few light seconds away from Earth, it is possible to
somewhat configure and run various IP based protocols and
applications to make it "work". Mars with a much longer delay is
Blanchet, et al. Expires 7 May 2025 [Page 3]
Internet-Draft IP in Deep Space November 2024
more difficult. Therefore, this document uses Mars as the base
example, knowing that if it works for Mars, a much harder problem, it
could be replicated easily for Moon, or for other networks made with
relays around a celestial body. This framework shall also work for
longer delays, such as reaching Jupiter or the whole Solar System
Internet(SSI), but it is not specifically discussed. This document
uses "deep space" extensively in order to differentiate with "space"
which often includes Earth orbiting communications, which is not
discussed in this document, even if the definition of deep space per
ITU does not include Moon, while this document is applicable to IP
networks on the Moon.
It should also be noted that DTN and BP were also designed for non-
space use cases. While this document focuses on the deep space use
case, it shall work for the other use cases of BP, but these use
cases are out of scope of this document.
Space missions are typically planned many years in advance and are
long-lived, spanning over many years even decades. Spacecrafts are
controlled from Earth and therefore should always be manageable from
Earth. Given the remoteness and the difficulty to physically access
the spacecraft, software upgrades and configuration changes are
avoided whenever possible.
As with Bundle protocol, this framework proposes to use IP in deep
space with a similar store-and-forward paradigm. Therefore, the IP
layer has to deal with the fact that a destination may not be
currently reachable and that IP packets should be stored for an
unusual amount of time, such as minutes or hours or days, in the
forwarding device waiting for a new link up opportunity. The
transport layer should be able to work with long and variable delays,
including intermittent communications. The application protocols and
application themselves should be properly set to wait a longer time
than on Internet to receive a response to a query. Finally, all
network services such as routing, security, naming and network
management should also be adapted in this new context. This document
is structured around these layers.
1.1. Document and Discussion location
The source of this document is located at
https://github.com/marcblanchet/draft-deepspace-ip-architecture.
Comments or changes are welcomed using a PR or an issue.
This subject should be discussed on the deepspace@ietf.org mailing
list.
Blanchet, et al. Expires 7 May 2025 [Page 4]
Internet-Draft IP in Deep Space November 2024
2. Use Cases
Multiple countries are developing systems aimed for a sustained lunar
presence combining manned and robotic missions, within several years.
IP has been included in the stack for the International Deep Space
Interoperability Standards[idsis], and the LunaNet Interoperability
Specification[lnis]. There is a general intention to extend and
reuse systems developed for lunar use to later Mars use
Separate space agencies and private companies are deploying lunar
space stations, orbiters, landers, rovers, habitats, crewed mission
elements, and other assets. Due to pervasive use and support of IP
in modern computing systems, it also is naturally used onboard many
space systems, and between co-located systems. As more-and-more IP-
enabled assets become deployed in lunar vicinity, it will
increasingly create opportunities to interconnect them. In fact,
internetworking of lunar (and future Mars) systems is becoming
essential, as plans call explicitly for cooperation between mission
elements and communications/navigation system assets operated by
different space agencies and/or private companies acting as service
providers. There are expected to be several different lunar network
service providers (LNSPs) offering different varieties of relayed
and/or direct services. It may be expected that lunar IP networks
should over time become united into larger aggregates, and even into
a single interoperable network (as intended within the LunaNet
conception).
Routing within and between dynamically connected network elements may
be handled in various ways, as the practices develop and specific
systems are deployed. There will likely be coordination between
LNSPs and some methods to share and control pre-determined time-
varying static routes (similar to PCE architecture), traffic volume
expectations, security policies, etc. The early steps in lunar
networking may not actually interconnect the global Internet directly
with the lunar surface, though later on this may become reasonable.
2.1. Examplary Network
The examplary network for this document is where deep space links are
using IP over CCSDS space links[IPoverCCSDSSpaceLinks] and that on
and around a celestial body, a connected IP network is established
with local network infrastructure and services. Orbiters around the
celestial body provides connectivity to and from Earth to the devices
on the celestial body. As an example, a rover on the Mars surface is
connected to a Mars surface IP network which receives intermittent
connectivity from a few orbiters with an average of 6 hours per
orbit. Some of those orbiters have circular orbits, other
elleptical. The latter means that the overpass are not at a fixed
Blanchet, et al. Expires 7 May 2025 [Page 5]
Internet-Draft IP in Deep Space November 2024
frequency. The orbiters are connected to Earth ground station while
they are in line of sight with Earth. Earth and Mars have variable
distance from 4 to 20 minutes light seconds. That one way delay
however change "slowly" as the planets are orbiting around the Sun.
When an orbiter has direct line of sight with Earth, it can receive
from and transmit packets to Earth. During that window, it may have
connectivity using another radio or laser to devices on the orbit or
on the surface, but very often it does not. Therefore, during those
periods where only one segment of the path is up, the orbiter must
buffer the received packets until the next segment becomes available
when it forwards the packets and flushes the buffer.
2.2. Current situation on Mars
While the target scenarios for Moon or Mars are way more complex than
what is deployed today, it is useful to know what has been deployed
already. This section describes the Mars communications
infrastructure as it relates to its layer 2
On Mars, there are a few devices such as rovers or helicopters that
are in use. There are currently 5 active orbiters that provide
communications relay services between Mars surface and Earth. On
Earth, various antennas such as the Deep Space Network(DSN)[DSN] are
used for communicating with Mars. The MAROS project at the Jet
Propulsion Laboratory is a broker software enabling missions to enter
data about the communications capabilities such as frequencies,
bandwidth, window of communication time, ... so that rover missions
can schedule the available communications windows for transmitting
and receiving. Most orbiters are used and scheduled in MAROS. One
of the Mars orbiters is Mars Reconnaissance Orbiter(MRO)[mro]. It
was launched in 2005 and has a single 40Mhz processor but over 100G
of solid state memory. As demonstrated by a study[marscommstudy] on
Mars communication windows, the communication windows seem of having
a constant frequency, but the reality shows that they are pretty
variable, which means a very large range of resulting round-trip time
(RTT) for communications from Earth to Mars and back. For example,
within 3 months in 2024, the RTT varied from 30 minutes to 170 hours.
3. Layer 2 in Deep Space
3.1. Celestial Body Surface
The Interagency Operations Advisory Group(IOAG)[ioag] has defined the
communications architecture for Moon and Mars. On the celestial body
surface, it is planned to use 3GPP and IEEE 802.* link layer
protocols. The IP protocol suite is expected to be used over these
link layers.
Blanchet, et al. Expires 7 May 2025 [Page 6]
Internet-Draft IP in Deep Space November 2024
3.2. Deep Space Links
Deep space links typically use the Consultative Committee for Space
Data Standards(CCSDS)[CCSDSWEB] standards for link layers, such as
Telecommand(TC)[CCSDS_TC], Telemetry (TM)[CCSDS_TM], Advanced
Orbiting Systems(AOS)[CCSDS_AOS], Proximity1(Prox1)[CCSDS_PROX1]or
the Unified Space Data Link Protocol (USLP)[CCSDS_USLP]. CCSDS has
defined a generic encapsulation mechanism for the payloads for all
these link layer protocols which defines IP as an encapulated
protocol[IPoverCCSDSSpaceLinks][SANAIPEHeaderRegistry]. Therefore,
IP packets can be transported over any CCSDS link layers.
3.3. Celestial Body Orbits
On celestial body orbits, IOAG has planned the use of CCSDS link
layer protocols. However, as on Earth, it may be possible to use 6G-
NTN technology around celestial bodies, such as Moon or Mars orbits.
6G-NTN technologies use IP as its layer3 technology.
4. Internet Protocol
IPv4 or IPv6 packets can be carried as is over long delays and
disruptions, as IP itself has no notion of time. Originally, the
Time To Live(TTL) field of IPv4 was defined based on time[STD5], but
it has been effectively implemented as an hop count, which was
renamed as "Hop Count" in IPv6[STD86]. Nothing needs to be changed
to the IP protocol or its packet format.
4.1. IP Forwarding and Store-and-Forward
For deep space applications, an IP packet may need to be stored
temporarily over much longer periods than are typical for the
Internet when the next hop is currently unreachable or undefined,
which can happen due to orbital dynamics. This is commonly referred
to as "store-and-forward" and bears no relationship to the same term
when used in reference to switch architectures.
This store and forward mechanism may be implemented at layer 2 as is
currently done by the Mars orbiters. In this case, the frames are
stored, independent of payload type. In this case, IP packets are
unaware of the store-and-forward and no changes are needed in the IP
forwarding function. The L2 network is just behaving as a point-to-
point link with a large and variable latency.
Blanchet, et al. Expires 7 May 2025 [Page 7]
Internet-Draft IP in Deep Space November 2024
If an IP router has an interfaces on an intermittent link, then a
queueing discipline should be used to store packets. This might be
implemented as a deep queue with active queue
management(AQM)[RFC7567]. When the link to the next hop is up again,
maybe minutes or hours later, the stored packets can then be
transmitted.
This store-and-forward mechanism requires proper provisioning of
storage at each forwarding interface for the target deployment and
usage. Mechanisms such as ECN (Section 6.4) can be used to signal
storage congestion can be used to request that end nodes throttle
their transmissions. If the appropriate queue is full, then the
interface MAY drop packets and MAY send ICMP error messages to the
source, so that the transport protocol can recover by resending the
dropped packets. The choice of which packets to drop during a queue
congestion event depends on the queuing policies configured in the
node, which may be a function of diffserv/traffic class, source or
destination IP addresses, flow label, or other parameters. An
example is described in [I-D.blanchet-tvr-forwarding].
4.2. Header Compression
Deep space links are point-to-point links and bandwidth in space is
very valuable, so header compression is very useful. Static Context
Header Compression (SCHC) [I-D.ietf-schc-architecture] is a header
compression technique that relies on rules in a static context, and
is therefore more efficient for deep space. SCHC should be
considered on a deep space point-to-point link or a string of L2
links.
5. IP Routing
Existing routing protocols have a requirement for proof of liveness
between protocol partners that is implemented through the periodic
exchange of packets between partners. This is impractical on long-
delay or intermittent links, so a PCE [RFC4655] based approach seems
appropriate for those domains possibly supplemented by contact plan
schedules [I-D.blanchet-tvr-contactplan]
[I-D.ietf-tvr-schedule-yang]. Interconnection between domains can
still be done with BGP [RFC4271], but long-delay or intermittent
links should be avoided. Domains straddling such links will need to
provide proxy advertisements for prefixes reachable across such
links.
Optimal routing for domains with intermittent links is out of scope
for this document.
Blanchet, et al. Expires 7 May 2025 [Page 8]
Internet-Draft IP in Deep Space November 2024
On the surface of celestial bodies and in proximal orbit, traditional
protocols are applicable and should be used (e.g.,
[I-D.li-arch-sat]).
5.1. Addressing
The IP address space is a hierarchical namespace where ranges of
addresses are encoded as "prefixes". Individual domains advertise a
set of prefixes to the broader Internet and assign these addresses
internally. Prefixes may be aggregated into less-specific prefixes,
which makes the routing subsystem more efficient by decreasing
overhead.
Space networks provide a unique opportunity to provide extremely
efficient routing by assigning a unique prefix or block of addresses
per celestial body and its proximal orbits. Management of the IP
address space is currently documented in [RFC7020], but this only
covers continental regions and does not provide for addressing for
space.
Address space for outer space should be managed by a single Regional
Internet Registry (RIR) and blocks of address space should be
allocated for each celestial body of interest. Space service
providers should use prefixes assigned by this RIR.
6. Transport
6.1. UDP
UDP[RFC768] has no notion of time, therefore can be used as is in
deep space. Protocols using UDP transport can therefore be used in
space as is, if they do not rely on time or if they can be configured
with timeouts appropriate in deep space.
6.2. QUIC
QUIC[RFC9000] like most IP transports implements congestion control
mechanisms, which, based on various metrics such as calculated delays
or packet loss, pace the rate of sending packets at the source node
to decrease the perceived congestion in the network. QUIC supports
many new features suitable and useful in deep space such as 1 RTT for
connection establishment and security, mobility, 0RTT, streams, user-
space, ....
Current implementations of QUIC typically set various transport
configuration parameters suitable for the Internet environment, with
RTT in the hundreds of milliseconds and relatively always connected
network. Therefore, QUIC stacks using default configurations will
Blanchet, et al. Expires 7 May 2025 [Page 9]
Internet-Draft IP in Deep Space November 2024
not work in deep space. However, studies and simulations[quic-sim]
showed that with proper transport configuration parameters, QUIC
stacks support delays and disruptions in deep space.
[I-D.many-deepspace-quic-profile] describes how to properly configure
a QUIC stack for deep space application, where the QUIC transport is
unaware of disruptions. If the transport is aware of the
disruptions, then further optimizations may be done.
The ability to have multiple streams and applications within a single
QUIC connection is valuable and useful for deep space. A ground
station may setup the initial QUIC connection with a spacecraft and
then carry all needed applications and streams over that same
connection for the whole duration of the mission.
Session key and certificate lifetime together with certificate
validation and trust chain anchors need to be carefully configured
and handled.
QUIC proxies[I-D.ietf-masque-quic-proxy] can be used at space edge to
isolate, apply policies or to optimize trafic at ingress/egress to a
celestial body network.
6.3. Other Transports
Other transports such as TCP[RFC9293], SCTP[RFC9260], DCCP[RFC4340]
and others were not investigated for their suitability in space.
6.4. Explicit Congestion Notification(ECN)
Explicit Congestion Notification(ECN)[RFC3168] enables a network
forwarder to signal to the sources to pace down in the context of
congestion. In deep space where forwarders will be buffering
packets, the actual congestion is when the storage is approaching its
full capacity. ECN enables the forwarders to signal that issue.
Given delays and disruptions which means the reception by the source
may take longer time, the forwarders should be pro-active and preempt
based on the types of links and actual rate of storage usage. IP
clients with QUIC should process the received ECN signals
appropriately.
7. HTTP
HTTP by itself has no notion of time. An HTTP request and response
may take minutes or hours to be completed. However, current
infrastructure and software on Internet have various time-related
configurations that will not work as is in the deep space context.
Blanchet, et al. Expires 7 May 2025 [Page 10]
Internet-Draft IP in Deep Space November 2024
HTTP headers containing time, such as Cache-Control and Expires
[RFC9111], should not be used or if used be set to large enough
values to cover the longest delay so that expiration does not happen
before the actual data arrives at the destination. As with any HTTP
application and content on Internet, these headers should be set
properly based on the deployment use case, which is ever more
important for deep space. Similarly, when continuous content
transfer is used, as with 100-Continue [RFC9110], proper values for
headers should be set.
HTTP clients and servers typically have default timeouts that shall
be modified. For example, curl [curl] has the "-m" option for this
use case. Similarly, HTTP server implementations have various
timeouts configuration variables to be set properly. Testing with
HTTP client Curl and HTTP server nginx and an introduced network
delay of 20 minutes showed that HTTP communications work just fine
with very basic configuration changes.
HTTP applications themselves must be developed using an asynchronous
pattern and if they have timeouts, they should be adjusted
appropriately.
Internet Web sites are designed with the assumption of hundred of
milliseconds delay and relatively always connected, where pages
contain multiple queries to further get resources, media, queries to
web services and downloading additional code and frameworks. This
could work in theory in this context of space, but it will not be
optimal, as multiple queries will be generated and therefore taking
multiple RTT before the whole page is received complete. This issue
can be mitigated by using various techniques such as Web Assembly
[wasm] or pre-caching. Moreover, tt could be possible to have very
basic HTML pages with zero or very few href and no media content
unless locally cached to be used. An example would be a rover on
Mars presenting an HTTP server with a base and bare HTML page to
offer basic info on its status (maybe all in text) and some
additional detailed pages, most likely also in base html text.
However, it is foreseen that most applications based on QUIC-HTTP
transport in deep space would be using REST or similar asynchronous
patterns and not typical web browsing.
Caching should be used extensively on celestial bodies networks to
maximize local fetching. Preemptive caching by pre-populating caches
with data that shall be used locally on the celestial body network
shall be done as much as possible to provide better response time on
the local celestial body network.
QPACK [RFC9204] should be considered for higher bandwidth efficiency.
Blanchet, et al. Expires 7 May 2025 [Page 11]
Internet-Draft IP in Deep Space November 2024
8. Network services
8.1. Naming
At a small scale, one can use IP addresses directly or can use static
names to IP address mappings such as /etc/hosts. However, this does
not provide easy dynamic updates, scaling by hierarchy, service
discovery, authentication of records, ... Therefore, the Domain Name
System (DNS) shall be considered early on in the space deployment.
However, naming hierarchy and infrastructure has to be carefully
designed to avoid name resolution over deep space links, given that
answers may come after minutes or hours. There are clear advantages
of having the space name hierarchy anchored to the current Internet
root, as it enables DNSSEC using the same security infrastructure
currently used and deployed. Using the same root also does not
require new policies. A new TLD or a new root is way more
complicated and does not bring any significant value compared to
using the current domain tree.
Care must be taken to manage key lifecycles and resource record
lifetimes. [I-D.many-dnsop-dns-isolated-networks] discusses the
various methods and naming hierarchy that can be used in space.
8.2. Network Management
NETCONF[RFC6241] and RESTCONF[RFC8040] shall be used with proper
configuration values to avoid timeouts and appropriate transport.
NETCONF over QUIC transport[I-D.ietf-netconf-over-quic] or RESTCONF
over HTTP over QUIC transport shall be configured with appropriate
QUIC transport parameters as discussed in Section 6.2.
While being declared historic in IETF, SNMP[RFC1157] runs over UDP
and have no notion of time. Therefore, with proper configuration of
client timeout, it can be used as is to manage nodes and services in
deep space.
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
Using the current IP protocol stack in deep space inherit all the
work on privacy, cryptography, key management, firewalls and relative
high scrutiny of protocols that is deployed on Internet. As an
example, TLS has been way more scrutinized than almost any other
secure transport protocol. Moreover, given that no changes are made
in the protocols, this architecture does not bring new security
Blanchet, et al. Expires 7 May 2025 [Page 12]
Internet-Draft IP in Deep Space November 2024
issues. Obviously, the deep space security requirements are
different than on Earth Internet, but nothing has been found to
prevent the conformance of the IP protocol stack to those
requirements.
As it is currently planned, the deep space network shall be isolated
from the current Internet by "air gap", to disable any direct
communications from Internet to deep space. Moreover, destination IP
prefixes filtering shall be used to restrict the traffic to only the
relevant one for each link. Note that this shall also be implemented
in the routing control plane, but additional security might be
appropriate to further protect the deep space links.
Each celestial network edge device shall have firewall rules to
disable non-useful trafic to go through deep space links. If
communications from Mars may only occur to Earth, but not Moon, then
appropriate filtering based on destination IP prefixes shall be used.
Given the air gap on Earth for Internet, there shall be no default
route advertised in space that could for example point to Earth
Internet.
11. References
11.1. Informative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", RFC 1157,
DOI 10.17487/RFC1157, May 1990,
<https://www.rfc-editor.org/info/rfc1157>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
Blanchet, et al. Expires 7 May 2025 [Page 13]
Internet-Draft IP in Deep Space November 2024
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[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>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
Internet Numbers Registry System", RFC 7020,
DOI 10.17487/RFC7020, August 2013,
<https://www.rfc-editor.org/info/rfc7020>.
[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/info/rfc7122>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[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>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
Blanchet, et al. Expires 7 May 2025 [Page 14]
Internet-Draft IP in Deep Space November 2024
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[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>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>.
[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/info/rfc9174>.
[RFC9204] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Field Compression for HTTP/3", RFC 9204,
DOI 10.17487/RFC9204, June 2022,
<https://www.rfc-editor.org/info/rfc9204>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[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>.
[STD5] Internet Standard 5,
<https://www.rfc-editor.org/info/std5>.
At the time of writing, this STD comprises the following:
Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, DOI 10.17487/RFC0919, October 1984,
<https://www.rfc-editor.org/info/rfc919>.
Blanchet, et al. Expires 7 May 2025 [Page 15]
Internet-Draft IP in Deep Space November 2024
Mogul, J., "Broadcasting Internet datagrams in the
presence of subnets", STD 5, RFC 922,
DOI 10.17487/RFC0922, October 1984,
<https://www.rfc-editor.org/info/rfc922>.
Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950, August
1985, <https://www.rfc-editor.org/info/rfc950>.
Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[STD86] Internet Standard 86,
<https://www.rfc-editor.org/info/std86>.
At the time of writing, this STD comprises the following:
Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[I-D.blanchet-tvr-contactplan]
Blanchet, M., Torgerson, J. L., and Y. Qu, "Contact Plan
YANG Model for Time-Variant Routing of the Bundle
Protocol", Work in Progress, Internet-Draft, draft-
blanchet-tvr-contactplan-02, 6 July 2024,
<https://datatracker.ietf.org/doc/html/draft-blanchet-tvr-
contactplan-02>.
[I-D.blanchet-tvr-forwarding]
Blanchet, M., "Forwarding in the context of Time-Variant
Routing(TVR)", Work in Progress, Internet-Draft, draft-
blanchet-tvr-forwarding-00, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-blanchet-tvr-
forwarding-00>.
[I-D.ietf-masque-quic-proxy]
Pauly, T., Rosenberg, E., and D. Schinazi, "QUIC-Aware
Proxying Using HTTP", Work in Progress, Internet-Draft,
draft-ietf-masque-quic-proxy-04, 18 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-masque-
quic-proxy-04>.
Blanchet, et al. Expires 7 May 2025 [Page 16]
Internet-Draft IP in Deep Space November 2024
[I-D.ietf-netconf-over-quic]
Dai, J., Yu, S., Cheng, W., Blanchet, M., and P.
Andersson, "NETCONF over QUIC", Work in Progress,
Internet-Draft, draft-ietf-netconf-over-quic-01, 21
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-over-quic-01>.
[I-D.ietf-schc-architecture]
Pelov, A., Thubert, P., and A. Minaburo, "Static Context
Header Compression (SCHC) Architecture", Work in Progress,
Internet-Draft, draft-ietf-schc-architecture-02, 11 April
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
schc-architecture-02>.
[I-D.ietf-tvr-schedule-yang]
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M.
Blanchet, "YANG Data Model for Scheduled Attributes", Work
in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang-
03, 20 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr-
schedule-yang-03>.
[I-D.li-arch-sat]
Li, T., "A Routing Architecture for Satellite Networks",
Work in Progress, Internet-Draft, draft-li-arch-sat-09, 30
August 2024, <https://datatracker.ietf.org/doc/html/draft-
li-arch-sat-09>.
[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-02, 10 September 2024,
<https://datatracker.ietf.org/doc/html/draft-many-
deepspace-ip-assessment-02>.
[I-D.many-deepspace-quic-profile]
Blanchet, M., "QUIC Profile for Deep Space", Work in
Progress, Internet-Draft, draft-many-deepspace-quic-
profile-00, 19 October 2024,
<https://datatracker.ietf.org/doc/html/draft-many-
deepspace-quic-profile-00>.
Blanchet, et al. Expires 7 May 2025 [Page 17]
Internet-Draft IP in Deep Space November 2024
[I-D.many-dnsop-dns-isolated-networks]
Blanchet, M., "Domain Name System in Mostly Isolated
Networks", Work in Progress, Internet-Draft, draft-many-
dnsop-dns-isolated-networks-01, 5 November 2023,
<https://datatracker.ietf.org/doc/html/draft-many-dnsop-
dns-isolated-networks-01>.
[IPoverCCSDSSpaceLinks]
Consultative Committee on Space Data Systems(CCSDS), "IP
OVER CCSDS SPACE LINKS, Blue Book 702", September 2012,
<https://public.ccsds.org/Pubs/702x1b1c2.pdf>.
[SANAIPEHeaderRegistry]
"Internet Protocol Extension Header",
<https://sanaregistry.org/r/ipe_header/>.
[CCSDS_AOS]
Consultative Committee on Space Data Systems(CCSDS), "AOS
Space Data Link Protocol, Blue Book 732.0-B-4", October
2021, <https://public.ccsds.org/Pubs/732x0b4.pdf>.
[CCSDS_TM] Consultative Committee on Space Data Systems(CCSDS), "TM
Space Data Link Protocol, Blue Book 132.0-B-3", October
2021, <https://public.ccsds.org/Pubs/132x0b3.pdf>.
[CCSDS_TC] Consultative Committee on Space Data Systems(CCSDS), "TC
Space Data Link Protocol, Blue Book 232.0-B-4", October
2021, <https://public.ccsds.org/Pubs/232x0b4e1c1.pdf>.
[CCSDS_PROX1]
Consultative Committee on Space Data Systems(CCSDS),
"Proximity-1 Space Link Protocol—Data Link Layer, Blue
Book 211.0-B-6", July 2020,
<https://public.ccsds.org/Pubs/211x0b6e1.pdf>.
[CCSDS_USLP]
Consultative Committee on Space Data Systems(CCSDS),
"Unified Space Data Link Protocol, Blue Book 732.1-B-2",
October 2021,
<https://public.ccsds.org/Pubs/732x1b2s.pdf>.
[wasm] World Wide Web Consortium(W3C), "WebAssembly
Specifications", <https://github.com/webassembly/spec>.
Blanchet, et al. Expires 7 May 2025 [Page 18]
Internet-Draft IP in Deep Space November 2024
[ioag] Lunar Communications Architecture Working Group,
Interagency Operations Advisory Group, "The Future Lunar
Communications Architecture, Report of the Interagency
Operations Advisory Group", January 2022,
<https://www.ioag.org/Public%20Documents/Lunar%20communica
tions%20architecture%20study%20report%20FINAL%20v1.3.pdf>.
[ioag-mars]
Mars and Beyond Communications Architecture Working Group,
Interagency Operations Advisory Group, "The Future Mars
Communications Architecture, Report of the Interagency
Operations Advisory Group", February 2022,
<https://www.ioag.org/Public%20Documents/
MBC%20architecture%20report%20final%20version%20PDF.pdf>.
[picoquic-poc]
Huitema, C., "QUIC to Mars", February 2023,
<https://www.privateoctopus.com/2023/02/07/quic-to-
mars.html>.
[picoquic] Huitema, C., "picoquic",
<https://github.com/private-octopus/picoquic>.
[curl] "Curl", <https://curl.se>.
[CCSDSWEB] CCSDS, "Consultative Committee for Space Data Systems",
<https://ccsds.org>.
[mro] "Mars Reconnaissance Orbiter",
<https://science.nasa.gov/mission/mars-reconnaissance-
orbiter/>.
[DSN] "Deep Space Network",
<https://www.nasa.gov/directorates/somd/space-
communications-navigation-program/what-is-the-deep-space-
network/>.
[quic-sim] Blanchet, M., "Deep Space IP: Some simulation results",
July 2024,
<https://deepspaceip.github.io/meetings/ietf120/ietf120-
deepspaceip-simulation-results.pdf>.
[marscommstudy]
Blanchet, M., "Earth-Mars Communication Windows Usage
Study", October 2024,
<https://deepspaceip.github.io/meetings/ietf121/ietf121-
deepspaceip-mars-communications-study.pdf>.
Blanchet, et al. Expires 7 May 2025 [Page 19]
Internet-Draft IP in Deep Space November 2024
[idsis] "International Communication System Interoperability
Standards (ICSIS)", September 2020,
<https://internationaldeepspacestandards.com/wp-
content/uploads/2024/02/
communication_reva_final_9-2020.pdf>.
[lnis] "LunaNet Interoperability Specification", September 2022,
<https://www.nasa.gov/directorates/somd/space-
communications-navigation-program/lunanet-
interoperability-specification/>.
Acknowledgements
This work started by reassessing the use of the whole IP stack in the
context of deep space. Soon, QUIC was identified as the key
technology for this endeavour. Christian Huitema was very helpful in
not only confirming the ability to use QUIC but also took the time
and effort to test and modify its picoquic stack[picoquic] to confirm
the initial hypothesis[picoquic-poc]. Its involvement and
confirmation are the key for the launch of this work. Then, Martin
Thompson has been also kind to take time to answer initial questions
on QUIC, further confirming the possibility of using QUIC for deep
space. Since then, many individuals have provided significant
comments and perspectives on this subject.
This document and its underlying work has been reviewed and discussed
by many, who have provided valuable feedback and comments, including
disagreements, and made an overall more solid document. These people
are, in no specific order: TBD.
Authors' Addresses
Marc Blanchet
Viagenie
Canada
Email: marc.blanchet@viagenie.ca
Wesley Eddy
MTI Systems
United States of America
Email: wes@mti-systems.com
Tony Li
Juniper Networks
United States of America
Email: tony.li@tony.li
Blanchet, et al. Expires 7 May 2025 [Page 20]