RE: iFCP as an IP Storage Work Item

[Joshua Tseng <jtseng@NishanSystems.com>]

YP,

I think we are losing sight of the original topic.  The objective is
not to preserve ALL of the existing investment in the SAN environment.
Indeed, if everything in Fibre Channel worked great and met everyone's
needs, then there would be no need for the IPS WG, iSCSI, and iFCP.
Rather, the FC storage transport has unresolved issues that can be
addressed with IP, and so we are here to figure out how to transport
block storage data over TCP/IP.

IMO, iFCP is very consistent with the IPS WG's objectives in this
regard.  One day, iSCSI will solve all of our problems by integrating
all components of block-level storage networking natively on to TCP/IP.
But until that day, iFCP is an attractive solution that fixes the
"squeaky wheel" (i.e., Fibre Channel networking) by replacing it with
a working wheel (i.e., IP networking).  And it does it in a way without
the need to buy a brand-new car (i.e., iSCSI).  And even after iSCSI
becomes a reality, there will still be a huge installed base of FC devices
that will benefit by utilizing iFCP.

See below for responses to your comments:

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

Preserving FC switches is not the objective of iFCP.  Fibre Channel's
limited networking capabilities is THE issue that needs to be resolved.

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

iFCP and FCIP have nothing to do with OSPF.  I think your statements
show that you do not understand iFCP and its objectives.  I would
have hoped that those critical of iFCP would have at least a minimal
understanding of it.

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

In case you missed Charles' e-mail, he already answered your address
space issue.  However, there are other ways in which iFCP facilitates
the scalability of a storage network.

For example, SSP's need to be able to manage storage traffic flow
between many different independent autonomous network systems, as they
will need to separate their own network from their many customers'
networks, and their customers' networks from each other.  IP has
this capability through the combination of OSPF and BGP routing;
Fibre Channel does not have the equivalent to BGP.  Therefore, using
a Fibre Channel fabric and FCIP alone, the SSP will need to set up
a large number of small, independent, and non-interoperable SANs.
IMO, this will be difficult to manage and scale.

Furthermore, as Wayland pointed out earlier, a single large FC fabric
stretched over multiple WAN links by FCIP is vulnerable to temporary
disruptions in the IP network which may trigger reconfigurations in
the FC fabric, such as reallocations of DOMAIN_ID's.  iFCP addresses
this issue by assigning N_PORT ID's locally, eliminating the dependence
on a central addressing authority and the need for any "Class F" traffic.
The stability and scalability of a large storage network is thus improved.

Josh
> 
> Y.P. Cheng, ConnectCom Solutions.
>