Re: FCIP Multiple Connection Management

[Ralph Weber <ralphoweber@compuserve.com>]

Charles, Sudhir,

Please examine the title and first paragraph of Annex C
(which encompasses pages 39 to 44).

"ANNEX E - FC-BB-2 Inputs

  "This annex contains text from previous FCIP drafts that,
  because of the new model structure, probably belongs in
  FC-BB-2 [4]. As soon as the correctness of this annex is
  agreed, its contents will be transferred to a T11 document
  do be used in the development of FC-BB-2."

The correctness of the annex (such as it is) has been agreed
among the FCIP authors and the content of the annex can now
be found at:

    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.

Thanks.

Ralph...

Sudhir Srinivasan wrote:

>
>
> 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
> >