RE: iSCSI gateways, proxies, etc.

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

David,

> Folks,
>
> We've been going around on the topic of these for
> a while without much visible progress.  I'd like
> to suggest a means to extricate ourselves from this
> situation.
>
> Jim Hafner correctly observed that there is a
> fundamental difference between:
> - A gateway that always exposes TCP/IP addresses for the
> 	iSCSI targets behind it, and
> - A gateway that must be dynamically configured to
> 	obtain connectivity to the iSCSI targets behind it.
> We don't need to do anything to support the first class
> of gateway.  For the second class, there's another
> crucial distinction in the second category, namely
> between in-band and out-of-band configuration mechanisms.
>
> >From a protocol specification viewpoint, out-of-band
> configuration mechanisms are both more flexible and
> easier to deal with.  Flexibility comes from the
> variety of possible mechanisms, for example:
>
> [A] A NAT monitors DNS traffic to/from a DNS server in
> private address space behind the NAT.  When a DNS reply
> containing a translation is intercepted, the NAT sets up
> an external IP address that maps to the internal IP address
> in the DNS reply, and substitutes that external IP address
> for the internal IP address before forwarding the reply
> (in addition to the usual translation operations performed
> on the header).  Credit/apologies to whomever (Joshua Tseng?)
> originally described this example.

I have not heard of the scenario described as you seem to have mistaken a
MAC function related to switches. A possible process would be a portal
receiving a hostname rather than an IP and would then request a name lookup
from DNS (in a UDP packet) and the response, if any, would hopefully be
aware of this hostname and the address as related to the internal network.
The use of DNS must be discouraged as a solution for tunneling past a
firewall or NAT and only IP addresses be used for the SCSI transport.  With
DNS there would be issues of scope, such as global or site reference, and
then type such as IPv6 etc.  SAN *is* mission critical and waiting for a
dynamic DNS update is not possible.  DNS lookup requires additional threads
and delays to make these external queries and would not be something a time
and mission critical device should be doing EVER, not even as an
option!!!!!!!!!!!!!!!!!

How a DHCP server informs the host of network services is within the purview
of the IT administrators and that is another story.

> [B] An encrypting firewall does not provide connectivity
> to hosts behind the firewall for general traffic outside
> the firewall.  If an encrypted IPsec tunnel is set up in
> accordance with the firewall's policies, then connectivity
> to some of the hosts behind the firewall is provided for
> traffic using the tunnel in accordance with the firewall's
> policies.

Many flavors of VPN, border routing, and tunneling are possible and have
highly dedicated hardware to cure overhead associated with encapsulation and
encryption.  In other words, if there is a Firewall or NAT, let the IT
administrators determine how to get into their protection.

> Note that both the NAT and the firewall have to be configured
> by some means, and that both of these mechanisms work without
> any changes to the iSCSI protocol, as both the DNS lookup and
> IPsec tunnel setup happen before the first iSCSI packet is sent.
> The fact that we don't have to specify anything makes these
> easier to deal with, and gives iSCSI compatibility with all sorts
> of things we haven't thought of (yet).

Here. Here. Move the schedule up a year!

> Both the current URL mechanism and the discussion of the
> CONNECT message are in-band configuration mechanisms.  In the
> context of proxy configuration (Julian's concern about views
> is a different, but related issue), this has been turning
> into a tarpit on the list.  From what I can see, the issues
> here are similar to the issues in naming for 3rd party
> commands, something that is not in particularly good shape,
> despite T10's best efforts. I find it hard to believe that
> people want to repeat T10's experience with this from scratch
> for iSCSI, but ... I see three possible paths forward
> from which the WG needs to choose:
>
> (1) Rely on out-of-band gateway/proxy configuration.

Yes. No tunneling and NO hostnames.  A simple connection.

> (2) Reference T10's 3rd party naming formats for target naming.
> 	This WG would still define an iSCSI 3rd party naming format
> 	and recommend it to T10, and could define ways of using
> 	T10 naming formats with Internet protocols (e.g., LDAP).

Now you get into two areas of concern that are unrelated to support of
tunneling or hostnames.  I have recommended a means to standardize the
mapping of *real* SCSI targets to assist in creation of LDAP databases for
both bootstrapping and the creation of permission lists in a uniform manner.
This standardization should also assist in allowing multiple vendors
fail-over.  This is to differentiate from the iSCSI concept of a virtual
target. In the end, Service Delivery Ports are required to allow adequate
flow control which removes the concept of a virtual target as proposed.

With respect to third-party commands referenced off the same Service
Delivery Port, a type of SCSI gateway is required.  A SCSI target could be
used for each medium referenced by a Service Delivery Port where Extended
Copy is provided as a special service for the devices on the medium.  Should
the target be beyond the SCSI portal and required to transverse an IP
domain, this service would be made in a transparent manner unbeknownst to
the device making the Extended Copy request.  Devices using COPY and XOR
command would be required to be on the same medium as determined by the
Service Delivery Port.

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   MSB LUN     |   LSB LUN     |MSB Service Delivery Port (SDP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  LSB (SDP)    |                 Target Port                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     iSCSI LUN Mapping
  0                                       1
  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1   0 |        Target         |    Bus    |       LUN         |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
            MSB/LSB LUN breakdown for parallel SCSI


> (3) Invent new ways of naming targets.

As iSCSI should be revamped, I am not in love with the mapping I proposed.
I would insist that a fundamental component missing is resolution of
individual targets and service delivery ports.  To understand the limits or
"views" a device has from a particular perspective, these two elements are
required to allow an intelligent construction of a command.  I would not
suggest that the third-party naming conventions be changed with respect to
the underlying medium.  I think you can see how this medium is determined by
the iSCSI LUN mapping that I suggested.
I would also hope this mapping would be used to define the schema and rules
for populating.

Doug