FCP-2 resource recovery question

Binford, Charles cbinford at lsil.com
Mon Jul 19 15:07:27 PDT 1999

* From the T10 Reflector (t10 at symbios.com), posted by:
* "Binford, Charles" <charles.binford at lsil.com>
I agree with Greg as far as resources to be recovered.  However, Howard
brings up a another point I'd like to comment on.  Section 10.3 in FCP-2
needs to expand its scope.  For example, "exchange authentication" is
completed based on topology:

- private loop			PDISC/ADISC from host (covered by current
- FLA 				FAN from FL_Port
- direct F_Port connection  	???
- point-to-point			???

Under public or private loop we start the timer when the LIP finishes.  When
in old-port mode, when does the timer start?  If a port goes down, how long
does a target wait before flushing buffers and getting on with life using
the remaining good ports?

Charles Binford
LSI Logic Storage Systems
(316) 636-8566

> -----Original Message-----
> From:	Scherer, Greg [SMTP:Greg.Scherer at emulex.com]
> Sent:	Saturday, July 17, 1999 9:53 PM
> To:	'Howard Green'; Bob.Snively at sun.com
> Cc:	fc at nsco.network.com; t10 at symbios.com
> Subject:	RE: FCP-2 resource recovery question
> Howard,
> 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
> recovered:
>  - 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).
> Thanks,
> 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