FCP-2 resource recovery question

Scherer, Greg Greg.Scherer at emulex.com
Sat Jul 17 19:53:05 PDT 1999

* From the T10 Reflector (t10 at symbios.com), posted by:
* "Scherer, Greg" <Greg.Scherer at emulex.com>

Since there is no specification or requirement that a Fabric send an RSCN in
real time, having a Target register for RSCN can (and does) cause many other
problems.  Each port that has registered for RSCN receives it asynchronous
|from the actual event, in fact there is even benefit for the Fabric to
insert hysterysis in this notification, to avoid sending multiple RSCNs when
the link may "bounce" (many Fabric vendors have implemented this).

Here is a failing scenario:

1. An Initiator logs into the Fabric
2. This Initiator then logs into the NameServer and gets a list of Targets
3. The Initiator then Logs into the Target(s)
4. Some time later (1-2 seconds in some cases) the Fabric sends RSCN
5. The Target then goes to PDISC-Pending waiting for the Initiator to
authenticate itself

During this time the Initiator is oblivious to the fact that it "should"
authenticate, and all I/O sent during this RRTOV window will be ignored.
This can (and does) cause particular problems, especially during initial
discovery, during which Hosts generally employs very small I/O time-outs.

Since the Target takes on a Slave role in discovery/authentication (per
PLDA/FLA, a Target does not initiate login, unlike FCA-IP), I contend that
registering for RSCN is for Initiators ONLY, not slave devices.  The reason
that current Private Loop behavior works, is that notification of a link
event (LIP) is received by all N_Ports concurrently before I/O can be
resumed.  This is not and can not be the case in a Fabric, which has
different topology characteristics than a Private Loop.

Regarding how a Target may recovery resources;  from my perspective (which
is I'm sure not complete :-) ) there are two main kinds of resources to be

- Initiator Login Contexts

   . One way to recover these is to always accept a new login, by logging
out an existing context in a least frequently used basis.

- Exchange Contexts (most especially rcv buffers)

   . There is already a recommended way to recover these resources, by using
an I/O timer to age out the I/O if the initiator has not sent write data in
response to an XFER_RDY within this time-out.  All other transfers are
controlled by the Target (send FCP_DATA and/or FCP_RSP).

Greg Scherer
Emulex Fibre Channel Development

-----Original Message-----
From: owner-fc at nsg0.network.com [mailto:owner-fc at nsg0.network.com]On
Behalf Of Howard Green
Sent: Thursday, July 15, 1999 8:40 PM
To: Bob.Snively at sun.com
Cc: fc at nsco.network.com; t10 at symbios.com
Subject: FCP-2 resource recovery question

I've got a question regarding target resource recovery. FCP-2, in section
10.3 on RR_TOV, specifies that a target can recover resources in use on

behalf of an initiator if the initiator fails to authenticate itself within
RR_TOV following completion of loop initialization.

The FCP-2 text (and the corresponding FC-TAPE text, too) is pretty close to
a verbatim inclusion from PLDA, which dealt with FibreChannel universes no
larger than a single loop. In such an environment, one could reasonably
expect the demise of an initiator to cause a loop initialization, which
would provide targets with the event needed to trigger RR_TOV action, and
ultimately, resource recovery.

Times have changed, though, and Fabrics are a reality, and therein lies my
question. In a Fabric environment, initiator and target may be on different
Fabric ports---i.e., not on the same loop---and an initialization on one
loop won't generally propagate to any other. Further, if either initiator or
target is attached to the Fabric via a link, loop initialization events are,
um, kind of problematic.

So, suppose an initiator on one Fabric port is using a target on another. If
the initiator kicks the bucket, what event serves to inform the target that
it ought to start its resource recovery process?

One (obvious?) solution is to require targets to register for and monitor
RSCNs (and indeed, there are targets that already do this). If a target
receives an RSCN that pertains to a logged-in initiator, it suspends that
initiator (and presumably only that initiator!) and starts its RR_TOV timer.

Am I missing something? It seems like there's got to be something more than
loop initialization to trigger resource recovery in a Fabric environment.

Howard Green
Prisa Networks

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com

More information about the T10 mailing list