rfc-4939

Definitions of Managed Objects for iSNS (Internet Storage Name Service)

K. Gibbons, G. Ramkumar, S. Kipp
date2007-07 streamIETF areatsv wgips statusPROPOSED STANDARD pages80 canonicalhttps://www.rfc-editor.org/rfc/rfc4939 doi10.17487/RFC4939 errataview
The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. [STANDARDS-TRACK]

Extracted elements (28)

design-rationale §5

iSCSI node names (up to 223 bytes) are too long to use directly as SNMP table indices, so the MIB defines an integer IsnsNodeIndexId (Unsigned32 1..4294967295) as a 1-to-1 surrogate index. The mapping is persistent across server restarts only for nodes that belong to a DD or are registered as control nodes.

snmp

design-rationale §3.4

The MIB supports management of multiple iSNS server instances via a single SNMP context by using isnsServerIndex as the primary index across all tables. This allows a single SNMP agent to monitor heterogeneous deployments with several iSNS servers.

snmp

interoperability-note §3.3.4.3

The isnsDdPortalMemberTable supports explicit portal-to-DD assignment, which is preferred only when specific portals are needed for a DD. For iSCSI in general, the Portal Group Object (isnsRegPgTable) should be used for portal-to-node mapping across all discovery domains.

snmp

interoperability-note §5

The Portal Index (IsnsPortalIndexId) used to identify a specific IP-address and port number pair is only persistent across server reinitializations for portals that have been explicitly added to a Discovery Domain. Portals not explicitly in any DD may receive a different index after a server restart.

snmp

normative-requirement §5 MUST

FC Port WWN values (isnsDdFcPortMemberPortName, isnsControlNodeFcPortWwpn) MUST be valid FC WWNs per the FC-GS standard and are fixed at SIZE(8). A zero-length string is explicitly invalid.

snmp

normative-requirement §5 SHOULD NOT

Index values for recently deregistered iSCSI node objects SHOULD NOT be reused in the short term, to avoid confusion between a new registration and a prior one that shared the same index.

snmp

normative-requirement §5 MUST

iSCSI node names (isnsDdIscsiMemberName, isnsControlNodeIscsiNodeName) MUST NOT exceed 223 bytes. The iSNS server internally allocates 224 bytes to include a NULL terminator.

snmp

normative-requirement §5 SHOULD

The isnsServerEsiNonResponseThreshold object defaults to 3, meaning an iSNS server will deregister an entity after 3 unanswered ESI (Entity Status Inquiry) messages. A value of 0 disables deregistration due to ESI non-response.

snmp

normative-requirement §5 SHOULD

When isnsServerDefaultDdDdsStatus is inNoDomain (the default), newly registered devices are not placed in any Discovery Domain or DDS. When set to inDefaultDdAndDds, new devices are automatically added to a default DD and DDS.

snmp

protocol-element §3.5

iSNS notifications (isnsNotification subtree) provide SNMP trap/inform support for iSNS server state changes, as described in Section 3.5. Notification objects are grouped under isnsNotifications (isnsMIB 0).

snmp

protocol-element §3.3.1

isnsControlNodeIscsiTable and isnsControlNodeFcPortTable enumerate control nodes authorized to manage an iSNS server, identified by iSCSI node index/name or FC Port WWN respectively. Each entry indicates whether the node is currently registered and whether it receives Management SCNs.

snmp

protocol-element §3.3.2

isnsDdsTable holds configuration for each Discovery Domain Set, including its symbolic name (up to 255 bytes) and status bitmap (IsnsDdsStatusType). isnsDdsMemberTable maps DD IDs to their parent DDS, indexed by server, DDS ID, and DD ID.

snmp

protocol-element §3.3.3

isnsDdTable holds each Discovery Domain's symbolic name and feature bitmap (IsnsDdFeatureType). DD membership is tracked in three sub-tables: isnsDdIscsiMemberTable (iSCSI nodes), isnsDdPortalMemberTable (portals), and isnsDdFcPortMemberTable (FC ports).

snmp

protocol-element §3.3

isnsNumObjectsTable augments isnsServerEntry and provides per-server counts of registered object types: Discovery Domain Sets, Discovery Domains, Entities, Portals, Portal Groups, iSCSI Nodes, FC Ports, and FC Nodes, all as Gauge32 values.

snmp

protocol-element §3.3.4.1

isnsRegEntityTable records registered Network Entities, indexed by server and integer Entity Index. Fields include Entity Identifier (EID), block storage protocol (iSCSI=2, iFCP=3), management address, registration timestamp, and minimum/maximum protocol version.

snmp

protocol-element §3.3

isnsServerTable provides per-instance monitoring of iSNS servers, indexed by isnsServerIndex (Unsigned32 1..4294967295). Each row reports the server's name, iSNS version, TCP/UDP ports, operational role (server/backupServer/notSet), enabled discovery methods, and DD/DDS policy settings.

snmp

protocol-element §3.2

The MIB is structured into three major sections: iSNS server information (isnsServerInfo), registered object information (isnsReg), and iSNS notifications (isnsNotifications). The server information and notification sections are required to implement.

snmp

protocol-element §5

The well-known TCP and UDP port for the iSNS Protocol (iSNSP) is 3205, reported via isnsServerTcpPort and isnsServerUdpPort respectively. A value of 0 for either object indicates that transport is not supported by the server instance.

snmp

registry §5

The iSNS MIB module (ISNS-MIB) is assigned OID mib-2 163. It provides SNMP-based management of iSNS servers supporting iSCSI and iFCP storage protocols.

snmp, registry

security-consideration §7

The iSNS MIB defines exclusively read-only (MAX-ACCESS read-only) objects, limiting the attack surface to information disclosure. Implementors should apply SNMPv3 authentication and encryption (authPriv security level) to prevent unauthorized access to storage topology data including portal addresses, node names, and IPsec policy settings.

snmp, security

wire-format §5

IsnsDdDdsModificationType is a 5-bit BITS field encoding who may modify Discovery Domains and DDS: bit 0 = controlNode, bit 1 = targetIscsiNode, bit 2 = initiatorIscsiNode, bit 3 = targetIfcpNode, bit 4 = initiatorIfcpNode.

snmp

wire-format §5

IsnsDdFeatureType is a 32-bit BITS field; bit 31 (bootlist) indicates that targets in the DD provide boot capabilities for member initiators. All other bits are RESERVED.

snmp

wire-format §5

IsnsDdsStatusType is a 32-bit BITS field encoding DDS status; bit 31 (ddsEnabled) indicates whether the DDS is enabled. All other bits are RESERVED. Setting a bit to 1 enables the feature.

snmp

wire-format §5

IsnsIscsiNodeType is a 32-bit BITS field where bit 29 = control, bit 30 = initiator, bit 31 = target. A single iSCSI node may have multiple roles set simultaneously.

snmp

wire-format §5

IsnsIscsiScnType and IsnsIfcpScnType are 32-bit BITS fields encoding State Change Notification subscriptions: bits 24-31 encode initiator-only, target-only, management registration SCN, object removed/added/updated, and DD/DDS member removed/added.

snmp

wire-format §5

IsnsPortalGroupTagIdOrNull is an Integer32 in the range -1..65535, where -1 represents a NULL (no association) Portal Group Tag value, and 0..65535 is a valid Portal Group Tag associating a portal with an iSCSI node.

snmp

wire-format §5

IsnsPortalSecurityType is a 32-bit BITS field encoding IPsec/IKE security attributes for a portal. Bit 31 (bitmapVALID) must be set for other bits to be considered valid; bits 25-30 encode tunnel mode preference, transport mode preference, PFS, aggressive mode, main mode, and IKE/IPsec enabled.

snmp, ipsec, vpn

wire-format §5

IsnsSrvrDiscoveryMethodsType is a BITS field encoding enabled iSNS server discovery methods: dhcp(0), slp(1), multicastGroupHb(2), broadcastHb(3), cfgdServerList(4), other(5).

snmp