Re: Request to exclude FC over IP from storage over IP working group charter

[hufferd@us.ibm.com]

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