RE: FCIP Comment 44 - Proposed text for new section

[Brian Forbes <bforbes@Brocade.COM>]

I didn't see a lot of traffic on this. I think it's both well-written amd
useful, and should stave off certain classes of future questions.

Brian Forbes
Brocade Communications 

-----Original Message-----
From: Ralph Weber [mailto:ralphoweber@compuserve.com]
Sent: Friday, May 10, 2002 5:47 AM
To: IPS Reflector
Subject: FCIP Comment 44 - Proposed text for new section


The following is the text proposed for the new FCIP section
that is described in the response to Last Call comment 44.


8.2 Overview of FSF Usage in Connection Establishment

When a new TCP Connection is established, an FCIP Special Frame
makes one round trip from the FCIP Entity initiating the TCP connect
operation to the FCIP Entity receiving the TCP connect request and
back. This FSF usage serves three functions:

  - Identification of the FCIP Link endpoints
  - Conveyance of a few critical parameters shared by the FC/FCIP
    Entity pairs involved in the FCIP Link
  - Configuration discovery (used in place of SLP only when
    allowed by site security policies)

The specific requirements for this usage of the FSF are found in
section 9.1. This section provides an overview of the FSF usage
without stating requirements.

Because FCIP is only a tunnel for a Fibre Channel Fabric and because
the Fabric has its own complex link setup algorithm that can be
employed for many FCIP link setup needs, it is desirable to minimize
the complexity of the FSF usage during TCP Connection setup. With
this in mind, this FSF usage is not a login or parameter negotiation
mechanism. A single FSF transits each newly established TCP
connection as the first bytes sent in each direction.

Note: This usage of the FSF cannot be eliminated entirely because a
newly created TCP Connection must be associated with the correct
FCIP Link before FC Fabric initialization of the connection can
commence.

The first bytes sent from the TCP connect request initiator to the
receiver are an FSF identifying both the sender and who the sender
thinks is the receiver. If the contents of this FSF are correct and
acceptable to the receiver, the unchanged FSF is echoed back to the
sender. This send/echo process is the only set of actions that
allows the TCP Connection to be used to carry FC Fabric traffic. If
the send and unchanged echo process does not occur, the algorithm
followed at one or both ends of the TCP Connection results in the
closure of the TCP Connection (see section 9.1 for specific
algorithm requirements).

Note: Owing to the limited manner in which the FSF is used and the
requirement that the FSF be echoed without changes before a TCP
Connection is allowed to carry user data, no error checking beyond
that provided by TCP is deemed necessary.

As described above, the primary purpose of the FSF usage during TCP
Connection setup is identifying the FCIP Link to which the new TCP
Connection belongs. From these beginnings, it is only a small stretch
to envision using the FSF as a simplified configuration discovery
tool, and the mechanics of such a usage are described in section 9.1.

However, use of the FSF for configuration discovery lacks the broad
range of capabilities provided by SLP v2 and most particularly lacks
the security capabilities of SLP v2. For these reasons, using the FSF
for configuration discovery is not appropriate for all environments.
Thus the choice to use the FSF for discovery purposes is a policy
choice to be included in the TCP Connection Establishment "shared"
database described in section 9.1.1.

When FSF-based configuration discovery is enabled, the normal TCP
Connection setup rules outlined above are modified as follows.

Normally, the algorithm executed by an FCIP Entity receiving an FSF
includes verifying that its own identification information in the
arriving FSF is correct and closing the TCP Connection if it is not.
This can be viewed as requiring the initiator of a TCP connect
request to know in advance the identity of the FCIP Entity that is
the target of that request (using SLP, for example), and through the
FSF effectively saying, "I think I'm talking to X." If the party at
the other end of the TCP connect request is really Y, then it simply
hangs up.

FSF-based discovery allows the "I think I'm talking to X" to be
replaced with "Please tell me who I am talking to?", which is
accomplished by replacing an explicit value in the Destination FC
Fabric Entity World Wide Name field with zero.

If the policy at the receiving FCIP Entity allows FSF-based
discovery, the zero is replaced with the correct Destination FC
Fabric Entity World Wide Name value in the echoed FSF. This is still
subject to the rules of sending with unchanged echo, and so closure
of TCP Connection occurs after the echoed FSF is received by the TCP
connect initiator.

Despite the TCP Connection closure, however, the TCP connect
initiator now knows the correct Destination FC Fabric Entity World
Wide Name identity of the FCIP Entity at a given IP Address and a
subsequent TCP Connection setup sequence probably will be
successful.

The Ch bit in the pFlags field (see section 6.6.1) allows for
differentiation between changes in the FSF resulting from
transmission errors and changes resulting from intentional acts by
the FSF recipient.