unique worldwide tape names

Bob Baird bbaird at hpmfas3.cup.hp.com
Mon Aug 12 08:37:28 PDT 1996


* From the SCSI Reflector, posted by:
* Bob Baird <bbaird at hpmfas3.cup.hp.com>
*
IEEE Mass Storage Committee,

This is response to Jack Cole's message to ieee+mss at lard.nasa.gov.

The last time I looked, we already had a worldwide name format; it is the IP
address. Assume that every device were attached to a storage hub and each
hub had an IP address, the addition of a device (port) number to the IP
address would allow anyone to address any device given the proper authority.
A storage hub could be a host (like today) or a control unit (similar to
today but containing an IP layer). Hosts could still address devices within
their own physical domain by an abbreviated address like device number.

Using IP as the basis for storage device addressing allows the storage world
to leverage existing and new network technology for bridging, routing, etc.
that will be needed anyway for "worldwide" storage.

I just don't see why we need another "world-wide" addressing model besides
IP (or an extension to IP). We will have to re-invent everything that has
already been invented for networking if storage addresses truly go
worldwide. I don't think people have seriously put in enough effort to
leverage or extend IP for storage devices. Until we do that, we should
refrain from inventing new "worldwide" addressing models unless there is
COMPELLING added value.

Bob Baird
Hewlett-Packard Company
====================================================================
>Date: Sun, 11 Aug 1996 14:51:36 -0700
>From: Bob Snively <Bob.Snively at eng.sun.com>
>To: scsi at symbios.com, fc at network.com
>Subject: Proposal for new NAA_ID for unique worldwide names
>
>
>* 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.
>
>----- End of forwarded messages
>
>
Bob Baird
Hewlett-Packard Company
General Systems Divison, GSSL
19111 Pruneridge Avenue, MS 44UB
Cupertino, CA 95014
voice:	408-447-7084
fax:	408-447-1345





More information about the T10 mailing list