Subject: RE: iFCP as an IP Storage Work Item

From: Charles Monia <[email-masked]>
Date: Fri, 12 Jan 2001 19:20:07 -0800

Hi Y P:

As I see it, the software issue is not only related to support for the
low-level hardware and SCSI encapsulation.  It's in the effort needed to
transpose all the SAN value-add (naming, discovery, zoning, error recovery,
management, etc) to a new network environment. In other words, all the
higher level storage network and systems issues that must be dealt with by
middleware and the upper reaches of the driver stack. 

Yes, as you say, it is possible through careful design to structure the
driver stack around a common low-level shim that decouples it from the
hardware ASICs and transport-specific SCSI encapsulation assists.  And,
indeed, this low-level software can be readily ported to a target
environment with the appropriate tools. While such a shim provides a common
interface to SCSI semantics, nonetheless, it cannot hide these fundamental
differences in the network environment. It doesn't automatically get you a
Symmetrix or a Shark running in a native IP environment.

As an example, no shim can conceal the differences between a parallel SCSI
bus, supporting 16 drives, from an FC environment, with addressability in
the millions.  Likewise, issues like booting, device naming and discovery
have to be rethought and reimplemented in a new environment.  A simple
example is the third party copy functionality, which must be extended to
incorporate the iSCSI naming model.

So, rather than say that the iFCP preserves the existing driver stacks, we
should go further and extend the scope to the totality of software needed to
support the storage network environment.

Charles
> -----Original Message-----
> From: Y P Cheng [mailto:[email-masked]]
> Sent: Friday, January 12, 2001 11:09 AM
> To: [email-masked]
> Subject: RE: iFCP as an IP Storage Work Item
> 
> 
> > As far as FCP stacks go, it is a truism that no OS
> > (host) has a native FCP stack. Today.  (Stay tuned, though;
> > Blackcomb AS is going to be rather interesting)
> >
> > That's why the HBA rules.  It's the entity performing
> > all the translation between what the OSes see as a pure
> > SCSI universe and the real (or virtual) device FC universe.
> > Had we native motherboard FC physical interfaces and OS
> > FCP stacks, we would not need FC HBAs.
> 
> With native motherboard FC chips, the BIOS has the necessary 
> code to access
> the chip. After booting, the OS transition from BIOS to the 
> chip device
> driver.  There is no FCP stack.  There is only the device driver code
> supplied by the chip manufacturer. (In other words, different 
> FC chips have
> different drivers.)
> 
> > But, that's hosts.  Consider the world of devices for
> > a moment.  No one can argue that there are not a
> > plethora of FC devices today, all with FCP stacks by
> > definition.  Plus, many FC devices today are not just
> > one FC port but multiple, with multiple WWPN and one WWNN
> > to achieve higher RAS characteristics.
> 
> You are confused between the device driver and TCP stack.  Most RAID
> manufacturers use SDK, Software Development Kit, from HBA 
> manufacturers.
> The SDK allows RTOS to build device drivers for the ICs.  The 
> ICs generate
> FCP packets.  Unlike TCP/IP, the Fibre Channel IC device 
> drivers are not
> aware of the format of the FCP packets.  Therefore, they can 
> not be called
> the FCP stack.
> 
> > So while your statement
> > > iFCP as way to keep your investment in FCP stacks is a very
> > > weak argument.
> > is certainly true for hosts (initiators), it is certainly
> > not true for devices (targets).
> 
> No, Julo is correct.  The argument is very weak.  The statement is
> especially weak if an iSCSI adapter uses the same 
> implementation as an FCP
> adapter.  In the adapter implementation, the iSCSI header 
> will be added by
> the adapter.  There won't be an iSCSI stack in the OS for 
> adding the iSCSI
> headers.  Of course, a stack implementation of iSCSI in an OS 
> is likely
> although not efficiently.  Most manufacturers with high 
> performance in mind
> will choose to put the iSCSI stack inside the adapter, not in the OS.
> 
> Y.P. Cheng, Connectcom Solutions.
>

---

From: "Y P Cheng" <[email-masked]>
Date: Sat, 13 Jan 2001 14:32:09 -0800

> transpose all the SAN value-add (naming, discovery, zoning, error
> recovery, management, etc) to a new network environment.
> ......... <snip> <snip> .............
> should go further and extend the scope to the totality of
> software needed to support the storage network environment.
>
> Charles

Yes, we are now talking the right area.  However, I don't see how iFCP will
help preserve the software and hardware investment of SAN environment made
by customers.  Here is my understanding of the investment made by customers
in SAN environment.  (Experts of SAN can certainly correct me.)

1. Software from Oracle, Veritas, and Logato running in block address
instead of file system address.  I am pretty sure none of those software is
specifically programmed for FCP devices.  In fact, they treat everything
like "hard disks or tapes" whether they are ATA, SCSI, FCP, or RAID. Shark
and Symmetrix mentioned by you appear to the application software as
reliable hard disk devices.

2. SAN management and configuration software.  These are typically provided
by storage device manufacturers.  The software talks to the storage devices
through a separate Ethernet connection.  Most storage boxes use SNMP to send
and get Management Information Blocks (MIBs).  Again, iFCP is not
particularly helpful in saving the investment in this area.

3. Hardware investment like routers and switches.  The Name Server inside
the switches provides target device discovery function.  With Java support,
the switches provide customers the comfort at home using a browser to log
into the switches to check connectivity and do zone and domain management.
In such case, FCIP is in a better candidate to preserve the existing
investment.

4. Finally, the HBA's inside the servers and storage devices.  I can assure
you, every HBA manufacturer will have device driver to do FCP, iSCSI, iFCP,
or FCIP stack processing, whatever protocol chosen by the customers.  The
protocol stack processing are done inside the IC by microcode, not the
device driver.  Even MicroSoft Winsock Direct and TCP Remote DMA will be
implemented in the microcode of the IC to offload the host protocol stack
processing. No software investment is made by customers.  (The drivers are
free with the HBA.)

In all, if I may summarize, the strongest argument iFCP has is the OSPF
routing and scalability.  But, FCIP gets OSPF routing in the IP plane too.
For the scalability, storage-device attachment to servers is somewhat static
and confined, unlike the HTTP which requires huge amount of connectivity and
IPv6.  No Internet or dot com companies would need 16 million block-device
addresses allowed by the 24-bit D_ID of FCIP at one time.  :-)

Y.P. Cheng, ConnectCom Solutions.