6/95 FC-AL Direct Attach Disk Adhoc Minutes
Kurt Chan
kc at core.rose.hp.com
Thu Jun 29 19:23:41 PDT 1995
From: Kurt Chan
To: FC, SCSI Reflectors
Subj: 6/95 FC-AL Direct Attach Disk Adhoc Minutes
Date: 6/29/95
FC-AL Direct Attach Disk Adhoc Meeting Minutes
Rochester, MN
6/16/95
Dal Allan ENDL dal.allan at mcimail.com
Jaime Calle AT&T GIS jaime.calle at sandiegoca.attgis.com
Kurt Chan HP Roseville kc at core.rose.hp.com
Mike Chenery Fujutsu mchenery at fcpa.fujitsu.com
Jim Coomes Seagate jim_coomes at notes.seagate.com
Pete Cummings IBM petec at vnet.ibm.com
Brian Doore Seagate brian_doore at notes.seagate.com
Phil Duclos Array Tech pjd at arraytech.com
Bob Edge Tektronix bob.c.edge at tek.com
Dave Ford Cambex dford at cambex.com
Mike Fitzpatrick Seagate mike.fitzpatrick at notes.seagate.com
Gene Freeman Symbios Logic gene.freeman at symbios.com
Ed Frymoyer EMF emf at best.com
Ed Gardner Quantum gardner at acm.org
Bill Galloway Compaq billg at bangate.compaq.com
Gary Goodwin IBM ggoodwin at vnet.ibm.com
Doug Hagerman DEC hagerman at starch.enet.dec.com
Norm Harris Adaptec nharris at eng.adaptec.com
Tim Johnson Cray tjohnson at cray.com
Hyeu Tae Lee htlee at prism.etri.re.kr
Mike Miller Seagate mike_miller at notes.seagate.com
Gene Milligan Seagate gene_milligan at notes.seagate.com
James W. Oliver SGI oliver at sgi.com
Tom Osten IBM thomas_j_osten at vnet.ibm.com
Thomas M. Pasker crbh99a at prodigy.com
Wayne Rickard Emulex w_rickard at emulex.com
Richard Rolls IBM rrolls at vnet.ibm.com
Jeff Stai Western Digital stai at dt.wdc.com
Gary Stephens FSI 6363897 at mcimail.com
Arlan Stone Unisys arlan.stone at mv.unisys.com
Horst Truestedt IBM truested at vnet.ibm.com
Peter Walford FCSI/DemoGraFx walford at btr.com
Joel Warford Adaptec jwarf at corp.adaptec.com
Fanny Wong IBM fwong at vnet.ibm.com
Stewart Wyatt HP DMD stewart at hpbs3928.boi.hp.com
Teras Yonker IBM teras at vnet.ibm.com
1. SCHEDULE AND SCOPE
Although this was the last discusssion of the day, it is reported here
first since it had the most impact on the future activities of the
group. At the suggestion of Dal and Doug, it was agreed that our
highest priority was releasing a document for public consumption
representing closure on the agreements to date. An SD-3 for a Technical
Report will be submitted to X3T11 in August, with an editor for that TR
to be named. We'll still meet during the Monday of X3T10 week in
Colorado Springs at the Red Lion, but primarily to confirm the changes
agreed upon at this meeting. New subjects must be posted on the
disk_attach reflector prior to the next meeting in order to optimize
meeting time.
In order to invite review of the TR by the tape communities and others,
the term "Disk" will be replaced by "FCP" in the title, although the
content will not otherwise change (except some softer wording in the
Scope section to connote that the non-disk specific sections may be
applicable to other device types).
It is expected that Friday of X3T11 week in Tarrytown and Monday of
X3T10 week in Manchester will be available for FC-AL2 discussion.
2. ADDRESS DISCOVERY AND NPA USAGE
The FC-PH working group suggested that the Read Hard Address ELS be
changed to accomodate six identifiers:
- Hard Address for LIHA Loop Initialization (8 bits)
- Preferred Address for Fabric Login (24 bits)
- N_Port ID (24 bits)
- Port Name (60 bits)
- Node Name (60 bits)
The adhoc WG discussed the addition of one bit as a pointer to a "Node
Discover" function (yet to be defined). This function would report node
attributes such as how many ports are connected to the node, whether or
not the other ports have functional addresses, etc. However, since it
was unclear how this bit would be used to solve generic multi-pathing
diagnostics, it's inclusion will be deferred. For example, for an
N-ported node with 'N-M' ports functional, some method of communicating
configuration as well as diagnostic information is needed which is
beyond the scope of ADISC.
The NPA bit in PLOGI will be defined in a later version of FC-PH2. As a
placeholder for future reference, it's use will be prohibited in the
until the NPA proposal can be fully evaluated by the group or in public
review.
3. TARGET-INITIATED PDISC
A case was made for requiring targets to validate the initiators they
have open tasks with before resuming those tasks following a LIP. It
was deemed insufficient to have the ports which CHANGED their addresses
be responsible for originating PDISC, since Jim Coomes described a
scenario where target-initiated PDISC is essential.
Consider a dual-ported initiator connected to separate loops:
+-----------+-----------+ +------------+ +-----------+
| | Initiator |---->| Target |---->| Target |---+
| | Port | | AL_PA = 2 | | AL_PA = 3 | | LOOP 1
| | 1ABCDEF | +------------+ +-----------+ |
| | AL_PA = 1 |<---------<-----------<-----------<-----+
| +-----------+
| NODE |
| 0ABCDEF +-----------+ +------------+ +-----------+
| | Initiator |---->| Target |---->| Target |---+
| | Port | | AL_PA = 2 | | AL_PA = 3 | | LOOP 2
| | 2ABCDEF | +------------+ +-----------+ |
| | AL_PA = 1 |<---------<-----------<-----------<-----+
+-----------------------+
The above configuration consists of two identical loops with identical
AL_PAs. The targets for Loop 1 are in one cabinet, and the targets for
Loop 2 are in another cabinet. The cabinets are inadvertantly swapped
so that Initiator Port 1 connects to Loop 2, and Initiator Port 2
connects to Loop 1. Loop initialization in the initiator does not
detect any changes, so if the targets do not validate that the same
initiator ports are in use before they continue I/Os with those
initiator ports, data corruption may occur.
Furthermore, if an initiator merely goes offline, there are no timers in
the target to reclaim resources dedicated to the dead initiator, which
may affect the performance of the remaining initiators.
Resolution: If Target-Initiated PDISC detects that an Initiator for
which it has open tasks is no longer present (the Port|Node name pair is
nonexistent at the expected AL_PA) the target shall implicitly abort all
tasks associated with the missing initiator by performing implicit
logout.
4. HARD VS PREVIOUSLY ACQUIRED ADDRESSES
Brian described why he thought hard addresses should not use LIPA
following address switch changes:
WWN = A WWN = B
+-----------+ +----------+ +----------+
| |---->| TARGET |---->| TARGET |---+
| Initiator | | Hard = 1 | | Hard = 1 | |
| AL_PA = 3 | | Soft = 1 | | Soft = 2 | |
| | +----------+ +----------+ |
| |<---------<----------<---------<-----+
+-----------+
An initiator is loop master, and two targets share a conflicting hard
address. Target B defers to Target A, which is 'upstream' from B. The
initiator, through the use of ADISC, notices the hard address conflict
and points a system administrator to the pair of conflicting targets.
The administrator changes the hard address of Target A so it doesn't
conflict with B and resets A:
WWN = A WWN = B
+-----------+ +----------+ +----------+
| |---->| TARGET |---->| TARGET |---+
| Initiator | | Hard = 2 | | Hard = 1 | |
| AL_PA = 3 | | Soft = 1 | | Soft = 2 | |
| | +----------+ +----------+ |
| |<---------<----------<---------<-----+
+-----------+
Since B attempts to acquire it's previously acquired AL_PA instead of
it's hard address, we end up with the same configuration unless BOTH
targets are hard reset.
Brian's philosophy was that a device should not be configured to
acquire a hard address unless the application could not tolerate having
that address at any other value. An example was raised whereby
evolving software could initially require hard addresses, but in the
future may migrate to being tolerant of soft addresses but would not
want to require it's users to set switches to '7F' on all legacy
storage cabinets in order to function with the new SW.
The concensus of the group was that if 'N' devices are configured with
conflicting hard addresses, the acceptable penalty for applications
that require unique hard addresses is to:
a) resolve ALL switch conflicts before resetting ANY devices, and
b) reset/power-cycle all 'N' devices with address conflicts
rather than allow exceptions to the FC-AL rules regarding previously
acquired AL_PAs. Applications which ARE tolerant of soft addresss
need not take this action. All private loop devices will be required
to follow the FC-AL rules regarding previously acquired addresses.
(Note - this may lead to the '7F' setting never being used, since
targets will perform appropriately for soft address tolerant
applications regardless of what the hard address switches are set to).
5. RRQ
HP suggested that, in order to minimize differences in error recovery
between fabric and loop based initiators, that targets support the RRQ
ELS. For private loops (or fabrics which guarantee order) the recovery
timer can be set to zero. In the absence of protest from target
implementors, this will be added to the profile.
6. TIMERS
A basic dilemma exists between the various timers used. E_D_TOV, which
is used to determine when to time-out loop initialization, must be long
enough to accomodate large, maximally configured physical loops with
"slow" devices. However, other timing functions derived from E_D_TOV
need not be long (indeed, some can be zero) on in-order fabrics such as
private loops. I will summarize the issues and write up a set of timer
recommendations for the next working group.
7. FCP_RSP LENGTH
Jeff Stai proposed putting restrictions on the variable length fields in
FCP_RSP for both GOOD and non-GOOD status. The reasons are to be able
to automate the handling of status efficiently without having to worry
about large payloads. 24 bytes of payload overhead are already used in
FCP, even with zero length FCP_RSP_INFO and FCP_SNS_INFO. Therefore,
the following field length restrictions will be added:
FCP_RSP_INFO FCP_SNS_INFO Total FCP_RSP payload
------------ ------------ ---------------------
GOOD status 0 bytes 0 bytes 24 bytes
non-GOOD status 4 bytes 100 bytes 128 bytes
8. 128 REVISITED
It was decided that the profile should continue to require all devices
to be able to receive 256-byte frames, since FC-AL requires each
participating NL_Port to be able to receive 132-byte initialization
frames (see FC-AL 4.5, clause 10, page 50).
9. LOOP_ID DEFINITION
Dal suggested that the concept of Loop_ID need only apply to the
SFF-8045 definition: the 7-bit representation of the Hard AL_PA. His
reasons were:
a) if hard addresses are not being used, Loop_IDs lose their usefulness
in identifying targets (positional information or other application-
specific information is required), and
b) SFF-8045 already uses the term "Loop Identifier".
A separate term, therefore, will be defined to denote the 7-bit
representation of a "working" or "operating" address (which may be
fabric-assigned or a soft address as well as a hard address).
More information about the T10
mailing list