I_T nexus loss

Bob.Nixon at emulex.com Bob.Nixon at emulex.com
Fri Oct 31 15:16:41 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* Bob.Nixon at Emulex.Com
*
 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