RE: iFCP vs FCIP

[Wayland Jeong <wayland@troikanetworks.com>]

[ stuff deleted ]

>> 
>> An example is out-of-order delivery of exchanges. Creating an 
>> FC mesh with
>> FSPF (as described in FC-SW-2) can cause out-of-order delivery of FCP
>> exchanges. End points are supposed to deal with out-of-order 
>> delivery, but
>> very few SCSI drivers and target mode devices appear to deal 
>> with this. So,
>> fabric vendors are forced to guarantee in-order delivery; one 
>> way they do
>> this is to ensure that FSPF routes remain "fixed" and a route 
>> change can
>> only occur after an R_A_TOV time elapses without any I/Os on the ISL.
>
> Because iFCP uses TCP, in-order delivery is guaranteed by iFCP.
> If you are thinking about mFCP/UDP, most OSPF implementations will
> not chose different paths for traffic between the same two IP 
> addresses.  So the only case you will get alternate route selection
> is in a route-failure situation, in which case out-of-order is
> not your main concern (packet loss is).
>
Venkat is correct. In FC fabrics, you must be careful about re-routing
traffic. Many FC end-points will login in requesting in-order delivery. If
you change the route without waiting for outstanding exchanges to expire,
you may confuse some HBA's and targets. Many FC switches have the option of
re-routing immediately upon detecting a route failure or waiting for R_A_TOV
before invoking an alternate path.

[ more stuff deleted ]

>> 
>> Extending storage over a wide area either with iFCP or FCIP 
>> or FC-BB-2 needs
>> consideration of how applications are to deal with these problems and
>> issues. Without block-level applications adapting to 
>> wide-area networking
>> (loss rates of 10^-4, latencies of 100ms), it becomes harder 
>> to take care of
>> these issues in transport layer. Although iFCP and FCIP are 
>> both workable
>> technologies, I'm not sure if a mere address translation, or 
>> setting up a
>> tunnel is adequate. Again, what guarantees can we provide 
>> about in-order
>> delivery at the FCP Portals of iFCP?  Maybe block-level access in host
>> drivers and kernel block-level I/O will take care of these 
>> over time. But
>> until then, FC products and fabrics will continue to have its 
>> role. In that
>> respect, FC over ATM (FC-BB-2) appears to be  closer to the 
>> original design
>> goals of FC, compared to iFCP. BTW, I assume that iFCP handles FC-AL
>> correctly, by implementing an FL_Port equivalent.
>
> I agree that iFCP and FCIP have some common issues with regard to WAN
> networking which might be resolved in a similar ways.  However, note that
> in the iFCP case, the iFCP gateway is a visible entity to Fibre Channel
> devices.  Thus, the iFCP gateway does have the extra benefit of being
> able to interact with Fibre Channel devices, such as to manipulate FC
> frame sizes (to avoid fragmentation), and B-B credits (to coordinate TCP &
> B-B flow control).  The FCIP approach is much simpler--just pass
everything
> through the tunnel.
>
I don't believe that an iFCP gateway and an FCIP tunnel differ in their
respective abilities to segment and re-assemble traffic or manage credit
based flow control. The latest FCIP proposal which incorporates TCP as the
reliable transport between FCIP entities will require that these devices
fragment IP packets along the MTU of the network and possibly segment TCP.
Since iFCP is essentially an encapsulation as well, I don't see that there
is any difference here . . . unless you are implying that you spoof the FC
end-point fragment size by returning PLOGI ACC with a modified common
service parameter page (i.e. trick the FC nodes into sending conveniently
sized FC frames by modifying the max receive buffer size negotiated
parameter). Similarly, I don't see how an FCIP device and an iFCP gateway
differ relative to BB credit. Any effort to link BB credit on the FC side
with TCP flow-control on the LAN side would be highly implementation
dependent.

On the contrary, I see the main difference between FCIP and iFCP is in how
each performs naming. In FCIP, the SAN is one logical FC connected network
with the IP tunnel being for all intensive purposes, transparent. In this
case, the naming between FC SAN islands are coupled and thus the need for
FC-BB, BSW and all that gunk. Whereas in iFCP, naming is handled through a
DNS/SNS entity allowing devices to be named by referencing the IP gateway
and the MAC address (D_ID) behind it. I like to think of it as the
difference between tunneling between MAC bridges versus a true gateway.

> Josh
>
-Wayland