tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7147

Proposed STD
Pages: 92
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: STORM

Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI)

Part 1 of 4, p. 1 to 15
None       Next RFC Part

Obsoletes:    4544


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                          M. Bakke
Request for Comments: 7147                                          Dell
Obsoletes: 4544                                            P. Venkatesen
Category: Standards Track                               HCL Technologies
ISSN: 2070-1721                                               April 2014


                     Definitions of Managed Objects
        for the Internet Small Computer System Interface (iSCSI)

Abstract

   This document defines a portion of the Management Information Base
   (MIB) for use with network management protocols.  In particular, it
   defines objects for managing a client using the Internet Small
   Computer System Interface (iSCSI) protocol (SCSI over TCP).

   This document obsoletes RFC 4544.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by
   the Internet Engineering Steering Group (IESG).  Further
   information on Internet Standards is available in Section 2 of
   RFC 5741.

   Information about the current status of this document, any
   errata, and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7147.

Page 2 
Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Top       Page 3 
Table of Contents

   1. The Internet-Standard Management Framework ......................4
   2. Introduction ....................................................4
   3. Relationship to Other MIB Modules ...............................4
   4. Relationship to SNMP Contexts ...................................5
   5. Differences from RFC 4544 .......................................5
   6. Discussion ......................................................6
      6.1. iSCSI MIB Object Model .....................................7
      6.2. iSCSI MIB Table Structure ..................................8
      6.3. iscsiInstance ..............................................9
      6.4. iscsiPortal ................................................9
      6.5. iscsiTargetPortal .........................................10
      6.6. iscsiInitiatorPortal ......................................11
      6.7. iscsiNode .................................................12
      6.8. iscsiTarget ...............................................12
      6.9. iscsiTgtAuthorization .....................................12
      6.10. iscsiInitiator ...........................................13
      6.11. iscsiIntrAuthorization ...................................13
      6.12. iscsiSession .............................................13
      6.13. iscsiConnection ..........................................14
      6.14. IP Addresses and TCP Port Numbers ........................14
      6.15. Descriptors: Using OIDs in Place of Enumerated Types .....15
      6.16. Notifications ............................................15
   7. MIB Definition .................................................16
   8. Security Considerations ........................................88
   9. IANA Considerations ............................................89
   10. References ....................................................89
      10.1. Normative References .....................................89
      10.2. Informative References ...................................91
   11. Acknowledgments ...............................................91

Top      ToC       Page 4 
1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

2.  Introduction

   This document defines a MIB module for iSCSI [RFC7143], used to
   manage devices that implement the iSCSI protocol.  It obsoletes RFC
   4544 [RFC4544].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

3.  Relationship to Other MIB Modules

   The iSCSI MIB module is normally layered between the SCSI MIB module
   [RFC4455] and the TCP MIB module [RFC4022], and it makes use of the
   IP Storage (IPS) Identity Authentication MIB module [RFC4545].  Here
   is how these modules are related:

   SCSI MIB    Within systems where a SCSI layer is present, each
               iscsiNode, whether it has an initiator role, target role,
               or both, is related to one SCSI device within the SCSI
               MIB module.  In this case, the iscsiNodeTransportType
               attribute points to the SCSI transport object within the
               SCSI MIB module, which in turn contains an attribute that
               points back to the iscsiNode.  In this way, a management
               station can navigate between the two MIB modules.  In
               systems where a SCSI layer is not present, such as within
               an iSCSI proxy device, the iscsiNodeTransportType
               attribute points to the appropriate corresponding object
               within the appropriate MIB or is left blank.

Top      ToC       Page 5 
   TCP MIB     Each iSCSI connection is related to one transport-level
               connection.  Currently, iSCSI uses only TCP; the iSCSI
               connection is related to a TCP connection using its
               normal (protocol, source address, source port,
               destination address, destination port) 5-tuple.

   AUTH MIB    Each iSCSI node that serves a target role can have a list
               of authorized initiators.  Each of the entries in this
               list points to an identity within the IPS Identity
               Authentication MIB module that will be allowed to access
               the target.  iSCSI nodes that serve in an initiator role
               can also have a list of authorized targets.  Each of the
               entries in this list points to an identity within the
               IPS-AUTH MIB module to which the initiator should attempt
               to establish sessions.  The IPS-AUTH MIB module includes
               information used to identify initiators and targets by
               their iSCSI name, IP address, and/or credentials.

   This MIB module imports objects from RFCs 2578 [RFC2578], 2579
   [RFC2579], 2580 [RFC2580], and 3411 [RFC3411].  It also imports
   textual conventions from the INET-ADDRESS-MIB [RFC4001].

4.  Relationship to SNMP Contexts

   Each non-scalar object in the iSCSI MIB module is indexed first by an
   iSCSI instance.  Each instance is a collection of nodes, portals,
   sessions, etc., that can define a physical or virtual partitioning of
   an iSCSI-capable device.  The use of an instance works well with
   partitionable or hierarchical storage devices and fits in logically
   with other management schemes.  Instances do not replace SNMP
   contexts; however, they do provide a very simple way to assign a
   virtual or physical partition of a device to one or more SNMP
   contexts, without having to do so for each individual node, portal,
   and session row.

5.  Differences from RFC 4544

   [RFC7143] updates several RFCs, including [RFC3720].  This document
   updates the iSCSI MIB correspondingly.  The document uses
   iSCSIProtocolLevel as defined in [RFC7144].  It obsoletes [RFC4544].
   Below is a brief description of the changes.

   -  Added iscsiInstXNodeArchitecture to InstanceAttributes.
   -  Added iscsiSsnTaskReporting of type BITS to SessionAttributes.
   -  Added iscsiSsnProtocolLevel to SessionAttributes.
   -  Deprecated the marker objects.
   -  Fixed the errata to [RFC4544].

Top      ToC       Page 6 
   -  Added NOP counters at iSCSI session scope for heartbeat tracking.
   -  Added port number to the iscsiTgtLoginFailure and
      iscsiIntrLoginFailure notifications, and to the last failure info
      in iscsiInitiatorAttributesEntry.
   -  Added description string to the iSCSI portal.
   -  Added iscsiInstSsnTgtUnmappedErrors to support "Target Unmapped"
      session failure reporting in the iscsiInstSessionFailure
      notification.
   -  Added iscsiTgtLogoutCxnClosed and iscsiTgtLogoutCxnRemoved, which
      maintain the count of Logout Command PDUs received by the target
      with reason codes 1 and 2, respectively.
   -  Changed the conformance statements to match the above.

6.  Discussion

   This MIB module structure supplies configuration, fault, and
   statistics information for iSCSI devices [RFC7143].  It is structured
   around the well-known iSCSI objects, such as targets, initiators,
   sessions, connections, and the like.

   This MIB module may also be used to configure access to iSCSI
   targets, by creating iSCSI portals and authorization list entries.

   It is worthwhile to note that this is an iSCSI MIB module and as such
   reflects only iSCSI objects.  This module does not contain
   information about the SCSI-layer attributes of a device.  If a SCSI
   layer is present, the SCSI MIB module [RFC4455] may be used to manage
   SCSI information for a device.

   The iSCSI MIB module consists of several "objects", each of which is
   represented by one or more tables.  This section contains a brief
   description of the object hierarchy and a description of each object,
   followed by a discussion of the actual table structure within the
   objects.

Top      ToC       Page 7 
6.1.  iSCSI MIB Object Model

   The top-level object in this structure is the iSCSI instance, which
   "contains" all of the other objects.

      iscsiInstance
         -- A distinct iSCSI entity within the managed system.
         iscsiPortal
            -- An IP address used by this instance.
            iscsiTargetPortal
               -- Contains portal information relevant when the portal
               -- is used to listen for connections to its targets.
            iscsiInitiatorPortal
               -- Contains portal information relevant when the portal
               -- is used to initiate connections to other targets.
         iscsiNode
            -- An iSCSI node can act as an initiator, a target, or both.
            -- Contains generic (non-role-specific) information.
            iscsiTarget
               -- Target-specific iSCSI node information.
               iscsiTgtAuth
                  -- A list of initiator identities that are allowed
                  -- access to this target.
            iscsiInitiator
               -- Initiator-specific iSCSI node information.
               iscsiIntrAuth
                  -- A list of target identities to which this initiator
                  -- is configured to establish sessions.
            iscsiSession
               -- An active iSCSI session between an initiator and
               -- target.  The session's direction may be Inbound
               -- (an outside initiator to the target represented by
               -- this node) or Outbound (the initiator represented by
               -- this node to an outside target).
               iscsiConnection
                  -- An active TCP connection within an iSCSI session.

   An iSCSI node can be an initiator, a target, or both.  The iSCSI
   node's portals may be used to initiate connections (initiator) or
   listen for connections (target), depending on whether the iSCSI node
   is acting as an initiator or target.  The iSCSI MIB module assumes
   that any target may be accessed via any portal that can take on a
   target role, although other access controls not reflected in the
   module might limit this.

Top      ToC       Page 8 
6.2.  iSCSI MIB Table Structure

   Each iSCSI object exports one or more tables: an attributes table,
   and zero or more statistics tables, which augment the attributes
   table.  Since iSCSI is an evolving standard, it is much cleaner to
   provide statistics and attributes as separate tables, allowing
   attributes and statistics to be added independently.  In a few cases,
   there are multiple categories of statistics that will likely grow; in
   this case, an object will contain multiple statistics tables.

      iscsiObjects
        iscsiDescriptors
        iscsiInstance
          iscsiInstanceAttributesTable
          iscsiInstanceSsnErrorStatsTable
            -- Counts abnormal session terminations
        iscsiPortal
          iscsiPortalAttributesTable
        iscsiTargetPortal
          iscsiTgtPortalAttributesTable
        iscsiInitiatorPortal
          iscsiIntrPortalAttributesTable
        iscsiNode
          iscsiNodeAttributesTable
        iscsiTarget
          iscsiTargetAttributesTable
          iscsiTargetLoginStatsTable
            -- Counts successful and unsuccessful logins
          iscsiTargetLogoutStatsTable
            -- Counts normal and abnormal logouts
        iscsiTgtAuthorization
          iscsiTgtAuthAttributesTable
        iscsiInitiator
          iscsiInitiatorAttributesTable
          iscsiInitiatorLoginStatsTable
            -- Counts successful and unsuccessful logins
          iscsiInitiatorLogoutStatsTable
            -- Counts normal and abnormal logouts
        iscsiIntrAuthorization
          iscsiIntrAuthAttributesTable
        iscsiSession
          iscsiSessionAttributesTable
          iscsiSessionStatsTable
            -- Performance-related counts (requests, responses, bytes)
          iscsiSessionCxnErrorStatsTable
            -- Counts digest errors, connection errors, etc.
        iscsiConnection
          iscsiConnectionAttributesTable

Top      ToC       Page 9 
   Note that this module does not attempt to count everything that could
   be counted; it is designed to include only those counters that would
   be useful for identifying performance, security, and fault problems
   from a management station.

6.3.  iscsiInstance

   The iscsiInstanceAttributesTable is the primary table of the iSCSI
   MIB module.  Every table entry in this module is "owned" by exactly
   one iSCSI instance; all other table entries in the module include
   this table's index as their primary index.

   Most implementations will include just one iSCSI instance row in this
   table.  However, this table exists to allow for multiple virtual
   instances.  For example, many IP routing products now allow multiple
   virtual routers.  The iSCSI MIB module has the same premise; a large
   system could be "partitioned" into multiple, distinct virtual
   systems.

   This also allows a single SNMP agent to proxy for multiple
   subsystems, perhaps a set of stackable devices, each of which has one
   or even more instances.

   The instance attributes include the iSCSI vendor and version, as well
   as information on the last target or initiator at the other end of a
   session that caused a session failure.

   The iscsiInstanceSsnErrorStatsTable augments the attributes table and
   provides statistics on session failures due to digest, connection, or
   iSCSI format errors.

6.4.  iscsiPortal

   The iscsiPortalAttributesTable lists iSCSI portals that can be used
   to listen for connections to targets, to initiate connections to
   other targets, or to do both.

   Each row in the table includes an IP address (either v4 or v6), and a
   transport protocol (currently only TCP is defined).  Each portal may
   have additional attributes, depending on whether it is an initiator
   portal, a target portal, or both.  Initiator portals also have portal
   tags; these are placed in corresponding rows in the
   iscsiIntrPortalAttributesTable.  Target portals have both portal tags
   and ports (e.g., TCP listen ports if the transport protocol is TCP);
   these are placed in rows in the iscsiTgtPortalAttributesTable.

Top      ToC       Page 10 
   Portal rows, along with their initiator and target portal
   counterparts, may be created and destroyed through this MIB module by
   a management station.  Rows in the initiator and target portal tables
   are created and destroyed automatically by the agent when a row is
   created or destroyed in the iscsiPortalAttributesTable or when the
   value of iscsiPortalRoles changes.  Attributes in these tables may
   then be modified by the management station if the agent
   implementation allows.

   When created by a management station, the iscsiPortalRoles attribute
   is used to control row creation in the initiator and target portal
   tables.  Creating a row with the targetTypePortal bit set in
   iscsiPortalRoles will cause the implementation to start listening for
   iSCSI connections on the portal.  Creating a row with the
   initiatorTypePortal bit set in iscsiPortalRoles will not necessarily
   cause connections to be established; it is left to the implementation
   whether and when to make use of the portal.  Both bits may be set if
   the portal is to be used by both initiator and target nodes.

   When deleting a row in the iscsiPortalAttibutesTable, all connections
   associated with that row are terminated.  The implementation may
   either terminate the connection immediately or request a clean
   shutdown as specified in [RFC7143].  An outbound connection (when an
   iscsiInitiatorPortal is deleted) matches the portal if its
   iscsiCxnLocalAddr matches the iscsiPortalAddr.  An inbound connection
   (when an iscsiTargetPortal is deleted) matches the portal if its
   iscsiCxnLocalAddr matches the iscsiPortalAddr and if its
   iscsiCxnLocalPort matches the iscsiTargetPortalPort.

   Individual objects within a row in this table may not be modified
   while the row is active.  For instance, changing the IP address of a
   portal requires that the rows associated with the old IP address be
   deleted and that new rows be created (in either order).

6.5.  iscsiTargetPortal

   The iscsiTgtPortalAttributesTable contains target-specific attributes
   for iSCSI portals.  Rows in this table use the same indices as their
   corresponding rows in the iscsiPortalAttributesTable, with the
   addition of iscsiNodeIndex.

   Rows in this table are created when the targetTypePortal bit is set
   in the iscsiPortalRoles attribute of the corresponding
   iscsiPortalAttributesEntry; they are destroyed when this bit is
   cleared.

Top      ToC       Page 11 
   This table contains the TCP (or other protocol) port on which the
   socket is listening for incoming connections.  It also includes a
   portal group aggregation tag; iSCSI target portals that are within
   this instance and share the same tag can contain connections within
   the same session.

   This table will be empty for iSCSI instances that contain only
   initiators (such as iSCSI host driver implementations).

   Many implementations use the same Target Portal Group Tag and
   protocol port for all nodes accessed via a portal.  These
   implementations will create a single row in the
   iscsiTgtPortalAttributeTable, with an iscsiNodeIndex of zero.

   Other implementations do not use the same tag and/or port for all
   nodes; these implementations will create a row in this table for each
   (portal, node) tuple, using iscsiNodeIndex to designate the node for
   this portal tag and port.

6.6.  iscsiInitiatorPortal

   The iscsiIntrPortalAttributesTable contains initiator-specific
   objects for iSCSI portals.  Rows in this table use the same indices
   as their corresponding entries in the iscsiPortalAttributesTable.  A
   row in this table is created when the initiatorTypePortal bit is set
   in the iscsiPortalRoles attribute; it is destroyed when this bit is
   cleared.

   Each row in this table contains a portal group aggregation tag,
   indicating which portals an initiator may use together within a
   multiple-connection session.

   This table will be empty for iSCSI instances that contain only
   targets (such as most iSCSI devices).

   Many implementations use the same initiator tag for all nodes
   accessing targets via a given portal.  These implementations will
   create a single row in iscsiIntrPortalAttributeTable, with an
   iscsiNodeIndex of zero.

   Other implementations do not use the same tag and/or port for all
   nodes; these implementations will create a row in this table for each
   (portal, node) tuple, using iscsiNodeIndex to designate the node for
   this portal tag and port.

Top      ToC       Page 12 
6.7.  iscsiNode

   The iscsiNodeAttributesTable contains a list of iSCSI nodes, each of
   which may have an initiator role, a target role, or both.

   This table contains the node's attributes that are common to both
   roles, such as its iSCSI name and alias string.  Attributes specific
   to initiators or targets are available in the iscsiTarget and
   iscsiInitiator objects.  Each row in this table that can fulfill a
   target role has a corresponding row in the iscsiTarget table; each
   entry that fulfills an initiator role has a row in the iscsiInitiator
   table.  Nodes such as copy managers that can take on both roles have
   a corresponding row in each table.

   This table also contains the login negotiations preferences for this
   node.  These objects indicate the values this node will offer or
   prefer in the operational negotiation phase of the login process.

   For most implementations, each entry in the table also contains a
   RowPointer to the transport table entry in the SCSI MIB module that
   this iSCSI node represents.  For implementations without a standard
   SCSI layer above iSCSI, such as an iSCSI proxy or gateway, this
   RowPointer can point to a row in an implementation-specific table
   that this iSCSI node represents.

6.8.  iscsiTarget

   The iscsiTargetAttributesTable contains target-specific attributes
   for iSCSI nodes.  Each entry in this table uses the same index values
   as its corresponding iscsiNode entry.

   This table contains attributes used to indicate the last failure that
   was (or should have been) sent as a notification.

   This table is augmented by the iscsiTargetLoginStatsTable and the
   iscsiTargetLogoutStatsTable, which count the numbers of normal and
   abnormal logins and logouts to this target.

6.9.  iscsiTgtAuthorization

   The iscsiTgtAuthAttributesTable contains an entry for each initiator
   identifier that will be allowed to access the target under which it
   appears.  Each entry contains a RowPointer to a user identity in the
   IPS Authorization MIB module, which contains the name, address, and
   credential information necessary to authenticate the initiator.

Top      ToC       Page 13 
6.10.  iscsiInitiator

   The iscsiInitiatorAttributesTable contains a list of initiator-
   specific attributes for iSCSI nodes.  Each entry in this table uses
   the same index values as its corresponding iscsiNode entry.

   Most implementations will include a single entry in this table,
   regardless of the number of physical interfaces the initiator may
   use.

   This table is augmented by the iscsiInitiatorLoginStatsTable and the
   iscsiInitiatorLogoutStatsTable, which count the numbers of normal and
   abnormal logins and logouts from this initiator.

6.11.  iscsiIntrAuthorization

   The iscsiIntrAuthAttributesTable contains an entry for each target
   identifier to which the initiator is configured to establish a
   session.

   Each entry contains a RowPointer to a user identity in the IPS
   Authorization MIB module, which contains the name, address, and
   credential information necessary to identify (for discovery purposes)
   and authenticate the target.

6.12.  iscsiSession

   The iscsiSessionAttributesTable contains a set of rows that list the
   sessions known to exist locally for each node in each iSCSI instance.

   The session type for each session indicates whether the session is
   used for normal SCSI commands or for discovery using the SendTargets
   text command.  Discovery sessions that do not belong to any
   particular node have a node index attribute of zero.

   The session direction for each session indicates whether it is an
   Inbound session or an Outbound session.  Inbound sessions are from
   some other initiator to the target node under which the session
   appears.  Outbound sessions are from the initiator node under which
   the session appears to a target outside this iSCSI instance.

   Many attributes may be negotiated when starting an iSCSI session.
   Most of these attributes are included in the session object.

Top      ToC       Page 14 
   Some attributes, such as the integrity and authentication schemes,
   have some standard values that can be extended by vendors to include
   their own schemes.  These contain an object identifier, rather than
   the expected enumerated type, to allow these values to be extended by
   other MIB modules, such as an enterprise MIB module.

   The iscsiSessionStatsTable includes statistics related to
   performance; it counts iSCSI data bytes and PDUs.

   For implementations that support error recovery without terminating a
   session, the iscsiSessionCxnErrorStatsTable contains counters for the
   numbers of digest and connection errors that have occurred within the
   session.

6.13.  iscsiConnection

   The iscsiConnectionAttributesTable contains a list of active
   connections within each session.  It contains the IP addresses and
   TCP (or other protocol) ports of both the local and remote sides of
   the connection.  These may be used to locate other connection-related
   information and statistics in the TCP MIB module [RFC4022].

   The attributes table also contains a connection state.  This state is
   not meant to directly map to the state tables included within the
   iSCSI specification; they are meant to be simplified, higher-level
   definitions of connection state that provide information more useful
   to a user or network manager.

   No statistics are kept for connections.

6.14.  IP Addresses and TCP Port Numbers

   The IP addresses in this module are represented by two attributes,
   one of type InetAddressType, and the other of type InetAddress.
   These are taken from [RFC4001], which specifies how to support
   addresses that may be either IPv4 or IPv6.

   The TCP port numbers that appear in a few of the structures are
   described as simply port numbers, with a protocol attribute
   indicating whether they are TCP ports or something else.  This will
   allow the module to be compatible with iSCSI over transports other
   than TCP in the future.

Top      ToC       Page 15 
6.15.  Descriptors: Using OIDs in Place of Enumerated Types

   The iSCSI MIB module has a few attributes, namely, the digest method
   attributes, where an enumerated type would work well, except that an
   implementation may need to extend the attribute and add types of its
   own.  To make this work, this MIB module defines a set of object
   identities within the iscsiDescriptors subtree.  Each of these object
   identities is basically an enumerated type.

   Attributes that make use of these object identities have a value that
   is an Object Identifier (OID) instead of an enumerated type.  These
   OIDs can indicate either the object identities defined in this module
   or object identities defined elsewhere, such as in an enterprise MIB
   module.  Those implementations that add their own digest methods
   should also define a corresponding object identity for each of these
   methods within their own enterprise MIB module, and return its OID
   whenever one of these attributes is using that method.

6.16.  Notifications

   Three notifications are provided.  One is sent by an initiator
   detecting a critical login failure, another is sent by a target
   detecting a critical login failure, and the third is sent upon a
   session being terminated due to an abnormal connection or digest
   failure.  Critical failures are defined as those that may expose
   security-related problems that may require immediate action, such as
   failures due to authentication, authorization, or negotiation
   problems.  Attributes in the initiator, target, and instance objects
   provide the information necessary to send in the notification, such
   as the initiator or target name and IP address at the other end that
   may have caused the failure.

   To avoid sending an excessive number of notifications due to multiple
   errors counted, an SNMP agent implementing the iSCSI MIB module
   SHOULD NOT send more than three iSCSI notifications in any 10-second
   period.

   The 3-in-10 rule was chosen because one notification every three
   seconds was deemed often enough, but should two or three different
   notifications happen at the same time, it would not be desirable to
   suppress them.  Three notifications in 10 seconds is a happy medium,
   where a short burst of notifications is allowed, without inundating
   the network and/or notification host with a large number of
   notifications.


Next RFC Part