RE: iSCSI Naming and Discovery

["Douglas Otis" <dotis@sanlight.net>]

David,

> Douglas Otis wrote:
> > > 2) Naming once a connection is established is how to
> > > name and access the subcomponents underneath the IP address port
> > > number pair. I can see two approaches to this, the first is to
> > > keep the information local to the target and it is fetched
> > > in response to some SCSI command (e.g. a mode page or inquiry)
> > > or to use an external repository to store the information.  In
> > > the latter case there needs to be a mechanism to keep the local
> > > mapping and repository in sync, however in the former case you still
> > > need to find the IP/port pair (see next section) which involves
> > > syncronization.
> >
> > A naming service to get to a target can not be at the target.
> In effect you
> > have violated your item 1) statement.  Setting up an IP:Port
> dynamically at
> > the behest of the client still needs authorization unless anything goes.
> > For that, you have already added a SCSI name server, a
> tunneling protocol,
> > and now an authentication server needed to continue with data
> processing on
> > other connections.  Unless you can ensure information is
> completed ahead of
> > the connection and not during the connection, a substantial portion of
> > Portal bandwidth will be consumed doing all the work that
> should have been
> > done during Authentication.  As the Authentication server is already a
> > powerful database, it makes no sense to wait until the
> connection starts to
> > then work out what goes where.
>
> I actually proposed two possible ways but did not advocate either. With
> a completely external repository (the second suggestion) there is no
> violation of 1). The first suggestion does embed some naming knowledge
> in the wire protocol, it violates 1) but only so far as the initiator
> has
> already found the IP/port needed and it is simply determining the
> mapping
> of the LU/WWN to LUN nothing else. I am not advocating this but simply
> presenting it as an alternative.  I also agree that nothing I suggest
> changes the authentication necessary, if an external repository is used
> then you should have all the information needed to access the LU.
> If the alternate proposal to allow the target to resolve the final
> mapping does not change the authentication. Once the initiator is
> authenticated the target can only map or present the LUNs that are
> authorized. It is a tradeoff between managing the complexity locally
> versus globally.  I personally lean towards global as I have seen the
> lack of a global namespace hurt NFS compared to AFS, but I do see the
> ease of administation in simple configurations by keeping it local.

You seem to envision some target and lun will be visible without any prior
knowledge of targets and luns.  I assume you see name services are provided
as some type of special SCSI device.  I see this as a violation of article
1.  If you have gone to the well to get the names, verification numbers, as
well as, authentication, it need not be from the SCSI portal.  There has
already been extensive work at providing interfaces to LDAP database
servers.  You will have a far easier time finding tools to setup the names
and numbers required as well as to securely retrieve this information.

The best part of this standardized method of obtaining this information, it
could be done from any point in the world using the interface of your
choice.  I guarantee a new SCSI device to find SCSI devices will not be
understood for many years.  The need for bootstrapping opens the door for
including other desired information.  Dynamic Host Configuration Protocol is
the first step, Lightweight Directory Access Protocol should be the second.
With these very powerful tools, all of the overhead needed to communicate
with SCSI should be taken off of the table at that point in time.  That
would imply an intimate knowledge of SCSI is placed within this database.
If you look at AFS, it is a dog because of the high levels of verifications
that must be done real-time within this protocol.  Because of latency
performance expected from SCSI, any means to expedite operation should be
employed.

SCSI space should be just that, SCSI space.  Either a SCSI device or SCSI
Portal could provide access to third-party devices using private
configuration.  Connection to a device or Portal should not open the door to
yet another authentication.  Once a permission map is establish prior to
connection, it would not provide protection if the third-party address
changed via configuration from the client.  This authentication MUST not be
done real-time within the operation of the SCSI transport beyond receiving
and sending the initial round of cookies that should have been pre-baked at
the time of authentication.

> > > DNS is commonly used for the name to IP mapping function so it
> > > might be used for all or part of the resolution, however the name
> > > is likely to address lower level constructs which LDAP is much
> > > better suited.  Whether it is one name service or a two in combination
> > > I don't know.  But the boot issue is a false issue.  If we agree
> > > that 1) above is true, then either placing the resolution of
> > > the service address to IP/port pair into NVRAM or use a boot
> > > service to return it makes it a non-issue.  No external nameservice
> > > is needed to establish an initial connection to storage on boot.
> > > As examples, most x86 BIOS allow you to specifiy C: or D: as the
> > > boot devices, likewise OpenBoot stores the boot device as a string
> > > in NVRAM.
> >
> > You will also see a network boot option.
>
> I do not understand this claim.  If I store in NVRAM all of the
> information
> that would otherwise get resolved by a network nameservice I need no
> external network boot option. You can decrease the amount of information
> stored in NVRAM by adding software to the PROM to fetch the information
> from the network.  As an example, booting Solaris diskless on ia32 can
> be accomplished using either PXE to get everything from the network or
> via a floppy (aka a form of NVRAM) using no network protocols. It is
> simply a tradeoff of space versus software.

The effort to TFTP in a boot sector involves only a few dozen instructions.
I find it difficult to imagine an IT manager wants to walk around to each
machine to setup a NVRAM.  DHCP does not need any settings but rather takes
advantage of the burned-in MAC address and assisted broadcasts.  There could
be a specially named drive that associates with the text string of the
machine's MAC address.  It could be something like NETSCSIBOOT:XXXXXXXXXXXX.
With this convention, all machines drive's boot image could be uniquely
defined.  Unique to any machine anywhere on the LAN.

> > > So I see the WG needed to resolve two independant issues, the first
> > > is how to name a sub-unit at login, the second is how to define
> > > the service level name that resolves into an IP/port and what the
> > > resolver is.  I think a URL is overkill for the former but might
> > > be appropiate for the latter.
> > >
> > > For third party transfers, we should just consider the target to
> > > become the initiator and it passes either the resolved address
> > > from 3) or the unresolved service name.
> >
> > To resolve an address, you are once again violating your
> statement 1).  You
> > never know when a third-party command is sent.  To say this is
> done early in
> > the exchange overlooks other exchanges already taking place as
> well as the
> > number of servers required to keep this process going.  You do
> not want the
> > client to interact with other servers but then you insist that the SCSI
> > Portal then interact with tunnels, SCSI name servers, and authentication
> > servers in a highly iterative basis real-time.  All this while parsing
> > packets, looking for names, logins, and tunneling specifications while
> > building maps and deciding on which address space.
>
> Third party transfers are very special and I excluded them from my 1)
> above.
> You have to communicate from the current initiator to the target a new
> target for it to communicate to it.  This requires sending information
> in the protocol, no way around it. There are a range of choices with a
> variety of tradeoffs varying from sending a fully resolved address
> (similar to the information needed to boot without any nameservices) to
> the fully generic service address that requires the target to completely
> resolve it.  There are arguments that can be made both ways.

I strongly disagree about there being no way around sending information
within the protocol for third party commands.  Perhaps a standard backdoor
for making a table for providing an alternative address, again as part of a
response from authentication as part of the permission list if you insist
that there be some dynamic routing.  These third-party addresses must not be
defined within the protocol as this ensures an in-line authentication
process.  This should be avoided if at all possible and it is possible.

I guess there should be a second specification for configuring a portal or
SCSI device at the conclusion of the authentication process either started
at the observation of the client at the portal or prior as a signal from the
authentication server with the cookie is assigned.  This could be a slave
LDAP server embedded within the portal or device, but I expect most would
wish to see this as some secure exchange of tables.

I hope this helps you feel like there is still some fun remaining.

Doug

> However, I strongly believe that we should separate the discussion of
> how to name and resolve the common case of simple initiator and target
> from that of third party transfers. If we solve how to handle the simple
> case first we can then have the third party discussion on if the target
> is now acting as a full fledged initiator or simply a proxy for the
> original initiator. Its role may determine the type of address sent over
> the wire but should not matter how we generally name and resolve
> addresses.
>
> 	-David
>