Internet Engineering Task Force M. Blanchet
Internet-Draft Viagenie
Intended status: Informational W. Eddy
Expires: 3 September 2025 MTI Systems
M. Eubanks
Space Initiatives Inc
2 March 2025
IP in Deep Space: Key Characteristics, Use Cases and Requirements
draft-many-tiptop-usecase-01
Abstract
Deep space communications involve long delays (e.g., Earth to Mars
has one-way delays 4-24 minutes) and intermittent communications,
mainly because of orbital dynamics. The IP protocol stack used on
Internet is based on the assumptions of shorter delays and mostly
uninterrupted communications. This document describes the key
characteristics, use cases, and requirements for deep space
networking, intended to help when profiling IP protocols in such
environment.
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 September 2025.
Copyright Notice
Copyright (c) 2025 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.
Blanchet, et al. Expires 3 September 2025 [Page 1]
Internet-Draft IP in Deep Space March 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Limitations of this document . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Document and Discussion Locations . . . . . . . . . . . . 3
2. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Common to all Cases . . . . . . . . . . . . . . . . . . . 4
2.2. Moon . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Mars . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Lagrangian Points . . . . . . . . . . . . . . . . . . . . 8
2.5. Cruising Spacecraft . . . . . . . . . . . . . . . . . . . 8
2.6. Spacecraft Onboard . . . . . . . . . . . . . . . . . . . 8
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Store-and-Forward . . . . . . . . . . . . . . . . . . . . 10
4.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Signaling and Exchanges . . . . . . . . . . . . . . . . . 12
4.4. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Addressing and Routing . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Deep space communications involve long delays (e.g., Earth to Mars is
4-24 minutes one way) and intermittent communications, mainly 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.
This document describes the key characteristics and use cases for
networking in deep space. It provides examples taken from the
current communications facilities to reach Moon and Mars, as well as
future plans. While these examples provide great insight on what is
possible today, the resulting architecture should also consider
future possibilities and farther celestial bodies. For example,
while the number of relays and orbiters around Moon and Mars is
currently limited, it is expected that their number will increase
Blanchet, et al. Expires 3 September 2025 [Page 2]
Internet-Draft IP in Deep Space March 2025
significantly, therefore providing improved coverage around those
celestial bodies, resulting in an impact on communications and
networking traffic patterns, intermittence and alternate paths.
This work is a followup of an assessment on the use of the IP
protocol stack in deep space[I-D.many-deepspace-ip-assessment].
1.1. Limitations of this document
Communication in deep space is vastly different than on Earth. This
document does not describe space communication technologies below IP,
but only the information relevant from the IP protocol stack
viewpoint for the purpose of its engineering. More information is
available for Moon[ioagmoon] and Mars[ioagmars].
Position, Navigation and Timing (PNT) is not discussed in this memo.
Near Earth orbits, such as Low Earth Orbit (LEO), Medium Earth Orbit
(MEO), and Geosynchronous Earth Orbit (GEO) communications and
networking to and from Earth are out of scope for this memo.
However, given the relatively small distance to the Moon, there are
possibilities to use spacecrafts around Earth or at Lagrangian points
to communicate with Moon assets. In this context, these
possibilities are in scope.
1.2. Terminology
* Deep space: while the ITU definition[deepspacewikipedia] of deep
space is beyond 2 million km, in this document, the Moon and its
environs are included.
* Direct-with-Earth(DWE): communications from/to a spacecraft
directly to/from Earth, without the use of relays.
* Moon, Lunar: refers to Earth's Moon.
* Deep Space Network(DSN): NASA’s international array of giant radio
antennas that supports interplanetary spacecraft missions[DSN].
* LunaNet Service Providers (LNSP): Private sector services
providers on the Moon
1.3. Document and Discussion Locations
The source of this document is located at
https://github.com/marcblanchet/draft-tiptop-usecase. Comments or
changes are welcomed by filing a PR or an issue against that
repository.
Blanchet, et al. Expires 3 September 2025 [Page 3]
Internet-Draft IP in Deep Space March 2025
This subject should be discussed on the IETF tiptop working group
mailing list.
2. Characteristics
Compared to Internet on Earth, space communications and networking
have multiple challenges, such as:
* significant and variable delays.
* frequent and long interruptions of communications, often with no
alternate path. Because of orbital dynamics, spacecrafts may not
be reachable because they are on the other side of a celestial
body. However, their location and reachability can be generally
precalculated so that the communication windows can be planned
between the spacecrafts or between a spacecraft and a celestial
body such as Earth, Moon or Mars.
* lower bandwidth
* one-way links
* asymmetrical bandwidth
* limited computing resources
* limited energy supply
and many others. Without any change, a typical Internet application
will not work in this environment. However, the primary factors are
delays and disruptions, discussed in this memo.
This section describes the following cases: Moon, Mars, Lagrangian
points, cruising spacecraft and onboard spacecraft, starting with
some commonality between all cases.
2.1. Common to all Cases
Various CCSDS link-layer protocols, such as
Telecommand(TC)[CCSDS_TC], Telemetry (TM)[CCSDS_TM], Advanced
Orbiting Systems(AOS)[CCSDS_AOS], Proximity1(Prox1)[CCSDS_PROX1] are
used on the links between Earth, orbiters and surface assets. A
single unified link-layer, Unified Space Data Link Protocol
(USLP)[CCSDS_USLP], has been designed to functionaly replace the
previous ones. A generic encapsulation mechanism is defined by CCSDS
for the payloads of all these link layer protocols, including IP as
an encapulated
protocol[IPoverCCSDSSpaceLinks][SANAIPEHeaderRegistry]. IP packets
Blanchet, et al. Expires 3 September 2025 [Page 4]
Internet-Draft IP in Deep Space March 2025
can be transported over any CCSDS link layers.
Surface assets on celestial bodies, such as habitats, rovers,
stations and others may communicate between each other while on the
surface network using Earth terrestrial technologies such as IEEE 802
and 3GPP 5G-6G/NTN[ioagmoon][ioagmars] using IP, similar to Internet,
where links are always connected and there are no significant delays.
They may also communicate using a relay orbiter.
Multiple providers, such as the LNSPs for Moon, will provide various
services including communications and networking.
Orbiters acting as communications relays are already deployed or
planned for both Moon and Mars. A sufficient number of orbiters will
create a constellation which may provide full coverage of the
celestial body surface. From one surface asset to another surface
asset through these orbiters may use either CCSDS link-layers or
link-layers similar to LEO constellations on Earth.
Space missions are typically planned many years in advance and are
long-lived, spanning over many years or 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.
Space exploration is more than ever carried by multiple stakeholders.
A mixture of assets operated by government, commercial, and academic/
research organizations from multiple nations are deployed. They will
operate largely independently, but collaboration over time is
expected to meet shared science goals, joint exploration missions,
and mission cross-support needs.
While links can be noisy due to weak signals, interference, etc.,
generally packet delivery is error-free due to the strong coding
available within the link layer. Delivery is generally in-order.
Queuing in modems, gateways, and other systems may be significant in
comparison to typical terrestrial device queues.
2.2. Moon
There are currently very few orbiters around Moon but there are plans
to establish a constellation of them to be used as communication
relays. As few as 5 cooperating orbiters at the right orbits is
sufficient to provide full coverage[ioagmoon], and smaller sets of
orbiters can be targeted to provide full coverage of specific limited
regions such as the far side or the polar regions. Until full
coverage is accomplished, interruptions of communications are
Blanchet, et al. Expires 3 September 2025 [Page 5]
Internet-Draft IP in Deep Space March 2025
expected. Earth ground stations are able to cover directly assets on
the near side of Moon.
Different types of networking nodes are expected on the lunar
surface, with a wide range of capabilities, from those that have very
limited functionality (similar to IoT devices on Earth), up to more
highly-capable infrastructure hub nodes that provide access for other
surface users (e.g. in a habitat or lander), and in-between cases
such as crewed or uncrewed rovers that may have combinations of
direct-to-Earth, with proximity orbiters, or via local wireless LAN
or cellular capabilities.
For human / crewed operations, nearly continuous coverage and data
flows might be expected. However, for other types of network users
(such as science missions), only limited communication opportunities
may be available.
Some nodes (such as those supporting human missions) may have
multiple/redundant links available simultaneously, but this should
not be expected in general, and even then it is likely to be more for
failover use than for multipath network transport.
Data link operation is scheduled in advance through coordination
between the end-user mission operations centers and LNSPs. The time
windows for operation and data rates are well-known in advance
(typically days or more). Successful link operation generally
requires both directional pointing/tracking (with knowledge of
vehicle locations and motion) of antenna systems, as well as pre-
configuration of modem / signal processing and gateway systems that
require prior coordination on many parameters. Ad hoc or random
access may be available at some later point, but is likely to be rare
for at least proximity and direct-with-Earth links.
While interoperability and cross support are frequently expected,
there is no assumption in-general that different parties can simply
connect at the link layer or trade packets at the network layer
(either directly or through intermediaries). Network routing and
interconnection is likely to be closely coordinated and limited by
policies established jointly between cooperating organizations. It
is not likely to be directly like the Internet, with BGP, DNS, etc.
generally available to support interdomain operations.
One-way delay from Earth to Moon is around 1.3 seconds.
It is expected to have hundred Mbps radio links and Gbps optical
links between Earth and Moon[ioagmoon].
Blanchet, et al. Expires 3 September 2025 [Page 6]
Internet-Draft IP in Deep Space March 2025
2.3. Mars
There are currently some orbiters around Mars, of which 4 are
actively in use as relays, and 2 active rovers. Multiple missions
are planned[ioagmars] in the coming years. Communications are from
ground stations on Earth, such as the DSN, to Mars orbiters acting as
layer0-1 relays to surface assets such as rovers, and reverse. The
relays do not have notion of frames, and only forward bits at
different frequencies for each segment, a mechanism named "bag of
bits"[ioagmars]. These orbiters can do as "bent-pipe" when the two
segments are active, or by storing the bits as "store-and-forward"
until the next segment becomes available. Since the current set of
orbiters do not provide full coverage of Mars, the communication
windows are calculated and planned between Earth and each orbiter,
and between each orbiter and each surface asset. Currently, only one
rover can use a relay link at any given time. The MaROS
project[maros] sponsored by the Jet Propulsion Laboratory acts as a
broker to enable 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. MaROS
experience over years shows that the current bottleneck is not the
temporary storage of the relays but the bandwidth from Mars surface
assets to Mars orbiter relays. As demonstrated by a
study[marscommstudy] on Mars communication windows, the communication
windows seem to happen at a constant frequency, but the reality shows
that the timing is 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 calculated RTT
of the various combinations of orbiters and rovers varied from 30
minutes to 170 hours.
Surface assets are commanded directly from Earth but at a very low
rate. The traffic from the assets to Earth goes through relays.
It is expected that future constellations of Mars orbiters acting as
relays will also have optical inter-satellite links[ioagmars]. The
current orbiters were put in various orbits for the purpose of
science, and usually have a small number of short relay opportunities
per day. However, dedicated relay orbiters could be put at much
higher altitudes to provide much better coverage.
About every two years, a solar conjunction happens for a period of
around 2 weeks, where the Sun is between Earth and Mars, therefore
causing the interruption of communications between Earth and Mars.
Blanchet, et al. Expires 3 September 2025 [Page 7]
Internet-Draft IP in Deep Space March 2025
One-way delay from Earth to Mars is from 4 to 24 minutes, depending
on the actual relative distance between them.
It is envisioned that optical links between Earth and Mars may
deliver hundreds of Mbps[ioagmars].
2.4. Lagrangian Points
Sun-Earth and Earth-Moon Lagrangian points, such as Earth-Moon(EML)-
1,2,4,5 and Earth-Sun(ESL)-1,2, are being considered for
communication relays and therefore potential network forwarders.
2.5. Cruising Spacecraft
A spacecraft currently cruising towards its deep space destination is
reached by a point-to-point link from Earth using CCSDS link-layers.
2.6. Spacecraft Onboard
On-board spacecraft contain multiple computers typically linked with
Ethernet, sometimes Time-Triggered Ethernet[tte](TTE), with IP as the
networking layer.
3. Use Cases
Multiple countries are developing systems aimed for a sustained lunar
presence combining manned and robotic missions. 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.
Blanchet, et al. Expires 3 September 2025 [Page 8]
Internet-Draft IP in Deep Space March 2025
There are expected to be several different lunar network service
providers (LNSPs) offering different varieties of relay 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).
It is expected that surface assets will communicate with other
surface assets through Earth based technologies such as Wifi or 5-6G,
but also via a relay orbiter
Regarding applications, the following is an incomplete list:
* Telecommand: Commanding can take different forms, either
individual commands or batching commands together. Individual
commands sent to a mission/spacecraft from Earth are typically
small (may fit within a single packet in many cases), and should
typically be received reliably and in-order to be processed.
Commands with dependencies or other relations may be grouped
together for transmission and to help assure coherent execution
rather than sent individually. This can resemble small file
transfer, for instance. Commands may be time-sensitive, or have
an "expiration date" after which they are not useful to store/
carry in the network. Required data rates may typically be in
kbps and bursty.
* Telemetry: Spacecraft stream telemetry data (periodically measured
onboard status, metrics, etc.) to Earth for monitoring and other
purposes. Timely delivery is useful, but storage in the network
is fine, if needed. Required data rates may be approaching the
Mbps range, and often a constant/steady stream of data is
produced.
* On-demand/real-time media(audio, video, ...): when a active path
from the asset to Earth, the asset sends a media feed. The delay
is only the propagation delay.
* Delayed media: the asset sends the media, but it is expected that
there is no active path from the asset to Earth, so data may be
temporarily stored in the network.
Blanchet, et al. Expires 3 September 2025 [Page 9]
Internet-Draft IP in Deep Space March 2025
* Emergency and Search and Rescue (SAR) messaging: sent from an
asset to one or many other assets (e.g. via broadcast or
multicast) that support emergency operations. Since crew or
mission safety may be at risk, this traffic should be prioritized
over most other types of packets when encountering queuing or
storage within the network. Timely delivery is necessary, but it
should also be delivered reliably.
* Science data: Typically science data may take the form of large
bulk file transfers unicasted from a spacecraft to Earth. In many
cases, storage and large delays in delivery can be tolerated.
File transfer applications such as CFDP are typically used, that
might be configured to either operate unidirectionally or may
provide reliability through retransmissions, and require some at
least small amount of feedback. Some science applications may
also use messaging patterns to collaborate between different types
of instruments in order to draw attention to events (e.g. gamma
ray bursts, etc.) and bring different types of instruments to
bear. These messages may need to be quickly delivered and/or
multicasted.
* Messaging: Many different types of machine-to-machine messaging
need to be supported, including for uses such as (1) providing PNT
data/measurements to feed positioning, orbit determination, and
time transfer or clock calibration, (2) providing space weather
alerts, (3) providing advisory or other network information (e.g.
almanac data such as ephemeris data for relay and other network
elements, scheduled future contacts, or other service management
related messaging). Messages are generally small (though may vary
depending on type) and might be unicast, broadcast, or multicast.
In cases where they are advisory, for instance, they may not need
reliable transport, though often it will be important to provide
timely transmission.
* Network and Asset management: sending requests and getting answers
from assets about their overall status, status of their
components, energy levels, storage capacities, etc.
4. Requirements
4.1. Store-and-Forward
Until full coverage by orbiter constellations is achieved around a
celestial body, the orbiters and other assets that are facing
intermittent communications have to provide store-and-forward
capability. These can be implemented at - layer-1, like the current
Mars orbiters, where frames are not seen ("bag of bits"), at layer-2
doing frame storage or at layer-3 doing packet storage. Storage
Blanchet, et al. Expires 3 September 2025 [Page 10]
Internet-Draft IP in Deep Space March 2025
higher in the stack enables more versatile, agile and policy-based
routing. A key factor for designing the store and forward capability
of an orbiter is its storage capacity.
Surface assets that are facing intermittent communications also need
the store-and-forward capability.
Mechanisms should be defined to avoid as much as possible storage
full events on a relay. This may include some in-advance signaling
to the network about future full storage event, so that the network
and/or the source can throttle down or reroute packets to avoid that
event.
In the event of full storage, a policy should be determined on which
packets should be dropped, such as the last one in the queue, the
first one in the queue, ones based on policies related to packet or
transport fields like source or destination addresses, traffic
classes, flow ids, etc. , similar to queue management used in
terrestrial networks.
Even if calculations can be done based on known orbital dynamics,
events happen that result in missed communication windows. For
example, some communication windows were not used on Mars because a
rover may be still charging and therefore does not have enough energy
to perform communications. Random events can also happen because of
space weather. Therefore, while the window of comms can be
calculated and used, the system should be able to cope with random
long interruption events.
Proper guards should be designed to avoid denial-of-service attacks
by filling storage in the network.
4.2. Time
Timers are used in transport protocols, application protocols and
applications themselves for various purposes, such as detecting/
presuming packet loss or data lifetime. Timers should be therefore
adjusted and configured based on the expected travel time and RTT
from the source to destination. Given variations and possible
dynamic changes in the network that can cause much longer latency,
appropriate safeguards should be put for timer values.
Lifetime is also attached to some data, such as content, security
keys, certificates, tokens, session keys and naming records.
Similarly, the lifetime should be adjusted and configured based on
the characteristics of the applications and expected travel time and
RTT.
Blanchet, et al. Expires 3 September 2025 [Page 11]
Internet-Draft IP in Deep Space March 2025
Current Internet protocols and applications typically use UTC as
their time reference. There are currently work to define Lunar
Standard Time, also called Coordinated Lunar Time and Mars Standard
Time [lunartime]. Depending on the application and use case, it may
be necessary to adapt the protocol or the application to use another
time reference.
Given the latency and intermittence, various security issues may
arise, as not only lifetime of keys and certs, but also the delay to
react to security issues that may happen. It may be also the case
that some security features of protocols have been designed with very
short delays assumptions, that in space, may not apply.
4.3. Signaling and Exchanges
Given the large latency of space communications, multiple steps of
exchanges or handshakes may still work but are far from optimal and
may never converge. Therefore, applications and protocols should be
adapted to minimize the number of exchanges.
Similarly, applications, protocols or networking stack that depend on
signaling back to the source or to somewhere in the path may arrive
too late for any usefulness, because of the latency. Therefore, any
signaling should be carefully designed based on the expected latency.
4.4. Bandwidth
Given that space communications will always have much lower bandwidth
than what is possible in shorter distances such as on Earth,
optimization of the bandwidth usage is important. This can be
implemented at many levels in the networking stack, starting from
layer-2 to IP header compression to transport and application data
compression.
4.5. Addressing and Routing
To minimize routing and forwarding tables, optimal address
aggregation is preferred, and it starts with proper allocation of
addresses.
The network in deep space, not including the surface networks on
celestial bodies, will grow at a small pace, which does not warrant
complex routing schemes. However, over time, the network will become
sufficiently complex not only because of the number of forwarders but
also because of the intrinsic intermittent and delay communication
patterns, which may warrant more complex routing solutions and
orchestration.
Blanchet, et al. Expires 3 September 2025 [Page 12]
Internet-Draft IP in Deep Space March 2025
5. Security Considerations
TBD
6. IANA Considerations
There are no actions for IANA in this document.
7. References
7.1. Informative References
[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>.
[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>.
Blanchet, et al. Expires 3 September 2025 [Page 13]
Internet-Draft IP in Deep Space March 2025
[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>.
[ioagmoon] 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>.
[ioagmars] 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>.
[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/>.
[marscommstudy]
Blanchet, M., "Earth-Mars Communication Windows Usage
Study", October 2024,
<https://deepspaceip.github.io/meetings/ietf121/ietf121-
deepspaceip-mars-communications-study.pdf>.
[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/>.
Blanchet, et al. Expires 3 September 2025 [Page 14]
Internet-Draft IP in Deep Space March 2025
[deepspacewikipedia]
"Deep space exploration",
<https://en.wikipedia.org/wiki/Deep_space_exploration>.
[maros] Gladden, R., "Mars Relay Operations Service (MaROS): A
Present Service Preparing for the Future", May 2014.
[tte] Wikipedia, "TTEthernet",
<https://en.wikipedia.org/wiki/TTEthernet>.
[lunartime]
NASA, "NASA to Develop Lunar Time Standard for Exploration
Initiatives", September 2024,
<https://www.nasa.gov/general/nasa-to-develop-lunar-time-
standard-for-exploration-initiatives/#:~:text=The%20lunar%
20time%20will%20be,Coordinated%20Universal%20Time%20(UTC)>
.
Acknowledgements
This following people have provided valuable feedback and comments,
in no specific order: Roy Gladden.
Authors' Addresses
Marc Blanchet
Viagenie
Canada
Email: marc.blanchet@viagenie.ca
Wesley Eddy
MTI Systems
United States of America
Email: wes@mti-systems.com
Marshall Eubanks
Space Initiatives Inc
United States of America
Email: tme@space-initiatives.com
Blanchet, et al. Expires 3 September 2025 [Page 15]