RE: iFCP as an IP Storage Work Item

[julian_satran@il.ibm.com]

Josh,

iFCP as way to keep your investment in FCP stacks is a very weak argument.
FCP stacks are not that stable neither that prevalent (there is none in the
most widespread OS family - Windows).

A gateway for a single device should be the exception rather than the rule.

I can support it as a work item ONLY if it plays a real gateway role and
can coexist with FCIP is some synergistic fashion.
As a end-to-end proposal is has little value IMHO.

Julo

Joshua Tseng <jtseng@NishanSystems.com> on 09/01/2001 07:39:18

Please respond to Joshua Tseng <jtseng@NishanSystems.com>

To:   Venkat Rangan <venkat@rhapsodynetworks.com>
cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: iFCP as an IP Storage Work Item




Venkat,
>
> Josh,
>
> Thanks for the clarification that iFCP is only presented as a gateway
> protocol. The one comment we would make is that we have FC to
> SCSI gateways
> already in place, without the need for any standards body
> standardizing a
> new protocol. The function of the gateway is defined by the
> standards for
> the two protocols being "connected", and gateway details are left as
> implementation details.

Actually, what I meant by gateway protocol is that it is a protocol
spoken by gateways.  It doesn't specify anything about how to
implement the protocol, which is internal to the gateway device as you
point out.  iFCP is the protocol that shows up on the IP network when
at least two iFCP gateways transport storage data between them.

>
> On another note, it should be feasible to build a gateway
> that receives FCP
> frames from an N_Port or NL_Port of a SCSI Initiator and map
> the FCP frames
> into iSCSI frames. The frames are sent on an IP interface and
> routed by a
> normal IP network and another gateway reconverts the iSCSI
> PDUs back to FCP
> frames and sends them to the target. You will notice that
> this does not
> require any routing in the FC Plane and accomplishes the same
> end goals as
> iFCP. Also, this does not require any further standards work,
> besides the
> usual FCP, iSCSI and related naming protocols. This also
> provides the same
> scalability of number of nodes on the network, because the
> conversion from
> locally significant S_ID and D_ID to iSCSI IP addresses can
> be done, with
> help from a standardized naming effort such as iSNS.

Yes, I agree.  But this is a different gateway which has nothing
to do with an iFCP gateway.  Definitely these types of gateways
will be needed as we transition to iSCSI.  The new iSNS draft has
a diagram showing both iSCSI-FC gateways and iFCP gateways.  They
have different roles.

>
> Based on these, we believe the need for IP Storage working
> group to pick up
> iFCP as a work item is reduced.

hmmm....you lost me here.  An iFCP gateway has nothing to do with
iSCSI.  They are completely separate.

In order to use iSCSI, you need one of the following:

1)  Two iSCSI devices
2)  One iSCSI device, one FC device, and one iSCSI-FC gateway
    (which you described above)

The situation of two FC devices and two iSCSI-FC gateways is clearly
not a design objective of iSCSI.  Of course it can be done, but we
believe iFCP is clearly the best solution here.

Fibre Channel has its issues, but one thing is certain:  the FCP driver
stacks are very stable and can provide excellent performance for storage
applications.  But the drawback is FC's networking capabilities leave
much to be desired.  On the other hand, IP networking capabilities are
quite stable and work exceedingly well, but the iSCSI driver stack does
not exist yet.

So, iFCP's objective is to marry the best of both worlds--to take the
existing stable, high-performance driver stacks of Fibre Channel and
directly internetwork their individual N_PORTs using TCP/IP.

Therefore, iFCP is an opportunity to leverage the existing and proven
Fibre Channel driver stacks and combine them with the capabilities that
IP networking can provide.  Until the day we have stable iSCSI driver
stacks everywhere, this may prove to be an attractive alternative for
many end users.  Another comparison I liken it to is the need for
NAT until we have IPv6 everywhere.

Josh

>
> Regards,
>
> 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
> Joshua Tseng
> Sent: Thursday, January 04, 2001 10:54 AM
> To: Ips@Ece. Cmu. Edu
> Subject: RE: iFCP as an IP Storage Work Item
>
>
> I don't want to stifle any creative technical discussion here,
> but I feel the need to remind everybody that iFCP is positioned
> as a gateway technology only.  While the thought of "native"
> iFCP HBA's might be interesting, this discussion is
> completely irrelevant with regard to whether iFCP should
> or should not become an IPS work item.  iFCP is being proposed
> as an IPS work item purely on its merits as a gateway technology.
>
> Regards,
> Josh
>
> > -----Original Message-----
> > From: Stephen Byan [mailto:Stephen.Byan@quantum.com]
> > Sent: Thursday, January 04, 2001 5:47 AM
> > To: 'ips@ece.cmu.edu'
> > Subject: FW: iFCP as an IP Storage Work Item
> >
> >
> >
> >
> > -----Original Message-----
> > From: Stephen Byan
> > Sent: Thursday, January 04, 2001 8:40 AM
> > To: 'Bill Terrell'
> > Subject: RE: iFCP as an IP Storage Work Item
> >
> >
> > It's all the FC stuff that lets iFCP work over an unreliable
> > data transport
> > like UDP. It's redundant when running over TCP/IP.
> >
> > Regards,
> > -Steve
> >
> > > -----Original Message-----
> > > From: Bill Terrell [mailto:terrell@troikanetworks.com]
> > > Sent: Wednesday, January 03, 2001 6:10 PM
> > > To: 'Stephen Byan'
> > > Subject: RE: iFCP as an IP Storage Work Item
> > >
> > >
> > > >The downside of this advantage is that native iFCP
> devices would be
> > > burdened
> > > >with greater complexity and cost. I therefor think iFCP
> > > should not be an IP
> > > >Storage work item.
> > > >
> > > >Regards,
> > > >-Steve
> > >
> > > How is a native iFCP endpoint (initiator or target) more
> > > complex or costly
> > > than an iSCSI native endpoint? What are the specific
> > > difficulties inherent
> > > to native iFCP devices versus native iSCSI devices?
> > >
> > > Bill
> > >
> >
>