Re: [Ips] iSCSI-specific unit attention conditions

["Bill Galloway" <[e-mail]>]

This is a re-send from a different email.... 

I am the guilty party associated with these sense codes.  I have been
traveling for the last few days or I would have chimed in sooner.  My
original proposal was not iSCSI specific.  It added three ASC/ASCQs which
were DEVICE PORT ADDRESS ADDED/CHANGED/REMOVED. The original names actually
explain the intent better (IMHO).

We produce an iSCSI target with many "Portal Groups" and "Network Portals".
Portal Groups come and go dynamically. Within a Portal Group, Network
Portals come, go, or change dynamically.  The intent is for the initiator to
be connected to all Network Portals, on all Portal Groups, all of the time.
This is usually accomplished with some combination of MCS in the initiator
and a MPIO (multipath) layer above the initiator.  The initiator is
perfectly willing to make all of these connections but there is no way
specified in any standard to accomplish this task.  There is a mix of layers
here that makes for a messy solution.  I am certainly open to a better one.

The SCSI layer could care less about Network Portals coming, going, or
changing but something has to kick the initiator to do a new discovery and
make the appropriate connections.  This would have been better handled at
the iSCSI layer but I could find nothing available.  In our implementation
the MPIO layer traps these UAs and kicks the initiator.

The SCSI layer does have a legitimate need to know about Portal Groups
coming and going.  These map to SAM target ports and the SCSI layer may need
to know. The initiator also needs to know so that it can make the new
connections.  In our implementation the MPIO layer also traps these UAs and
kicks the initiator.

Why three codes? No good reason.  My first proposal was more generic than
iSCSI and there was a hope that it would be useful to other protocols.  To
get the proposal passed, I agreed to change the names to be iSCSI specific.
In retrospect when I made the name change, I could have dropped it to one
code.  In our current implementation we treat all codes the same.

I hope this explains the rational for these ASC/ASCQs.  I am not aware of
anything in the iSCSI spec that accomplishes these goals. I am certainly
willing to explain further and to work with STORM to document this better
and/or come up with a better solution.

Bill Galloway
Pivot3, Inc.
BillG[-at-]Pivot3.com