Subject: FCIP Multiple Connection Management

From: "Binford, Charles" <[email-masked]>
Date: Mon, 9 Jul 2001 12:24:53 -0400

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

---

From: Sudhir Srinivasan <[email-masked]>
Date: Tue, 10 Jul 2001 11:43:46 -0400

> -----Original Message-----
> From: Ralph Weber [mailto:[email-masked]]
> Sent: Monday, July 09, 2001 4:15 PM
> 
>     ftp://ftp.t11.org/t11/pub/fc/bb-2/01-342v0.pdf
> 
> The annex will not appear in FCIP revision 04.
> 
> I cannot guarantee that discussions on this reflector will be
> considered by T11 in its deliberations over FC-BB-2, although
> they probably will.

Ralph, 

Given the overlap in attendees at T11, I would hope
some of the discussions on this reflector do carry
over there. Assuming so, it would be good if we could
have consensus on the allegiance rules - whether to
drop rules 2 & 3 - before we delete the annex and
forward the text to BB-2. The embedded author comments 
in the document listed above still leave this issue 
open - in other words, what exactly have the authors
"agreed upon"?

Regards,
- Sudhir