SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    FCIP Multiple Connection Management



    From pages 41-42 of FCIP rev 03 
    *******************************************
    5.5 Multiple Connection Management 
      
       A pair of FCIP device endpoints MAY establish a certain number of 
       TCP connections between them. Since a Virtual ISL potentially maps a 
       fairly large number of FC flows (where a flow is a pair of Fibre 
       Channel S_ID, D_ID addresses), it may not be practical to establish 
       a separate TCP connection for each Fibre Channel flow. In order to 
       address this, an implementation MAY choose to manage a pool of TCP 
       connections for a single Virtual ISL and map Fibre Channel flows to 
       TCP connections of that ISL. However, while assigning Fibre Channel 
       flows to TCP connections, an implementation SHALL follow the 
       following rules: 
      
       1)  Once a Fibre Channel flow is assigned to a TCP connection within 
           the virtual ISL, it SHALL send all Fibre Channel frames of that 
           flow on that connection. 
    
       2)  When an FCIP endpoint processes any response traffic from a 
           particular target, the Endpoint SHALL send the response on the 
           same connection on which the request was sent. 
      
       3)  Any class 2 ACK frames SHALL be sent on the same connection in 
           which the original frame was sent. 
      
       These rules are in place to honor any in-order delivery guarantees 
       that may have been made between the two end points of the Fibre 
       Channel flow. 
    *************************************
    
    Given the above rules, consider the following:
                               |-----|             |-----|
                     --------  |FCIP |--TCP_Con_1--|FCIP |   -------
    FC_Node_A -------|FC-SW |--|Dev1 |--TCP_Con_2--|Dev2 |---|FC-SW| ----
    FC_NODE_B
                     --------  |-----|             |-----|   -------
    
    FCIP devices 1 and 2 have a single Virtual ISL composed of two separate TCP
    connections.  Assume FC_NODE_A and FC_NODE_B both send PLOGI to each other
    at approximately the same time.  FCIP_Dev1 happens to choose TCP_Con_1 for
    the FC Flow of S_ID_A-to-D_ID_B.  FCIP_Dev2 happens to choose TCP_Con_2 for
    the FC Flow of S_ID_B-to-D_ID_A.  So far so good, both FCIP devices are
    following the above rules.
    
    Now, FC_Node_A sends the PLOGI ACC.  What is FCIP_Dev1 supposed to do?  Rule
    1 says choose TCP_Con_1 (this is the S_ID_A-to-D_ID_B flow and that flow has
    already been established to be TCP_Con_1).  Rule 2 says choose TCP_Con_2
    (this is a response to a frame that was received on TCP_Con_2).
    
    I believe rules 2 and 3 are not needed.  What the combination of all three
    rules really say is there must be a defined negotiation or hash algorithm
    that both FCIP_dev 1 and 2 have to follow to keep all of the traffic between
    FC_Node_A and B on the same TCP connection.  I believe this is totally
    unnecessary.
    
    If both sides obey only rule 1 then "any in-order delivery guarantees that
    may have been made between the two end points of the Fibre Channel flow"
    will still be met.
    
    Charles Binford
    Pirus Networks
    
    


Home

Last updated: Tue Sep 04 01:04:20 2001
6315 messages in chronological order