RE: iSCSI Naming and Discovery

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

David,

> [Be out sick for a day and see all the fun you miss! :-) ]
>
> In reading through this thread I see arguments on both
> sides that seem to muddle together the issues of establishing
> connections versus using an existing connection.
>
> 1) I think that it is required that once a connection is established
> there is no external service that is required to be operable in order
> to allow commands and data to flow between target and initiator.
> I hope there is universal agreement on that.

I agree.

> 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.

> 3) In order to establish the connection there must be a mapping
> from some service level name into an (IP address, port) pair.
> I assert that within the iSCSI transport the service level naming
> never appears (I am ignoring 3rd party transfers for now). Thus
> using some sort of URL like name as part of a connection login
> is redundant information, the target doesn't need to be told who
> it is.  All that is needed is the information described in 2) to
> determine which subcomponent behind the port that needs to be
> accessed. It is however important that we standardize how the service
> is named and how it is resolved into an IP address and port number.

Yes, using a class object convention within LDAP is a means to standardize.
LDAP does not define schemas or models.  This group must do that work.  Once
done, the process of finding things within the SCSI address space is Dead
Simple.  You would never use a symbolic means beyond LDAP, but rather
standard SCSI addresses.  Within the database would be the means to verify
the drive as a bonus.  Should a third-party command need to transverse IP
space, then this should be done by a fixed table within the Portal which is
used as a transparent bridge to a different Portal.  The means of arriving
at this hidden portal would not be shared with the client.  Prior to
accepting a cookie from the client to verify identity, and then responding
with a cookie to confirm the acceptance, all target and LUN permissions
would be applied prior to any transfers.  Part of the Authentication process
would be notice of authentication sent from the Authentication server to the
portal together with the secret and the permission list in SCSI address
form.  The translation tables would be a separate and relatively fixed
setting.  Something similar to routing tables.

> 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.

> 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.

What ever happened to statement 1)?

Doug

> 	-David
>