RE: iSCSI: URL scheme

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

Costa,

> Doug,
>
> This a really interesting example.
>
> > 		Server (Drive D)
> >                       \
> > (always Private)  SCSI Space ---- SCSI Space
> >                         \               \
> >                          \               \
> >              Routable SCSI Portal 1  Transparent Bridge Connection
> >                           \               \
> >                            \               \
> >                         IP Space        IP Space
> >                            /              /
> >                           /              /
> >                         NAT      Routable SCSI Portal 2
> >                         /              /
> > Non-Routable      Client (Bob)     Server (Drive C)
> >
> > How does Bob get to talk to the Drive C?
> >
> > Bob's system only knows about the Portal 1 however his drive is
> actually on
> > Portal 2.  Bob's system knows about this through a sequence of boot up
> > steps.  DHCP informs his system of an LDAP server.  Bob's system then
> > queries this server for SCSI services via SCSI class objects.
> Bob's system
> > leans how to authenticate with Portal 1 and what target/lun/wwn
> his system
> > will find his Drive C at within the realm of Portal 1.  Portal
> 1 knows that
> > this target/lun/wwn is actually within the realm of Portal 2.
>
> How is the mapping configured into portal 1?

There would be a class object with LDAP that would define the SCSI services.
At the device level, it may look something like
Target[]{LUN:WWN:(Name:USER)}{P-SCSI-Portal-IP:Port, S-SCSI-Portal-IP:Port}.
If the resources are not at the local LDAP, but rather an external LDAP
database, then there should be similar object that indicates the location
for these places.  I think it would be better to assume that if there is a
need to communication behind a firewall, that the IT managers know how to
route those packets via the required means.  If it is something exposed to
the internet, then it would be unwise to allow routes to be dynamically
establish at the behest of the client back into IP space.  I think one
should assume that SCSI address space is SCSI address space.  If there is a
need to transverse IP, it must be done in a pre-arranged transparent manner.
We do not want to re-invent routing technology.

> What if Bob uses his web browser to buy some storage from storage.com
> and wants to mount that storage (say as Drive E)? How does he configure
> all the portals?

The provider would only advertise his Authentication server via a DNS to the
public.  If the client's browser had a plug-in that knew about how to talk
to a SCSI device, it may allow the user to type
SCSI://my.storage.com/nasty_stuff and a pop-up would request a password or
use a stored password to then access the authentication server at this
location to look for the drives under nasty_stuff.  Once the needed
information was exchanged between the authentication server, the SCSI driver
would then have all the binary information required to access the SCSI
portal (not advertised via DNS).  The authentication server would return a
structure as I indicated prior together with a one-time secret for a cookie
exchange.  LDAP has a Java interface, so perhaps Java was used.  Whatever
the gurus indicate is the best means to hook into this database, I will nod
my head knowingly.  Should there be a third-party command that is required
to transverse the IP, it should be a node on the back-side of a portal that
has already been connected to yet another portal.  This connection may have
been established in response to the authentication or done in a prior
fashion.  The node on the back of the portal would have a SCSI address and
would map into yet another SCSI address within the realm of the other
Portal.  Again, even this translation would not be handled by the client nor
should it be as it would be in the domain of the provider.  The provider
would be required to make the conversion table prior to authentication.
Perhaps this table was made at the time of installation.  At no point in
time, should the client be able to change this table.  It would be like me
changing the table in a router on the fly via a symbol within one of my
packets.  Not a good idea.

> > At Portal 2,
> > his drive is at yet another target/lun/wwn.  Portal 1 will make the
> > translation for Bob without Bob's knowledge into Portal 2.  Bob does not
> > know how to Authenticate with Portal 2 nor where Portal 2 keeps
> his drive.
> > That would be handled transparently for Bob.  As Portal 1
> always responds
> > back to the client Bob at the IP and port that he came in at,
> the NAT is not
> > a problem.  As far as Portals are concerned, they must be exposed as
> > Routable.
>
> How is the mapping configured into portal 2?

Much like a router, routing and translating tables would be hard-coded in
these devices.  The LDAP database would be setup to take advantage of these
translations.  Should a connection be required at the time of use, then the
agent would be required to make the connection based on pre-arranged tables
beyond the access of the client.  Thus as far as the client is concerned,
once connected to the portal, everything is SCSI space and is defined by the
tables downloaded during the authentication.  This keeps the job of the
transport far simpler than processing strings like a web server.  The key to
getting everyone to place this in their browser for internet use is the
standardization of the authentication server. This very standard should also
work for enterprise environments as well.

Doug

>
> Thanks,
> _Costa
>