Subject: iSCSI - structured values

From: Keith McCloghrie <[email-masked]>
Date: Wed, 5 Dec 2001 09:22:55 -0800 (PST)

Hi,

The following ideas came up in a discussion I had about iSCSI.

The first issue is about the algorithm to use for allocating the
structured ISID values, which contain three fields:

 - The Type field identifies the format:
           00h     - IEEE OUI
           01h     - IANA Enterprise Number (EN)
           02h     - "Random"
           03h-FFh - Reserved
 - The Naming Authority field identifies the vendor or organization
 - The Qualifier field is a 16 bit value that provides a range of
   possible values for the ISID within the Type and Naming Authority
   namespace.

The "notes" in draft-ietf-ips-iscsi-name-disc-03.txt specify:

     (a) As noted, the structure of the ISID namespace provides each
     vendor with its own piece of the ISID namespace.  In effect, this
     provides for a vendor-partitioning of that namespace within each
     initiator.

So, this puts the onus on a "vendor" to come up with the vendor's own
scheme for allocating ISID values.  For the situation where a vendor
wants to assign different values to different interfaces/HBAs, the
simplest scheme would be to use a unique value which is shipped with
each product, such as a MAC address.  This would be simple because it
would obviate any need to coordinate between different interfaces
(even those from the same vendor).  In fact, the first three bytes of
a 6-byte MAC address are an IEEE OUI, which is exactly what type=0
specifies, except that the MAC address has 3 more bytes, and the
Qualifier field is only 2 bytes.  So, in order to allow vendors to
adopt such a simple scheme, I'd like to propose that the Qualifier
field be enlarged to at least 3 bytes.  It probably doesn't make much
sense to make the overall ISID to be 7 bytes long.  So, how about
making the Qualifier be 4 bytes so that the ISID is 8 bytes long ?  
As far as I'm aware the performance impact of this is virtually
negligible, and so I can't really see any disadvantage in doing so.

The second issue concerns Portal Group Tags.  It seems that despite 
the difference in terminology, that an ISID and a Portal Group Tag
are corresponding concepts.  For example, a SCSI Port Name is defined
as "the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag".  However,
a Portal Group Tag is defined as a 16-bit integer.  Now, I understand
that an ISID was originally defined as a 16-bit integer, before its
format was expanded (as discussed above).  So, with the correspondence
of ISID and Portal Group Tag, surely it makes sense for a Portal Group
Tag to have the same format as an ISID.  This will allow vendors of
iSCSI targets with multiple interfaces/HBAs to use a simple scheme as
and when they need to assign different Portal Group Tag values to the
different interfaces/HBAs.  So, whether or not the ISID format is
changed based on the first issue above, I propose that the same
structured format be used for both ISIDs and Portal Group Tags.

Keith.

---

From: Mark Bakke <[email-masked]>
Date: Fri, 07 Dec 2001 14:37:07 -0600

I agree with Keith on this; the new ISID format went a long
way to solve the problem of a single initiator name being
"represented" by multiple interface cards; I think that the
same thing needs to be extended to target portal groups.
Expanding the available identifier space in the ISID (and
target portal group) to at least 3 bytes allows the convenience
of a MAC address to be used for these identifiers.

This also allows multiple gateways to represent the same
initiator or target, without having to create different iSCSI
names for each representation of the same initiator or
target.  I think that solving this problem (which we almost
have already) would help these solutions scale much better.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054