iFCP as an IP Storage Work Item, Reset

["John Hufferd" <hufferd@us.ibm.com>]

I think the messages on iFCP have become somewhat decisive and unfocused.
And quite frankly it has been permitted to happen by both supporters and
detractors.  I think this has occurred because engineers tend to solve
things, whether or not the solution is useful  or if it has a business need
requiring a fix.  Therefore, having said that, we need to restate what the
playing field looks like. (The reader is cautioned that this is a lengthy
note.)

The iFCP draft says that it is intended to be a Gateway to Gateway
protocol.  Therefore supporters of iFCP  should stop responding to the
infinite possibilities to hallucinate various other purposes for this
protocol.  The protocol is NOT an end to end protocol, and responses that
do not end the speculation waist our joint time, and polarizes iSCSI
end-to-end folks against iFCP.   I believe, there are a number of things
that maybe missing for a robust end-to-end protocol with iFCP, but the
point is it does not matter, the protocol is structured, proposed and
analyzed as a Gateway to Gateway protocol, and nothing else is proposed or
analyzed as part of iFCP.  The head of the company that brought us iFCP,
has stated that he only wants this as a gateway to gateway protocol, and
that they are committed to iSCSI also.

I blame the iFCP supporters for not just shutting down these variant
thoughts.  The iSCSI supporters would be expected to worry and be paranoid
about anything they can hallucinate that might threaten iSCSI.  Therefore,
because the iFCP authors did not stop these thoughts dead in their tracks
(although Josh tried a couple of time), things got completely out of hand,
and we moved from a protocol, that in some ways was redundant to FCIP (or
visa versa), to something that also seemed to threaten iSCSI.  I strongly
suggest that no real interests are served by this wild speculation
(Note: I am not completely pure here either, since I also let paranoia
force me off the reservation when I worried about mFCP and a related
organization.)  So I want to strongly suggest that we look at iFCP for only
what it is proposed to be, and NOT stray into other areas.

To get my head straight, I had to refocus on the environments where FC,
FCIP, iFCP and iSCSI are going to play to see where the effective
redundancy and conflict might exist.  Clearly if I thought that iFCP gave a
serious problem to iSCSI and to FCIP, and was redundant to both, I would
have a problem.  To analyze this, I had to go through some "market think".
I know that we are suppose to be in an engineering environment, but it is
our views of the market that get us polarized.  So the following is the
analysis I went though and I hope it is helpful to others.

Working with iFCP defined as a Gateway to Gateway protocol, lets look at
the various environments where this technology could be deployed.  Also,
even though there are two types of Gateways that could be built with this
protocol, a Router, and a Switching Router (Switch with Router
capabilities) I will assume that a Switching Router is the subject product.
A Switching Router has several ports that can either be plugged with FC
cable or Gigabit Ethernet cable, in various combinations.  If only FC
cables are connected, it is a FC switch, when only Ethernet cables are
connected it is a IP Switch, with various combinations of FC and Ethernet,
it is a iFCP Routing Switch, called hereafter an iFCP Switch or an iFCP
Gateway.

We should also note that the iFCP Switch Vendor(s) are also claiming (as I
said above) that they will have, over time, iSCSI support also.  I will
submit that those environments which have iFCP (with latent iSCSI
capability) solutions will also help the deployment of iSCSI solutions.
This is because, the Gateways to FC Host and FC Storage will have already
have been put in place.

Here are the environments I examined:

1. Existing Single SAN Fibre Channel environments with a number of FC
Switches.  If the FC SAN already exists, the assumption here is that the
customer might want to replace his current FC Switches and Hubs with an
iFCP set of switches and LAN type interconnects.  However, I submit this is
not really very fertile ground for iFCP switches.  (By the way it is not
very fertile for iSCSI or FCIP solutions, in the short term, either.)  This
set of customers will be very hesitant to change since they have already
had a lot of investment, and they probably think they are on the down hill
slop of the compatibility and support issues.  They may wish that the cost
were lower, but any change will be only lots of additional cost to them.
Continuing with FC will be their probably action.

2. Existing Single FC environment, that uses FC to connect mostly point to
point and not invested in many, if any, switches.  This type of environment
may use Sharks or Symmetrix type Storage Controllers directly.  And some
time they will need to expand with new storage controllers, Host  etc. This
gives a possible reason to install a FC Switch with iFCP capability, (for
future expansion).  But this will be a head to head fight with existing FC
Switch vendors, and therefore such iFCP Gateways will not have a strong
market here.  (By the way, the iSCSI message is hard in this environment,
unless the customer has visions of important future expansion with iSCSI
storage controllers, or needs to bring Desktops and Laptops into the common
storage pool.)   Likewise there is not a FCIP message here either.)

3 a. Existing Multiple FC environments (locations) on a single campus.  FC
with normal Switch to Switch E-Port connections via long FC cables will be
able to easily bring interconnection to this environment.  However, the
bringing together of various FC environments is also a strong play for iFCP
Gateways.  That is, each environment can add a iFCP capable Gateway and
thereby interconnect the environments, and permit the sharing of various
storage facilities.  Each individual iFCP interconnected FC environment
will be able to change its addressing etc., without needing to coordinate
with any other local site (a Big Plus).   The FCIP solution is also viable
in this environment, however, when you get to more then two environments,
the number of (single in -- single out) Edge Connect FCIP routers, go up
dramatically as the number of locations increase.  The physical space issue
can be mitigated by a multi-in, multi-out FCIP capable router box.  That
is, a box that puts the electronics for multiple connections on the FC side
-- one for each location to location interconnect.  Note, this also
requires a FC switch with a E-Port that can be connected to an E-Port at a
specific target location.   Also the FCIP has a disadvantage in each of the
locations that might look like environment 2 above (since they have few or
no FC Switches).  iSCSI will find this a difficult environment in general
because of the existing FC investment.   (Note:  proposed combinations sets
of "FC-to-iSCSI boxes which route to iSCSI-to-FC boxes" can not be assumed
to work since iSCSI has not defined any protocol to handle FC ELS, as has
iFCP.)  Therefore, iSCSI will not be a popular solution here. The higher
the number of location the stronger the iFCP appears (cost wise) against
FCIP.  Note: if a iFCP Gateway gets installed, and if the unit also
supports iSCSI  (as the primary vendor has committed), the inroad for
iSCSI, in general, will be greatly simplified.  iSCSI folks, therefore,
should be careful in their dismissing of iFCP, because when it is teamed up
with iSCSI in this manor, it becomes be a great ally.

3 b. Existing Multiple FC environments across a Wide Area.  This case is
the same as 3a above, except normal FC techniques do not apply.  However,
both iFCP and FCIP approaches apply.  Again the advantage of iFCP vrs FCIP
have to do with the number of sites that are interconnected, and the site
independence that iFCP offers.  Also, if the iFCP Gateway has iSCSI
capabilities, it should permit strong and quick inroads for iSCSI into this
environment.

4. SCSI, and ATA based Host environments that need to grow into a network
attachment. The non server host, Desktops and Laptops, and servers that
have incidental remote Storage Access will not generally consider FC as an
approprate option.  Generally this environment is approprate for the iSCSI
initiators  (with normal TCP/IP NICs, and iSCSI SW Drivers).  Without FC
the FCIP will not apply to this environment.  iSCSI to FC Gateways will
exist at the remote environments and possibly iSCSI  native Storage
Controllers.  iFCP itself is not approprate but if the iFCP box also has
iSCSI capability, then that can be as valuable as any iSCSI to FC gateway.

5. Single  SCSI, based Server environments with needs to grow.  These
environments will have high access requirements.   When iSCSI HBAs are
available (1H2001), and with the availability of iSCSI to FC Routers
(1H2001), this is a fertile market for an iSCSI sale.  When iSCSI Storage
Controllers are available, this environment will be a significant growth
area for iSCSI.  It has a head to head message with FC SAN.  However, the
existing knowledge of IP networks and IP Switch cost will be the swing
consideration to iSCSI.  FCIP has no evolvement in this environment.  iFCP
in this environment would require FC HBAs, and at lest two iFCP Switching
Routers. If the customer wants to add iSCSI Storage Controllers, the iFCP
Switches will not be useful (until it supports iSCSI also).  In this
environment where the target storage is FC based, iSCSI requires (in
addition to iSCSI HBAs, & IP Switches),  one or more iSCSI to FC Gateways.
The winner here, between iFCP and iSCSI will be the solution with the least
cost. That is, the total cost of the HBAs (initially this maybe a push
between FC and iSCSI), the IP Switches, and the iSCSI to FC Gateways vs the
Cost of FC adapters, IP Switches and iFCP Gateways.  If the resultant cost,
is close, then iSCSI will probably be the winner here, because of industry
direction.  Having said that, this is one of the environments where iSCSI
folks think that the iFCP message is diversionary.   If the customer is not
polarized against FC, and the customers looks at having to buy FC adapters
for the iFCP deployment, they are probably going to look at a complete FC
SAN as a more straight forward deployment.  Therefore, the competitive play
will very often be between FC and iSCSI the possibly diversionary iFCP
messages  will not be significant and maybe helpful selling the IP Storage
message.

6 a. Multiple  SCSI, based Servers environments (locations) on a single
campus.  Like 5. above, these environments will have high access
requirements, and when iSCSI HBAs are available (1H2001), and the iSCSI to
FC Routers (Gateways) are available (1H2001), this becomes a fertile market
for an iSCSI sale.  iSCSI will then have a head to head competitive message
in this environment with FC SANs, and very probably a head to head
competitive message with the FC and FCIP combo.  (So lets not deceive
ourselves that iSCSI doesn't have a market conflict with FCIP.)  Since I
believe that in this environment, the customer probably had a reason for
not already jumping on FC, and because since I also think they are probably
well versed in TCP/IP Networks, the iSCSI message, will be well received.
The iFCP message may also have a play in this environment, they can play to
the same TCP/IP knowledge as iSCSI does, and suggest to the customer that
iFCP is a better choice because there are more HBAs and Storage Devices
based on FC then on iSCSI, etc.  Therefore I think that this is a
competitive play between everyone, FC SAN, FC and FCIP, iFCP, and iSCSI.
However. the more iSCSI based storage controllers are shipped, the more the
play tips toward iSCSI in this environment.  Some iSCSI folks look at iFCP
having a diversionary message in this case also, however it looks to me as
a general free for all amongst all the options that are valid in this
environment and cost will be the driving force.  By the way, the iFCP IP
Storage message will probably do more to help iSCSI, then it does to
distract from iSCSI.  Also, in this environment, the trade offs between
FCIP and iFCP, mentioned in 3a. above, apply here as well.

6 b. Multiple  SCSI, based Servers environments (locations) across a wide
area. This environment fits the same solutions as 6 a. above, except a FC
only solution is not an option.  That is, an iFCP or FC&FCIP solution is
approprate as is the iSCSI option, just as in 6a above, but not FC only.

7. Multi Hosting environments with Storage Service Providers (SSPs).  These
environments will be primarily networked environments which when built
today, are Fibre Channel, but here a iFCP Gateway would be a reasonable
consideration.  In this environment today, the Hosts will have a FC
adapters so in either case,  the question is -- will the cost be less using
iFCP Gateways (where the FC Fibre leave the "Cage", and then goes through
IP Switches, and then terminates at a iFCP Gateway  just before the FC
based Storage Units)?  Since the SSPs will be competent in both FC and IP
networks, the trade off will be primarily cost.  If the costs are close,
the edge will probably go to iFCP since it can also combine multiple sites
at less cost then multiple FCIP Gateways (see discussion in point 3 above).
Having said all that, if iSCSI HBAs, and iSCSI Gateways are available
(1H2001), then, the SSP  will be able,  to apply additional security
features (if required by the customer), and they only need low cost IP
Switches all the way into the Storage Area.  This  will probably the most
flexible and lowest cost.  Since iSCSI will also be able to glue multiple
sites together it will be the most probable configuration in this
environment, over time.   Until that time, iFCP has a strong chance of
being heavily  used in a SSP environment, perhaps supplanting FC networks
in this environment.   An iFCP & iSCSI Gateway, would seem to be a very
high seller, and permit graceful migration to an all iSCSI network.

--------------------------------------------------------------

The iFCP messages, in all but environment #7, will be dwarfed by the number
of vendors shipping iSCSI, and the iSCSI message will be the only important
IP Storage message that will come through.  But since the number of SSPs is
small they are easy to market too, and will be fully aware of the
approprate maturity of iFCP and iSCSI.  However, iFCP will probably only be
a stepping stone to iSCSI in an SSP environment.  Further, if you take the
primary iFCP vendor at their word, they will combine their iFCP product by
including iSCSI, and therefore the total message will be very supportive of
iSCSI.

Let me build a matrix that can summarize the above environments (Cases)
with probability of success.

Here are the cases again:
1. Existing Single SAN Fibre Channel environments with a number of FC
Switches.
2. Existing Single FC environment, that uses FC to connect mostly point to
point and not invested in many, if any, switches.
3 a. Existing Multiple FC environments (locations) on a single campus.
3 b. Existing Multiple FC environments across a Wide Area.
4. SCSI, and ATA based Host environments that need to grow into a network
attachment.
5. Single  SCSI, based Server environments with needs to grow.
6 a. Multiple  SCSI, based Servers environments (locations) on a single
campus.
6 b. Multiple  SCSI, based Servers environments (locations) across a wide
area
7. Multi Hosting environments with Storage Service Providers (SSPs).

+----+-------+-------+-----+------+----------+--------+
|Case|FC only|FC&FCIP|iFCP | iSCSI|iFCP&iSCSI|iFCP Msg|
+----+-------+-------+-----+------+----------+--------+
| 1  | High  |   NA  | Low | Low  |   Med    |Helpful |
+----+-------+-------+-----+------+----------+--------+
| 2  | High  |   NA  | Low | Low  |   Med    |Helpful |
+------------+-------+-----+------+----------+--------+
| 3a | High  |  High |High+| Low  |Very High |Helpful |
+----+-------+-------+-----+------+----------+--------+
| 3b | NA    |  High |High+| Low  |Very High |Helpful |
+----+-------+-------+-----+------+----------+--------+
| 4  | Low   |   NA  | NA  | High |   Med    |NA      |
+----+-------+-------+-----+------+----------+--------+
| 5  | Low+  |   NA  |Low+ | High |   Med    |Min Help|
+----+-------+-------+-----+------+----------+--------+
| 6a | Med   |  Med  |Med+ | High |Very High |Min Help|
+----+-------+-------+-----+------+----------+--------+
| 6b | NA    |  Med  |Med+ | High |Very High |Min Help|
+----+-------+-------+-----+------+----------+--------+
| 7  |Hi->Med|  Med  |High |Med>Hi|Very High |Helpful |
+----+-------+-------+-----+------+----------+--------+

This table says that in the existing FC environment Case 1-3b,  iSCSI,
will have tough play.  On the other hand, in multiple location
environments,  iFCP will have a strong play, against FC & FCIP.   When the
iFCP product is combined with iSCSI support its  probability of success
becomes Very High.   In other environments (4-7),  iSCSI has a high
probability of success.  And when the iFCP product gets iSCSI support it
will greatly improve its success position.  The marketing messages from
iFCP are Helpful, or Minimally Helpful.

Hence the only important conflict is between FCIP and iFCP, and this is
mostly a "push" except for Multiple Sites, where the Cost might favor iFCP
(and that is not completely obvious).

Many of us wanted the FCIP and the iFCP combined so this conflict does not
exist, however, this looks like both sides have refused to cooperate, so a
product shoot out will occur.  It looks to me that both will take a piece
of the market and continue to exist.

The table indicates that when iFCP is combined with iSCSI, the results
offers a better product in several areas then either by themselves.

Therefore, I believe that iFCP has important potential value to our
customers, and should be part of the IP Storage effort within the IETF.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: hufferd@us.ibm.com