RE: FCIP: RE: iFCP

[Joshua Tseng <jtseng@NishanSystems.com>]

Hi Wayland,

Thanks for your very good questions.

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

Yes, you are absolutely correct about this.  The IP network essentially
becomes the "fabric".  More on this below.

> 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 

Yes, you are correct.  An iFCP gateway CAN be connected to the
FC fabric.  In this sense, iFCP can allow an implementer to preserve
pre-existing investments in Fibre Channel, with the goal of migrating
to a 100% IP fabric solution in the long run.  It is an implementation
choice (not requirement) as to whether to implement a FC fabric switch
in the iFCP gateway, and the iFCP protocol doesn't need to specify how
to do this.  FC-SW-2 and other Fibre Channel specifications provide
everything needed to interface with existing Fibre Channel fabrics.

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

There are various implementation approaches that can address this.
One method is for the iFCP gateway to support E-Port, which by definition
requires that FSPF be implemented.  This approach may require one of the
iFCP gateways to become the principal switch.  But there are other methods
and approaches which do not require such complexity.

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

Once again, there are implementation approaches which can address this.
But keep in mind your earlier point that iFCP's primary purpose is to
replace the FC switching fabric with an IP switching fabric.  This being
the case, it is more likely to see topologies in which iFCP gateways
interconnect multiple FC fabrics and FC devices than the other way around.

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

Yes, I agree there is no reason why iFCP can't carry any other FC-4
protocol.

Josh

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