RE: iFCP as an IP Storage Work Item

[julian_satran@il.ibm.com]

There is no NT/2000 FCP support. Drivers are build on the "old" SCSI port
driver. Very little if any FC is visible (even addressing is twisted).

Julo

Charles Monia <cmonia@NishanSystems.com> on 13/01/2001 00:35:52

Please respond to Charles Monia <cmonia@NishanSystems.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  RE: iFCP as an IP Storage Work Item




Hi Julo:

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

I don't understand where you're coming from.

Granted, you won't find many FC adapters on notebooks and desktops.
However
every enterprise-class operating system, including Windows NT/2000,
provides
robust Fibre Channel support.  What's more HBAs, host driver stacks and
middleware for management and failover have been deployed and in-service in
mission-critical applications for some time.

End users have an enormous investment in qualifying, deploying and
supporting these systems. Anyone who's ever had to deal with such users in
major accounts will appreciate what's at stake. From that perspective, I
believe there's value in an approach to IP migration that protects that
investment.

Charles
> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Thursday, January 11, 2001 9:23 PM
> To: ips@ece.cmu.edu
> Subject: RE: iFCP as an IP Storage Work Item
>
>
>
>
> 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
> > > >
> > >
> >
>
>
>