RE: questions about FCIP connection failure detection

["Murali Rajagopal" <muralir@cox.net>]

Chong:

According to the Action Items from the Vancouver T11 meeting, Dave Peterson
is expected  to bring in a contribution at the June T11 meeting on
Discovery. I will ask Dave to share any text he may at this time on this
topic. (But note that this will need the approval of the BB-2 WG for
inclusion into the BB-2 document).

-Murali

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Chong Peng
Sent: Thursday, April 25, 2002 1:48 PM
To: ips@ece.cmu.edu
Subject: 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.