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

[[e-mail]]

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]> On Behalf Of Sipos, Brian J.
Sent: Friday, April 12, 2024 5:57 AM
To: Jorge Amodio <[e-mail]>; John Dowdell <[e-mail]>
Cc: Carsten Bormann <[e-mail]>; Rieber, Richard R (US 347R) <richard.r.rieber=[e-mail]>; DTN WG <[e-mail]>; [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

> -----Original Message-----
> From: dtn <[e-mail]> On Behalf Of Jorge Amodio
> Sent: Friday, April 12, 2024 6:25 AM
> To: John Dowdell <[e-mail]>
> Cc: Carsten Bormann <[e-mail]>; Rieber, Richard R (US 347R) 
> <richard.r.rieber=[e-mail]>; DTN WG 
> <[e-mail]>; [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] 
> 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]>
> 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]> 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/
> >>
> >> 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-
> 12.html#section-3.4
> >> [3]: https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-
> 12.html#section-7.2
> >> [4]: https://www.iana.org/assignments/cbor-tags/cbor-
> 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]> 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]
> >>> [phone]
> >>> _______________________________________________
> >>> dtn mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/dtn
> >>
> >>
> >> _______________________________________________
> >> dtn mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dtn
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn