SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    FW: iSNS: Event registry and notification



    JP,
    
    One thing I forgot to mention until after I sent this
    message is that there is an "SCN Bitmap" which allows
    the iSNS client to register for specific events.  If
    it is only interested in devices being added, but doesn't
    care if devices are pulled, then it sets the appropriate
    bits of the SCN bitmap.  This may help it to keep from
    being deluged by notifications that it doesn't care about.
    See section 6.4.4.
    
    Josh
    
    -----Original Message-----
    From: Joshua Tseng 
    Sent: Sunday, May 06, 2001 10:02 PM
    To: 'Raghavendra Rao'; ips@ece.cmu.edu
    Subject: RE: iSNS: Event registry and notification
    
    
    JP,
    
    <Snip...snip> 
    > Well, DDs may solve flooding of events to all unnecessary iSCSI nodes
    > to some extent. But I still visualise DDs to contain a good number of
    > iSCSI nodes even though the number won't be huge. In that case, it may
    > not be correct to assume that all iSCSI nodes are capable of 
    > heavyweight
    > 
    > processing of all kinds of events in the discovery domain - 
    > Turning off
    > events might be an option for those nodes but these Nodes might still
    > be interested in receiving notification about certain Nodes inside of
    > a discovery domain, not ALL of the nodes in the DD.
    > 
    Registration for notification is optional.  If an iSCSI device
    is afraid of being deluged by notification messages, then perhaps
    it shouldn't register for notifications, and instead periodically
    query to get an update on DD membership.
    
    > So what I would like to see is:
    > 
    >     a) more fine grained list of events
    >         -  One such example event would be to notify when an 
    > iSCSI node
    >            with certain attributes (such as access permision to a
    > specific iSCSI
    >            node)  or capabilities is added /removed to/from a 
    >  Disocvery
    > domain.
    >            Otherwise, let us say, if there are 255 iSCSI nodes in a
    > discovery
    >            domain, and if a new node is added, and even if 
    > the new node
    > has
    >            access permission to ONLY one iSCSI node in the discovery
    > domain,
    >            we would see all 255 nodes receiving notification 
    > and all 255
    > nodes
    >            probing for access control which might cause needless storm
    > of activity
    >            in the network.
    
    DD's define security/access control policy.  If a new node
    only had access permission to one other iSCSI node, then those
    two nodes would be the only members of the DD.  A node can be
    a member of multiple DD's.  If 255 devices are in the DD, that
    implies that all 255 devices have permission to access each
    other.  Initiators would therefore see and receive access to
    all targets and initiators in the common DD, although in practice
    they would ignore info on the initiators.
    
    > 
    >     b) mechanism to selectively receive one or more (set) of these
    > events
    >        as a certain iSCSI node may not be interested in all 
    > that happens
    > inside
    >        a DD, however small a DD might be.
    
    We have to keep the protocol simple.  Notification is for all
    events in the DD, or else you turn notification off and have the
    node periodically query to re-synch with the iSNS server.
    
    Josh
    
    > 
    > -JP
    > 
    


Home

Last updated: Tue Sep 04 01:04:46 2001
6315 messages in chronological order