Direct Attach Ad Hoc Meeting Minutes, 8/94
kc at core.rose.hp.com
Tue Aug 23 11:30:34 PDT 1994
From: Kurt Chan
To: FC, SCSI Reflectors
Subj: Aug FC Direct Disk Attach Ad Hoc Meeting Minutes
FC-AL Direct Disk Attach Ad Hoc Meeting Minutes
Red Lion Stapleton
Dal Allan, ENDL 250-1752 at mcimail.com
Kurt Chan, HP kc at core.rose.hp.com
Jim Coomes, Seagate jim_coomes at notes.seagate.com
Brian Doore, Seagate brian_doore at notes.seagate.com
Giles Frazier, IBM gfrazier at ausvm6.vnet.ibm.com
Norm Harris, Adaptec nharris at eng.adaptec.com
Jean Kodama, QLogic j_kodama at qlc.com
Fred Kool, Adaptec fredkool at eng.adaptec.com
Greg Scherer, Emulex g_scherer at emulex.com
Ken Smith, Conner ken.smith at conner.com
Paul von Stamwitz, Adaptec
1. PUBLIC VS PRIVATE LOOP DEVICE COEXISTENCE
+---------+ +--------------+ +-------------+
| FL_Port |---->| Private Loop |---->| Public Loop |--->.
+----+----+ | Device | | Device | |
| +--------------+ +-------------+ |
| +--------------+ +-------------+ |
+-----<----| Private Loop |<----| Public Loop |<---'
| Device | | Device |
One of the difficulties of the above topology is that FC-AL requires
ALL devices on a loop which contains an FL_Port to be able to live
with a "soft-assigned" address due to possible address reassignment by
the Fabric when an Public Loop device logs in with the FL_Port. If the
FL_Port reassigns an AL_PA which conflicts with a hard-assigned Private
Loop device address, the Private Loop device must be able to use a
soft-assigned address (one of the remaining, unused AL_PAs).
Open issues for next meeting:
1) Can closed loop devices live with soft-assigned addresses?
2) Why do FL_Ports need to reassign the AL_PA? Can/should we prohibit this?
3) Does system SW expect a guaranteed relationship between a physical
device and an AL_PA (like SCSI parallel)?
4) To simplify FL_Port architecture and make address resolution on "mixed"
loops straightforward, can Private loop devices be required to perform
FL_Port login as the price of FL_Port coexistence?
Aside from the FLOGI issue, as part of power-up initialization SCSI
Initiators are required to (in the following order):
a) discover the Target N_Ports with which it is expected to
communicate (typically on a Private loop by attempting OPNs to the
AL_PA address space).
b) perform N_Port login with the discovered Targets,
c) perform Process Login with the Targets with which N_Port login
has been successfully completed.
If Fabric Login is required, step (a) would include attempting OPN to
AL_PA=0, and step (b) would include performing login with AL_PA=0.
It was also decided that:
- N_Port LOGO carry with it an implicit PRLO.
- PLOGI or PLOGO abnormally terminates all open Exchanges
- A "soft" login would be useful for login parameter discovery...
3. "PASSIVE" LOGIN
A "verify" Login, equivalent to MODE SENSE in SCSI, would allow
devices to exchange Service Parameters without actually modifying them
or having them take effect (a "non-destructive", or "Passive" login
versus "Active" login). This could be accomplished by defining a new
bit in the Common Service Parameters:
23.6.3 N_Port Common Service Parameters - N_Port Login
18.104.22.168 Common features
Word 1, bit 27 - Passive Login
If set = 1, Passive Login is in effect. Login parameters both
in the Login payload and the ACC payload are for reporting
purposes only, and shall not modify or otherwise have any effect
on login parameters in either the Login Initiator or Login
Recipient. Passive Login also shall not affect Process Login
parameters, or any open Sequences or Exchanges.
If set = 0, Active Login is in effect and operates per clause
The purpose of this login option is to give devices the ability to
"poll" the loop upon device insertion, to determine if the login image
before insertion matched the login image after insertion without
actually terminating all open Exchanges. This would also allow an
Initiator to only perform Active Login with the device(s) that were
newly inserted, allowing a more friendly "hot plugging" environment.
4. TARGET-INITIATED RECOVERY ABORT
It was agreed upon that Target ULPs should NOT be required to initiate
Recovery Abort procedures, and that these procedures should be the
responsibility of SCSI Initiator ULPs. Since all communication is in
class 3 for Private Loop devices, even FC-2 requirements do not mandate
ABTS for this Profile. Therefore, neither the Target ULP or the
Target NL_Port will transmit ABTS in the Private Loop profile. It was
agreed that the group will support a proposed change to FCP to
accomodate this behavior (and also to align FCP wording to accomodate
class 3 implementations).
In class 2, it is expected that future Public Loop Target NL_Ports would
follow FC-PH rules for transmitting ABTS even though the Target ULP
would still not be required to initiate Recovery Abort.
- Target ULPs are never required to initiate FCP Recovery Abort,
regardless of the class of service under which their N_Ports
- Class 3 Target N_Ports are never required to initiate ABTS.
- (Future) Public Loop Class 2 Target N_Ports are required to obey
FC-PH rules for ABTS.
- Task management flags on Private loops thus become merely "early
warning" of impending Recovery Abort processes to allow Targets
to begin clearing Exchange resources.
A write-in concern from Bob Snively involved "Dead" initiators which
leave open Exchange resources lingering in Targets. FCSI-compatible
Targets have the option of implementing "Resource Recovery" timers
which spontaneously reclaim Exchange resources which have been idle
for longer than a predefined period of time. Should we add this
option or leave it unaddressed (as in parallel SCSI)?
5. SCSI COMMANDS
It was agreed that the SCSI Command table be pared to simply a list of
commands required to be implemented at the Target. All other commands
would be optional.
READ DEFECT DATA was viewed as a useful and required prognostic tool.
However, F/C/DLF = 0/0/000 is described as a "Vendor-specific" format.
If this format is used (as with FORMAT UNIT) then it is unclear
whether or not Block Format, Bytes from Index Format, or Physical
Sector Format is used to describe the defects. Open issue:
Since READ DEFECT and FORMAT are mandatory in the Profile, how does
a Vendor-specific Defect Descriptor Format promote interoperability
on these commands? (see 8.2.1 and 8.2.8 in SCSI-2).
ACA ACTIVE status = Required was in conflict with Table 7, which
prohibited the ACA Type task attribute. It was agreed that the
profile should reflect SCSI-3 requirements for ACA and therefore ACA
Type will be changed to Required. CA with autosense was perceived to
be insufficient in handling all error recovery scenarios in future
Targets. In particular, Seagate emphasized that recovering cached
data when Write Caching was implemented requires ACA.
Jim Coomes gave an overview of the Loop Resiliency Circuit, which he
also later repeated in Keystone for ANSI attendees. Below is a
logical block diagram of the LRC function:
| +-----------+ |
| | MUX | |
| | | |
+--->| 0 | |
| Out |--->------- | --> To next
From previous --+------->| 1 | | LRC input
LRC output | | | |
| | Select | |
| | Input | |
| +-----------+ |
| ^ |
| | Bypass |
| | Control |
| | |
| +-----+-----+ |
| Disk | | Disk |
| Input | | Output |
+------->| DISK |------>-----+
At the ANSI meeting there was some confusion as to what the disk
should do if there is no LRC circuit present. My understanding is
that all the disk does when it receives the PBE is that it sets the
"Bypass" signal, and goes to MONITORING state in NON-PARTICIPATING
mode until a PBD is received. The Bypass control on the mux selects
the "1" input rather than the "0" input, which bypasses the Disk
Output and replaces it with the output from the previous Disk/LRC
The Mux, if present, prevents the Disk Output from being "seen" by the
Loop even though the disk is still echoing it's Input to it's Output.
What the downstream device will actually be seeing is the output from
the upstream device as asynchronously buffered through the bypass
circuitry. However, while the disk is bypassed, it is "eavesdropping"
on it's input line for a PBD primitive.
If no Mux is present, the disk appears to the rest of the loop to
simply exist transparently in Monitoring/Non-Participating mode until
a PBD restores normal operation. A disk which has been bypassed
without the LRC circuit does NOT "break" the loop. The disk, upon
receiving PBD, will clear the "Bypass" line, and will respond normally
to Disk Input activity.
For disk drives, a Target which receives a PBE will terminate all open
Exchanges. This is because when a Target comes back online after a
PBD, it is unaware of not only how long it may have been offline, but
whether or not topologies or Hosts have changed. The responsibility
of reinitializing the device and/or the Loop is owned by the PBE
Originator or it's proxy. This raises the question of whether or not
the Target needs to clear it's login parameters when bypassed, or
whether it can rely on the PBE Originator to reinitialize the Target
once it has been enabled.
Jim also mentioned that Seagate's implementation has been modified to
consolidate the bypass circuitry on a set of plug-in cards, rather
than force implementation of an active backplane. This results in
more backplane traces, but a more flexible design for those worried
about having active components on a backplane.
Obviously, this area will be discussed in more detail at the next
8. RESET, INITIALIZATION, and ADDRESSING
Open issues which were either deferred until after the Keystone
meeting or are still under discussion:
- OPN-NOS/OLS or LR/LRR vs LIP for selective reset
- L bit vs LIP for global reset
- Dual port behavior on selective/global reset, Target Reset, and
Clear Queue (see recent SCSI reflector discussion on this subject)
- What events at the Target cause logout of all Hosts and
termination of open Exchanges?
o Loop Failure (Loss of Sync for > R_T_TOV)
o First initialization
o New address
o Global reset (both ports?)
o Selective reset (both ports?)
o Unable to acquire hard address during initialization
o Unable to acquire previously assigned address during initialization
- Should Targets be required to accept soft addresses from FL_Ports or
should FL_Port interoperability be deferred? Hosts?
- Should Private loop Targets be required to perform FLOGI with FL_Ports?
- Address assignment - behavior if unable to obtain:
o hard address
o previously assigned address (not from fabric)
o fabric assigned address (only if fabric login performed - could only
happen if new fabric was inserted in place of old fabric and old fabric
addresses were lost)
An attempt will be made to document the clearing effect of specific actions
via a table similar to the one below:
Tar Clr Glob Abort Sel OPN +
CLEARING EFFECT Rst Queue Rst Task Rst PLOGO PRLO NOS/OLS ABTS ...
--------------------- --- ----- ---- ----- --- ----- ---- ------- ----
N_Port Login parms
Tasks for other Inits
Mode Page parms
9. COMMANDS RECEIVED IN ABSENCE OF LOGIN
- Class 3 Frames discarded
- If N_Port Login missing, N_Port Logout issued as courtesy to Originator
- If FCP Login missing, FCP Logout issued as courtesy to Originator
It was agreed that the SFF document will be referenced instead of
including the mechanical drawings in Figures 3 and 4.
Gary Stephens had some comments on an earlier revision of the profile.
I have incorporated some of the editorial changes, and will bring
copies of his comments to the Sept meeting so that we can discuss the
technical issues which are still relevant.
Version 0.40 of the Profile will be handed out at the meeting.
Postscript will be available via ftp on the NCR reflector.
More information about the T10