RE: iFCP as an IP Storage Work Item

[Charles Monia <cmonia@NishanSystems.com>]

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:ycheng@advansys.com]
> Sent: Friday, January 12, 2001 11:09 AM
> To: ips@ece.cmu.edu
> 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.
>