Some thoughts on SCSI names, addresses, identifiers

Elliott, Robert Robert.Elliott at
Mon Feb 19 14:59:00 PST 2001

* From the T10 Reflector (t10 at, posted by:
* "Elliott, Robert" <Robert.Elliott at>
[with sections removed that didn't draw comments]

> -----Original Message-----
> From: Jim Hafner [mailto:hafner at]
> Sent: Wednesday, February 14, 2001 5:42 PM
> Subject: Some thoughts on SCSI names, addresses, identifiers

> SCSI Ports are required to have at least one address type identifier
> (or else how can anybody talk to it!).  They may have more than one
> such address identifier (e.g., IPaddress:IPPort combinations for the
> same physical port).  SCSI Ports may have zero or more name type
> identifiers.  E.g., a DNS name in the iSCSI protocol is a Port
> Identifier of the "name" type, but the IP Address or addresses (as
> resolved by DNS) are the "address" type identifiers of that port.
> It's an open question whether the iSCSI WWUI (Initiator or Target) can
> be equated with the Device Identifier or with a Port Identifier (type
> name) -- see 5.2.2.
> A SCSI Port Identifier may be both a name and an address type.  E.g.,
> in SPI, the SCSI address can be viewed as both a name and an address.
> [It might be the case that an IPv6 address serves the dual purposes in
> SRP, or at least in Infiniband, but I'm not knowledgeable enough to
> make this claim.]

>From what I understand, IPv6 addresses are considered volatile, 
with part of the address subject to change by routers even
while a session is open.  This is unlike IPv4 where an address
is static while it is in use.

In InfiniBand, the IPv6 address (called a GID) includes a "subnet 
prefix" that identifies the subnet where the port is connected.  
This parallels the IPv6 router-assigned portion of the
address.  To me, this makes the GID unsuitable as a "name."
A better port name is the port GUID, an EUI-64 value that 
doesn't change based on the subnet on which the port 
is connected.

> 2.1 Name to Address Resolution
> Transport protocols may or may not define procedures for resolving a
> SCSI Device Identifier into one or more SCSI Port Identifiers.
> Management systems may also provide this sort of device name->port
> address resolution in implementation-specific ways.  Similarly,
> transport protocols may (should, shall?) define procedures for
> resolving SCSI Port Identifiers of the name type into those of the
> address type.
> SCSI Port Identifiers of the address type need not be static but may
> change on each reconfiguration of parts of the SCSI domain (e.g., FC
> LIPs or changes in the FC Name service; or changes in IPName to
> IPaddress because of DHCP).  SCSI Port Identifiers of the name type
> should be more persistent than the corresponding addresses.
> With this in place, a third-party reference to a device may use the
> device identifier or it may use any port identifier by name or
> address.

Using a port address alone may be too volatile.  It may be 
prudent to accompany a port address with a port name or 
device identifier (the FC extended copy descriptors include
this kind of pairing).

> 3.0 Reservations and other things
> 3.1 Reservations
> With this model it is possible to associate a reservation with any one
> of three things:
> a) the I_T_L nexus itself: this means that if a second I_T_L nexus
>    exists, e.g., as established by a second login, then only 
>    one of these nexi can hold a reservation
> b) the I of the I_T_L nexus, where the 'I' in the nexus means the
>    Initiator Port:  assigning the reservation to the 'I' 
>    means that any I_T_L nexus with the same 'I' implicitly has 
>    the same reservation properties
> c) the Initiator Device: in this case, the reservation is held
>    commonly across all Initiator Ports and all I_T_L nexi (nexuses?).
> d) the Initiator Device+Initiator Port: this is essentially the same
>    as (b) unless there are more than one Initiator Device sharing the
>    same Initiator Port (see the Sharing section below).
> [We should ask the same question about what happens on the 'T' side of
> the nexus.  How does the Target side break down?  Must it be the 'T'
> (as in Port), or can it cross through the Target Device?]
> I believe that historically we've assumed more or less case (b).
> However, the distinction between (a) and (b) is blurred in SPI and FCP
> because there has been a tacit assumption that there couldn't be two
> (or more) different distinguishable I_T nexi with the same 'I' and 'T'
> (however one defines the 'I' and 'T').  For SPI, we've equated 'I' and
> 'T' with ports on the bus.  At any given instant, there can't be more
> than one I_T nexus (relationship). For FCP, there has generally only
> been one process login between an initiator FC port and a target FC
> port (and this has defined the nexus).  On the other hand, FCP
> requires that persistent reservations follow a portname through port
> address changes so this more implies (b) than (a).  [However this
> conclusion is colored a little by the view from the 'T' side.]

I think it's a mix of a) and b) today.  

The logical unit must remember initiator identity based on
the target port through which the reservation was made as well
as with the initiator port that made the reservation.  If you
want to reserve a logical unit in a multiported target, you 
must send a PERSISTENT RESERVE OUT to every target port 
|from every initiator port.

Additionally, the logical unit must track any initiator port
changes through logout/login by remembering the initiator port
worldwide name (in protocols that have such, like Fibre Channel).  
This lets the address be reassigned as needed by the fabric.
Using your name/address terminology, this could be phrased as
using the initiator port name.

I'd like to see the model evolve for SRP and iSCSI to support:
* don't care about the target port
* don't care about the initiator port name or address; use
  the initiator device identifier instead

> 3.3 Third-party operations
> This model enables identification/specification of third party devices
> via a number of different 'identification' schemes.  For example, in
> an EXTENDED COPY target descriptor, the target device can be
> referenced by SCSI Device Identifier, or any of its SCSI Port
> Identifiers or a combination of both.  The recipient of such a
> descriptor may need to do some name->address resolution, depending on
> the type of identifier provided.
> For example, such a descriptor might specify the N_PortID of an FC
> port (that is, SCSI Port Identifier of the address type).  Or it might
> specify an FC WWN (that is, a SCSI Port Identifier of the name type),
> but this might require address resolution.  In FCP, a descriptor could
> in the future specify a Platform WWN; in iSCSI, a descriptor could
> specify a SCSI Device Identifier with or without some additional Port
> Identifier (e.g., dns name).
> 4.0 Can Devices Share Ports?
> It is possible in this naming/address/identifier scheme for a single
> SCSI Port to be a component of different SCSI Devices.  New protocols
> (like SRP and iSCSI) with a login phase where these identifiers can be
> shipped around, can enable a box (host or storage) to have a set of
> physical ports, but also have a set of virtual SCSI devices
> (distinguished by their SCSI Device Identifiers) sharing those some
> physical ports.
> This, of course, has implications with respect to the questions above
> about reservations?  If the reservation belongs to the Initiator Port,
> then multiple initiator devices sharing that port all get the
> reservation rights.  With this observation, I believe that option (b)
> above can't work as outlined above.

New protocols can mandate using device identifiers for reservations
and access control TransportIDs rather than port names or addresses. 

> 5.1.1 SPI
> Here, we're pretty much in the position (without names for devices and
> ways to pass them through 'login' type protocol) that initiators must
> be 'single-ported' and that the Initiator Device Identifier can be
> equated to the Initiator Port Identifier and that equals the SCSI bus
> address (as both a name and an address).  I don't think this
> perspective limits anything.

Any SCSI domain containing a parallel SCSI bus is limited to 16
total initiator ports and/or target ports so there's not much hope
of mapping a large SAN into it.  I agree:

initiator device identifier = initiator port name = initiator port address
target device identifier = target port name = target port address

> 5.1.2 FCP
> There are many ways to go here.  We already have WWPortNames and
> addresses (N_PortIds) for ports.  Enclosing those two within the scope
> of the SCSI Port Identifier is pretty much what we've been doing.
> WWNodeNames, I think, were supposed to play the role of SCSI Device
> Identifier but it didn't work out that way in practice.  Instead
> there's the move toward a WWPlatformName.  We might use this to map to
> the SCSI Device Identifier.  FC Nameserves give the mechanism by which
> 'names' (either PortName or PlatformName) get resolved to 'addresses'.

Apparently FC's node WWN is unreliable.  The new platform name
in FC-GS-3 seems like a good candidate for initiator device
identifier, and perhaps can be share the iSCSI WWUI namespace.  

However, do we want to change how reservations and access 
control TransportIDs are handled at this time?  We'd need
an INQUIRY bit indicating whether the logical unit supports
the old or new behavior, and software would have to query

Compatible with today's devices:
initiator port address = 24-bit FC address (dynamic)
initiator port name = Worldwide Name of port
initiator device identifier = initiator port name

Possible FC extension:
initiator port address = 24-bit FC address (dynamic)
initiator port name = Worldwide Name of port
initiator device identifier = initiator platform name

In both cases:
target port address = 24-bit FC address (dynamic).  Used in
  third-party references (but port name versions preferred).
target port name = Worldwide Name of port.  Used in third-party
target device identifier = target port name

> 5.2.1 SRP
> I'm not too knowledgeable about this protocol, but from what I gather
> we can use the LID, GID and GUID for ports as various forms of the
> SCSI Port Identifier.  We can define at any level a new SCSI Device
> Identifier (particularly at the initiator side) and this identifier
> can be exchanged in the SRP login.

In the SRP InfiniBand annex (01-028r2) we're proposing:
initiator port address = target's queue pair number (for open
initiator port name = initiator port GUID
initiator device identifier = iSCSI WWUI.  Used for reservation
  tracking through logout/login and access controls TransportID.

target port address = initiator's queue pair number for open
  channels, and target's LID/GID for third-party references.
target port name = target port GUID.  Not used.
target device identifier = iSCSI WWUI.  Used for third-party
  references (for Extended Copy and XOR).

> 5.2.2 iSCSI
> The SCSI Port Identifier of the address type may map nicely to the
> IPAddress:IPPort used for TCP socket connections.  Similarly, the Port
> Identifier of the name type maps nicely to the IPName:IPPort.  The
> iSCSI WWUI (Target or Initiator) could map to the SCSI Device
> Identifier, though layering principles may suggest otherwise.  Note
> that, for iSCSI, the SCSI Port is actually the endpoint of an iSCSI
> session and that this may span multiple NICs, with multiple IPNames or
> addresses and/or IPPorts.  Consequently, an SCSI Port in this context
> may have many different SCSI Port Identifiers of either the name or
> address type.
> Another interpretation is that the iSCSI WWUI identifies a SCSI Port
> identifier (name) and there is as yet no object that maps to the SCSI
> Device or Device Identifier.
> Also, iSCSI opens the door very readily to multiple SCSI Target
> Devices (e.g.) sharing the same set of network hookups.  This means
> effectively that the same SCSI Port can be shared by multiple SCSI
> Devices.  The use of a SCSI Device Identifier in login can distinguish
> the different Devices sharing a Port.

I'd say:
initiator port address = set of IPAddress:IPPort
initiator port name = set of IPName::IPPort
initiator device identifier = iSCSI WWUI.  Used for reservation
  tracking through logout/login and access controls TransportID.

target port address = set of IPAddress:IPPort
target port name = set of IPName::IPPort.  Used for third-party
  references (always with target device identifier checking).
target device identifier = iSCSI WWUI.  Used for third-party
  references (for Extended Copy and XOR).

The iSCSI WWUI definition could be brought into SAM-2 so all 
new protocols could use it, making for easier gateways/bridges
between protocols.

Rob Elliott, Compaq Server Storage
Robert.Elliott at

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list