RE: iFCP vs FCIP

[Charles Monia <cmonia@NishanSystems.com>]

Hi Folks:

See comments in-line below.

Charles
> -----Original Message-----
> From: Wayland Jeong [mailto:wayland@troikanetworks.com]
> Sent: Wednesday, December 06, 2000 8:05 AM
> To: 'Joshua Tseng'; Venkat Rangan; Ips (E-mail)
> Subject: RE: iFCP vs FCIP
> 
> 
> [ stuff deleted ]

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

At the architectural level, I believe the differences are significant.

In tunneling, the IP session endpoints are at the edge of the fibre channel
fabric. Here the role of the IP network is limited to providing a
transparent conduit for inter-san frame traffic.

iFCP extends the session endpoints, and hence the IP network boundary, to
the FCP storage devices themselves. The "net" effect is that iFCP and iSNS
can evolve within and and directly benefit from the sizeable investment in
IP technology. The result is a true IP storage fabric.

Charles