RE: FC/IP vs. iSCSI

["Douglas Otis" <dotis@sanlight.net>]

Elizabeth,

You should investigate the SCTP specification.
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-13.txt

It can be used to add congestion and packet loss control for FC over IP
applications with less than dedicated networks.  It directly handles
fragmentation, adds additional authentication and spoofing security,
improved error checking, and does not require sequential delivery.  SCTP
still allows frame alignment and would need only a minimal amount of
management (LDAP as example).  As a quick extension to the existing
specification, it then places FC over IP within the iSCSI charter.  For
applications where aggregation takes place by a hierarchy of FC controllers
and switches, FC over IP and FC over SCTP/IP makes sense.  iSCSI as proposed
does not for that environment.

Once a native IP device becomes available it should make use of existing
networking conventions for reliability and scalability. iSCSI should not be
designed to touch the top of the FC pyramid, but instead the bottom.  Lock,
cache, and array servers should remain close to the client or network
latency becomes a significant problem.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Rodriguez, Elizabeth G (Elizabeth)
> Sent: Wednesday, August 16, 2000 9:31 PM
> To: 'mjacob@feral.com'; csapuntz@cisco.com
> Cc: ips@ece.cmu.edu
> Subject: RE: FC/IP vs. iSCSI
>
>
> All,
>
> The purpose of FC over IP is to extend FC networks with minimal impact to
> existing devices and existing installations.
> It is not intended to be an iSCSI equivalent/counterpart, e.g. I would not
> expect someone to put FC over IP into an end device.  It is
> really intended
> to be something put into a switch, not at an endpoint.
>
> If you have an existing FC environment, the question is not whether you
> could run GigE as well (you could, and probably would), but do you want to
> replace all the existing FC environment (e.g. all the existing FC
> controllers, disks, tapes, RAID, JBOD, etc), with new equipment,
> (equipment
> that is iSCSI compliant), or do you want to add a single device
> at the edge
> of each of your FC fabrics, and enable the fabrics to overcome distance
> limitations utilizing a network that is already in place for other LAN/WAN
> traffic.
>
> Over the next few days, I will post more information about FC over IP to
> this reflector.
> This will include some of the items that will most likely become
> requirements for the FC over IP draft.
> Included will be some requirements addressing Costa's comments below.
>
> Elizabeth Rodriguez
> Lucent Technologies
> -----Original Message-----
> From: Matthew Jacob [mailto:mjacob@feral.com]
> Sent: Wednesday, August 16, 2000 6:16 PM
> To: csapuntz@cisco.com
> Cc: ips@ece.cmu.edu
> Subject: Re: FC/IP vs. iSCSI
>
>
>
> I'm certainly inclined to agree. The sole realistic purpose of
> requirements
> I've seen to date FC/IP is to utilize an existing FC environment so that
> management and data go over the same wire. If you're carrying SCSI over
> TCP/IP
> now, it's somewhat absured to try and carry FC/IP over the same transport.
> It's as if you want to tunnel TCP/IP over TCP/IP, which is a cute
> trick, but
> a
> trick for all that.
>
> If you have an existing FC optical environment, it could probably run
> GigEthernet just as well- and it then becomes a question as to
> whether iSCSI
> serves the systems and applications as well or better than
> FC-SCSI or FC/IP
> over the same physical media.
>
> -matt
>
>
> On 16 Aug 2000 csapuntz@cisco.com wrote:
>
> >
> > FC/IP is NOT an alternative to iSCSI for most applications.
> >
> > Unfortunately, making a protocol that works well in complex networks
> > is not as simple as just putting stuff into IP packets. IP packet
> > headers are not magical pixie dust that suddenly make higher-layer
> > protocol issues go away.
> >
> > The FibreChannel stack today has the following deficiencies which do
> > not disappear when tunneling over IP:
> > 	- FCP has no congestion control
> > 	- FCP deals poorly with packet loss
> > 	- Target naming is done with either 24-bit port IDs or 64-bit WWNs,
> > 	   neither of which scale to Internet size
> > 	- No secure login
> >
> > Of course, you could address all the deficiencies by fixing FCP. But
> > by the time you do that, I maintain you will most likely end up with
> > something in the same order of complexity as iSCSI/TCP/IP.
> >
> > -Costa
> >
> >
>