RE: iFCP implementation doubts

[Charles Monia <cmonia@NishanSystems.com>]

> -----Original Message-----
> From: Sathya [mailto:n.sathya@gdatech.co.in]
> Sent: Wednesday, June 13, 2001 6:22 AM
> To: ips@ece.cmu.edu
> Cc: sathya
> Subject: iFCP implementation doubts
> 
> 
> 
> Hi all,
>  I am working on iFCP/FCIP implementation for bringing up a 
> LAN -SAN Switch. I have some doubts on the iFCP protocol 
> implementation
> 
> 
> The iFCp document specifies a Switch topology for connecting 
> the iFCP gateway , the master Switch and the FC elements. Is 
> this topology a mandatory or can we go with a FC-AL configuration ?
> 

Hi Sathya:

There are no restrictions on the FC fabric topologies that an iFCP gateway
can support, so a gateway implementation can support loops as well as
switches.

The switch topology shown in the spec is simply a convenient example,
intended to show the transition from a fibre channel fabric to an IP fabric.
(Since this issue has come up before, I believe it's worthwhile to discuss
alternate FC topologies in an appendix to the iFCP spec.)

> 
> If Switch Topology:
>  
> 1. what shall be the interaction between the iFCP gateway and 
> the Principal switch in terms of FC Domain address and N port 
> ID assignments? 
> 

If the iFCP gateway is operating in address translation mode as part of a
switched environment, then it simply receives its domain I/D from the
Principle Switch.


> 2. Is it possible for a iFCP GW and the FC Switch (Master) to 
> have transactions other than via the E-port
> 

Yes -- Another way is to emulate a hub, and present the FC devices as shown
below.

+----------+      +-------+     +------+FL     FC-
| FL Port  |      | iFCP  | IP  | iFCP +<----->AL
|          +<-FC->+ GW    +-----+  GW  |Port
+----------+  AL  |       |Cloud|      |
                  +-------+     |      |FL     FC-
                                |      +<----->AL
                                |      |Port
                                +------+

In the above topology, the left-hand iFCP GW presents the remote devices as
loop-attached NL_PORTs attached to the FL port.


+----------+      +-------+             +------+NL     FC-
| NL Ports |      | iFCP  |             | iFCP +<----->AL
|          +<-FC->+ GW1   +--IP Cloud---+ GW2  |Port
+----------+  AL  |       |             |      |
                  +-------+             |      |NL     FC-
                                        |      +<----->AL
                                        |      |Port
                                        +------+

In this alternative topology, GW1 and GW2 present remote devices as NL_PORTs
attached to a local loop.

Once again, these are examples and other configurations are possible.

> 3. Or the iFCP GW can take the functionality of even the 
> Principal switch?
> 

Yes.

> 4. For an existing iFCP network will it be possible to add 
> the iFCP gateway  If so what will be the methods to handle 
> the already assigned addresses without any conflict.?
> 

In address translation mode, there should be no problem in gracefully adding
an iFCP gateway, since the scope of the N_PORT addresses for locally
attached devices is restricted to the GW.

> If FC-AL Topology: ----- (if it is allowed by the iFCP )
> 
> 1. Can we have the iFCP GW as the Loop Master in the FC-AL 
> and the FC Switch as one of the loop element?
> 

Yes -- as described above, a gateway can implement either role in a loop
topology.  I assume the case you refer to above is one in which the FC
switch element implements logical loop behavior by representing
switch-attached devices as though they were connected to an FC-AL loop.


> 2. If (1) is allowed then whether the Domain ID assignment 
> for the FC Switch is controlled by the iFCP GW or the 
> Switch can have its own domain ( i.e. ) the switch can be 
> independent on maintaining its FC domain by having a separate 
> iSNS Server as a repository for IDs.
> 
> 

I'm not sure I understand the question.  As an FL port, the gateway would,
of course, be in charge of domain ID assignment, in which case, it could
then choose to operate in address-transparent mode and obtain its domain id
from the iSNS server.

Charles