|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iSCSI: DLB's Comment on SCSI Port Names
Marjorie,
I'll list this as issue 37 and I think we can
settle on 249 :-)
I would appreciate if you let me know what
constants change (in 2.4.2?)
Julo
----- Original Message -----
Sent: Tuesday, July 09, 2002 4:04
AM
Subject: RE: iSCSI: DLB's Comment on SCSI
Port Names
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
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
|
Home
Last updated: Tue Jul 09 10:19:00 2002
11204 messages in chronological order
|