IP in Deep Space: Key Characteristics, Use Cases and Requirements
draft-many-tiptop-usecase-00

Internet Engineering Task Force                              M. Blanchet
Internet-Draft                                                  Viagenie
Intended status: Informational                                   W. Eddy
Expires: 25 August 2025                                      MTI Systems
                                                              M. Eubanks
                                                   Space Initiatives Inc
                                                        21 February 2025

   IP in Deep Space: Key Characteristics, Use Cases and Requirements
                      draft-many-tiptop-usecase-00

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 25 August 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 25 August 2025                 [Page 1]
Internet-Draft              IP in Deep Space               February 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  . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Store-and-Forward . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Time  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.3.  Signaling and Exchanges . . . . . . . . . . . . . . . . .  11
     4.4.  Bandwidth . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.5.  Addressing and Routing  . . . . . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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 25 August 2025                 [Page 2]
Internet-Draft              IP in Deep Space               February 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.

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.

   This subject should be discussed on the IETF tiptop working group
   mailing list.

Blanchet, et al.         Expires 25 August 2025                 [Page 3]
Internet-Draft              IP in Deep Space               February 2025

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.  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.

Blanchet, et al.         Expires 25 August 2025                 [Page 4]
Internet-Draft              IP in Deep Space               February 2025

   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 LunaNet Service Providers (LNSP) 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 will be 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 are 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
   expected.  Earth ground stations are able to cover directly assets on

Blanchet, et al.         Expires 25 August 2025                 [Page 5]
Internet-Draft              IP in Deep Space               February 2025

   the near side of Moon.

   A variety of 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 25 August 2025                 [Page 6]
Internet-Draft              IP in Deep Space               February 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 Deep Space Network(DSN)[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.  MqROS 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 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 25 August 2025                 [Page 7]
Internet-Draft              IP in Deep Space               February 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 using CCSDS link-layers as discussed
   before.

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, 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.

Blanchet, et al.         Expires 25 August 2025                 [Page 8]
Internet-Draft              IP in Deep Space               February 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: Send a command to an asset

   *  Telemetry: Receive data, often science and sensor data, from an
      asset in an asynchronous way, where it is expected that the data
      may be temporarily stored in the network

   *  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.

   *  Emergency and Search and Resue(SAR) messaging: sent from an asset
      to one or many emergency operations.

   *  Network and Asset management: sending requests and getting answer
      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
   higher in the stack enables more versatile and agile routing.  A key
   factor for designing the store and forward capability of an orbiter
   is its storage capacity.

Blanchet, et al.         Expires 25 August 2025                 [Page 9]
Internet-Draft              IP in Deep Space               February 2025

   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 25 August 2025                [Page 10]
Internet-Draft              IP in Deep Space               February 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 25 August 2025                [Page 11]
Internet-Draft              IP in Deep Space               February 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 25 August 2025                [Page 12]
Internet-Draft              IP in Deep Space               February 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 25 August 2025                [Page 13]
Internet-Draft              IP in Deep Space               February 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 25 August 2025                [Page 14]