FW: FCP-3 Clarification to TPRLO
michael.banther at hp.com
Tue Nov 9 10:55:21 PST 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* "Banther, Michael" <michael.banther at hp.com>
This is a multi-part message in MIME format.
The message below, from Rob Elliott, raises some issues with an HP
proposal to clarify the effect of TPRLO. I've posted it so that
interested parties can consider Rob's comments and concerns.
Telephone +44 (117) 312-9503
From: Elliott, Robert (Server Storage)=20
Sent: 07 November 2004 23:13
To: Banther, Michael; Bhat, Vinod
Subject: RE: FCP-3 Clarification to TPRLO
The proposed 4 new words in note 3 don't seem to change anything.
I think most of the necessary changes (to require that the recipient of
TPRLO send PRLO on each affected I_T nexus) belong in FC-LS.
One problem with that proposal is FCP discusses support for implicit
PRLI and PRLO. That may imply that implicit process logout due to =
is also of interest to some.
These are the areas what I think FCP-3 needs to attack:
"4.11 I_T nexus loss notification events An FCP_Port shall deliver an
I_T nexus loss notification (see SAM-3) for the following:
a) Sending or receiving LOGO (explicit or implicit);
b) Sending or receiving PRLO (explicit or implicit);
c) Receiving TPRLO;
d) Sending TPRLO with a Third Party Originator N_Port_ID (see FC-LS)
that matches the N_Port_ID of the sending FCP_Port; or
e) Sending TPRLO with the GLOBAL bit set to one to a target port that
has an I_T nexus with the sending initiator port."
Item c) should be delayed until the TPRLO recipient has attempted to
send PRLO on the affected I_T nexus. Also, the FCP_Port that receives
TPRLO isn't the one that delivers an I_T nexus loss notification; =
supposed to come from the port which was logged out. If global is set,
then all the ports do so including the one that received TPRLO; if not
set, then only the specified one does so (after trying to send PRLO, if
the key part of the proposal is accepted).
For item d) and e), will the recipient of TPRLO be expected to send =
back on that same nexus? If so, d) and e) could probably be removed
(just rely on the PRLO to create the notification).
"4.14 Process Login/Logout
The Process Login (PRLI) ELS is used to establish the FCP operating
relationships between two FCP_Ports (see 6.3). The Process Logout =
ELS is used to de-establish the FCP operating relationships between two
FCP_Ports (see 6.4). Implicit PRLI/PRLO parameters may be defined for
FCP_Ports. Such definitions are outside the scope of this standard."
This section should mention TPRLO too.
An initiator shall have successfully completed a PRLI with a target =
establishes an image pair before any FCP IUs are exchanged. An image
pair may also be established by an implicit PRLI established by methods
outside the scope of this standard. An image pair is removed by a PRLO
(see 6.4). If an image pair is not established by an initiator to a
target, the initiator and target shall not exchange any FCP IUs. Any =
IUs received by a target from an Nx_Port that does not have an image
pair with that target shall be discarded. In addition, a target that
receives an FCP_CMND IU from an Nx_Port that is logged in but does not
have an image pair with that target, shall discard the FCP_CMND IU and
respond with an explicit PRLO (see 12.6). Reasons why the Nx_Port does
not have an image pair with the target include:
a) the Nx_Port has not established an image pair with that target;
b) the target performed an implicit PRLO of the Nx_Port; or
c) the target processed a TPRLO that effected the Nx_Port."
The sentence "An image pair is removed by a PRLO" is incomplete.
effected s/b affected in c).
"6.4 Process Logout (PRLO)
The Process Logout (PRLO) request is transmitted from an Originator
FCP_Port to a Responder FCP_Port to indicate to the Responder that the
image pair specified in the FCP Service Parameter pages of the PRLO is
being discontinued by the Originator. If the PRLO logs out the image
pair between an initiator and a target, then all clearing actions
specified in 4.10 shall be performed and an I_T nexus loss notification
shall be delivered (see 4.11).
For the Fibre Channel protocol, the PRLO FCP Service Parameter page
identifies an image pair where neither the Originator or Responder
supports Process_Associators by marking the Originator
Process_Associator and Responder Process_Associator as invalid. After
PRLO, no further Fibre Channel protocol communication is possible
between those N_Ports or NL_Ports.
The PRLO accept (ACC) is returned to the Originator FCP_Port to =
that the Responder FCP_Port recognizes that the image pair is being
discontinued. The ACC shall present a response FCP Service Parameter
page for the request FCP Service Parameter page. It is not an error to
perform a PRLO for an image pair that does not exist.
A link service reject (LS_RJT) indicates that the PRLO request is
invalid and not accepted.
The PRLO common service parameters and accept response codes are =
TPRLO should be mentioned here.
"If the PRLO logs out the image pair between an initiator and a target"
seems odd. When would it not do so? If TPRLO is going to spawn PRLO,
then it needs to cause the clearing effects even if the PRLO times out.
What it does if the PRLO is explicitly rejected is an interesting
Rob Elliott, HP Server Storage
elliott at hp.com
From: Banther, Michael
Sent: Sunday, November 07, 2004 6:39 PM
To: Elliott, Robert (Server Storage)
Subject: FW: FCP-3 Clarification to TPRLO
Meant to cc you on this proposal for Vinod.
From: Banther, Michael
Sent: 07 November 2004 18:38
To: Bhat, Vinod
Subject: FCP-3 Clarification to TPRLO
Here's the FCP-3 proposal. Please review it and return comments ASAP.
The FCP-3 meeting occurs first thing Tuesday morning. I must have
comments by end-of-play on Monday if you want any changes.
Telephone +44 (117) 312-9503
Content-Description: BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf
More information about the T10