Subject: FCIP and wandering duplicates

From: Vivek Kashyap <[email-masked]>
Date: Sun, 10 Sep 2000 15:17:32 -0700 (PDT)

I read the FCIP document recently. It does not address the issue of
duplicates. 

Does fibre channel protect itself from duplicates ? I looked at the
header and it does not have a time to live field. Thus a duplicate
caught in a loop and then released at the 'right' time could be
accepted by the receiver. Even if the FC fabric path algorithms do
ensure loop free paths transient loops due to errors, switch
misconfigurations or failures are possible. Does FC handle such a case ? 

If it does not then FCIP will exacerbate the problem because the IP
network could have 'transient' loops. Such a 'wandering duplicate'
could be re-injected into the FC island and be accepted by a newer
incarnation of a FC inter-island exchange. Furthermore with no TTL one
can't really provide a timout between starting two conversations.

Vivek
-- 
Vivek Kashyap
IBM-NumaQ
[email-masked]

---

From: "Raj Bhagwat" <[email-masked]>
Date: Sun, 10 Sep 2000 22:57:12 -0700

Vivek,

In a properly implemented FC-only fabric, duplicates should not happen. A
frame that enters a fabric should either be delivered within E_D_TOV
(typically 2 sec) or be discarded. FC devices don't retransmit a frame
before the E_D_TOV timer expires.

You do bring up an interesting point when two SAN islands are bridged across
an IP network. Once an FC frame enters the IP network, it is hard to say how
the E_D_TOV is enforced by that part of the network. As authors of the
FCoverIP draft, we have given some thought to the possibility of delivering
duplicate frames when both the TCP stack at the FCIP gateway and the
original FC device initiate recovery/retransmission procedure in an
overlapping time period. This is one of the major reasons why we initially
chose to make the FCIP gateway a stateless device with no buffering and no
retransmission.

The good news is that the {IP encapsulated} FC frame will be protected by
the IP TTL once it enters the IP network. The bad news is that detecting the
E_D_TOV timeout while the frame is inside the IP network may be difficult.

Regards,

Raj Bhagwat
LightSand Communications