iSCSI: Async events and text

[Mark Bakke <mbakke@cisco.com>]

Kaladhar had asked this question a while ago; I don't think
a thread was started on it, though.

iSCSI has defined the text message mechanism to allow initiators
to send in-band commands outside of SCSI itself (e.g. SendTargets)
to targets.  This mechanism also allows experimental and vendor-
specific functions to be implemented without breaking the rest
of the protocol; if a text key is not recognized by one side or
the other, it is dropped.

The Asynchronous Message also defines a mechanism to allow
targets to send in-band, iSCSI-level messages to initiators;
these are indicated with the iSCSI Event code, and are used
to communicate the target's wishes that the initiator would
log out, or similar issues.

We have discussed on the list the ability to add other things
to async messages, such as the ability to communicate on a
discovery session that there are new iSCSI targets, and that
a new SendTargets command should be sent.  We never did decide
as a group to add such a feature, but I think there was some
talk about allowing something vendor-specific for this type
of thing.

Anyway, I was taking another look at async messages, and it
appears that for an iSCSI event, the data portion of the PDU
could be used for vendor-specific text keys and values, but
there is no way to tell the initiator to look at these.

If we want to do such a thing, we could handle it in three
ways:

1. Have the initiator and target use vendor-specific keys during
the login phase to pre-negotiate the use of a special iSCSI event,
and simply send whatever they want for the iSCSI event.  This would
ensure that an initiator will never receive unwanted events, but it
also means that vendors may define their own uses for the iSCSI
Event codes or other PDU header fields, which might conflict with
future additions to the standard protocol.

2. Add an iSCSI Event "5 - Text event"; this would be a standard
event, which would include text keys and values in the data portion
of the PDU.  This removes conflicts with future versions, and the
spec could still require that an initator and target negotiate
the use of these events, to avoid an unsuspecting initiator from
receiving them.

3. Change all of the iSCSI events to use text key/value pairs,
including the ones already defined.  This would change the way
the events are sent now, would add some overhead to the message,
and some additional processing of the text fields (vs. the binary
fields used now).  However, it would allow vendor-specific keys
in any async event message, and would be more in line with the
way the other iSCSI-level mechanisms (login and text) work.

I'm not particularly attached to any of the above methods, but
I would like to see a way that a vendor could add a new async
event.  Any thoughts?

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054