Direct Attach Ad Hoc Meeting Minutes, 8/94

Kurt Chan kc at
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
Date:   8/23/94

           FC-AL Direct Disk Attach Ad Hoc Meeting Minutes
                      Red Lion Stapleton
                         Denver, CO


    Dal Allan, ENDL             250-1752 at
    Kurt Chan, HP               kc at
    Jim Coomes, Seagate         jim_coomes at
    Brian Doore, Seagate        brian_doore at
    Giles Frazier, IBM          gfrazier at
    Norm Harris, Adaptec        nharris at
    Jean Kodama, QLogic         j_kodama at
    Fred Kool, Adaptec          fredkool at
    Greg Scherer, Emulex        g_scherer at
    Ken Smith, Conner           ken.smith at
    Paul von Stamwitz, Adaptec


         +---------+     +--------------+     +-------------+
         | 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...


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 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.


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
  are operating.
- 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)?


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).

6. ACA

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


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 PBE
  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 +
---------------------  --- ----- ---- ----- --- ----- ---- ------- ----
N_Port Login parms
PRLI parms
Task set
Tasks for other Inits
Mode Page parms
Open Sequences
Open Exchanges


- 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 mailing list