Proposal for IEEE company_id based formats for FC-PH world-wide identifiers

Mon Jan 13 15:32:24 PST 1997

* From the SCSI Reflector (scsi at, posted by:
Concerns have been raised about the omission of the "Association" field from the
Device ID page in SPC.  Rod DeKoning's proposal defining the "Association"
field arrived too late for inclusion in SPC, which was starting first public
review at the time.  The proposal will be incorporated in SPC-2, a first
draft of which should be available by summer.

Regarding the matter of the WW_id for a RAID controller being used to set the 
high-order 64-bits of a 128-bit volume's WW_id, I have the following comments.

My understanding of Rod's proposal is that the definitions being described
represent one suggested way of producing most, probably all of the uniqueness
results Mike and Larry desire.  WARNING, this statement applies ONLY to the
uniqueness requirements; the FRU requirements are another matter entirely.

One cannot use the information in Rod's proposal to build an algorithm that 
decodes the WW_id received from any volume into FRU information about the 
hardware currently providing access to the volume that sent you the WW_id.  
Stated differently, I think Rod IS NOT attempting to do anything that makes 
a volume WW_id useful as a FRU identification tool.  FRU identification must 
be accomplished using some other SCSI tool; Request Sense data, the ASCII 
information page, SES, some other (any other) SCSI tool.

Also, if someone else devised a method for creating volume WW_ids that meet the 
uniqueness needs described by Mike, I seriously doubt that Rod would block their 
using that method.

Starting from the assumption that the primary goal is to give a newly created
volume a WW_id that is truly globally unique for all time, let's consider
how Rod's proposed scheme works.

First, the controller that creates the volume places its own globally unique
WW_id stamp on the volume's WW_id.  Any given RAID volume can only be created
by one controller in one place at one instant in time.  So, when the controller
that creates the volume stamps its own WW_id onto the volume's WW_id, a primary
level of uniqueness has been established.

In addition, using the controller's own WW_id as part of the new RAID volume's 
WW_id immediately bounds the amount of knowledge the controller must have in
order to guarantee the global uniqueness of the volume's WW_id.  Since no other
controller anywhere in the world can share the creating controller's WW_id, 
the only knowledge the creating controller needs to make the volume's WW_id
unique is knowledge it has stored inside itself.  Any other scheme that I
can think of requires the controller creating the RAID volume to use knowledge
|from outside itself to guarantee the global uniqueness of any volume WW_ids
it creates.  Reliance on this outside knowledge inherently adds a risk of
non-unique WW_ids creeping into the system.  For example, reliance on volume
labels probably will produce WW_ids that are not globally unique, because
of the human preference for certain volume labels, e.g., SYSTEM.

What follows is my attempt to read Rod's mind.  This should in no way be
thought of as anybody's product plans.  I'm just a sales guy.

You might ask, what knowledge can a RAID controller hold in itself that can
be used to guarantee that each low-order 64-bit number it concatenates with
its own WW_id is different from every other such number it creates?

One possibility is time (the time that the RAID volume is created).  Most RAID
controllers need a system clock for other purposes, so creation time usually
is available for making WW_ids.  Time is pretty unique, but subject to repeats 
caused by time zone changes or switches to daylight savings time.

Another possibility is a counter that gets bumped by one every time a new RAID 
volume is created.  This means that the controller must have a nonvolatile 
place to store the counter, but what's another byte of NVSRAM among friends.
Of course, even NVSRAM gets blown now and then, and there's always the hacker
bent on destroying the world by breaking a volume's WW_id.  So, even the
counter idea isn't perfect.

What if we take two 90% solutions and combine them into a 99.999% solution?
Let part of the "only the controller knows for sure" 64-bits be generated
|from the time at which the volume is created and the rest of the 64-bits come
|from a handy NVSRAM counter.  Sure, the 128-bit WW_ids created from a combina-
tion of controller WW_id, time and a counter are subject to potential repeats.  
But, the odds of such repeats are getting so small that no sane betting person 
would take them.

As Rod has noted, after the RAID volume is created, its WW_id belongs to it
regardless of how its accessed, regardless of what happens to the RAID control-
ler that created it, for ever an always (or at least until it's reformatted).
Aside from the fact that a volume's WW_id uniquely identifies it as different
|from all other RAID volumes, no useful information can be gained by parsing
the contents of the volume's WW_id.  Okay, a hot-shot hacker can tell you
the WW_id of the controller that first created the volume, but who cares.
The controller that created the volume could be silicon dust in somebody's
recycling plant by now.

Rod, I apologize in advance for any misrepresentations of your thinking
I may have stated or implied in the above discussion.

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

More information about the T10 mailing list