SCSI device names

Elliott, Robert (Server Storage) Elliott at hp.com
Wed Oct 23 09:55:45 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C27AB5.07BB8168
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is one place the SCSI model breaks down, because gateways are not
visible.  From the perspective of devices in the iSCSI domain, there
appear to be two different iSCSI devices, each with its own name.  They
both contain the same logical unit (which raises the ire of many in =
T10,
who feel that logical units are only allowed to be in one device).
=20
The logical unit thinks it is in in a Fibre Channel device, so will do
all its reporting based on that.  For example, it returns a FC target
port name for VPD association=3D1h.  Each gateways needs to intercept =
the
VPD data and change it so it looks like the logical unit is in the
appropriate iSCSI device (e.g. change the association=3D1 identifier to
match the iSCSI port name being used).  The same would have to happen
for VPD association=3D2h identifiers.
=20
One goal of the MSC (management server commands) project is to expose
gateways to software, so they can let the logical unit's data flow
through unchanged.  Software would not be surprised at seeing a FC
target port identifier and FC target device name when it's using an
iSCSI target port address, since it would know there is a =
bridge/gateway
there and be able to retrieve its mapping table for iSCSI/FC target =
port
address mapping. =20
=20
--=20
Rob Elliott, elliott at hp.com=20
Industry Standard Server Storage Advanced Technology=20
Hewlett-Packard=20

-----Original Message-----
From: James Smart [mailto:james.smart at trebia.com]=20
Sent: Wednesday, October 23, 2002 10:32 AM
To: Elliott, Robert (Server Storage)
Cc: t10 at t10.org
Subject: Re: SCSI device names


Rob,=20

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=3Dtarget device (2h)
protocol identifier=3DSAS (6h)
identifier type=3DNAA (3h) =20
identifier=3DIEEE Registered format (NAA=3D5h), 8 bytes long

2. iSCSI device name
association=3Dtarget device (2h)
protocol identifier=3DiSCSI (5h)
identifier type=3DiSCSI name-based (7h)    (to be proposed in 02-419)
identifier=3DUTF-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. =20

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.=20

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 =20
Industry Standard Server Storage Advanced Technology
Hewlett-Packard




------_=_NextPart_001_01C27AB5.07BB8168
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

Message This=20 is one place the SCSI model breaks down, because gateways are not = visible. =20 From the perspective of devices in the iSCSI domain, there = appear to be=20 two different iSCSI devices, each with its own name.  They both = contain the=20 same logical unit (which raises the ire of many in T10, who feel that = logical=20 units are only allowed to be in one device).
  
 The=20 logical unit thinks it is in in a Fibre Channel device, so will do all = its=20 reporting based on that.  For example, it returns a FC target port = name for=20 VPD association=3D1h.  Each gateways needs to=20 intercept the VPD data and change it so it looks like the logical unit = is in the=20 appropriate iSCSI device (e.g. change the association=3D1 identifier to = match the=20 iSCSI port name being used).  The same would have to happen for = VPD=20 association=3D2h identifiers.
  
 One=20 goal of the MSC (management server commands) project is to = expose=20 gateways to software, so they can let the logical unit's data flow = through=20 unchanged.  Software would not be surprised at seeing a FC target = port=20 identifier and FC target device name when it's using an iSCSI target = port=20 address, since it would know there is a bridge/gateway there and be = able to=20 retrieve its mapping table for iSCSI/FC target port address = mapping. =20 
 
 -- = 
Rob Elliott, = elliott at hp.com=20 
Industry Standard = Server Storage=20 Advanced Technology 
Hewlett-Packard 

-----Original Message-----
From: = James Smart=20 [mailto:james.smart at trebia.com] 
Sent: Wednesday, October = 23, 2002=20 10:32 AM
To: Elliott, Robert (Server Storage)
Cc: = t10 at t10.org
Subject: Re: SCSI device = names


Rob,=20 

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

-- James

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



------_=_NextPart_001_01C27AB5.07BB8168--




More information about the T10 mailing list