Note reply from Eddy Wesley (NASA) below. He sees no real DTN requirements for TICTOC except that TICTOC allow for one-way time transfers (no ACK needed)...
Sincerely, Malcolm ******************************************************** Malcolm J Airst, The MITRE Corporation, 49185 Transmitter Rd., San Diego, CA 92152-7335 (619) 758-7822 (w) (619) 318-3837 (c) (619) 222-2260 (f) ******************************************************** -----Original Message----- From: Eddy, Wesley M. (GRC-RCN0)[VZ] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2008 10:30 AM To: Airst, Malcolm J.; [EMAIL PROTECTED] Subject: RE: [dtn-interest] TICTOC Timing Requirements >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On >Behalf Of Airst, Malcolm J. >Sent: Thursday, November 20, 2008 3:26 PM >To: [EMAIL PROTECTED] >Subject: [dtn-interest] TICTOC Timing Requirements > >Following up on my request this morning: Please send me any >DTN timing information and I'll be glad to send to the TICTOC >List and convey any comments. > After reading the latest TICTOC requirements draft, I don't think there should be any requirement on TICTOC for supporting DTN time synchronization. The TICTOC requirements are broken down by the "application" driving them, and if you considered synchronizing DTN bundle agents to be one of those applications, then the requirements would be orders of magnitude easier than for the other applications like cellular towers. The cellular backhaul requirements have things like a time accuracy on the order of microseconds, and frequency stablity in a few dozen ppb, both of which vastly exceed what bundle agents need. The only unique aspect of DTN that influences the capability to use TICTOC is that unidirectional time-transfer should be possible (not requiring real-time acknowledgements, or any feedback channel at all). It seems like this will be the case for some of the already-identified TICTOC applications like Time-of-Day, "legal time", and metrology, where a master clock signal is distributed out to essentially slave nodes. The TICTOC requirements don't seem to exactly say that unidirectional time-transfer needs to be supported, but as multicast is a natural fit given a single source and dozens/hundreds of sinks, it seems like it will develop to permit unidirectional use on its own. A DTN has 2 needs for timing signals: 1) A bundle agent can have start times or periodicity associated with some of its contacts with other bundle agents. In order for a system to do things like turn radios on, point antennas, etc., it will need an accurate sense of time. If these activities occur outside the bundle agent, some means of synchronizing the bundle agent's actions with the rest of the system is needed. If the bundle agent runs within the same computer that performs these other actions, then the system clock itself is sufficient. In the worst case, the bundle agent will likely still be part of an integrated unit with the rest of the system that controls antennas, amplifiers, etc. and can use some local time distribution means to keep in sync onboard a spacecraft or other deployment platform. However, the bundle agent on the other end of the contact may also need to have its communications equipment configured at the same time in order for the contact to start right away. Any skew in system times can cut into the usable contact time. But since, by definition, the bundle agents aren't in contact before the scheduled contact time, there's not much hope of something like TICTOC keeping them in sync because it can't create comm links where none exist :). Once the links are up, time-transfer could be used to correct for any skew and help future contacts, but some damage may have already been done to the current contact. For this, the only requirement on using TICTOC would be that it allow for unidirectional time-transfer, not relying on acknowledgements. How time-transfer signals are treated is a thornier operational problem for DTNs, as we cannot always assume a simple master-slave relationship where one side of a contact always delivers clock and the other always accepts it. But this is mostly a policy issue in each particular case of DTN deployment. 2) When a bundle agent creates a bundle, it adds a "creation timestamp" to the bundle, as well as a "lifetime" after which the bundle is considered to be expired, and discarded. These fields are checked by intermediate and destination bundle agents. Some potential issues that can come from clock skew involve: - "bundles from the future" where a sender's clock gets ahead of another bundle agent on the path's and so the creation timestamp appears to be in the future. Some systems may choose to discard these as invalid. - "bundles thrown out too soon" where a sender's clock is too far behind another bundle agent on the path's relative to the expiration lifetime. In this case, bundles can be discarded before the sender intended them to be. This can affect applications that set a short lifetime such as dtnping, VoBP/VoDTN (Voice over Bundle Protocol / DTN), etc. The correct way to deal with this is by changing the semantics of the creation timestamp and lifetime fields in the bundle protocol (I believe Joe Ishac described this some time ago), rather than levy any requirement on TICTOC which would be difficult to define or achieve given the intermittently- connected, spatially-dispersed, and possibly mixed ownership and control of nodes in a "typical DTN". _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
