Re: Request to exclude FC over IP from storage over IP workinggroup charter

["Robert B. Harmon" <bharmon@osicom.com>]

If we are looking for concensus, I'd much rather 
have FC/IP here.

FC/IP has gateway issues as part of the charter.  An FC/IP
bridge is the 1st step to a iSCSI/FCP gateway.

hufferd@us.ibm.com wrote:
> 
> I think that Somesh stated this very well and I agree the FC over IP is an
> important problem but a completely different problem.
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSD San Jose Ca
> (408) 256-0403, Tie: 276-0403
> Internet address: hufferd@us.ibm.com
> Notes address: John Hufferd/San Jose/IBM @ IBMUS
> VM address: hufferd at IBMUSM54
> 
> somesh_gupta@hp.com@ece.cmu.edu on 08/10/2000 03:54:37 PM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   ips@ece.cmu.edu, mankin@east.isi.edu, sob@harvard.edu
> cc:
> Subject:  Request to exclude FC over IP from storage over IP working group
>       charter
> 
> Scott/Allsion,
> 
> I would urge you to not include FC over IP in the charter of
> the SCSI over IP working group.
> 
> Using (TCP)/IP to transport SCSI command blocks fits very
> naturally as part of the SCSI Architecture Model which allows
> for the use of different transports to transfer SCSI
> commands. This include the parallel SCSI, fibre-channel (FCP),
> SCI, and many others including a generic packet transport
> mechanism.
> 
> In this case (TCP)/IP acts as a mechanism to transport an
> application level protocol as is intended - preserving the
> protocol layering principles and allowing for an architecturally
> clean solution.
> 
> I have been impressed with the momentum behind this idea and saw
> a number of participants at the ietf who were there for this
> session (including myself). This specification will really drive
> the convergence to IP based networks. There is significant
> technical and commercial push for this idea.
> 
> FC over IP is a proposal (at least based on the presentation at
> the ietf meeting in Pittsburg) to have IP act as a tunnel
> between two FC islands i.e. there is a fully functional
> fibre-channel island A and a fully functional fibre-channel
> island B, and the proposal is to connect them together using
> an IP based network (don't know if it is to make a super island
> or connect them as a "router" would connect two sub-nets).
> 
> I think that the problems being solved and the motivations (from
> a technical perspective - not just a commercial perspective)
> are significantly different.
> 
> 1. This is putting a transport over another transport using
> tunneling protocols. A lot of the issues will be about making
> one work while satisfying the contraints and using the
> capabilities of the other. Probably combines the timing and
> recovery mechanisms of the two transports in some horrible way.
> 
> 2. The naming issues are entirely different. In storage over IP,
> each of the partcipating entities is an IP entity. In FC over IP,
> the participating entities are actually FC entities and will have
> some mechanism of figuring out that the other FC entity lives
> across a tunnel avaliable on the local network. If the proposal
> is to create a larger net, then again the FC port addresses will
> have to partitioned in some interesting way.
> 
> 3. How would arbitrated loop work in such an environment of creating
> a large net, or will it connect only Fabric ports together.
> 
> 4. Security issues are again completely different as the end nodes are
> really not IP entities.
> 
> 5. The protocol encapsulation is also completely different.
> 
> In Summary, putting scsi over ip is architecturally very clean and
> accomodated by the SAM architecture as well as networking layered
> architecture. The end systems communicating in this case are using
> TCP/IP to transfer application (SCSI) PDUs and the problems/solutions
> have a very good framework to work with.
> 
> FC tunnels through IP is a commerically important problem to solve
> but is a completely different problem.
> 
> I would like to keep both of them seperate so that each of them
> can be successful and provide useful specifications.
> 
> Regards,
> Somesh Gupta
> Project Manager/Architect
> Storage over IP
> (for HP-UX servers)
> Hewlett-Packard