RE: iSCSI has already been done before, sort of...

[Roger Cummings <roger.cummings@veritas.com>]

Matt, Bill,

There is no iIPI document that I've ever seen. However the definition of
IPI-3 on "HIPPI Raw framing protocol" is defined in section A.2 of the
latest IPI-3 Disk standard - ANSI X3.291:1997, the Revised Device Generic
Command Set for Magnetic and Optical Disk Drives. The standard can be
purchased in paper for from the usual sources, and online as a PDF file from
http://www.ncits.org. Details of all IPI projects are still available from
the link that Bill gave, http://www.t11.org, which is the T11 committee web
site that I happen to maintain - follow the "IPI" links.

I was the editor of the IPI-3 Tape standard, and I worked on IPI very
actively from 1984 thru the early 1990s. IPI was mostly used by large system
companies such as IBM and what used to be known as the BUNCH (Univac,
Control Data, Honeywell etc.), because its architecture used some of the
same principles as their previous proprietary channels. With the demise of
the BUNCH in the early 90s, IPI basically faded away and was replaced by
SCSI for server storage. Maximum Strategy certainly did have an IPI-3 over
HIPPI and over FC product, and I think that they had plans for a IPI-3 over
TCP/IP product as well. I still have contact with some of the folks that
worked there, so I'll see if I can find anything that will be useful for
iSCSI.

The reason why it was fairly straightforward to create definitions of how
IPI-3 was transported on the multiple interfaces was that IPI-3 was
conceived from the start as a "packetized" protocol. This was most certainly
NOT originally true of SCSI, which has the message system and other physical
layer signaling aspects. However in the last 10 years T10 has put a LOT of
effort into the SCSI-3 architecture to enable SCSI to be "packetized" and
work across multiple transports. A number of people who have been involved
in this process have been up front about using the functionality of IPI-3 as
guidance for that effort. It can certainly be argued that things like status
reporting and error recovery are unnecessarily complex in SCSI because of
its heritage. However the fact is that SCSI, complexity and all, is
implemented in every major server OS, and that it made eminent sense in the
mid 1990s to take advantage of that support to speed the adoption of Fibre
Channel. Supporting essentially the same protocol over parallel SCSI & FC
enabled SAN configurations that take the best advantage of both
technologies, through the equivalent of bridges and routers. I submit that
it makes equal sense to take the same approach for IP Storage.

Bill's list of the attributes of IPI-3 is essentially correct, but I'd like
to add a few comments:

1) IPI-3 certainly had the concept of a "Transfer Notification" that
preceded a data transfer, and even allowed information such as address and
length to be included, but I don't think we ever did standardize the format
of that information.
2) The IPI-3 packet format only allocated a byte each for the "Target" and
LUN address, which would clearly not be sufficient for today's SANs, and
changing those size would have a major impact on the protocol because a
number of the protocol aspects assume a fixed length header.
3) IPI-3 did have multiple port support, but this was achieved with simple
bit masks that clearly would not work for multiple different transport
technologies in today's SANs.
4) IPI-3 predated the use of worldwide unique identifiers for configuration
discovery in storage.
5) There has never been any IPI-3 "controller chips" at any level
approaching the level of integration and complexity of today's intelligent
SCSI silicon, as far as I know. The highest level of integration achieved
was a single chip physical interface state machine.

Therefore, despite its technical excellence (and there are still a number of
people around who will confirm that it was a good technical solution), I
cannot believe that IPI-3 is a viable candidate for a 21st century storage
protocol over any transport mechanism.

Regards,




Roger Cummings
Veritas Software

roger.cummings@veritas.com

-----Original Message-----
From: Matthew Jacob [mailto:mjacob@feral.com]
Sent: Friday, July 07, 2000 11:56 PM
To: Jim McGrath
Cc: 'Black_David@emc.com'; wmain@gis.net; ips@ece.cmu.edu
Subject: RE: iSCSI has already been done before, sort of...




> 
> 
> I think the question is whether there is a document similar to iSCSI for
IPI
> over a network that we could learn from.  My problem with the actual IPI-3
> document is that I believe it is similar in scope to the SCSI documents
> themselves - good at defining the protocol for the traditional storage
> model, but not good at highlighting the changes/issues associated with
> putting it over a network.
> 
> If there was a iIPI (IPI-3 over some network) document(s) out there, then
> that could provide some useful guidance.
> 
> If I am mistaken, and the actual IPI-3 documents provide this level of
> guidance, then it would probably help others to identify the appropriate
> sections, since the document itself is rather large.

I don't believe that there have ever been any public specs in  this area. I
know of a couple of implementations of IPI-3 over both TCP/IP and Hippi raw
framing protocol- but I don't recall that they got to any kind of
standardization level (possibly in the Hippi specs somewhere- I don't have
them handy).

Anybody on the list know anyone from MaxStrat (mass storage for
SuperComputer's company- maybe bought by Sun???? I think they may have also
done this as well.

-matt