RE: iFCP: FC-BB exists, why invent something new?

["Venkat Rangan" <venkat@rhapsodynetworks.com>]

Y.P. Cheng,

> As an HBA manufacture, I would like to be able to connect to either iFCP
> or FCIP device without having two sets of microcode.

I don't think there is any issue with HBAs having to run two sets of
microcodes. Both iFCP and FCIP would allow you to attach the N_Port of the
HBAs to their F_Ports.

But the fact is that if you go with iFCP, you need an iFCP gateway to be
installed at either end of the IP cloud, which will translate between FC and
TCP/IP at both ends, delivering FC frames to the final end points. Unless
both iFCP devices are from the same vendor, you need to ensure
interoperability, but once the two interoperate, HBAs are immune from that.
Of course, both iFCP devices must implement their N_Ports per FC-FS and
FC-PI specs, but that is different from iFCP interoperability.

If you are an adventurous HBA vendor, you could integrate the iFCP portal on
your HBA, so you don't need FC connectivity to another device from your HBA.
But that product presumably would present an alternative to an iSCSI NIC,
perhaps causing customer confusion. If you want to provide dual mode HBAs, I
agree that your HBA will then have two sets of microcodes.

If you go with FCIP, only the switches on the border (BSW) would do the
conversion. Frames are routed using E_Ports until they get the BSW, upon
which the B_Ports at the BSW will convert to IP frames for routing over an
IP network. The other end of the B_Port will convert it back to FC frames.

The issue is whether you can use existing FC switches and add to it FCIP
(and make it  BSW) or take an FC switch and add to it iFCP (and IP/GigE
implementation). You can also take an layer-2 IP/GigE switch and add FC and
iFCP to get an iFCP device. Each vendor will advocate an approach that
advances their position, leaving the market place to decide.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Y
P Cheng
Sent: Friday, December 15, 2000 12:17 PM
To: IPS Reflector
Subject: RE: iFCP: FC-BB exists, why invent something new?


> > restricted to FCP). What does iFCP bring to the table that
> > FC-BB does not already provide?
> > -Matt
> >
> iFCP allows routing storage traffic between individual
> FC devices over an IP network.  FC-BB only bridges SAN islands.
> As you are aware, there is a very significant difference
> between bridging and routing.
>
> The former (FC-BB) requires the routing to be performed by
> FC switches.  The latter (iFCP) has the routing performed by IP
> switches.  Since I work for Nishan, my opinion is the latter is
> much superior, but I have to admit there may be situations where
> a simple bridging/tunneling implementation will be sufficient to
> address a particular requirement.  BUT, I also believe
> there will be situations, especially with increasing storage
> networking demands, that the latter will be needed to achieve
> the required scale of storage networking deployments that will
> be needed in the near future.
> Josh

Taking my technical hat off, as a business person, may be I can say
something that Josh did not say. Nishan is in business of routing.  They
wish to connect IP networks directly to FC nodes (N, NL, F, and E) that do
not have FC-BB functions.  They are in business to replace BSW ports
Therefore, they propose iFCP, like a NAT device, to map the S-ID and D-ID
into unique fibre channel addresses in other FC domains.

On the other hand, by saying an FCIP device being a bridge and tunneling
device in connecting to the E-port with FC-BB functions, Josh simply says
that FCIP depends on BSW for routing which is not scalable to IP network.
There are companies making FCIP devices.  But, the FCIP device is inferior
to iFCP in its capability of routing.  Nishan certainly is not interested in
FCIP devices.

>From an end user point's of view, should there be a winner between FCIP and
iFCP?  I believe they will coexist.  As an HBA manufacture, I would like to
be able to connect to either iFCP or FCIP device without having two sets of
microcode.  This is why I believe we should have a single specification for
iFCP and FCIP.  May be all we need is a common frame format between them.
The N- or NL-nodes can care less about routing or tunneling. Just make sure
FLOGI and name services for discovery staying transparent.

Am I right in this assessment?

Y.P. Cheng