Subject: RE: iFCP as an IP Storage Work Item

From: Joshua Tseng <[email-masked]>
Date: Thu, 4 Jan 2001 10:53:42 -0800

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:[email-masked]]
> Sent: Thursday, January 04, 2001 5:47 AM
> To: [email-masked]'
> 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:[email-masked]]
> > 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
> > 
>

---

From: "Venkat Rangan" <[email-masked]>
Date: Mon, 8 Jan 2001 19:09:35 -0800

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.

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.

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

Regards,

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]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

Regards,
Josh

---

From: Matt Wakeley <[email-masked]>
Date: Tue, 09 Jan 2001 14:08:46 -0800

Joshua Tseng wrote:
> as a gateway technology only.

If iFCP is a "gateway", that to me means that it will convert FCP to iSCSI. 
In that case, FCP is defined as a standard, and iSCSI is a work in progress by
this group.  Those building such gateways then only have to figure out how to
make one side of the gateway look native to the other.  What is there to
standardize?

-Matt Wakeley
Agilent Technologies