RE: iSCSI: DLB's Comment on SCSI Port Names

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and the currently specified port name encoding causes inconvenience (at best).  IMO, it makes sense to be able to treat an iSCSI name field, be it device name or port name, the same - as a string of display characters, portions of which may contain ASCII-encoded numeric values.

 

I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings or values, since as Jim says, there are no calculations performed using these things, and they are basicly just "tags".  The issue for me is that the rest of the "SCSI port name" is a string and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should have no need to use the ISID or TPGT values separately from the entire port name.  And even if SCSI had such a need, it's a simple matter to convert a numeric string representation to a value.

 

The downside of a string-encoding is the increased maximum size of the SCSI port name.

 

If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000")

 

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard

-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 9:08 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: DLB's Comment on SCSI Port Names

David,

I believe it will (may?) be used, so I agree we're in the second case.  However, this format is the intended use in SCSI protocol stuff.  Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however)

I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...).  

However, I think the issue comes down to a simple question:  are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here).

If they are values, then I'd like to see them formatted for SCSI in "value form";  if they are strings, then any representation should be OK.

Does that at least get to the core of the issue?

Jim Hafner

CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required.

To:        Jim Hafner/Almaden/IBM@IBMUS
cc:        ips@ece.cmu.edu
Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names



Jim,

My view of this is that either:
- The SCSI Port Name is never going to be used, in which case
it shouldn't be designed to this level of detail. OR
- It's going to be used, and hence is worth designing in a fashion
that is reasonable to use.
I think we're in the second category, and turning the ISID into
hex ASCII (well, UTF-8) so the SCSI port name is a string is
worth doing now to avoid problems when people actually try
to use it.  I would have no problems if someone wanted to
pad the string, but I'd make specifying the padding the
responsibility of the protocol/API/situation in which it
was used rather than incorporating the padding into the name.

Thanks,
--David

-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 11:42 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: DLB's Comment on SCSI Port Names



David,

You wrote:

>[T.9] 2.4.2  SCSI Architecture Model
>
>  The SCSI Port Name is mandatory in iSCSI. When used in SCSI
>  parameter data, the SCSI port name MUST be encoded as:
>  - The iSCSI Name in UTF-8 format, followed by
>  - a comma separator (1 byte), followed by
>  - the ASCII character 'i' (for SCSI Initiator Port) or the
>    ASCII character 't' (for SCSI Target Port), followed by
>  - a comma separator (1 byte), followed by
>  - zero to 3 null pad bytes so that the complete format is a
>    multiple of four bytes long, followed by
>  - the 6byte value of the ISID (for SCSI initiator port) or the
>    2byte value of the portal group tag (for SCSI target port) in
>    network byte order (BigEndian).

> That's a peculiar format with padding nulls in the middle and
> a number concatenated after the padding - for example, it can't
> be passed in iSCSI login without format conversion.  How about
> converting the number to 4 or 12 bytes of hex (ASCII characters)
> and moving the padding to the end so the result is actually a
> string, and excluding the padding from the definition of the name?
> This will increase the maximum length of port names, but produce
> names that are easier to deal with.

Admittedly that's an odd format, however here was the reason for this
layout.
1) it's not used directly in iSCSI "Text" strings; it's intended to be a
description of how this information is packed into a byte array for
representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER
"passed in iSCSI login" (in this form).
2) the padding after the string was to force the binary values of the ISID
or PGT to be better word aligned and can be more easily extracted as a value
direct from the byte array without conversion.

What do you think?

Jim Hafner