RE: FC encapsulation

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

David,

I understand a desire to start with a clean slate and then look to see how
FCP can map into whatever is created.  A valid alternative would be to take
FCP structures 'as is' and  define use within constructs of IP transport.  A
considerable advantage from control and documentation would immediately fall
into place.  Unless there is something abhorrent in starting from a known
point, it should receive consideration.  No one should expect IP transport
to be tightly coupled to SCSI as it is currently conceived.  Wide-open
traffic problems found with FC will become apparent with IP and dealt with
in much the same manner.  The value of such a standard would be in terms of
facilitating both simple bridges with minimal states as well as native IP
access.  There are solutions for perceived limitations with the FC
transport.  A simple buffer and a timestamp prefix, as example.  If you wish
to combine connections, there are already IP standards for doing so.  This
effort may be years ahead to use what already exists and define the practice
as applied.

Discussing tags for 256 commands in a drive from an initiator? 64 bit tags
would allow mapping to an address on a high end machine.  Most often this is
mapped to a 32 bit process ID and so perhaps 32 bits would be okay.  A
justification for tossing the ugly baby?  Now we have a SCSI level flow
control of check and dump.  Hardly the improvement expected over FCP.  Gaps
in FC documentation only illustrates effort required to strike a new path.
With much to be done once communications structures become defined, I would
expect a far easier time explaining why something was added rather than how
it was remapped.

Doug

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, September 14, 2000 6:42 PM
> To: dotis@sanlight.net; Black_David@emc.com; ips@ece.cmu.edu
> Subject: FC encapsulation
>
>
> Doug,
>
> I think you missed the point ...
>
> > The FCoverIP specification has already defined FC encapsulation.  Should
> > there be  additional information required to transport an FC frame over
> IP,
>
> I suggest you reread Charles Monia's proposal for use of FCP formats in
> iSCSI - this is the sort of thing that T10 is asking for, although the
> request
> is not for slavish adherence to FCP in all aspects.  This is fundamentally
> different from the FC over IP approach of encapsulating SCSI in FCP in
> FC-2 and then in an IP transport of some form.  It's not at all clear that
> FC-2 is necessary in this context.
>
> FWIW, the current version of FC over IP doesn't even encapsulate all
> of FC-2.  For example, the ABTS basic link service used by FCP to
> abort a SCSI task is missing.  I presume that this is an oversight that
> will be corrected in a future version of the FC over IP draft,
> but I suspect
> that this isn't the only basic or extended link service that needs to be
> added.
>
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>