RE: iSCSI: INQUIRY page 0x83 identifier

[Michael Krause <krause@cup.hp.com>]

At 08:31 PM 1/26/2001 -0800, Patrick Stirling wrote:

>On Fri, 26 Jan 2001, Michael Krause wrote:
>
> > At 01:30 PM 1/26/2001 -0800, Robert Snively wrote:
> >
> > >However, I feel that iSCSI should be a lot more hard nosed than
> > >SAM-2 and require that VPD page "83" contain a mandatory world-wide
> > >unique logical unit identifier in an appropriate invariant format.
> > >For compatibility with other SCSI drivers, it should be limited
> > >to 128 bits of length.  This would not be an identifier set by
> > >the user (there are other SCSI identifiers that can be set by the
> > >user), but one that is invariant from the time of manufacture (for
> > >physical devices) or creation (for logical devices) of the logical unit.
> >
> > Why not just require EUI-64 which is a very large name space and is / will
> > be used in many hardware solutions today / future?  This would also fit in
> > well with other I/O standards that use EUI-64 for identifying all I/O
> > components / controllers.  Having a 128-bit value seems like overkill and
> > provides little benefit.
>
>Well, I'd prefer to stick with the current scheme of allowing the device
>to specify its identifier within certain limits (table 181 in spc2r18).
>
>I'm working on a virtual storage server, which serves up virtual disks on
>the fibre-channel SAN (with iSCSI coming soon I expect). We set just this
>identifier in VPD page 0x83, using a type 3 identifier (FC-PH) - actually
>a Registered Extended IEEE Name, 128bits. It's convenient to use this
>length as it allows me to set the upper 64bits to our server's WWN (which
>is also used as the World-Wide Node Name shared by all target HBAs on the
>server), and the lower 64bits to a simple number identifying the virtual
>disk on this server.

Sounds like an IPv6 address.  InfiniBand uses the same technique where an 
EUI64 is combined with an IPv6 subnet prefix.  This provides the 
flexibility you desire with a manufacturer unique GUID.  It also makes 
attachment to the Internet much simpler as well as leverages existing / new 
IPv6-based tools / services.  BTW, wireless seems to be moving towards IPv6 
as well so why not just use the same paradigm for everything: server I/O 
interconnect, wireless, storage, etc.

Mike