FCP-2 resource recovery question

Bob Snively Bob.Snively at EBay.Sun.COM
Tue Jul 20 15:52:01 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* Bob Snively <Bob.Snively at EBay.Sun.COM>
*
I have always hoped that the text was pretty obvious.

	RR_TOV is the minimum time a SCSI Target shall wait for a specific 
	SCSI Initiator to perform Exchange Authentication following the 
	completion of the Loop Initialization Protocol (i.e., the receipt of CLS 
	while in the OPEN-INIT state). RR_TOV is also the minimum time a SCSI 
	Target shall wait for a SCSI Initiator response following transfer of 
	Sequence Initiative from the SCSI Target to the SCSI Initiator (e.g., 
	following transmission of the FCP_XFER_RDY during a write command).

This provides both clear indications as to when the timer should start
(independent of topology in the second case), and when it should end.

In the first case, there is a topology factor in the definition of
exchange authentication, which means PDISC/ADISC for PLDA environments and
FAN for FLA environments.  For fabric attach point-to-point environments,
the question gets a bit more interesting, but not much.  If a link
reset protocol is required, I have always assumed that it will be finished
in a short time compared with RR_TOV.  Thus a recovery for exchange
authentication purposes is indistinguishable from the recovery waiting for
transfer of sequence initiative.  For recoveries requiring a new login
(such as online-offline-online transitions), it would seem to me that
the RR_TOV would not be so relevant, since exchange resources were already
cleared at both ends.

What other factors have I missed?

Do we want to specify this in tabular format, as Charles does below,
as part of the discovery annex or in the body of the document?

Bob



> From: "Binford, Charles" <charles.binford at lsil.com>
> To: fc at nsco.network.com, t10 at symbios.com
> Subject: RE: FCP-2 resource recovery question
> Date: Mon, 19 Jul 1999 17:07:27 -0500
> MIME-Version: 1.0
> 
> * 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
> words)
> - 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

*
* 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