Subject: [nfsv4] Global Namespace - LDAP Proposal for Location Resolution

From: Manuel Pereira <[email-masked]>
Date: Fri, 22 Apr 2005 17:19:05 -0700

We are interested in comments and/or questions in response to our last post
regarding global namespace and a standard approach to location
resolution.[1]  In that post, we described a three-tier naming architecture
and focused on a standard location resolution scheme to offer a mapping
repository for logical to physical resolution.

This approach does not have to be complicated and should strive to minimize
operational dependencies.  The type of repository required for this
function must be capable of efficiently maintaining large flat indices of
strings that map to one or more records, which may contain more than one
field.  Access to the repository must be light-weight with satisfactory
performance.  An important goal in choosing a repository access protocol is
that it be a well-established standard.  The repository and access protocol
to the repository must meet performance, scalability, security, and
efficiency criteria for any proposed resolution scheme to be usefully
practical to NFSv4.

We believe that the repository and associated access protocol meet the said
criteria.  We also believe that the formation of a standard approach to
location resolution in NFSv4 and the selection of a specific repository
technology are separate decisions.

We consider one potential candidate for such a repository access protocol
is the Lightweight Directory Access Protocol (LDAP).  LDAP is perhaps the
most prominent directory service available today, and therefore presents a
reasonable candidate to consider with regard to an access protocol for a
logical-to-physical mapping repository.  Using existing LDAP deployment in
enterprises and organizations can help reduce the management overhead of
maintaining the global namespace and help consolidate I/T infrastructure.
LDAP defines a communication protocol for accessing and searching a
database of entries annotated with attributes.  Accordingly, LDAP does not
define a directory service but rather the transport and format of messages
used by clients to access data in a repository.  These messages deal with
repository entries, whose structure and relationships are described by a
schema.  An LDAP repository may be defined as a specialized database
serving relatively static information that is optimized for high volume
read operations.  LDAP uses a simplified and optimized access protocol that
can be used in thin and relatively simple applications.

There are a number of LDAP characteristics that fit nicely with the
essential requirements of a namespace resolution scheme.  First, data
stored in the global namespace should be relatively static under normal
circumstances.  Second, a thin and optimized client access protocol is
clearly desirable.  Third, LDAP implementations can hold over a billion
objects on a single server demonstrating considerable scalability even
within a single server.  Fourthly, LDAP describes a “referral” feature
which easily enables integration of multiple distributed servers, enabling
delegation and wide-area scalability, which is very important to a global
namespace resolution scheme.  Lastly, LDAP has been used in enterprise IT
environments for important business and infrastructure data, how LDAP's
security model is mapped/integrated with the rest of an enterprise’s
security domains can be a guideline of NFSv4's potential use of LDAP.
Other features demonstrated by LDAP, which appeal to the resolution
function of the global namespace, include: distributed replication
mechanisms, extensibility, and performance.

Considering our comparison and consideration of LDAP as a potential
candidate for an NFSv4 namespace repository access protocol, are we missing
anything?

Regards,
Manuel Pereira
IBM Almaden Research Center
408-927-1935 [T/L 457]

[1] http://www1.ietf.org/mail-archive/web/nfsv4/current/msg01653.html

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 28 Apr 2005 16:54:28 -0400

It's been registered in a way that made perfect sense at the time
but doesn't really allow for v4.  I suppose we would need "nfs4"
which says use the highest minor version of v4 you support and
go down from there.

One interesting issue is that RFC2224 starts at the "public file 
handle".  V4 has a specific op to get the public file handle but 
for the  purposes being discussed here I would think we would 
really want the root fh.

Does anybody implement a PUTPUBFH that is different from PUTROOTFH?

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Tuesday, April 26, 2005 7:36 PM
To: Noveck, Dave
Cc: Manuel Pereira; [email-masked]
Subject: Re: [nfsv4] Global Namespace - LDAP Proposal for Location
Resolution

On Tue, Noveck, Dave wrote:
...
> 
> > Finally, we propose a fully qualified URL string serve as the
representation of 
> > a physical address. The URL syntax must comply with RFC 1738, being
in the form: 
> > <file system protocol>://<hostname>[:<port>]/<path to data> (where
port is optional). 
> 
> <file system protocol> is worrisome in that nfsv2, nfsv3, nfsv4.0,
nfsv4.1 are 
> all different protocols, even though I would imagine that we would not
want a 
> fileset to have different locations for different nfs protocols.
RFC1738 describes 
> the first part of a the URL as a "scheme" which governs the
interpretation of what 
> follows.  There is no scheme definition for "nfs" in the document but
"nfs" is listed 
> in section 4 as something for which a scheme has been discussed and
that IANA should 
> make this reserved.  There is a registration process described in
section 4.  Has 
> "nfs" been registered?

Yes, "nfs" has been registered.  See:
http://www.iana.org/assignments/uri-schemes
and more specifically: http://www.ietf.org/rfc/rfc2224.txt

Spencer