Re: [dtn] [EXTERNAL] Re: [EXT] Re: LTC timescale (Re: Question regarding RFC 9171 - How to incorporate "Coordinated Lunar Time")

["Rieber, Richard R (US 347R)" <[e-mail]>]

Hello all,

Thanks for a great thread! Let me summarize what I’ve heard:

  *   Any solution should be extensible to any planetary body and not just the moon (mentioned by Jorge).
     *   Note that the White House’s memorandum specifically says to develop a time system that is extensible to any body, but the impetus and first time system will be LTC.
  *   Any protocols we develop should abide by international standards and not a US Government mandate.
     *   For this, I 100% agree. Note that the memorandum specifically states that LTC should be developed within the current international standards framework. As such, I think that LTC (and other planetary time systems) will become a standard rather than a local US thing.
  *   DTN Time using UTC is OK for now. (I agree, and so does John Dowdell on ESA’s Moonlight mission, Jorge Amodio, and Scott Burleigh)
  *   Carsten has highlighted a draft CBOR standard<https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/> defining timescales/timesystems which could be used instead of the current version of DTN Time in BPv7.
     *   Carsten also said that we would need to add these new time systems to the registry of CBOR Timescales<https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#timescales>. (See also here<https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-12.html#section-7.2>.)
  *   Brian Sipos highlighted that multiple time systems on the network would create a burden on lower-level processing (and I agree)

With the thread summarized, I want to chime in a bit more. First off, I’m a systems engineer, so I’m always thinking about how things interact with each other. Lunar spacecraft internal clocks may operate exclusively within the LTC time system. For those spacecraft needing to communicate with BP, they would have to convert the current LTC to UTC to populate the DTN Time field. However, this time conversion is unnecessary if the communication network is exclusively lunar (think communications around the Artemis Base Camp). The only time we’d need to worry about time conversion is bundles that flow between planetary bodies. So Brian, your argument about creating lower-level processing burden may be true regardless.

Additionally, the operations could become problematic and confusion if UTC is used in the bundle header for data originating from a lunar spacecraft. Events are happening on the moon in the LTC time system, then are reported in data that is stamped with UTC. Operators could quickly be confused when trying to correlate lunar-based events using data stamped in UTC.

Does anyone think we should tweak the DTN Time field to utilize the CBOR Timescale/Timesystem standard Carsten mentioned? I think we should. If so, we need to have a thought session on how the functions for timer/duration/contact graphs/bundle status reports should be tweaked to support different time systems.

~Rich

From: Jorge Amodio <[e-mail]>
Date: Friday, April 12, 2024 at 08:55
To: [e-mail] <[e-mail]>
Cc: EXTERNAL-Sipos, Brian J (US 9300-Affiliate) <[e-mail]>, John Dowdell <[e-mail]>, Carsten Bormann <[e-mail]>, Rieber, Richard R (US 347R) <[e-mail]>, DTN WG <[e-mail]>, [e-mail] <[e-mail]>
Subject: [EXTERNAL] Re: [dtn] [EXT] Re: LTC timescale (Re: Question regarding RFC 9171 - How to incorporate "Coordinated Lunar Time")

100% Agreement.

PNT is a completely different challenge and not only will it require precision timing, we still need to have an international standard for a lunar coordinate system which is currently under discussion.

One small note, space exploration is not longer confined to NASA, Roscosmos, nowadays ESA, JAXA, ISRO, CNSA, etc, are catching up and moving at a fast pace, so even when NASA has a mandate and has a leadership position, the "Club" now has now many more members. For example LNIS is not a NASA product but a collaboration between many space agencies and now also the commercial sector, so the standards development process will need to be broader and inclusive.

There is some standards related work being discussed at other forums like LSIC, LOGIC, etc.

It will get more complicated but with more fun .., and paperwork :-)

Regards
Jorge


On Fri, Apr 12, 2024 at 10:41 AM <[e-mail]<mailto:[e-mail]>> wrote:
This sounds right to me.

A general solution to the problem of coordinating planetary timescales is going to be needed to support accurate spacecraft position, navigation, and timing considerations, which have got to be accurate to small fractions of seconds.

But for bundle protocol operations the requirement is less urgent.  "DTN time" is used as the basis for bundle identification (together with a counter, for use when multiple bundles are issued per second), for bundle expiration decisions, for reporting on the occurrence of bundle processing events (in optional bundle status reports), for starting and stopping bundle transmission and reception per published contact plans, for initiating scheduled network management directives, and potentially for other operational purposes.  None of these purposes require universal clock alignment at sub-second granularity.  It could be argued that clock inaccuracies on the order of several seconds would not seriously degrade the operation of the network.

The articulation and implementation of LTC is going to be vital in general for operating in planetary space over the coming decades, but for DTN specifically I think we are going to be okay with DTN time as currently defined.

Scott

-----Original Message-----
From: dtn <[e-mail]<mailto:[e-mail]>> On Behalf Of Sipos, Brian J.
Sent: Friday, April 12, 2024 5:57 AM
To: Jorge Amodio <[e-mail]<mailto:[e-mail]>>; John Dowdell <[e-mail]<mailto:[e-mail]>>
Cc: Carsten Bormann <[e-mail]<mailto:[e-mail]>>; Rieber, Richard R (US 347R) <richard.r.rieber=[e-mail]<mailto:[e-mail]>>; DTN WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [dtn] [EXT] Re: LTC timescale (Re: Question regarding RFC 9171 - How to incorporate "Coordinated Lunar Time")

Richard,
While there are mechanisms to use alternative time scales in CBOR in ways that would be backward (but not forward) compatible, I agree with Jorge's rationale that "a network" and a networking layer should use a consistent time scale. This is similar to how early internet protocols (e.g. SNMP and pre-1.0 HTTP) allowed use of alternative time zones but modern versions disallow all but UTC-representing timestamps (e.g.  HTTP's Date format [1]) because it adds unnecessary burden onto the lower-level processing that should be a higher-level concern.

[1] https://datatracker.ietf.org/doc/html/rfc9110#section-5.6.7<https://urldefense.us/v3/__https:/datatracker.ietf.org/doc/html/rfc9110*section-5.6.7__;Iw!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqCXrlGEmw$>

> -----Original Message-----
> From: dtn <[e-mail]<mailto:[e-mail]>> On Behalf Of Jorge Amodio
> Sent: Friday, April 12, 2024 6:25 AM
> To: John Dowdell <[e-mail]<mailto:[e-mail]>>
> Cc: Carsten Bormann <[e-mail]<mailto:[e-mail]>>; Rieber, Richard R (US 347R)
> <richard.r.rieber=[e-mail]<mailto:[e-mail]>>; DTN WG
> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Subject: [EXT] Re: [dtn] LTC timescale (Re: Question regarding RFC
> 9171 - How to incorporate "Coordinated Lunar Time")
>
> APL external email warning: Verify sender [e-mail]<mailto:[e-mail]>
> before clicking links or attachments
>
>
> I believe that for the time being until an international standard not
> a government mandate is fully developed, implemented, tested and
> accepted we will have to stick with UTC.
>
> Also, location based time systems should in the long term be defined
> on a planetary basis, not only for the Moon, which brings again the
> question of developing an international standard that goes beyond the cislunar space.
>
> But still we will always need a common system of reference for the
> whole interplanetary network, and so far for now UTC is the most reasonable answer.
>
> On a planetary basis such as the Moon, for those applications that
> require a local time system of reference we will have to figure how we
> convert from/to UTC, but at the *application* level, IMHO for comms
> and networking we should stick with UTC.
>
> My .02
>
> Regards
> -Jorge
>
> > On Apr 12, 2024, at 04:42, John Dowdell
> > <[e-mail]<mailto:[e-mail]>>
> wrote:
> >
> > Hi Carsten and Richard
> >
> > As a comms engineer working on ESA Moonlight, I’m also interested in
> resolving this. Given timescales, I guess we’ll end up going with UTC
> even on the moon, but in the longer term there is a need for a standards-based resolution.
> >
> > - John
> >
> >> On 12 Apr 2024, at 06:58, Carsten Bormann <[e-mail]<mailto:[e-mail]>> wrote:
> >>
> >> Hi Richard,
> >>
> >> I read your message with interest.
> >>
> >> draft-ietf-cbor-time-tag [1], an approved specification that is
> >> currently in the
> RFC editor queue for publication as an RFC, defines a versatile
> representation of timestamps in CBOR.
> >> While DTN BP does not directly use this extended time tag
> >> currently, I would
> imagine that any evolution of its time representations would
> coordinate to maintain interoperability with the extended time tag.
> >>
> >> [1]: https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/<https://urldefense.us/v3/__https:/datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqCT4VT9LA$>
> >>
> >> The extended time tag defines a way to indicate the timescale in use [2].
> >> This is based on a IANA registry [3] that is currently just listing
> >> UTC and TAI
> [4].
> >>
> >> [2]: https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-<https://urldefense.us/v3/__https:/www.ietf.org/archive/id/draft-ietf-cbor-time-tag-__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqAMUA5dwg$>
> 12.html#section-3.4
> >> [3]: https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-<https://urldefense.us/v3/__https:/www.ietf.org/archive/id/draft-ietf-cbor-time-tag-__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqAMUA5dwg$>
> 12.html#section-7.2
> >> [4]: https://www.iana.org/assignments/cbor-tags/cbor-<https://urldefense.us/v3/__https:/www.iana.org/assignments/cbor-tags/cbor-__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqD8WYrsyw$>
> tags.xhtml#timescales
> >>
> >> I would expect that LTC should be added to this registry, and that
> >> a short
> specification could provide information about how this is to be used
> and how this timescale interoperates with the existing ones.
> >>
> >> Grüße, Carsten
> >>
> >>
> >>>> On 12. Apr 2024, at 06:46, Rieber, Richard R (US 347R)
> <richard.r.rieber=[e-mail]<mailto:[e-mail]>> wrote:
> >>>
> >>> Hello DTN leads,
> >>> I am a DTN advocate at JPL and working as the Mission Operations
> >>> Systems
> Engineer on the CADRE mission. This mission is slated to send 3
> shoe-box sized rovers to the moon on Intuitive Machine’s IM-3 lander
> in Q1 2025. Needless to say, I’m paying attention to all things moon-related and DTN-related.
> >>> There are two things I want to highlight:
> >>>   • NASA’s SCaN office has released the LunaNet Interoperability
> specification, which mandates the use of DTN for communications in
> Feb. 2023, and
> >>>   • On 4/2/2024, the White House has tasked NASA with developing a
> “Coordinated Lunar Time”, amongst other planetary time systems.
> >>> BP’s DTN Time (see 4.2.6 of RFC-9171) is defined as milliseconds
> >>> since 2000-
> 001T00:00:00 UTC. How should this change if there is a lunar time system?
> >>> I would imagine that Lunar spacecraft use LTC for their internal
> >>> clocks. How
> do they interpret bundles sent from Earth that are stamped with UTC?
> Must they internally convert the current LTC to UTC to compare to that
> bundle’s DTN Time? Similarly, what time system is used in the DTN Time
> field for bundles created by a lunar spacecraft?
> >>> Now imagine the Artemis Gateway that may act as a communication
> >>> relay
> node. Some bundles would be from Earth and tagged with UTC. Some
> bundles would be from the moon and may be tagged in LTC. This gets quite confusing.
> >>> Needless to say, I think the DTN community needs to have a
> >>> conversation
> about if and how the protocol must be modified to support different
> time systems across the solar system. What’s the venue for having that conversation?
> How would one go about proposing a protocol modification?
> >>> Thanks in advance,
> >>> ~Rich
> >>>  Richard Rieber
> >>> NASA/JPL
> >>> Robotics Systems Engineer
> >>> 347R – Robotics Operations and V&V [e-mail]<mailto:[e-mail]>
> >>> [phone]
> >>> _______________________________________________
> >>> dtn mailing list
> >>> [e-mail]<mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/dtn<https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqC7SlCQFw$>
> >>
> >>
> >> _______________________________________________
> >> dtn mailing list
> >> [e-mail]<mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/dtn<https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqC7SlCQFw$>
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/dtn<https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqC7SlCQFw$>
>
> _______________________________________________
> dtn mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dtn<https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqC7SlCQFw$>