Some thoughts on SCSI names, addresses, identifiers

Jim Hafner hafner at almaden.ibm.com
Wed Feb 14 15:42:12 PST 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* "Jim Hafner" <hafner at almaden.ibm.com>
*
Folks,

This is a strawman proposal for changes to SAM-2 with regards to
names, addresses, identifiers, etc.  It fundamentally belongs in the
Multi-port model discussions (00-268) but also relates to the Long
Identifiers proposal (00-425) and possibly a number of other
proposals and has implications for SRP and iSCSI.  Because of it's
reach and because this is just "thoughts", this is just a strawman.

Here's an outline (this got longer than I expected):

1.0 Background
2.0 Strawman Proposal
  2.1 Name to Address Resolution
3.0 Reservations and other things
4.0 Can Devices Share Ports?
5.0 Protocols
  5.1 Legacy protocols
    5.1.1 SPI
    5.1.2 FCP
  5.2 New protocols
    5.2.1 SRP
    5.2.2 iSCSI
6.0 Concluding remarks

1.0 Background

The current thinking in the multi-port model defines a SCSI Device
entity.  This Device contains one or more SCSI Ports (with Initiator
Devices containing Initiator Ports and Target Devices containing
Target Ports).

SAM-2 defines the term "SCSI device identifier" and this has
traditionally been applied to mean the/an address of the SCSI Port
(though this is loosely enforced in FCP).  The work on multi-port
seems to be going toward making this explicit by changing the name to
"SCSI port identifier" (I think).

2.0 Strawman Proposal

Consistent with where the multi-port model is evolving, I'm proposing
the following two definitions:

1) "SCSI device identifier" should refer to a NAME for a SCSI Device.
   This is NOT an address, just a name.  (The current glossary
   definition for this term should realistically be the definition of
   the term "SCSI port identifier".)

2) "SCSI port identifier" should refer to either a NAME or an ADDRESS
   for a SCSI Port.  This extends the current definition to apply to
   not just addresses.

For example, a SCSI Port Identifier may be the FC N_Port_ID (D_ID or
S_ID in an exchange) or it may be the FC WWPortName.  The former is an
address, the latter is a name.

SCSI Devices are NOT required to have an identifier (name).  However,
such device identifiers might reasonably be required to be WWUnique.
SCSI Devices don't have addresses (only Ports have addresses).  A
device that has a name can more easily be proxied across gateways with
newer protocols (e.g., iSCSI and SRP) that can carry this name
information within the protocol (e.g., in login).

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.]

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.

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 personally have no strong preference for selecting any choice of
model, though as noted in the Sharing section, there are issues with
case (b).  I'm merely pointing out that where we're going with both
the Multi-port model AND with new protocols that have a 'login' phase
(and possibly multiple independent such logins through the same set of
hardware), we are enriching SAM in ways that require careful choices
about these things.

NOTE: Another point to make is that new protocols with globally unique
identifiers for devices and for ports are effectively turning the SCSI
world into one gigantic global SCSI Domain coupled with all the local
SPI SCSI domains.  In effect, once an entity has a GUID, it can
(perhaps) be identified across physical/topological barriers that
separate physical/topological SCSI domains.

3.2 Access Controls

A similar association choice can be made for other properties of
initiator/target/lun relationships, e.g., Access Controls.  The
current access controls model has TransportIDs map to Initiator Ports
and AccessIDs map to a layer higher up than Initiator Device.

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.

5.0 Protocols

5.1 Legacy protocols

Here's how I see these concepts mapping to legacy protocols:

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.

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'.

5.2 New protocols

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.

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.

6.0 Concluding Remarks

These are all very preliminary thoughts about a host of interrelated
issues.  I hope that these notes provide food for thought as we try to
simultaneously evolve SAM to accomodate the practical considerations
of the newer protocols (and not break the existing protocols) and
evolve the newer protocols to a well-defined SAM.

Jim Hafner

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




More information about the T10 mailing list