N/A A. Deason Internet-Draft Sine Nomine Intended status: Informational March 7, 2011 Expires: September 8, 2011 Base Types for Time in AFS-3 draft-deason-afs3-type-time-00 Abstract This document defines two types to be used in future AFS-3 Rx Remote Procedure Calls (RPCs) to represent time. Current AFS-3 RPCs represent time as 32-bit integers representing seconds. This is insufficient in both granularity and range, so new types to represent time are defined in this document to overcome these limitations. Internet Draft Comments Comments regarding this draft are solicited. Please include the AFS-3 protocol standardization mailing list (afs3-standardization@openafs.org) as a recipient of any comments. 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 http://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 September 8, 2011. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of Deason Expires September 8, 2011 [Page 1] Internet-Draft AFS-3 Base Time Types March 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. AFSAbsTime . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. AFSRelTime . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Deason Expires September 8, 2011 [Page 2] Internet-Draft AFS-3 Base Time Types March 2011 1. Introduction All extant AFS-3 RPCs represent time as a 32-bit integer, as encoded by XDR in [RFC4506], which represents a number of seconds. For RPCs that specify an absolute time, this is the number of seconds that have passed since since midnight or 0 hour January 1, 1970 Coordinated Universal Time (UTC), not counting leap seconds. These time structures will be unusable after January 2038, and are already insufficient to represent time with more granularity than one second. This limited granularity creates inefficiencies in various parts of the AFS-3 protocol when it must be determined in what order two events have occurred (for example, whether or not a file was changed since the last time a volume has been backed up). When those two events have occurred during the same second, implementations must take a conservative assumption about which event occurred first, often resulting in unnecessary duplication or retransmission of data. In addition, metadata can be lost when files are copied to AFS from other filesystems that store file modification times with finer granularity than one second. This document defines a new type, AFSAbsTime, to be used in AFS-3 RPCs in the future. This type aims to solve these problems, as it supports a much wider range of dates at a much finer granularity. Another type, AFSRelTime, is defined to represent times relative to some other event, which provides for greater granularity over the existing representations via 32-bit integers. Both of these new types also provide standard type identifiers to be used when specifying relative or absolute time in AFS-3 RPC arguments and structures. Currently, both of these are just specified as "afs_int32" types in the XDR language definitions, which can make it ambiguous whether or not a field is an absolute time, relative time, or something else completely. Using the standard types AFSAbsTime and AFSRelTime will make this unambiguous. 2. Data Types This document defines two new data types: AFSAbsTime and AFSRelTime. Both of these are encoded on the wire using the XDR standard described in [RFC4506], and are described using the XDR language specification therein. 2.1. AFSAbsTime The new AFSAbsTime type is represented as an XDR-encoded structure containing a 64-bit unsigned integer as the timestamp, and an Deason Expires September 8, 2011 [Page 3] Internet-Draft AFS-3 Base Time Types March 2011 unsigned 32-bit integer representing the resolution. It is defined as thus in XDR: struct AFSAbsTime { unsigned hyper timestamp; unsigned int resolution; }; The AFSAbsTime structure represents the amount of time that has passed since midnight or 0 hour January 1, 1601 Coordinated Universal Time (UTC). The value of the timestamp field represents this amount of time in increments of 100 nanoseconds (ns). This precision and starting date is equivalent to the Microsoft Windows FILETIME structure. The value of the resolution field represents the resolution of the time source from which the timestamp was obtained. The presence of this field is important when calculating the order in which two events occurred relative to each other. If a timestamp is obtained from a time source that only has 1-second granularity, the event may have occurred anywhere in that second, whereas if it was obtained from a source with 100-ns granularity, it is known that it occurred before an event that occurred 0.5 seconds later. The value of the resolution field is the smallest amount of time representable by that time source, in increments of 100 ns. If the value of the timestamp field is X, and the value of the resolution is Y, the AFSAbsTime structure describes an event that occurs at or after time X, but before time X+Y. For example, to represent the time 60 seconds after midnight on January 1, 1601, the value of the timestamp field would be 600000000 (600 million). If the time source this was obtained from only has 1-second granularity, the resolution field would have the value 10000000 (10 million). In effect, the AFSAbsTime structure then represents an event that happened at or after 60 seconds after midnight on January 1, 1601, but happened before 61 seconds after midnight on January 1, 1601. This structure can represent any time from January 1, 1601 up to the year 30282 with 100-ns granularity. 2.2. AFSRelTime The new AFSRelTime type has nearly the same representation on the wire as AFSAbsTime in Section 2.1: Deason Expires September 8, 2011 [Page 4] Internet-Draft AFS-3 Base Time Types March 2011 struct AFSRelTime { hyper timestamp; unsigned int resolution; }; The AFSRelTime structure represents the amount of time that has passed since some other event. The event to which this time is relative is unspecified, and can be anything; it must be specified by the RPC or structure that defines a field of the AFSRelTime type. The value of the timestamp field represents this amount of time in increments of 100 ns. Values greater than 0 represent dates that occur after the relative event, and values less than 0 represent dates that occur before the relative event. The meaning and value of the resolution field is the same as that of the resolution field in AFSAbsTime specified in Section 2.1. For example, to represent the time 5 seconds before some other event, the value of the timestamp field would be -50000000 (negative 50 million). If the time source has 1-second granularity, the resolution field would have the value 10000000 (10 million). In effect, the AFSRelTime structure then represents an event that happens at or after 5 seconds before some other event X, but before 4 seconds before the event X. 3. Security Considerations This memo raises no security issues. 4. IANA Considerations This document makes no request of the IANA. 5. Acknowledgements The author thanks Simon Wilkinson And Jeffrey Altman for some background text and for bringing up the question of varying time resolution, and Tom Keiser and David Boyes for input on the problem of time resolution. 6. Informative References [RFC4506] Eisler, M., "XDR: External Data Representation Standard", Deason Expires September 8, 2011 [Page 5] Internet-Draft AFS-3 Base Time Types March 2011 STD 67, RFC 4506, May 2006. Author's Address Andrew Deason Sine Nomine Associates 43596 Blacksmith Square Ashburn, Virginia 20147-4606 USA Phone: +1 703 723 6673 Email: adeason@sinenomine.net Deason Expires September 8, 2011 [Page 6]