10/94 Direct Attach Disk Adhoc Minutes
kc at core.rose.hp.com
Fri Oct 14 01:27:18 PDT 1994
From: Kurt Chan, HP (kc at core.rose.hp.com)
To: FC, SCSI Reflectors
Subj: Minutes of 10/4/94 FC-AL Ad Hoc Meeting
FC-AL Direct Attach DIsk Ad Hoc Meeting Minutes
Red Lion Stapleton
There were 21 attendees:
Dal Allan, ENDL 250-1752 at mcimail.com
Charles Binford, ATT-GIS charles.binford at wichitaks.ncr.com
Kurt Chan, HP kc at core.rose.hp.com
Jim Coomes, Seagate jim_coomes at notes.seagate.com
Steve Dean, HP dean at core.rose.hp.com
Brian Doore, Seagate brian_doore at notes.seagate.com
Giles Frazier, IBM gfrazier at ausvm6.vnet.ibm.com
Gene Freeman, ATT-GIS-NCR Micro gene.freeman at colospgs.ncr.com
Stillman Gates, Adaptec stillman at eng.adaptec.com
Norm Harris, Adaptec nharris at eng.adaptec.com
M.K. Jibbe, ATT-GIS mahmoud.jibbe at wichitaks.ncr.com
Jon Kellen, Cray Research jjk at cray.com
Jean Kodama, QLogic j_kodama at qlc.com
Jim McGrath, Quantum jmcgrath at qntm.com
Greg Scherer, Emulex g_scherer at emulex.com
Ken Smith, Conner ken.smith at conner.com
Horst Truestedt, IBM truested at vnet.ibm.com
Peter Walford, FCSI walford at btr.com
Dan Weinstein, EMC danw at emc.com
Jeff Williams, HP jlw at hpdmd48.boi.hp.com
Fanny Wong, IBM fwong at vnet.ibm.com
As usual, feel free to comment if you see issues/inaccuracies in any of the
following and these will automatically become agenda items for next month.
1. FUTURE SCHEDULE
Although Nov 1 meant travelling on Halloween night, a straw poll indicated
that people were unwilling to move the meeting later into the week (sorry
Jeff, I tried!). So the next meeting will be:
Date: Nov 1-2
Location; Red Lion Stapleton, Denver
I hope to wrap up all of the remaining private loop protocol issues so we
can publish a profile in December and start the new year with Public Loop
work. We'll make the second day Dal's FL_Port WG and a springboard into
public loop work. See the November Agenda below.
Beginning in January, I'd like to begin holding our meetings in conjunction
with X3T10 and X3T11 on Mondays:
Mon, Jan 9 X3T10 Lake Tahoe, NV
Mon, Feb 6 X3T11 So. Calif.
Mon, Mar 6 X3T10 Newport Beach, CA
Mon, Apr 3 X3T11 Monterey, CA
Mon, Jun 12 X3T10 Rochester, MN
Mon, Jul 10 X3T11 Colorado Springs
Steve reviewed the fairness problems brought up at the previous meeting,
and discussed over email since. After reviewing the nature of the problems
and the proposed solutions by Emulex, the agreement was not to change the
existing FC-AL document for the following reasons:
a) the need to forward a document for public review were perceived to
outweigh the need to solve the problems before forwarding.
b) Further analysis/simulation may reveal other problems with FC-AL that
would warrant changes to the proposed solutions.
c) 2 of the 3 scenarios would not result in long-term or wide-spread
starvation, and the third requires very specific configurations, traffic
patterns, and congestive traffic volumes in order to create the problem
in a private SCSI Loop application. ULP timeouts should provide
recovery in severe cases without changes to FC-AL.
d) Early implementors can still move forward with fixes to these problems
to ensure fairness, despite the absence of documentation in FC-AL.
However, this should not affect interoperability with ports which have
not implemented the same solutions.
- Horst will document the details of the problems and the proposed
solutions of the early implementors on the reflector.
- The private loop profile will add these to an Informative Annex.
- These solutions may show up as FC-AL public review comments if they
survive scrutiny over the next 4 months.
The consensus of the participants is that ACA=1 appears to be the only
viable method for Initiators and Targets to reliably interoperate. A
problem exists since Peter Walford indicated that the FCSI SCSI
Profile requires ACA=0, and FCSI participants have been reluctant to
depart from previous revisions of the profile.
One of the problems with ACA=0 is that sense data will be permanently
lost with autosense if FCP_RSP to a faulting command is lost.
Furthermore, I suggest that ACA=1 can only work in this profile if:
- Sense data is retained by a Target as long as an ACA condition exists
(suggested by Charles Binford)
- ABTS/ABTX do not clear an ACA condition.
- An ACA condition is established upon transmission of FCP_RSP, regardless
of the class of service.
- One of the three changes is made:
a) SAM is modified to accomodate protocols where the delivery of autosense
b) Autosense is made optional in FCP for class 3,
c) Autosense delivery is made reliable in FCP through the creation of two
new IUs (e.g., I8: ACA_RSP and T12: I8_RSP) which are only used for
ACA will be discussed in further detail Nov 1-2.
4. TASK MANAGEMENT
It was agreed that FCP_RSP to Task management functions were
architecturally consistent and needed to ensure a reliable task
management delivery service is provided by FCP, in both class 2 and
class 3. It was suggested that a public review comment be generated
to allow the use of T1 instead of T5 for Task Management:
o All commands have the same Information Category = 6.
o I4 would be used with normal payload for the response with:
FCP_RSP_LEN_VALID = 1
SCSI status byte = 0
- FCP_RESID = 0
- FCP_SNS_LEN = 0
- FCP_RSP_LEN = 8
RSP_CODE = 00 task management function
= 04 not performed because not function not supported
= 05 not performed but function is supported
- What is returned if Target Reset is sent to a Target which has
an ACA condition established with another Initiator?
- Do ACA conditions live across Target Reset?
- No ports are prohibited from issuing selective power-on reset. However,
FL_Ports and public loop devices are prohibited from *responding* to them.
- This table applies to single-lun Targets only.
- This profile prohibits the transmission of NOS, OLS, LR, or LRR on
a Loop, regardless of whether or not they are preceded by ARB+OPN.
- I've also added ACA and UA conditions to the table, and simplified
the footnotes and removed some notes which were redundant with
requirements from existing standards.
- FLOGI references were removed.
LOGO, PRLI, Target Task Task
LIP(y,x) PLOGI ABTS PRLO Reset Set Set
-------- ----- ----- ------ ------- ------- -------
PLOGI parmameters Y(4) Y N N N N N
Open Sequence(s) Y(4) Y(2) Y(2) Y(2) N(3) N(3) N(3)
Open Task(s) Y(4,5) Y(2,5) Y Y(2,5) Y(4,5) Y(4,5) Y(2,5)
EE_Credit_CNT Y Y N N N N N
BB_Credit_CNT Y Y N N N N N
AL_PA N(1) N N N N N N
PRLI parms Y(4) Y(2) N Y N N N
Mode page parms = saved Y(4) Y(2) N Y(2) Y(4) N N
UA condition N N N N N N N
ACA condition Y(4) N N N ? N N
1. Unless AL_PA's have changed (i.e., preferred address has already
been taken by another port)
2. For Process or N_Port Login Initiator only, not for all
3. Tasks are cleared internally within the Target, but open FC-PH
Sequences must be individually aborted by the SCSI Initiator via
4. For all initiators
5. All open tasks
6. QUESTIONS FROM DAN WEINSTEIN, EMC
Q: Do we need an -AL version number referenced in the Profile?
A: FC-AL is already referenced in clause 3. It will be updated to
Q: How is the loop master determined?
A: The Lowest algrebraic WWN determined by LISM wins mastership (see
10.4.3 page 54 in FC-AL 4.34)
Q: Will drive respond to commands from 2 initiators on same loop?
A: Yes, this is standard multiple-initiator behavior. On a dual
ported, multi-initiator implementation, if you send a command on one
port, the Target must respond to that command on the same port.
Q: Is the new AMP-Champ connector with ESD blades and staggered pins
A: Yes - will specify "blind mate" connector by referencing SFF once
they agree on a specification.
Q: Are any input pins to the connector being established in order to
communicate environmental conditions such as fan, temperature,
A: These pins are being defined in SFF, but disk drives will NOT
implement temp/fan/power conditions. It is more likely that a
cabinet will have a separate entity to perform this function rather
than require the drive to do this.
Q: FLOGI prohibited on page 7 but explicit F_Port Login is allowed by
initiators. Is this a typo?
A: Yes - will be fixed in next revision.
Q: If linking is not supported, how will we be able to handle Skip
Read/Write? How do we do skip mask?
A: Linking commands are optional in profile, but not prohibited.
Therefore, the above functions may be implemented and still conform
to the profile.
Q: Same with read long, write long, seek, write same.
A: See (7) above.
Q: Provide signals for future 5V gate and 12V gate.
A: These functions are already supported via the "Long" pins on the
precharge lines in the SFF committee. If EMC wants the resistor on
the drive instead of the backplane, it should address the issue in
SFF. [Dan - bring this up again if not addressed to your
Q: Full Duplex code - can we write and read simultaneously to same drive?
A: Yes. When an Initiator opens a drive, it may offer it BB_credit
by transmitting R_RDYs. This gives the Target the ability to transmit
data back to the host at the same time the host is transmitting to
the Target. The amount of credit offered is implementation-specific.
If the Initiator has no inbound buffers available, it will disallow
full duplex behavior for that loop tenancy by not transmitting any
7. HORST'S COMMENTS
Horsts comments brought up several discussion items:
a) Login and Target Discovery:
Instead of rejecting new PLOGIs as login resource limits are reached,
- all PLOGIs must be accepted with the "oldest" PLOGI implicitly
discarded, where the determination of "oldest" is vendor-unique
- frames received from ports which are not logged in shall be discarded
and PLOGO shall be issued to the offending port.
A new "Port Discovery" ELS will allow open Exchanges to be preserved
across insertion of new devices or power-cycling of existing devices
(see proposal on FC Reflector and included below). The Port Discovery
algorithm will be mandatory in Private Loop Profile. If Port Discovery
shows no WWN or parameter changes following LIP, the Initiator shall not
continue with PLOGI or PRLI (both of which would terminate open
b) Loop Initialization:
For hub-type topologies where LIPs are not intrinsically generated on
insertion, all NL_Ports must have some means of detecting power-on or
insertion into the cable plant, and must generate their own LIP to alert
others of a potential topology change.
c) Private vs public reset clarification:
Only private devices may respond to power-on LIP reset. If a device
becomes public, it cannot respond to power-on LIP hard reset, and Target
Reset must be used in order to protect Public Initiators (which may not
be on the local loop) from other Initiators.
Private loop devices shall not attempt OPN to AL_PA to 00, or attempt
FLOGI. Public loop devices must attempt FLOGI to AL_PA=00, but may
revert to private loop behavior if the OPN to AL_PA=00 or FLOGI fails.
d) Resource recovery scenario:
- LIP occurs.
- Target keeps its own address, Initiator changes it's address.
- Target does not have resource recovery timers.
- Initiator performs Port Discovery (PDISC) with Target
- Target can detect by the WWN in the PDISC payload that it is the same
Initiator (without looking at the S_ID). Therefore the Target can
reclaim the old resources associated with the old WWN, and abnormally
terminate all Exchanges with that WWN, not the S_ID (regardless of
whether or not the new Initiator attempts PLOGI with the Target).
e) OPNyr and OPNfr:
Both Steve and Greg admitted they missed the change to OPNyr and OPNfr,
Primitives, but agreed that they should remain as specified in 4.34
since the implementations are already being changed to accomodate 4.34.
8. NOVEMBER AGENDA
- Future meeting schedule
- Review these minutes and any associated comments
- Discuss why 3.3V disappeared and whether or not is should reappear
(request by HP DMD).
o handling of undelivered FCP_RSP to errored commands
o Task Management and ACA
- Review general FC-EP, SAM, FCP changes needed to make Profile work
(am compiling now - see future posting).
More information about the T10