RE: iFCP as an IP Storage Work Item

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

Y.P.,

Hardware and software implementations will benefit from a direct use of FCP
rather than those structures undergoing change to better support new
environments which lead to FCIP and iFCP.  An IP network will not permit a
direct boot in the same manner as SCSI as there are no physically captured
devices.  A normal DHCP-MTFTP to obtain boot sectors will likely prevail in
these environments as alternatives remain unstable.  Emulating an existing
system interface will benefit from a transport that adopts the same
underlying structures and behavior.  The strength of the argument may be
found in simplicity with resulting conformity and stability.  A stable
scheme may be years away otherwise and stability represents strength.

Doug

> > 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.
>
>