RE: iFCP as an IP Storage Work Item

[Charles Monia <cmonia@NishanSystems.com>]

> -----Original Message-----
> From: Ken Hirata [mailto:Ken.Hirata@Vixel.com]
> Sent: Thursday, January 04, 2001 6:57 PM
> To: Ips@Ece. Cmu. Edu
> Subject: Re: iFCP as an IP Storage Work Item
> 
> 
> Charles,
> 
> There's one item with your reply that I have a question 
> about.  With regards
> to processing overhead, do you agree that FCIP as a tunneling protocol
> would not have to look for ELSs in the Fibre Channel 
> datastream as iFCP
> must do?
> 

Hi Ken:

First of all, ELS's are well off the performance path, so there's no effect
on performance.

More to the point, we process ELS's and other frame traffic because doing so
gives us a big payoff in cost-performance.  A payoff that comes from
allowing iFCP implementations to intelligently leverage IP technology. For
example, maintaining a seperate session for each N_PORT login gives the
gateway  a handle for controlling the flows between individual FC storage
devices, thus fully exploiting IP-based routing and traffic management.
Concealing the Fibre Channel transport infrastructure behind the FC side of
the gateway eliminates the need to for a two-plane routing scheme. IP
routing is then unconstrained by and fully decoupled from FC routing.
More importantly, doing so makes it easier to integrate otherwise
incompatible FC infrastructures.

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.

Charles 
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385