RE: iFCP vs FCIP

[Joshua Tseng <jtseng@NishanSystems.com>]

Wayland,

[stuff deleted]
> >
> > 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.
> 
FC devices which are internetworked using iFCP will have their
exchanges transported over TCP.  TCP will re-order the segments
in the event of out-of-order before it passes the data up to
iFCP and FCP.  Whether the network reorders or not is immaterial.

As far as OSPF, it is no different from FSPF (actually, I should
say FSPF is no different from OSPF).  Therefore, OSPF's behavior
in support of mFCP/UDP is be no different from that of a Fibre
Channel fabric compliant with FC-SW-2.

[stuff deleted]
> >
> 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

HINT HINT.... (!!)

> 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.

Yes, you are very perceptive regarding the things that an iFCP gateway
IMPLEMENTATION can do.  FCIP is explicitly prevented from doing
these things because it is a tunneling protocol.  It therefore
is prevented from performing implementation-specific adjustments
that may be needed to stabilize and optimize the interaction
between two independent transports (i.e., FC and TCP/IP).

> 
> 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.

As I will be mentioning at the upcoming IETF, iSNS can also be
extended to provide a dynamic tunnel discovery mechanism for
FCIP.

Josh

> 
> > Josh
> >
> -Wayland
>