RE: iFCP as an IP Storage Work Item

[Charles Monia <cmonia@NishanSystems.com>]

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Friday, January 05, 2001 3:58 PM
> To: ips@ece.cmu.edu
> Subject: RE: iFCP as an IP Storage Work Item
> 
> 
> > While I'm at it, and since this issue has come up several 
> times, I should
> > point out that the NAT-like address translation we do 
> reflects a design
> > choice made to exploit IP scalability. We could have made 
> the tradeoffs
> > differently without affecting iFCP in any fundamental way.
> 
> I'm not sure about that.  An important consequence of the 
> NAT-like address
> translation is that the allocation of the 24 bit addresses 
> used for S_ID and
> D_ID
> need not be coordinated across the iFCP boxes.  If two boxes 
> happen to use
> the same address(es), the conflicts are resolved by:
> - Picking new addresses for the remote ports on the FC side 
> of iFCP and
> 	translating appropriately.
> - Using the IP addresses on the IP side of iFCP to disambiguate which
> 	iFCP box is involved.
> If this address translation isn't done, the resulting need 
> for coordination
> of
> address allocation strikes me as a "fundamental" change, 
> especially given
> the fact that both FC fabrics and loops have their own ideas about how
> address allocation happens.
> 

Hi David:

You are correct about the need to coordinate such address assigments across
gateways. As you suggest, there are additional consequences stemming from
the way N_PORT addresses are assigned on the FC side of the gateway.  All of
these can be handled by  straighforward extensions to iFCP.

Relative to the basic iFCP model for communications between N_PORTs,
therefore, I don't consider these differences to be fundamental.

Charles