SCSI device names

James Smart james.smart at trebia.com
Wed Oct 23 08:31:31 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* James Smart <james.smart at trebia.com>
*

--------------040105030703080602000008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Rob, 

How does the statement "one name per transport protocol" fly relative to
gateways providing different names for the same target ?   and is the
requirement - "one and only one" ?  E.g  there's two iSCSI to FCP
bridges which are non-cooperative, and an FCP target. The iGATE document
mandates, for this scenario, that each of the non-cooperating bridges
must have an independent and unique name.

-- James

Elliott, Robert (Server Storage) wrote:


The current rule in SAM-3 is that a device may have one device name per
transport protocol.  This means, for example, that a target device with
both SAS and iSCSI target ports has two device names - the iSCSI name
and the SAS device name.

Assuming 02-254 (WWNs for W-LUNs) passes, these would be returned as two
device identifiers in VPD data:
1. SAS device name
association=target device (2h)
protocol identifier=SAS (6h)
identifier type=NAA (3h)  
identifier=IEEE Registered format (NAA=5h), 8 bytes long

2. iSCSI device name
association=target device (2h)
protocol identifier=iSCSI (5h)
identifier type=iSCSI name-based (7h)    (to be proposed in 02-419)
identifier=UTF-8 format string, up to 224 bytes long

It would be simpler if there were only one device name for a device.

Since only iSCSI has defined device names to date (SAS is just planning
to include a device name now, and FCP-3 might define one too), we have
an opportunity to make all device names follow the iSCSI name-based
format and let each device have a single device name regardless of
protocol.  

The iSCSI name format is a UTF-8 (similar to ASCII) string that starts
with a naming authority:
"iqn."  for an iSCSI-defined reverse domain name string (e.g.
"iqn.2001-04.com.acme:storage.disk2.sys1.xyz")
"eui."  for a hexadecimal representation of an EUI-64 identifier (e.g.
"eui.02004567A425678D")

iSCSI could easily add an "naa." type to carry a hexadecimal
representation of an NAA identifier (e.g. "naa.52004567A425678D"),
needed to carry the format used by SAS and Fibre Channel port names.

Then, a target device with target ports of different protocols could use
any string format it likes as its sole device name. 

Likely choices:
iSCSI-only device: "iqn." (it may have no hardware names available)
SAS-only device: "naa."
FC-only device: "naa."
SRP-only device: "eui."
SBP-2-only device: "eui."
iSCSI/SAS combination device: "naa." since it is already using NAA
identifiers available for port names
SRP/iSCSI/SAS combination device: "naa." or "eui." since it already has
NAA and EUI-64s for port names

This would divorce the device name concept from the transport protocols.
Transport protocols could still require their devices have a device
name, but wouldn't comment on the format.

--
Rob Elliott, elliott at hp.com  
Industry Standard Server Storage Advanced Technology
Hewlett-Packard




--------------040105030703080602000008
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


Rob, 

How does the statement "one name per transport protocol" fly relative to gateways providing different names for the same target ?   and is the requirement - "one and only one" ?  E.g  there's two iSCSI to FCP bridges which are non-cooperative, and an FCP target. The iGATE document mandates, for this scenario, that each of the non-cooperating bridges must have an independent and unique name.
 
-- James
 
Elliott, Robert (Server Storage) wrote:
 SCSI device names The current rule in SAM-3 is that a device may have one device name per transport protocol.  This means, for example, that a target device with both SAS and iSCSI target ports has two device names - the iSCSI name and the SAS device name. Assuming 02-254 (WWNs for W-LUNs) passes, these would be returned as two device identifiers in VPD data:
 1. SAS device name
 association=target device (2h)
 protocol identifier=SAS (6h)
 identifier type=NAA (3h)  
identifier=IEEE Registered format (NAA=5h), 8 bytes long 2. iSCSI device name
 association=target device (2h)
 protocol identifier=iSCSI (5h)
 identifier type=iSCSI name-based (7h)    (to be proposed in 02-419)
 identifier=UTF-8 format string, up to 224 bytes long It would be simpler if there were only one device name for a device. Since only iSCSI has defined device names to date (SAS is just planning to include a device name now, and FCP-3 might define one too), we have an opportunity to make all device names follow the iSCSI name-based format and let each device have a single device name regardless of protocol.  The iSCSI name format is a UTF-8 (similar to ASCII) string that starts with a naming authority:
 "iqn."  for an iSCSI-defined reverse domain name string (e.g. "iqn.2001-04.com.acme:storage.disk2.sys1.xyz")
 "eui."  for a hexadecimal representation of an EUI-64 identifier (e.g. "eui.02004567A425678D") iSCSI could easily add an "naa." type to carry a hexadecimal representation of an NAA identifier (e.g. "naa.52004567A425678D"), needed to carry the format used by SAS and Fibre Channel port names. Then, a target device with target ports of different protocols could use any string format it likes as its sole device name. Likely choices:
 iSCSI-only device: "iqn." (it may have no hardware names available)
 SAS-only device: "naa."
 FC-only device: "naa."
 SRP-only device: "eui."
 SBP-2-only device: "eui."
 iSCSI/SAS combination device: "naa." since it is already using NAA identifiers available for port names
 SRP/iSCSI/SAS combination device: "naa." or "eui." since it already has NAA and EUI-64s for port names This would divorce the device name concept from the transport protocols. Transport protocols could still require their devices have a device name, but wouldn't comment on the format. --
 Rob Elliott, elliott at hp.com
 Industry Standard Server Storage Advanced Technology
 Hewlett-Packard 



--------------040105030703080602000008--




More information about the T10 mailing list