SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iFCP: Responses to David Black iFCP Technical review comment s



    Hi David:
    
    Please see responses in line.
    
    > -- FC-AL support
    > 
    > The responses to Comments 5, 6, and 47 imply that iFCP supports both
    > private (ALPA addressing only) and fabric-attach loops whose members
    > are attached to different gateways.  I don't understand how this
    > can work because it requires forwarding FC-AL loop initialization
    > ELSs (LINIT) among gateways, but those ELSs do not have a usable
    > destination port (they're passed directly among neighbors), and
    > the ports involved in the loop have not performed either FLOGI or
    > PLOGI when the loop is initializing.  So how does a gateway figure
    > out whether and where to forward a LINIT that it receives?  I can
    > figure out how to make this work if only fabric-attached loops are
    > supported and loops never span gateways, but even that will need
    > some explanation.
    > 
    
    The issue is whether or not a gateway can support a loop topology. Currently
    deployed gateway and FC switch products support such topologies in one of
    the following ways:
    
    a) Loop topology emulation in which remotely attached N_PORTs are presented
    locally as loop-connected devices.  As you suggest, the loop is emulated
    locally and does not span gateways. The emulated device can support either
    the public or private loop protocol.  The 'view' looking into the gateway
    port from the fibre channel side is a series of N_PORTs presented as
    loop-attached devices (NL_Ports).  The loop population consists of
    externally attached devices and gateway-emulated NL_Ports.
    
    b) An FL port, which provides fabric access for loop-connected devices.
    
    Neither of these approaches requires anything special on the part of the
    iFCP protocol.
    
    The primitives with the behavior you ascribe to LINIT are those such as LIRP
    (Loop Initialization Report Position) and LILP (Loop Initialization Loop
    Position), which are frames serviced sequentially as they flow though
    NL_Ports on the loop. The loop primitive semantics may emulated locally by
    the gateway implementation and need not be propagated by iFCP.  How the
    gateway populates the loop with emulated NL_Ports is up to the
    implementation.
    
    As to LINIT, it is one in a set of ELS functions for remote control of a
    fibre channel public loop.   As such, these are standard ELSs which are sent
    to the 'Loop Fabric Address' (LFA) of the FL port controlling the loop. 
    
    This, however, does bring up the issue of exposing the fc network topology
    of the remote gateway region.  A gateway that chooses to expose remote,
    loop-connected devices as NL_Ports should assign the local alias such that
    the corresponding LFA can be derived by setting the port_id component of the
    address to zero.
    
    The discussion in the spec should be expanded to include these issues.
    
    > --- Multiple Gateways
    > 
    > The proposed new text is:
    > 
    >              For either iFCP fabric type, an N_PORT may be 
    > behind more than
    >              one gateway provided:
    > 
    >              a) One gateway becomes the 'principal switch' and
    > 
    >              b) All gateways attached to a given gateway 
    > region coordinate
    >                 the assignment of N_PORT IDs and N_PORT 
    > aliases such that
    >                 each N_PORT has one and only one assigned address.
    > 
    >              The above will be added to the specification.
    > 
    > The implications of multiple gateways for the same N_Port on iSNS
    > servers and other gateways needs to be discussed.  This may be short,
    > because if the Port's Network Address is registered with iSNS as
    > a consequence of FLOGI, only one address will be registered because
    > FLOGI only occurs once, and hence all traffic to the N_Port will
    > flow through one gateway.
    > 
    
    The constraints that should be documented are as follows: 
    
    a) Within a gateway region, all N_PORTs whether locally or remotely
    attached, must have one and only one N_PORT address.
    
    b)  All iFCP frame traffic between any two N_PORT pairs must flow through a
    single iFCP session.  However, each session may traverse a different gateway
    attached to the region.
    
    In order to meet these constraints, a multi-gateway implementation may
    require an out of band mechanism for redirecting frame traffic from one
    physical gateway to another.
    
    Charles
    
    


Home

Last updated: Tue May 14 03:18:32 2002
10114 messages in chronological order