A/B Port bit in Inquiry Data

Binford, Charles cbinford at ppdpost.ks.symbios.com
Wed Feb 25 14:52:00 PST 1998

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Binford, Charles" <cbinford at ppdpost.ks.symbios.com>

[I Cc'd the FC reflector because I feel this issue is of interest to that 
side as well.  Sorry for the overlap to those of us on both reflectors.]

Thanks for the response Bob.  However, I don't like the answer :-).  Using 
the fact that "the loop is implicitly and vendor specifically identified by 
the esm port" is unacceptable to me.  From my point of view we have a set of 
standards with a hole in them.  Filling that hole with a *vendor unique* 
method may work for the here and now, but I think we should drive to a 
*standard* method of determining which loop is "A" and which loop is "B".

Today I feel the easiest and best solution to this problem is the A/B port 
bit in the Inquiry.  I am more that willing to listen to other ideas on how 
to solve the problem.  I'm not wanting to push the A/B bit, I just want a 
*standard* solution.

By the way, I curious what some of the other FC system vendors think. 
 Clariion, HP, Unisys, Compaq/Dec (others I probably missed...)

Charles Binford
Symbios Inc.

>From: Bob Snively
>To: cbinford; T10
>Subject: Re: A/B Port bit in Inquiry Data
>Date: Tuesday, February 24, 1998 4:34PM
>See my recommendation below.
>> * From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>> * "Binford, Charles" <cbinford at ppdpost.ks.symbios.com>
>> *
>> Hello Bob,
>> I agree with your comments in general.  However, I don't see how I can 
>> the mechanisms you mention below to solve the problem of mapping a path 
>> device to either port A or B in SES.  Consider the following:
>>        |--------------|
>>        |     Host     |
>>        |              |  Host with 2 FC adapters - hba1 and hba2
>>        |              |
>>        | hba1    hba2 |
>>        |---+------+---|
>>            |      |
>>           /        \
>>   Loop 1 /          \ Loop 2
>>         /            \
>>   |------------------------|
>>   |  esm device            |
>>   |                        |   FC JBOD with 5 dual-ported drives
>>   | d1   d2   d3   d4   d5 |   (d1 - d5), plus a dual ported enclosure
>> service
>>   |------------------------|   device (esm).
>> The SES definition of the Device element page (rev 8a, page 39) provides
>> ability to enable and disable the bypass for port A and port B
>> independently.  In my example above, I'd like to use SES to bypass ports
>> connected to loop 2 (say a port's receiver broke and brought the loop
>>  Given the picture, the host would issue an SES command via hba1, across
>> loop 1, to the esm device.  In the SES data, the host would indicate that 

>> the esm should bypass the 'B' ports of the drives.
>> Now, lets consider the assumptions I just made:
>>  - The "loop 2" connector on the JBOD box is connected to the 'B' port of
>> drives.  Valid assumption, manufacture can ensure that.
>>  - The ESM device interprets the 'ENBALE BYP B' bit in the SES data as
>> associated with loop 2.  Again, a valid assumption because it is under
>> control of the JBOD manufacturer.
>>  - Loop 2 is connected to hba2. INVALID assumption.  The *user* ran the
>> cables from the JBOD to the HBAs, software has no way to know if loop 2
>> (port B on the drives) is connected to hba1 or hba2.
>The trick here is that the loop is implicitly and vendor specifically
>identified by the esm port, which is identified by the appropriate report
>bit.  Hope that is some help.
>> Another way to look at the same problem is this.  Assume that loop 2 goes 

>> down for the same reason (broken receiver in a port).  The host knows 
>> the remaining good path is loop 1, **but he doesn't know if he should 
>> the esm device to bypass loop A or loop B ports**.  There must be some
>> reliable way to know if hba1 is connected to port A or port B of the 
>> The bit in the Inquiry seems to be a handy way to accomplish this.
>> it is limited to only two port devices, but then again so is SES's Device 

>> element definition.
>> If you have another way to solve the problem I'd love to here it.
>> Charles Binford
>> Symbios
>>  ----------
>> >From: Bob Snively
>> >To: T10 at symbios.com
>> >Subject: Re: A/B Port bit in Inquiry Data
>> >Date: Monday, February 02, 1998 5:51PM
>> >
>> >* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>> >* Bob Snively <Bob.Snively at Eng.Sun.COM>
>> >*
>> >
>> >As a reminder of the mechanism that was selected to handle port 
>> >the dual port stuff was essentially thrown out some time ago.  The
>> >mechanism that was put in place to address the questions that were 
>> >by dual ports were two:
>> >
>> >    Persistent reservation allowed establishment of reservations for
>> >    multiple initiator/port environments and allowed those initiators
>> >    in charge of the configuration to eliminate failing initiators from
>> >    the permitted group.  While there is still some work going on in 
>> >    area, the principles are sound.
>> >
>> >    The Device ID "page" in the Inquiry Data included a node identifier.
>> >    After SPC, but before SPC-2, this node identifier was extended to 
>> >    multiple identifiers in a single field.  One of the identifiers was
>> >    intended to identify the port uniquely, providing all the tools that
>> >    were necessary to complete the management of multiple port devices.
>> >
>> >For that reason, it is certainly unclear to me that any additional
>> >flag information is required to properly identify and manage multi-port
>> >devices, including large RAID devices.  It is even less clear to me that
>> >we want to drag in either an "a/b" concept or an "active/alternate"
>> concept.
>> >
>> >Bob
>> >
>> >
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at symbios.com
>> ------------- End Included Message -------------
* 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