SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    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.
    


Home

Last updated: Wed May 15 15:19:08 2002
10128 messages in chronological order