I_T nexus loss

Shawn Authement Shawn.Authement at texmemsys.com
Wed Nov 5 06:25:46 PST 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* Shawn Authement <Shawn.Authement at texmemsys.com>
*
That is precisely the direction I would lean.  The devices I am 
currently working with behave this way already.
-- 
Shawn Authement
Bob.Nixon at Emulex.Com wrote:
>  For a couple reasons, I would lean toward making both the PLOGI and the
binding PRLI I_T Nexus Loss events if there were a prior nexus, even if the
service parameters are unchanged.
>
> The first reason is practical: Table 7 makes the clearing effects for PLOGI
identical to LOGO, and the clearing effects for PRLI the same as PRLO.	Since
these effects include wiping out Exchanges (and therefore, any pending SCSI
commands and task management functions), the effects are almost the same as
SAM-4 gives for Nexus Loss, lacking only the explicit requriements for
clearing ACAs and establishing the I_T NEXUS LOSS OCCURRED unit attention
condition.
>
> The second is more philosophical: If an Initiator that is logged in sends
another PLOGI, it is a violation of good behavior, unless the Initiator has
lost state. FCP seems to make a similar presumption about PRLI, given table
7.  If the Initiator has lost state, it would be best to give him notice
(unit attention) that something was going on that might be incomplete.
>
> There is a particular case where it would be important, and that is if a
duplicate Nx_Port were placed in the Fabric, and were ping-ponging back and
forth for ownership of the Initiator identity.	Unfortunately, this is not
uncommon, given the tendency of tech support to replace a questionable HBA
with a new one that has been given the same N_Port_ID/N_Port_Name, then
forgetting and putting the old one back in when no defect was found.
>
> So I vote for adding "PLOGI on an established I_T nexus" and "PRLI on an
established I_T nexus" to the list of I_T Nexus Loss events. Do we know of
anything that would break if we did this?
>
>    - bob
>
>
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Jim.Coomes at seagate.com
> Sent: Friday, October 31, 2008 9:51 AM
> To: Shawn Authement
> Cc: t10 at t10.org
> Subject: Re: I_T nexus loss
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Jim.Coomes at seagate.com
> *
> Shawn,
>
> I was thinking that if the Service Parameters do not change in the Process
Login, the I_T_Nexus should be preserved. But I looked at FCP-4 and it
hindges on the ESTABLISH IMAGE PAIR bit. If a zero, the PRLI is Informative.
Repeated Informative PRLIs only exchange the parameters. It does not say
anything about the parameter being the same. If the ESTABLISH IMAGE PAIR bit
is one, the PRLI in Binding. The reset actions in FCP-4 clause 4.10 are
invoked and all open exchanges terminated.
>
> I am not sure if I_T_Nexus Loss is the right status.
>
> Jim
>
>
>
>
>
>
>
>	       Shawn Authement
>	       <Shawn.Authement@
>	       texmemsys.com>						  To
>	       Sent by: 		 t10 at t10.org
>	       owner-t10 at t10.org					  cc
>	       No Phone Info		 Bob.Nixon at emulex.com
>	       Available					     Subject
>					 Re: I_T nexus loss
>
>	       10/30/2008 11:58
>	       AM
>
>
>	       Please respond to
>		Shawn Authement
>	       <Shawn.Authement@
>		texmemsys.com>
>
>
>
>
>
>
> I am finally able to spend some time on this issue of I_T nexus loss.  One
thing in your response Bob was that "PRLI causes I_T nexus loss if it changes
existing FCP-4 Service Parameters".  What if it doesn't change them (i.e.,
the given service parameters are equivalent to the previous service
parameters?
>
> To re-cap, I am investigating the following scenario:
>
>  o Nx_Port (A) (already logged in) sends PLOGI sequence with the same exact
service parameters as the original login  o Nx_Port (B) sends LS_ACC  o
Nx_Port (A) sends PRLI with the exact same service parameters as the original
login  o Nx_Port (B) sends LS_ACC  o Nx_Port (A) sends TEST UNIT READY
>
> As this point, does Nx_Port (B) send back a status of CHECK CONDITION, a
sense key of UNIT ATTENTION, and an additional sense code (qualifier) of I_T
NEXUS LOSS HAS OCCURRED?
>
> Thanks!
>
> --
> Shawn Authement
> Sr. Software Engineer
> Texas Memory Systems, Inc.
> Shawn.Authement at texmemsys.com
> ph: +1.713.266.3200
>
> Bob.Nixon at Emulex.Com wrote:
>	Hi, Shawn, sorry to be slow in responding, but as you pointed out,
>	it's vague in the standads that apply (FCP-3/4 and FC-LS), and I ahd
>	to struggle to find anything. In the end, I came to the same
>	conclusion as Kevin Butt about intent.
>
>	There is some hint in both standards that a PLOGI in the presense of
>	an existing N_Port Login is traumatic: In FCP-4 table 7, the columns
>	for PLOGI and PRLI are the same as the ones for LOGO and PRLO.
>
>	In FC-LS concerning PLOGI, the third paragraph of  subclause 6.3.2.1
>	requires treatment of new Sequences "as though a Logout had been
>	performed". From the standpoint of FC-LS, this is essentially
>	equivalent to an implicit logout, since FC-LS and FC-FS-3 specify no
>	persistent behavior that is not either renegotiated by PLOGI or
>	reflected in the collection of open Sequences.
>
>	Concerning PRLI, FC-LS insists on the next to last paragraph on page
>	180 (printed numbering) that it does NOT imply Process Logout;
>	however, the last paragraph suggests the iimpact is similar if
>	Service Parameters are changed. FCP-3/4 would appear to override
>	this, at least in part.
>
>	You're right that some clarification would be nice.  I suspect that
>	FC-LS-2 needs to explicitly say that a PLOGI causes implicit logout
>	of any existing N_Port Login with the same N_Port, and FCP-4 should
>	say that PRLI causes I_T nexus loss if it changes existing FCP-4
>	Service Parameters. Others on this reflector may be able to make a
>	better statement. Would you like to propose text for FCP-4 and/or
>	FC-LS-2? Would you like me to?
>
>	   - bob nixon (secretary for FCP-4 and FC-LS-2)
>
>
>
>	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Shawn
>	Authement
>	Sent: Wednesday, October 01, 2008 9:31 AM
>	To: t10 at t10.org
>	Subject: Re: I_T nexus loss
>
>	A big thank you to all who responded!  I was just wondering if anyone
>	may know where I can reference the situations which cause an implicit
>	LOGO/PRLO, or maybe is this a better question to ask T11?  FC-LS-2
>	section 6.4.4 seems to be vague on the issue, and doesn't mention
>	this case.
>
>
>	Thanks,
>	--
>	Shawn Authement
>	Sr. Software Engineer
>	Texas Memory Systems, Inc.
>	Shawn.Authement at texmemsys.com
>	ph: +1.713.266.3200
>	Kevin D Butt wrote:
>
>	      Shawn,
>
>	      Yes, when an N_Port performs a PLOGI/PRLI it logs in again.
>	      This can be viewed as an implicit LOGO/PRLO and as stated in
>	      4.11 of FCP-4 (
>	      http://www.t10.org/ftp/t10/drafts/fcp4/fcp4r01.pdf) this
>	      generates an I_T nexus loss notification.
>
>	      Regards,
>
>	      Kevin D. Butt
>	      SCSI & Fibre Channel Architect, Tape Firmware
>	      MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
>	      Tel: 520-799-2869 / 520-799-5280
>	      Fax: 520-799-2723 (T/L:321)
>	      Email address: kdbutt at us.ibm.com
>	      http://www-03.ibm.com/servers/storage/
>
>
>  From:      Shawn Authement <Shawn.Authement at texmemsys.com>
>
>  To:	      t10 at t10.org
>
>  Date:      09/24/2008 12:17 PM
>
>  Subject:   I_T nexus loss
>
>
>
>
>
>
>
>	      * From the T10 Reflector (t10 at t10.org), posted by:
>	      * Shawn Authement <Shawn.Authement at texmemsys.com>
>	      *
>	      All,
>
>	      I am currently researching device behavior with respect to
>	      N_Port login
>	      and was wondering if anyone can provide clarification.
>
>	      Q: If an already-logged-in N_Port performs login again (via
>	      PLOGI), is
>	      this considered an I_T nexus loss as defined by SAM-3, 6.3.4?
>
>	      The ENDL Fibre Channel Bench Reference implies that re-Login
>	      causes an
>	      implicit Logout.	However, I cannot find any supporting
>	      information in
>	      either the FCP-3 for FC-LS specifications.  My goal is to
>	      ultimately
>	      determine whether a SCSI Target Port should set a Unit
>	      Attention if a
>	      SCSI Initiator Port re-logs in.
>
>	      Thank you for your your help!
>
>	      --
>	      Shawn Authement
>	      Sr. Software Engineer
>	      Texas Memory Systems, Inc.
>	      Shawn.Authement at texmemsys.com
>	      ph: +1.713.266.3200
>
>	      *
>	      * For T10 Reflector information, send a message with
>	      * 'info t10' (no quotes) in the message body to
>	      majordomo at t10.org
>
>
>
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>   
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list