Summary of ANSI Discussions on Device IDs

Mike Wenzel mw at core.rose.hp.com
Mon Aug 26 16:34:35 PDT 1996


* From the SCSI Reflector (scsi at symbios.com), posted by:
* Mike Wenzel <mw at core.rose.hp.com>
*
Hi Bob,

Things are getting clearer, but I'm still confused on a couple of points.
Could you clarify the spots noted below?

Thanks,

Mike Wenzel
mw at core.rose.hp.com
======================
At 04:27 PM 8/13/96 -0700, Bob Snively wrote:
>* From the SCSI Reflector, posted by:
>* Bob.Snively at Eng.Sun.COM (Bob Snively)
>>D. NODE IDENTIFICATION
>>   -------------------
>>The third most important entity to identify is the node.  The "Node"
>>appears to mean different things to different people.  The two
>>prevalent views, I will term as "enclosure" and "controller".  A unique
>>identifier for the node is already required as part of the Port log-in
>>for FibreChannel.  It is not clear to me whether this should refer to
>>the enclosure or the controller.  It appears to me that both levels are
>>needed.  Further clarification is needed. But there was definite agreement 
>>that Node identifiers should also be globally unique.
>>
>> 1. ENCLOSURE ID
>>
>>    "Enclosure" in this context, means the box containing the Storage
>>    Entity.  This could be recursive, since a Storage Entity could, for
>>    exmaple, be a physical device that shares a box with other physical
>>    devices, and the box itself could share a rack with other boxes.
>>
>>    Firewire has the concept of a "Module", which contains one or more
>>    nodes that are removed or installed together as a whole.
>>
>>    The computer's system administrator obviously needs to know the physical
>>    location that corresponds to a Storage Entity and what other Storage
>>    Entities will be affected if the related box is removed.
>>
>>    Therefore, the Enclosure ID would be the same regardless of what port
>>    is used to reach the Storage Entity.
>>
>>    There is another document, available from http://playground.sun.com/SES,
>>    that defines the SCSI-3 Enclosure Services (SES).  This defines a number
>>    of services that may be provided by a separately-addressable enclosure
>>    device.  (I'm not clear how the address of this device is inexpensively
>>    correlated with a given Storage Entity.)
>>
>
>An identifier, typically the hard-wired address of the device (8-bits or less)
>is provided for each device.  The driver then correlates access through
>the same port or node as the SES device with the hard-wired address of
>the physical devices.  Virtual devices are not defined by the SES, but
>must be managed by the RAID device manager.
>
>Note that the enclosure ID is not necessarily the same as the "node ID"
>or controller ID presented by the FC login process or by the INQUIRY
>VPD access to LU 0.  The enclosure ID is provided by the SES.

OK. Now I've read the SES document, and I still have big-picture questions.
Maybe there is another document (like some forthcoming draft of the SCSI
architecture) that answers these questions.  If so, please just tell me
where to look.

The SES document talks about an "enclosure services process" that can be
reached via an "enclosure services device" or by using the enclosure
services commands with some other device that has indicated support of the
enclosure services, together with other device functions.  Other places in 
the document make it look like the "enclosure services device" might be a 
LUN at the same target address as other LUNs within the enclosure, but this
isn't clear.  So my questions are:

1. For the SES enclosure model, how many SCSI Targets are there per enclosure?  
   Using FibreChannel as an example, how many FibreChannel port addresses may 
   there be for a given enclosure?  
   a. For high-availability topologies, I would assume that there may be many
      targets, just for routing purposes.  So the real question is whether ALL
      the LUNs within the enclosure are accessible from ANY of the 
      SCSI Target (FibreChannel port) addresses?
   b. If the answer to (a) is that there may be an arbitrary relationship
      of LUNs to target (FC Port) addresses within the enclosure, then
      what tells the host computer which target addresses are related to
      the same enclosure?  Must each target address support the enclosure
      services, as either a separate or a combo LUN?

2. Since you are careful above to say that an enclosure is not equivalent to
   a node, and below, that a controller is not equivalent to a node, what IS 
   a "node" expected to correspond to?  What does the "Node ID" in the FC
   login correspond to?  Is it a super-enclosure that other enclosures may
   be nested within?  I'm lost.

3. What correlates a given LUN with an SES-provided, vendor-dependent
   "hardwired address" byte?  I can't see how this works without either
   adding fields to Type Descriptor Header (SES Table 5, page 13), or
   requiring all LUNs to support some enclosure services.


>SES provides mechanisms to identify the path by which the SES process
>was accessed and to determine which of redundant SES processes is
>active and provided the data.

These mechanisms did not jump out at me.  Where are they in the SES
document?

>> 2. CONTROLLER ID
>>
>>    Several people also thought it was important that the controller
>>    related to a port be identified.  Perhaps this would help the computer's
>>    system administrator know what ports to Storage Entities would be
>>    affected if a controller is replaced?  (I'm not sure of the other
>>    possible applications.) 
>>
>>    Therefore, the Controller ID would be the same for all ports to a
>>    Storage Entity that share the same controller.  But since an
>>    enclosure may contain multiple controllers, not all ports to a
>>    given storage entity would have the same Controller ID.  (Perhaps
>>    only LUN 0 for a given port needs to report the controller ID?)
>>
>
>The node ID is potentially independent of the controller id and the
>LUN 0 id, although typically, one process serves all these functions
>and would generate a single value for all of them.
>
>>
>>F. IMMEDIATE AVAILABILITY OF IDs
>>   -----------------------------
>>It was pointed out that hosts usually need Storage Entity IDs as part
>>of initial configuration and therefore, that these IDs should be
>>available immediately from a device (e.g., without waiting for a
>>spindle to spin up).
>>
>>Another point is that a disk array may have thousands of LUNs (and
>>Storage Entities).  It may be prohibitive to store multiple corresponding
>>identifiers in non-volatile RAM.  So perhaps a mechanism is needed for
>>the system administrator to tell the array which LUNs must have their
>>IDs immediately available (and which may not need to be available until
>>spin-up).
>
>I have difficulties identifying this as a problem.
>
>	1)	If the LUN is a disk drive, it is already required
>		to be able to Login independently of its spin-up state.
>		Login provides the port ID and node ID.
>
>	2)	If the LUN is a virtual volume, it is in the not ready 
>		state until the INQUIRY command can be executed.
>		INQUIRY provides the port ID and node ID.

I'm concerned about getting the ID of the "storage entity" as soon as
possible.  (I'll use the term "LUN" when we're done with this chain, if 
that's the right term.)  I'm assuming that sub-structuring of the 64-bit
or other ID formats is to be left up to the device vendor as much as
possible.  So the host computers cannot know the relationship of storage
entities to nodes and ports: the node ID and port ID values provide no
information as to where a given storage entity is, only the Device ID
does.

So it is necessary but not sufficient that the device has logged in with
the fabric immediately after power-up.  The host cannot configure its mass
storage until the Device IDs are available.  We'd like to get these before
the media spins up.  Also, as you point out below, the Device ID is not
a media label anyway.

>>=================== END OF ANSI DISCUSSION ON DEVICE IDs =================
>>
>>=================== ROD DeKONINGS PORT ID PROPOSAL =======================
>>
>>Changes approved by the working group to be added to SPC for the Device 
>>Identification VPD Page.
>>
>>The following is proposed to allow a client to determine the port that is 
>>being used to access a client:
>>
>>    Add a new field, called +Association+ to byte 1, bits 4-5 to the 
>>    Identifier descriptor (table 110 of SPC):
>>
>>[ED: See the above reference to the same document and section discussed
>> above for the Device ID.  Table 109 defines the Device Identification
>> Page, which contains a list of Identification Descriptors.  Table 110,
>> which Rod shows here, defines the structure for each Identification
>> Descriptor.]
>>
>>
>>   Bit      7     6     5     4     3     2     1     0
>>Byte     +=======================+=======================+
>>0        |     Reserved          |     Code Set          |
>>         +-----------+-----------+-----------------------+
>>1        | Reserved  |Association|     Identifier Type   |
>>         +-----------+-----------+-----------------------+
>>2        |                   Reserved                    |
>>         +-----------------------------------------------+
>>3        |               Page Length (n-3)               |
>>         +-----------------------------------------------+
>>4        |(MSB)                                          |
>>         +--                 Identifier                --+
>>n        |                                          (LSB)|
>>         +===============================================+
>>
>>
>>The following text and table is to be added to the Device Identification VPD 
>>description (Section 8.4.3) to support this change:
>>
>>+The Association field specifies the entity that the Identifier field is 
>>attached to.+
>>
>>Table xxx - Association
>>Value     Description
>>0    The Identifier field is associated with the addressed physical or 
>>     logical device.
>>
>>[ED: I take this to be the "Storage Entity"]
>
>[Snively:  I believe this is correct and clear from Rod's description.]
>
>>
>>1    The Identifier field is associated with the port that received the 
>>     request.
>>
>>2-3  Reserved
>>
>>[ED: Might we also use one of these values for the Controller and one for
>> the Enclosure?  What do people think?  Are there other places that are
>> more appropriate for attaching these IDs? ]
>
>[Snively:  No.  We have the necessary and sufficient IDs nicely defined now.]

I'm encouraged that you think so.  I still don't see how to correlate the
enclosure with the other entity levels, as I indicated in the questions
above.

>>The following rewording is also required for the last sentence of the first 
>>paragraph for section 8.4.3.
>>
>>+Logical Units may have more than one identification descriptor (e.g., if 
>>several types or associations or identifier are supported).+
>>
>>=================== END ROD DeKONINGS PORT ID PROPOSAL ===================
>>
>>===========MIKE WENZEL'S ANALYSIS/COMMENTARY ON SPC SECTION 8.4.3 ========
>>
>>The Device Identification page looks to be very close to what we need for
>>identifying Storage Entities!  There are several corrections and
>>clarifications (maybe specifications) that would help, though.
>>
>>Page 125, Section 8.4.3, first sentence: Since this section says that it is
>>    a "logical unit" that is being identified, it would help greatly if
>>    the "Storage Entity" concept that we discussed be linked to the 
>>    definition of "logical unit" in this document.  The definition on
>>    page 4 is fairly abstract and speaks mainly of the device server.
>>    I'm concerned that this could be confused with the controller.  There
>>    may be multiple controllers concurrently accessing a storage entity,
>>    so this would NOT be what we're after.  Wording on either page 4 or,
>>    preferable page 125 to clarify would be helpful.
>
>Long historic use and the SCSI glossaries are very clear about what
>constitutes a LUN and a device server.  The word storage entity is
>a dangerous word that may encourage people to think of this as providing
>a Unix volume label function.  It does not identify the data or the 
>recording medium, but rather the device (or in the case of a virtual
>device, the program) accessing the data.  I believe no change is necessary.

Bob, I respectfully disagree that the glossaries are clear on this.  In
looking over the documents, I find only abstract or simple definitions.  
Nothing I've found deals with multiple ports, controllers, etc., accessing 
the same chunk of storage.  I want to ensure that there is little or no chance
of misinterpretation of this point: that the Device ID indicates the physical 
or virtual chunk of storage, for fixed media, or a mount point for removable
media, and is the SAME value, for all paths used to reach the thing.

I'm not at all stuck on the term "storage entity".  If there is an existing
term that applies to the "thing", including these multi-port nuances,
then let me know and I'll use it.  So far, I'm not satisfied with the
definitions of either the logical unit (target-resident entity which 
implements a device model and executes SCSI commands) or the device
server (an object within the logical unit that executes SCSI tasks).
Without more description, it seems like multiples of these could operate
on the same, shared chunk of storage.  Tell me where to look where this
is clarified and I'll back off.

I agree that the Device ID (storage entity ID) does NOT provide a Unix
volume label function.  It also doesn't directly identify the data.  I don't
know what you mean that it identifies the "program" for a virtual device.
This is not anything like a Unix major number.  When an array controller
maps LUNs to physical spindles in some virtual relationship, I expect the
device ID to represent the application-visible chunk of storage that is
exported to the world outside the array.  I also think we need to insist 
that the Device ID value reported by a LUN change when this virtual 
relationship changes--the old entity does not exist any more, the LUN 
represents a different storage entity.  

>>Page 125, Section 8.4.3, end of first paragraph: We must specify that the
>>    ID values be the same for all ports used to reach the Storage Entity.
>>    In other words, it's OK to have multiple ID formats reported, but it 
>>    would make life impossible for the host if a different format is used
>>    for one or more interfaces; it would make life difficult if more
>>    formats are used on one interface than on another (creates a matching
>>    problem).  So we need the same list from all interfaces.
>>
>
>It is only necessary that the node id list be constant.  The port ids can
>be any old unique value and may have different formats.  SPC should
>clean this up as you suggest. 

I agree that the main problem is the node id, rather than the port id.
I like your wording, "any old UNIQUE value", as if that were easy and
commonplace.  ;->

>>Page 125, Note 53: This note contradicts the definition of type value 0 in
>>    table 112. The former says that the identifier should be guaranteed to
>>    be globally unique and the former says that there is no guarantee.
>>    We MUST have the guarantee.
>>
>>    Why must the type value be 0 for a virtual logical unit? 
>
>Beats me.  Your requirement of uniqueness and the same list seems to me
>to be more than adequate.
>
>>    Btw, what IS
>>    a "virtual logical unit"?  Is it the same thing as a logically-mapped
>>    volume, like the ones discussed at the ANSI meeting?  
>
>Virtual logical unit is the SCSI politically correct name for Virtual
>Storage Entity.

OK. So if we clarify the term "logical unit" to refer to a "chunk of storage,
regardless of how accessed", we'll be there, right?

>>    For our purposes,
>>    we certainly want the vendor to prefer EUI-64 for all sorts of Storage
>>    Entities.
>>
>
>We should have no prejudice about which worldwide unique value is used.

OK. 

>>Page 127, last paragraph: Why does the vendor only assign 24 bits?  So that
>>    each Storage Entity in an enclosure can have a globally-unique ID,
>>    why isn't the vendor working with the whole 36-bit space following
>>    the IEEE OUI?
>>
>
>I believe the main problem here is that Ralph will either have to 
>reference the standard formally or provide the analysis of the format.
>There may be some rules here we are not aware of, but that he understands.
>
>>Page 128, Table 113: It would help the understandability of the example if
>>    the ASCII values aligned with the Hex, i.e., one ASCII character per
>>    hex byte value.  Some of the ASCII values are on different lines from
>>    the corresponding hex.
>
>This looks correct to me.  Could you please identify the problem?

Hmm.  Something threw me off.  Now that I pick up an ASCII table and look
at it, everything looks right except for the ASCII for the last three
digits, which should be "#Eg" instead of "...".  I'm not sure how I was
looking at the table before, sorry.

>>=========================== END MIKE WENZEL'S COMMENTARY ================


*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list