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]