RE: iFCP vs FCIP

[Douglas Otis <dotis@sanlight.net>]

Charles,

In very general terms, to minimize impact on a transport proposal and ensure
stability at the interchange level, keeping routing functions contained
within a separate document to that of an encapsulation document does seem to
offer several advantages.  Revision creep on the important aspect of
encapsulation with respect to perhaps a rapidly evolving routing scheme
could be avoided.  With a level of sensitivity to encapsulation, the user
would not be confused by changes to routing.  The user will not care as much
about how information is routed, but will care if the boxes properly
recognize exchanges.  Keeping encapsulation free of names would also be a
good technique of ensuring such functional isolation.  Judging from
difficulties incorporating a name server, I suspect it may be more efficient
to use authorization to handle routing.  The concept of dynamic naming and
out of sequence handling also seems at odds.  This could be an example of
why routing changes should be kept independent of encapsulation.

Doug

Doug

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