RE: FCIP: RE: iFCP

[Wayland Jeong <wayland@troikanetworks.com>]

I agree. The fact that the FCIP and iFCP are anagrams of each other is
about where the similarity ends ;-)

The intention of iFCP is to completely replace a FC fabric with an IP
network.
Thus, an iFCP gateway is best connected directly to FC devices. FCIP on
the other hand is a way to extend a FC fabric across an IP infrastructure. 
Connections between FCIP devices appear to the FC network, for all intensive

purposes, as ISL's between E-ports. 

I am curious though . . . is it the intention of iFCP to not preclude the
use of
a FC fabric within the gateway? That fact was implied in this thread, but
I'm
not quite sure how that would work. Since an iFCP device allocates 24-bit
identifiers to remote FC attached nodes, wouldn't an iFCP device on a FC
fabric need to always be the principal switch? If a FC fabric exists inside
the gateway, how is the routing resolved (FSPF in FC and OSPF in IP)?
How do you resolve routing on a FC fabric which has two iFCP gateways?
Since each gateway locally creates a 24-bit key for describing remote 
IP address and N_port ID pair, how do you keep the remote D_ID naming 
coherent between gateways connected to a common FC fabric?

Also, even though the name iFCP implies that the gateway only services
FCP (i.e. SCSI), I don't believe that it precludes the transport of any FC-4
layer protocol like FC-VI. There doesn't seem to be anything FCP-specific
in iFCP.

-----Original Message-----
From: Joshua Tseng [mailto:jtseng@NishanSystems.com]
Sent: Thursday, November 23, 2000 11:53 PM
To: Murali Rajagopal; Vi Chau
Cc: ips@ece.cmu.edu
Subject: RE: FCIP: RE: iFCP


Murali,

What I meant by this is that in iFCP, end-to-end routing decisions
are made by examining the destination IP address.  FCIP is a
tunneling protocol, and does not specify switching or forwarding
of Fibre Channel frames.  Rather, it delegates forwarding decisions
to a Fibre Channel switch running the FSPF or DMP routing
protocols (specified by FC-SW-2).  These routing decisions are
made in the Fibre Channel network domain through examination of
the D_ID.

On the other hand, iFCP specifies the mapping of the D_ID to a
destination IP address, after which the iFCP gateway can make the
forwarding decision through a routing table lookup of that IP address.
The routing table is populated by OSPF or some other IP routing
protocol.  The intent of my last message was to Vi was to clarify a
misunderstanding that a Fibre Channel switch needs to be implemented
in the iFCP gateway.  In fact, it is an IP switch in the iFCP gateway
which makes the next-hop forwarding decision.  This is a subtle, but
very important difference between FCIP and iFCP.  Mark Carlson is 100%
correct in his statement that iFCP can be implemented without a Fibre
Channel switch.

Yes, I understand that an FCIP-tunneled Fibre Channel frame is
routed through the IP network through its IP address.  But that
is only after the Fibre Channel switch has made a routing decision
based on the D_ID and either FSPF or DMP, and has forwarded the
frame to the proper E-Port.  All FCIP does is tunnel the frame
between E-Ports, after all routing decisions in the Fibre Channel
domain have been made.  The IP routing that takes place occurs only
to support the tunnel that connects the E-Ports.

I hope this clarifies everything.

Josh

> -----Original Message-----
> From: Murali Rajagopal [mailto:muralir@lightsand.com]
> Sent: Wednesday, November 22, 2000 5:32 PM
> To: Joshua Tseng; Vi Chau
> Cc: ips@ece.cmu.edu
> Subject: FCIP: RE: iFCP
> 
> 
> With my Technical Coordinator hat off:
> 
> I like to clarify that the FCIP protocol forwards all 
> encapsulated FC frames
> inside the IP network also based on destination IP 
> address.There are No FC
> Switches or no FC switching inside the IP network. In this 
> respect, both
> iFCP and FCIP are similar.
> 
> Regards,
> 
> Murali Rajagopal
> LightSand Communications
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Joshua Tseng
> Sent: Tuesday, November 21, 2000 7:26 PM
> To: Vi Chau
> Cc: ips@ece.cmu.edu
> Subject: RE: iFCP
> 
> 
> Hi Vi,
> 
> Lest there be any confusion about iFCP and mFCP, I would
> like to clarify that in these protocols, all next-hop
> forwarding decisions between switching nodes are made on the
> basis of the destination IP address, NOT the D_ID as
> in Fibre Channel switches.  While an iFCP implementation
> MAY have Fibre Channel elements, these are statelessly
> mapped to IP.  But once again, all routing and forwarding
> decisions are made by the switch looking at the destination
> IP address.  This means you need an IP switch, not a
> Fibre Channel switch, to route and forward iFCP through
> a network.
> 
> Josh
> 
> > -----Original Message-----
> > From: Vi Chau [mailto:vchau@gadzoox.com]
> > Sent: Tuesday, November 21, 2000 4:35 PM
> > To: 'mark.carlson@sun.com'; KRUEGER,MARJORIE (HP-Roseville,ex1)
> > Cc: 'John Hufferd'; ips@ece.cmu.edu
> > Subject: RE: iFCP
> >
> >
> > If you have an iFCP gateway that connects multiple
> > FC nodes to the IP network, and if you want these
> > FC nodes to talk to one another, you need an FC
> > switch inside the gateway. An FCoverIP device
> > works in exactly the same way; but it is not
> > limited to shipping FCP frames around. It can do
> > FC-VI, for instance, in addition to FCP. SANs (and
> > more) can be had with FCoverIP.
> >
> >
> > Vi Chau
> > Gadzoox Networks, Inc.
> >
> >
> > > -----Original Message-----
> > > From: Mark A. Carlson [mailto:mark.carlson@sun.com]
> > > Sent: Tuesday, November 21, 2000 3:16 PM
> > > To: KRUEGER,MARJORIE (HP-Roseville,ex1)
> > > Cc: 'John Hufferd'; ips@ece.cmu.edu
> > > Subject: Re: iFCP
> > >
> > >
> > > IMHO, the most interesting thing about this proposal is that
> > > "SAN"s can be had without a single FC switch anywhere. This
> > > is quite different from bridging FC switch based SANs over
> > > IP.
> > >
> > > All the n*n stuff can happen in IP based switches without
> > > changing hosts or devices (in theory ;-). The "edge connects"
> > > do the conversion for hosts and devices.
> > >
> > > -- mark
> > >
> >
> >
>