Subject: [Ips] iSNS State Change Notification (SCN)

From: Steve Byan <[email-masked]>
Date: Tue, 6 Sep 2005 12:30:06 -0400

I'm trying to discern the intention of the iSNS draft with respect to 
when iSCSI targets should send state change notifications and with 
respect to the meaning of the bits in the iSCSI Node SCN Bitmap.

I'm not a Fibre Channel expert, but it's my understanding that it's 
customary for Fibre Channel storage arrays to send a registered state 
change notification when the logical unit inventory changes.

If an iSCSI target changes its logical unit inventory, is it the 
intention of the iSNS draft that the target could send an SCN message? 
What bit should the target set in the SCN bitmap - the "TARGET AND SELF 
INFORMATION ONLY" bit?

I find the description of the TARGET AND SELF INFORMATION ONLY and 
INITIATOR AND SELF INFORMATION ONLY bits somewhat hard to follow.  
Draft 22 says:

>    TARGET AND SELF INFORMATION ONLY SCNs (bit 25) provides information
>    only about changes to target devices, or if the iSCSI Storage Node
>    itself has undergone a change.  Similarly, INITIATOR AND SELF
>    INFORMATION ONLY SCNs (bit 24) provides information only about
>    changes to initiator Nodes, or the target itself.

Should "iSCSI Storage Node itself" in the first sentence be read as 
"initiator Node itself"? Just what circumstances should an iSNS server 
consider to have changed the "initiator Node itself"? Similarly, what 
circumstances should an iSNS server consider to have changed "the 
target itself"?

In summary,
1) does iSNS provide a mechanism for targets to notify initiators of 
the need to perform logical unit discovery, and
2) if so, what is that mechanism?

If iSNS SCNs are not intended for this use, then the initiator will 
have to rely on receiving a REPORTED LUNS DATA HAS CHANGED unit 
attention condition. Note that unit attention conditions are lossy and 
rely on the initiator polling the target in order to provide prompt 
notification of a condition.

Regards,
-Steve
--------
Steve Byan <[email-masked]>
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: David Weibel <[email-masked]>
Date: Tue, 06 Sep 2005 11:41:58 -0600

It sounds like your focusing on a logical unit change for a
discovered target.  In this case it seems like a iSCSI ASYNC
PDU with sense data would be the correct solution to notifying
the initiator.

Steve Byan wrote:

> What bit should the target set in the SCN bitmap - the "TARGET AND 
> SELF INFORMATION ONLY" bit?
>

---

From: Joe Souza <[email-masked]>
Date: Tue, 6 Sep 2005 12:58:06 -0700 (PDT)

First, the target should not send SCN but rather the
iSNS server.  Of course it is possible that the iSNS
server may be contained in the same physical device as
an iSCSI target.  Second, if you really want your
target to be able to send SCN, there is an iSNS
function for that (SCNEvent), but beware that some
iSNS servers (i.e. Microsoft's) may not support this
function as it could potentially be used to bring down
an IP storage network by causing the iSNS server to
generate a flood of SCN requests, each in turn
potentially causing the registered iSNS clients in the
affected Discovery Domain(s) to subsequently issue
queries to rediscover registered IP storage nodes.

In more specific answer to your question, perhaps it
might be easier to understand the meaning of the SCN
registrations if in your mind you ignore the "AND
SELF" portion.  The "AND SELF" text is necessary
because you will always receive SCN's about yourself
if you are registered to receive SCN's.  The
"INITIATOR" or "TARGET" specification indicates
whether you are concerned with receiving SCN's about
initiators, targets, or both.  This granularity was
provided because most initiators will only be
concerned about changes to target registrations, and
most targets will only be concerned about initiator
registrations.  If an initiator registers to receive
SCN's by specifying "INITIATOR AND SELF" and not
"TARGET AND SELF", then that initiator will receive
SCN's which concern only targets which are members of
at least one active Discovery Domain in common with
the initiator.

In further answer to your question, the target need
not  be concerned about sending SCN's.  The iSNS
server will  send these whenever there is a
registration/change/deregistration to a storage node
in the database.  In your case, for example, when you
register your target with the iSNS server, the iSNS
server will send SCN to any initiator which is a
member of at least one active Discovery Domain in
common with your target.

Hope this makes sense and it answers your questions.

-Joe Souza

---

From: Joe Souza <[email-masked]>
Date: Tue, 6 Sep 2005 13:11:23 -0700 (PDT)

I mistyped below, and I apologize for that.  I meant
to say:

If an initiator registers to receive SCN's by
specifying "TARGET AND SELF" and not "INITIATOR AND
SELF", then that initiator will receive SCN's which
concern only targets which are members of at least one
active Discovery Domain in common with the initiator.

Sorry for the confusion.

-Joe

--- Joe Souza <[email-masked]> wrote:

> > respect to the meaning of the bits in the iSCSI
> Node
> > SCN Bitmap.
> > 
> > customary for Fibre Channel storage arrays to send
> a
> > registered state 
> > change notification when the logical unit
> inventory
> > changes.
> > 
> > >    TARGET AND SELF INFORMATION ONLY SCNs (bit
> 25)
> > provides information
> > >    only about changes to target devices, or if
> the
> > iSCSI Storage Node
> > circumstances should an iSNS server consider to
> have
> > changed "the 
> > target itself"?
> > 
> > 
> > 
> > In summary,
> > If iSNS SCNs are not intended for this use, then
> the
> > initiator will 
> > rely on the initiator polling the target in order
> to
> > provide prompt

---

From: Steve Byan <[email-masked]>
Date: Tue, 6 Sep 2005 16:54:11 -0400

Hi Joe,

Thanks for the informative response.

On Sep 6, 2005, at 3:58 PM, Joe Souza wrote:

> function for that (SCNEvent),

I was speaking loosely. I meant that the target could send an SCN Event 
to the iSNS server, which would then cause the iSNS server to send an 
SCN to affected iSCSI nodes.

If a target were to wish to send an SCN event message, just what should 
it put in its SCN bitmask? OBJECT UPDATED?

> but beware that some

Couldn't a malicious iSCSI node perform the same denial of service 
attack by continually de-registering and then re-registering? Isn't it 
up to the iSNS server to limit the frequency of SCN's pertaining to a 
single iSCSI node?

> at least one active Discovery Domain in common with

Thanks, I was under the mistaken impression that only the OBJECT 
REMOVED/ADDED/UPDATED bits were used for deletions, changes, or 
additions to discovery domains. Where's the text in the draft that 
specifies this behavior? I don't recall reading it.

> member of at least one active Discovery Domain in

I'm asking how to communication the notification of changes in the 
logical unit inventory in a target that is already registered with the 
iSNS server. In this case, there is no registration or de-registration, 
unless the suggestion is that a target should de-register and then 
re-register when its logical unit inventory changes.

Perhaps a better phrasing of my question is:

How are iSCSI targets supposed to notify iSCSI initiators of a change 
in their logical unit inventory (i.e. a LUN has been added, removed, or 
the ACL for an initiator has changed)?

In an off-list message, Dave Weibel pointed out to me the support for 
SCSI asynchronous event notification (AEN) in iSCSI. I had forgotten it 
was in the standard, since AEN is so rarely supported in the SCSI world 
and was obsoleted in SAM-3. Does Microsoft's initiator support AEN? Is 
that how Microsoft expects targets to inform the initiator of a change 
in logical unit inventory?

Regards,
-Steve
--------

---

From: Joe Souza <[email-masked]>
Date: Tue, 6 Sep 2005 23:43:14 -0700 (PDT)

Steve,
 
Responses inline below:

Steve Byan <[email-masked]> wrote:
Hi Joe,

[Joe Souza] Yes.

[Joe Souza] You have a point, and an iSNS server implementation would need to guard against this type of attack as well.  But there are also other reasons, in my opinion, why SCNEvent is not a good idea.  One of the main goals for iSNS is for centralized management of an IP storage network.  SCNEvent, in my opinion, is not conducive toward this end; it removes some of the management functionality and control away from the server and toward the clients.  However, if you have strong feelings that the Microsoft iSNS server should support SCNEvent, you should send email to [email-masked] expressing your concerns.  I no longer work for Microsoft and thus am not the appropriate audience for such concerns.

[Joe Souza] Except for Management SCN's, which only Control Nodes receive, all SCN's are scoped to Discovery Domains where the recipient of the SCN shares at least one active Discovery Domain in common with the Node which caused the SCN to be generated.  This is mentioned in section 5.6.5.8 State Change Notification (SCN) but is also more clearly described in section 5.6.5.5 SCN Register Request (SCNReg).  SCN's are sent not only for changes to Discovery Domains but also for changes to Nodes which are members of active Discovery Domains.

[Joe Souza] I will defer to [email-masked] for questions about the Microsoft initiator, but in answer to your question, using iSNS, the recommended method (in my opinion) for an iSCSI target to cause registered iSNS clients to receive SCN's for changes to iSCSI target nodes, would be for the target to send an UPDATE registration for the target node (i.e. send DevAttrReg message for the target node, with the Replace bit clear) that it wishes the SCN to be sent for.

Regards,
-Steve
--------
Steve Byan 
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125

---

From: Steve Byan <[email-masked]>
Date: Wed, 7 Sep 2005 08:51:27 -0400

Hi Joe,

Thanks for your help. I've got a much clearer picture of how iSNS state 
change notifications are intended to be used now.

Regards,
-Steve
--------