SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    questions about FCIP connection failure detection


    • To: <ips@ece.cmu.edu>
    • Subject: questions about FCIP connection failure detection
    • From: "Chong Peng" <ChongPeng@MaXXan.com>
    • Date: Thu, 25 Apr 2002 13:47:54 -0700
    • Content-Class: urn:content-classes:message
    • Content-Transfer-Encoding: quoted-printable
    • Content-Type: text/plain; charset="iso-8859-1"
    • Sender: owner-ips@ece.cmu.edu
    • thread-index: AcHsmcmVHRllCleqEdaUgACw0PIHqQ==
    • Thread-Topic: questions about FCIP connection failure detection

    Hi, all
    
    The Section 9.4 (TCP Connection Considerations) of draft-ietf-ips-fcovertcpip-09 
    says:
     
       In idle mode, a TCP Connection "keep alive" option of TCP is
       normally used to keep a connection alive. However, this timeout is
       fairly large and may prevent early detection of loss of
       connectivity. In order to facilitate faster detection of loss of
       connectivity, FC Entities SHOULD implement some form of Fibre
       Channel connection failure detection (see FC-BB-2 [4]).
     
       When an FCIP Entity discovers that TCP connectivity has been lost,
       the FCIP Entity SHALL notify the FC Entity of the failure including
       information about the reason for the failure.
    
    I have a couple of questions regarding this section:
    
    1. The first pragraph states that the FC entity is responsable to discover the 
       connection failure. But the second paragraph implys the FCIP entity discovers 
       the connection failure first and then notifies the FC entity. Is there an 
       editorial error?
    2. If we let the application protocol on the top of TCP to discover the 
       connection failure, what scheme are we going to use? Are we planning to
       define some "FCIP keep alive" frames in the future? I checked FC-BB-2,
       in the section related to discovery (13.2.2.4.2), it says "TBD".
    
    Chong Peng
    
    
    This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized use; review, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message. 
    Copyright © 2002 MaXXan Systems, Inc. All rights reserved.
    


Home

Last updated: Thu Apr 25 20:18:23 2002
9800 messages in chronological order