Re: iSCSI Naming and Discovery

[David Robinson <David.Robinson@EBay.Sun.COM>]

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.

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

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

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