RE: FC encapsulation (FCIP)

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

Raj,

You should review the document.  There is encoding for these primitives as
both prefix and suffix.  An alternative scheme might be to place both prefix
and suffix into the prefix.  This would prevent a simple linear encode, but
would make accessing these items a bit easier.  Of course, you could use the
encapsulated frame size parameter as a means to find the suffix directly.
As far as being a complete document, implemented within SCTP actually
provides a much higher level of documentation than is present within iSCSI
specification.  Much of the configuration management, I argue, does not
belong within the transport specifications.  LDAP does a much better job in
providing configuration management.  Using pre-existing tools allows
flexibility in management required whether it is the client or the provider.

Within LDAP, you may wish to add flags to prohibit acceptance of various
settings from various clients on the control stream as example.  What you
will find missing in this document is how to go about mapping and filtering
frames.  Something iSCSI has yet to address as well.  As some point, you may
wish to map a subset to FC or Ethernet cable as example.  Should this
standard be used as a bridge, a timestamp could be used within a prefix to
decide if the frame is stale.  Such an option would not be required if it
was not acting as a bridge.  A simple buffer will add adequate latency to
provide effective bandwidth control within a bridge by taking advantage of
burst limits.

Doug

> -----Original Message-----
> From: Raj Bhagwat [mailto:rajb@lightsand.com]
> Sent: Friday, September 15, 2000 9:24 AM
> To: Black_David@emc.com; dotis@sanlight.net; ips@ece.cmu.edu
> Subject: RE: FC encapsulation
>
>
> David,
>
> The 'FC over IP' draft specifies how to encapsulate any FC frame with no
> regard to what is inside the FC frame. BLS/ELS commands have regular FC
> frame format (FT-1) with 24-byte FC header and optional payload.
> The things
> 'FC over IP' cannot encapsulate are primitive signals and primitive
> sequences because they are not FC frames. These are meant for
> physical link
> level operation only.
>
> Regards,
>
> Raj.
>
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> 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
> ---------------------------------------------------
>
>