RE: iFCP as an IP Storage Work Item

["Peglar, Robert" <robert_peglar@xiotech.com>]

Some HBA vendors offer a full-blown NT port driver
now, instead of the (prior) NT mini-port which indeed
interfaced with the standard NT SCSIPORT.SYS driver.

Viz. Qlogic with their QLDirect driver.  It bypasses
SCSIPORT.SYS completely.

Rob


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