bridging issues

[julian_satran@il.ibm.com]

Dear colleagues,

Lately some iSCSI issues related to bridging to/from FC networks where
brought to my
attention.  I thought that it would be wise to share them (and my first
rough attempt to solve them) with you for two reasons:

   that's why we have a Working Group (don't we?)
   there might be more of this kind and this is a good time to think about
   them and bring the with or without a solution to the WG

FC and iSCSI are SCSI mappings over a network that share a "network" view
of the
transport infrastructure but have widely different views of the network
with regard
to distances, reliability, flow control etc..

FCP assumes a locally controlled environment using an unreliable delivery
version of FC
and doing recovery (a very rare event) at FCP level.

FC addressing model uses locally generated dynamic addresses as part of the
"naming"
and its tagging.

An iSCSI initiator should be able to operate a FCP target through a very
simple and
stateless (or almost stateless) gateway.

A designer attempting to do this (and I know many of you already did or are
in the midst
of doing that) will find it difficult to do achieve a stateless design (but
not impossible).

The FCP recovery model from packet loses (commands, data and status) is
based on sequencing (if lost packets are within sequences) or timeouts if
those are at sequence
boundaries.  In the FC world those are very rare events and in an iSCSI+FCP
hybrid
could be handled by a statefull gateway (expensive) or by a stateless
gateway and
a more radical initiator recovery - based on TCP connection close and
reopen.
The later solution requires iSCSI to enforce a set of timeouts (an
initiator requirement only)
and provide an API for timeout setting and connection abort to an upper
layer.
Enforcing a set of timeouts would have the good side-effect of making iSCSI
also
tolerant to aberrant device behavior - and that is unfortunately bound to
happen more
often as the complexity of the devices will increase.
Please observe that the set of timeouts I am referring to are not a
"protocol" element
(they do not appear on the wire). Specifying the expected behavior of an
iSCSI
initiator will simplify the task of building bridges to FCP.
We propose to do so by adding a "host requirements" chapter.

Another bridging issue is the initiator tag-translation mechanism.
iSCSI is requiring the initiator issue a unique tag for each task but does
not require any structure for the tag. This way an implementer may choose
the most efficient structure for his implementation (e.g.,
use the address of it's control structure representing the task as a tag).

FCP on the other hand demands some structure for the tag.

A stateless bridge would want to pass the tag unchanged from initiator to
target or translate it with a stateless rule.

If we restrict the design space to gateways that present a "homogenous"
view of the device conglomerate behind them (e.g., all devices are FCP)
and we may pass this information to the initiator - then the initiator can
use the slightly more restrictive FCP tagging mechanism.

Julo