AFSVol Tag-Length-Value Remote Procedure Call Extensions
draft-tkeiser-afs3-volser-tlv-03
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Authors | Thomas Keiser , Steven Jenkins | ||
| Last updated | 2010-08-04 (Latest revision 2010-06-15) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
AFS-3 is a distributed file system based upon prototypes developed at Carnegie Mellon University during the 1980s. AFS-3 heavily leverages Remote Procedure Calls (RPCs) as the foundation for its distributed architecture. In 2003, new RPCs were introduced into AFS-3 that provide for capability introspection between file servers and cache managers. This memo introduces equivalent functionality to the volume server RPC interface, thus making the volume management interface more extensible. Furthermore, this memo extends the volume management interface to support getting and setting of AFS volume attributes via an extensible Tag-Length-Value (TLV) encoding, which is based upon XDR discriminated unions. TLV-based get and set RPCs are specified, along with a tag enumeration RPC. The TLV encoding side-steps the typical XDR union decode problem, whereby failure to decode a union leg causes the entire RPC payload decode to fail, by mandating an XDR opaque default leg for the union, along with a standard mechanism for encoding new leg types inside the XDR opaque blob. Finally, tags are allocated for existing volume and transaction metadata, and implementation-private tags are allocated for metadata related to the OpenAFS Demand Attach File Server and RxOSD protocol. 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.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)