98-145r0 - Discovering If This Is SES Port A or Port B

ROWEBER at acm.org ROWEBER at acm.org
Tue Apr 21 17:25:03 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* ROWEBER at acm.org
*
T10/98-145r0

Date:	 19 April, 1998
To:	 T10 Membership
From:	 Ralph Weber, T10 Alternate member from Symbios, Inc.
Subject: Discovering If This Is SES Port A or Port B

FC-AL drives are being implemented with the ability to have redundant
loops.  To utilize this redundancy systems are configured with
redundant host adapters or adapters with dual ports.  Let's label the
redundant loops from the host's point of view as loop X and loop Y.

Using the Device element entry in the SES Enclosure Control page, an
application client may independently manage the bypass circuits found
on dual port disk drives by setting the ENABLE BYP A (enable bypass on
port A) and/or the ENABLE BYP B bits. The physical connection from the
drive's port A (or B) to the host's loop X (or Y) is an FC cable, often
installed by the user.  So, the association between A and B and X and Y
is unpredictable and must be detected automatically by the application
client.  If the association is not detected correctly, use of the SES
Enclosure Control page ENABLE BYP X bits could easily render device
access impossible.

An application client might detect a configuration by trial and error.
It could enable the bypass on port A and scan loops X and Y to discover
where the path to the device disappeared.  This is unacceptable due to
its disruptive nature, especially in multiple-host environments.

For years, SCSI provided an acceptable means for the application client
to learn the identity of the port being used for communications, but
that capability was expunged from SCSI recently based on the idea that
a standard covering only two-port devices must be insufficient.  The
problem was further complicated by lack of an agreed mechanism for
identifying obsolete definitions, which resulted in the port identify-
ing mechanism being labeled vendor-specific when it should have been
labeled obsolete.

The goal of this proposal is the reinstatement of the long-standing
mechanism for identifying the port being used for communications.  The
history of the capability will be reviewed, showing that the capability
was on record much longer than it has been absent.  Then, a specific
proposal for reinstating the capability will be presented.  Lastly,
future possibilities for devices with more than two ports will be
discussed in light of the specific proposal made here.

History

In December, 1990, Gerry Houlder presented X3T9.2/90-136r2 (Extensions
for dual port SCSI ) to the plenary and received approval for inclusion
of a revised proposal (r3) in the applicable SCSI-3 documents (see
minutes in X3T9.2/90-193).  The revised proposal was reviewed at the
January, 1991 working group meeting without modification (see minutes
in X3T9.2/91-004) and 90-136r3 had its final document distribution at
the February, 1991 plenary (see minutes in X3T9.2/91-026).

The approved proposal (r3) included the following new bit definitions
in byte 6 of  the Standard Inquiry data.

    |=============================================================
    | Bit|  7   |  6   |  5   |  4   |  3   |  2   |  1   |  0   |
    |Byte|      |      |      |      |      |      |      |      |
    |=============================================================
    | 6  | Reserved    | Port |DualP |      Reserved             |
    |----|-------------------------------------------------------|

The meanings of  the two bits were as follows:

The Port bit is only defined when the DualP bit is set to one.  In this
case a Port bit of zero indicates that the current nexus connects to
port A and a Port bit of one indicates that the current nexus connects
to port B.  When the DualP bit is zero, the Port bit must also be zero.

A Dual Port (DualP) bit of one indicates that this is a dual port
device and conforms to the dual port requirements in this standard.  A
value of zero indicates that this device has a single port and doesn't
implement the dual port requirements.

In July, 1994, Gerry's proposal was incorporated in SPC revision 1.
The bit definitions were modified to remove the SCSI-2 nomenclature,
and became:

The Port bit is only defined when the DualP bit is set to one. A Port
bit of zero shall indicate that the device server received the INQUIRY
command on port A.  A Port bit of one shall indicate that the device
server received the INQUIRY command on port B.  When the DualP bit is
zero, the Port bit also shall be zero.

A Dual Port (DualP) bit of one shall indicate that this is a dual port
device and conforms to the SCSI-3 dual port requirements found in the
various applicable standards.  A value of zero indicates that this
device has a single port and does not implement the dual port
requirements.

The bits and their definitions remained unchanged in SPC until revision
8a (December, 1995).  At that time, only the DualP bit definition was
changed, to:

A Dual Port (DualP) bit of one shall indicate that this is a multi-port
(2 or more ports) device and conforms to the SCSI-3 multi-port device
requirements found in the various applicable standards.  A value of
zero indicates that this device has a single port and does not
implement the multi-port requirements.

In January, 1996, the working group changed the DualP (Dual Port) bit
to the MultiP (Multi-Port) bit but left the definition unchanged (from
revision 8a).  The working group also changed the Port bit to
Vendor-Specific.  These changes and others produced SPC revision 9,
which was the subject of a X3T10 letter ballot.  Four revisions later,
SPC revision 11a was approved as an ANSI National Standard.

There was no concept of "obsolete" is SPC in revision 9.  The word
"obsolete" appears only once in the entire document, in a description
of the DEC vendor id (part of an informational annex) as follows:
"Digital Equipment (Obsolete: New products use 'Digital')."  The
working group had no mechanism for making the Port bit obsolete, and
it could not make the bit reserved, so it took the only available
alternative, making the Port bit Vendor-Specific, to allow the
long-standing usage of the bit to continue.

In summary, from December, 1990 to January, 1996 the committee approved
definitions for bits 4 and 5 in byte 6 of the Standard Inquiry data
were as follows:

    |=============================================================
    | Bit|  7   |  6   |  5   |  4   |  3   |  2   |  1   |  0   |
    |Byte|      |      |      |      |      |      |      |      |
    |=============================================================
    | 6  | no interest | Port |MultiP|  not interesting          |
    |----|-------------------------------------------------------|

Taking some liberties with the actual wording, the meanings of the two
bits can be characterized as follows:

  |=====================================================================|
  | Port/  |                                                            |
  | MultiP | Meaning                                                    |
  |=====================================================================|
  |   00b  | Multiple SCSI ports not implemented.                       |
  |   01b  | Multiple SCSI ports implemented and this is port 0 (or A). |
  |   11b  | Multiple SCSI ports implemented and this is port 1 (or B). |
  |   10b  | Illegal combination of bits.                               |
  |=====================================================================|

>From January 1996 to the present (less than half the time the previous
definitions were approved), the bits 4 and 5 in byte 6 of the Standard
Inquiry data have been defined as follows:

    |=============================================================
    | Bit|  7   |  6   |  5   |  4   |  3   |  2   |  1   |  0   |
    |Byte|      |      |      |      |      |      |      |      |
    |=============================================================
    | 6  | no interest |  VS  |MultiP|  not interesting          |
    |----|-------------------------------------------------------|

VS means Vendor-Specific, MultiP=0 means 'multiple SCSI ports not
implemented', and MultiP=1 means 'multiple SCSI ports implemented'.

The Proposal

It is proposed that SPC-2 reclaim the "obsolete" Port bit by extending
the MultiP field to encompass both bits 4 and 5 as follows:

    |=============================================================
    | Bit|  7   |  6   |  5   |  4   |  3   |  2   |  1   |  0   |
    |Byte|      |      |      |      |      |      |      |      |
    |=============================================================
    | 6  | no interest |   MultiP    |  not interesting          |
    |----|-------------------------------------------------------|

It is further proposed that the following table of definitions be
provided for the MultiP field:

  |=====================================================================|
  | MultiP | Description                                                |
  |=====================================================================|
  |   00b  | This device has only one port or does not conform to the   |
  |        | SCSI multiple-port device requirements found in this       |
  |        | standard, SAM-2, and the applicable SCSI protocol standard.|
  |   01b  | This device has two or more ports conforming to the SCSI   |
  |        | multiple-port device requirements found in this standard,  |
  |        | SAM-2, and the applicable SCSI protocol standard(s).       |
  |        | The device server received the INQUIRY command on port 0   |
  |        | (or A).                                                    |
  |   11b  | This device has two or more ports conforming to the SCSI   |
  |        | multiple-port device requirements found in this standard,  |
  |        | SAM-2, and the applicable SCSI protocol standard(s).       |
  |        | The device server received the INQUIRY command on a port   |
  |        | other than port 0 (or A).                                  |
  |   10b  | Reserved                                                   |
  |=====================================================================|

Discussion of the Proposal

First, it must be noted that this proposal effects no changes for dual
port devices, even though the wording looks different from that found
in X3T9.2/90-136r3.  If a device has only two ports, then the port that
is not port A must be port B, and the long-standing description is
still valid.

However, the wording changes are more than gratuitous.  They address
the issues that caused the Port bit to be made obsolete (vendor
specific).  The 01b code allows identification of the 0 port,
potentially an interesting condition even for devices with more
than two ports.

When there are more than two ports, the 11b code identifies the case
when the application client must look beyond the currently defined
Standard Inquiry data to determine which port received the INQUIRY
command.  Many mechanisms might be used to standardize the port
identification process.  A field might be added to the Standard Inquiry
data.  However, there is no sufficiently large collection of contiguous
bits before byte 56, which puts usage of the Standard Inquiry data in
previously uncharted territory.  A VPD (Vital Product Data) page might
be added or a current VPD page extended.  A Log or Mode page might be
added or extended.  Lacking knowledge of specific requirements for
identifying multiple ports beyond two, it is prudent to postpone
proposing how to accomplish the task to a time when more solid needs
exist.  It must also be noted that, in the 2.5 years since the Port bit
was made obsolete, no proposal has been made to provide for identifying
more than two ports.

Finally, the 10b code is available for future standardization for
identifying multiple ports, should some capability not envisioned here
be needed.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list