RE: FCIP Multiple Connection Management

[Sudhir Srinivasan <SudhirS@trebia.com>]

Charles,

Agree 100% - this was discussed in the following thread,
although, to my recollection, we did not explicitly 
state a consensus and the text is still found in 
Annex E of rev 0.3.

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg04662.html

> -----Original Message-----
> From: Binford, Charles [mailto:CBinford@pirus.com]
> Sent: Monday, July 09, 2001 12:25 PM
> To: ips@ece.cmu.edu
> Subject: 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
>