Notes on IEEE as Unique ID Registration Authority

Mike Wenzel mw at core.rose.hp.com
Wed Sep 18 12:21:15 PDT 1996


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

I'm currently trying to "tie a ribbon" on the "Device ID" subject initially
discussed in the Serial Concerns group.  Several of the loose ends have been:
  * the SPC's references to an IEEE "EUI-64" format that is extremely 
    difficult to locate in IEEE documentation; 
  * the structure and use of the "IEEE Extended" Name_Identifier illustrated 
    in Table 44, page 115, of PC-PH rev 4.3, June 1, 1994; 
  * and conflicting reports of the viability of IEEE as a registration
    authority to ensure world-wide uniqueness of IDs for non-IEEE standards.
The purpose of this memo is to further discussion toward tying down these
loose ends.

To recap the subject: the problem we were mainly trying to solve is to 
uniquely identify a physical or virtual chunk of mass storage, regardless of 
the port or path used to reach it (e.g., in a multiply-connected, 
high-availability topology and/or in a multi-port disk array).  The ANSI 
X3T10 meeting held on July 15 in Colorado Springs, decided to use the
"Device ID" INQUIRY page for this purpose.  The Device Identification page 
is currently described in SPC (SCSI-3 Primary Commands, X3T10/995D, rev 9d, 
May 10, 1996, see page 125, section 8.4.3 of:
   ftp://ftp.symbios.com/pub/standards/io/x3t10/drafts/spc/spc-r09b.pdf
It was also agreed that the Unit Serial Number (see SPC, page 130, 
section 8.4.6) must identify the physical or virtual chunk of mass storage: 
in other words, it must be the same value regardless of the port used to 
reach the same chunk of storage. 

Along with other people, I talked to Gary Robinson, the chair of IEEE's
Registration Authority Committee (RAC).  Here is a summary of what I learned,
in the form of a question-answer session:

Q: Is it true that the IEEE only wants to administer Manufacturer IDs (OUI) 
   for Network Applications, like Ethernet/802?

A: That was IEEE-802's initial, knee-jerk reaction several years ago, when
   the request to use the 802 registration authority was first made by
   IEEE IO interconnect projects, like 1212-CSRs.  After much discussion,
   the IEEE decided that the need for unique IDs was so widespread that 
   the 802 registration authority was renamed and broadened to serve a
   wide range of projects.  Today, IEEE Organizationally Unique Identifiers
   (OUI) are used for unique addresses (the original purpose in 802), as
   well as unique IDs in 1212-CSRs, SCI, Firewire, FutureBus, and many other
   projects, ...even cellular telephones!

Q: Is the IEEE RAC worried about running out of Manufacturer ID values?

A: The OUI is 24 bits wide and can encode millions of manufacturer IDs.  In
   the 10 years that the registration authority has existed, a little over
   1000 values have been assigned.  There is very little danger of running
   out of OUI values in the foreseeable future.

   However, the IEEE is VERY careful in policing how the OUI values are
   used.  They want to ensure that the overall ID object that the OUI is
   embedded in is wide enough (in bytes), and that the procedures for 
   assigning ID values are tight enough, that there will be almost no need
   for a manufacturer to come back to the IEEE for additional OUI values
   (because of running out of space in the rest of an ID object).  To this
   end, they require that the uses of the OUI be carefully documented and
   presented to the IEEE RAC for review, dissemination, and archiving.
   Gary has concluded that the needs of different organizations are
   sufficiently different that it is a waste of time to try to negotiate
   a single format for a given value width (e.g., 64- or 128-bits)
   across all organizations.  So it is more practical to just ensure that
   each use is carefully thought through.

   Until recently, neither ANSI nor the FibreChannel groups had submitted
   a write-up of their desired use of the OUI to IEEE.  Several weeks ago,
   Bob Snively took the initiative to submit the attached draft proposal to
   the IEEE RAC for their review and comment (Bob had previously circulated
   this draft to the relevant reflectors for comment).  Gary said he thought
   the proposal was very well structured and that it only needed the addition
   of two carefully-worded points before it should be circulated to the
   rest of the IEEE RAC for review:
   a) A given manufacturer should only need one OUI value for all 
      applications, 802/Ethernet addresses, 1212 IDs, cellular phones, 
      whatever.  It is up to the company to maintain an internal registration
      authority to manage the values in its various ID spaces.
   b) All addresses and ID values, across all uses, must be as unique as
      possible.  For example, values used for 802/Ethernet addresses should 
      not be duplicated in FibreChannel world-wide names.  

      The thinking here is that new relationships and interconnections are 
      being invented every day and it is possible that number spaces which 
      were originally thought to be disjoint, can suddenly be found to be
      interrelated.  If and when this happens, the values may not be unique
      anymore, without this provision.  For the multitude of problems it 
      would cause, it is not worth trying to tightly-pack ID values into a
      narrow number space to save bytes anyway.  So as long as we have the
      space, we should manage it such that uniqueness need never be an 
      issue, regardless of changes in connectivity.

Q: Where is the EUI-64 format defined?

A: There was a draft 64-bit ID format document that was used for IEEE IO
   interconnect purposes some time ago.  It is not an IEEE standard and
   has not been posted to the IEEE web site, although it will be:
                  http://stdsbbs.ieee.org/faqs/OUI.html
   This format reportedly uses 24 bits for the OUI and the rest for 
   vendor-dependentID values.  No space has been set aside for a registration
   authority identifier, like the four-bit Network_Address_Authority used in
FC-PH.  Since it has already been used in a couple of places (like 
   FireWire), it is too late to change the format to add an NAA field.
   Therefore, this format does not meet the SCSI and FC groups' needs and
   something like the attached proposal is more appropriate.

---

Based on these discussions, I hope we can turn Bob's draft around and
formally submit it to the IEEE RAC.  I also hope that we can rapidly
modify out understanding of the relevant fields of SPC and FC-PH to
reference this ID format, so that we can begin using these values
in FibreChannel (and other serial) mass storage products as soon as 
possible.

I really like the proposed structure of the IDs and think it is well-advised
not just for removable media, as currently implied, but also for the
virtual chunks of mass storage presented by products like disk arrays.
[For example, the extra "breathing room" provided by the second 64-bit
field could allow a disk array to automatically change the Device ID for
a LUN when the storage behind it is reconfigured to comprise a distinctly
different (as opposed to just larger) entity.  Changing the value allows
hosts sharing the LUN to detect when their use of the LUN has become 
obsolete.]  So with a couple of minor edits, it appears to me that it
should be ready to go.

Questions?  Comments?

Best Regards,

Mike Wenzel

 ************* |  Mike Wenzel,
 *****   ***** |  Hewlett-Packard - NCD System Interconnect Lab,
 *** /_  _ *** |  Mailstop 5601,
 ** / / /_/ ** |  8000 Foothills Blvd.,
 ***   /   *** |  Roseville, CA 95747-5601
 *****   ***** |  E-mail: mw at core.rose.hp.com
 ************* |  Telephone (916) 785-5609  FAX (916) 785-2875

============ Bob Snively's Draft Submission to IEEE RAC =============
Return-Path: <scsi-owner at Symbios.COM>
Date: Sun, 11 Aug 1996 14:51:36 -0700
From: Bob.Snively at Eng.Sun.COM (Bob Snively)
To: scsi at Symbios.COM, fc at network.com
Subject: Proposal for new NAA_ID for unique worldwide names
X-Sun-Charset: US-ASCII
Sender: owner-scsi at Symbios.COM

* From the SCSI Reflector, posted by:
* Bob.Snively at Eng.Sun.COM (Bob Snively)
*

I have been asked by the Fibre Channel working group to assemble
a proposal for new worldwide name formats.  This paper provides
a proposal for discussion before I prepare the final proposal.
Note that some details depend on whether or not IEEE chooses
to provide worldwide names for peripheral use as well as network
use.

To:		SCSI reflector  (scsi at symbios.com)
		Fibre Channel reflector (fc at network.com)

From:		Bob Snively

Date:		August 11, 1996

Subject:	Proposal for new NAA_ID

Several authorities have been identified as
registers for unique Worldwide names.  The authorities
are identified by the NAA_ID field.  The format for each
worldwide name has previously been defined.
At present, X3T11 and X3T10 are working with IEEE to determine
if the IEEE registration authority will be able to provide
extended support using registration numbers provided by IEEE.

In addition, some companies have suggested the possibility of
extending the world wide name concept to removable recordable
media, including tape cartridges, removable magnetic media, and
removable optical media.  These name spaces would be much
larger than peripheral device or network node spaces and may
be sparse spaces, possibly using time stamping or other means
to create the unique identifiers.

For these reasons, two new formats are proposed.  The first format,
peripheral node/port name, provides a powerful and flexible
name space that is convenient for peripheral ports to use and
is expected to be used exhaustively.  The second format, extended
name space, provides a 64-bit extension to the peripheral
node/port name.  The extension may be used as
a sparce addressing field.

It is suggested that these names use a registered field of 28
bits if a new naming authority is established.  If the IEEE naming
authority can be used, a 24-bit registration field would be used
instead for compatibility reasons.

NAA 5	Peripheral node/port name

	Format:

        _______________________________________________________
       |  NAA  |  Registered Field  |   Vendor Specific Field  |
       | 4 bits|       28 bits      |           32 bits        |
       |_______|____________________|__________________________|


This format is defined to provide a set of contiguous identifiers
under vendor specific management for each of 2**28-1 address spaces.
The registered field is assigned to the vendor by the 
registration authority.  The vendor specific field is
intended to be used exhaustively by the vendor.  The
registration authority should establish a policy such that new registered
field values will not be made available to a vendor until the
vendor specific field is essentially exhausted.  The vendor
specific field may be subdivided and assigned to ports and nodes
in a vendor specific manner.  Sparse assignments of the values
in this field are allowed up to 25% of the address space.  This
would allow dual port devices to use a 2-bit field identifying the
two ports and a single peripheral node.  While a policy recommending
that companies be allowed to register consecutive registered field
values was discussed by the working group, this seems incompatible
with the policy that requires one registered address space to be
exhausted before the next is made available.


NAA 6	Extended peripheral name

	Format:
        _______________________________________________________
       |  NAA  |  Registered Field  |   Vendor Specific Field  |
       | 4 bits|       28 bits      |           32 bits        |
       |_______|____________________|__________________________|
       |              Vendor Specific Field Extension          |
       |                     64 bits                           |
       |_______________________________________________________|	


This format is defined to provide a set of contiguous identifiers
under vendor specific management for each of 2**28-1 address spaces.
The registered field is assigned to the vendor by the 
registration authority.  Consecutive registered field values
may be requested by a vendor.  The vendor specific field is
intended to be used exhaustively by the vendor.  New registered
field values will not be made available to a vendor until the
vendor specific field is essentially exhausted.  The vendor
specific field may be subdivided and assigned to ports and nodes
in a vendor specific manner.  Sparse assignments of the values
in this field are not allowed.  The vendor specific field 
extension may be subdivided and assigned by the vendor as desired.
Sparse assignments of this space are allowed, making the 
format desirable for removable media, recording media 
cartridges, and for other sparsely populated name spaces.
The location of the vendor specific field extension is vendor
specific and is not defined by any Fibre Channel documents.  It is
expected that the SCSI identifier field will be 128 bits for this
world wide name format.


*
* 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