Internet Storage Name Service (iSNS)
Extracted elements (30)
Discovery Domains are modeled on Fibre Channel zoning (FC-GS-4 Generic Services Name Server) to provide familiar storage-network partitioning and login control on IP networks, reducing unnecessary logins as the storage network scales beyond a per-device management model.
iSNS database records are distributed between servers via out-of-band mechanisms such as LDAP replication or SNMP management GET/SET rather than a dedicated iSNS replication protocol, allowing inter-organization storage sharing without new protocol work; interactions among multiple authoritative primary iSNS servers are deferred as future work.
The iSNS server stores open FC-to-iSCSI device mappings (Proxy iSCSI Name tag 101, WWNN Token tag 37) rather than keeping them internal to gateways, so any authorized iSNS client can retrieve and use the mapping without relying on proprietary gateway mechanisms.
NAT boundaries cause IP address information registered in the iSNS database to be invalid when interpreted in a different addressing domain. Recommended workarounds include using DNS FQDNs stored in the Entity Identifier field instead of nominal IP addresses, or deploying local iSNS servers inside each NAT domain.
SNMP OIDs are limited to 128 sub-identifiers, but iSCSI Names and FC identifiers can exceed 128 characters; iSNS therefore provides persistent integer index attributes as secondary SNMP-accessible keys, and 'next available index' attributes so SNMP clients can request valid OIDs for creating new objects.
A maximum of one logical backup iSNS server SHALL exist at any individual IP address, to avoid conflicts from multiple servers listening on the same canonical iSNS TCP or UDP port number.
Each object of a specific type in the iSNS database MUST have an implicit internal linear ordering based on its key(s), enabling DevGetNext queries; the relative order of surviving entries SHOULD NOT change due to insertions or deletions.
If no Portals of a Network Entity have been placed into a DD, queries scoped to that DD SHALL report all Portals of that Entity; if one or more Portals have been explicitly placed, only those Portals SHALL be reported.
In order for a Portal to provide access to an iSCSI Node, the Portal Group Tag (PGT) of the PG object MUST be non-NULL; a NULL PGT or absent PGT means the Portal does not provide access to that iSCSI Node in the Entity.
It MUST be possible to use TCP for iSNS communication, and the iSNS server MUST accept TCP connections for client registrations.
The iSNS server implementation MUST provide an administrative control interface for settings (ESI threshold, DD/DDS modification policy, authorized Control Nodes) that cannot be configured via iSNSP. Specified default values MUST be used in the absence of administrator-provided settings.
The iSNS server MUST maintain the state of DD membership for all Storage Nodes, even those that have been deregistered; DD membership is persistent regardless of active registration status.
Use of iSNS is OPTIONAL for iSCSI but REQUIRED for iFCP; no alternatives exist for iFCP Naming and Discovery functions.
When a backup server assumes the active server role it SHALL transmit heartbeats replacing its own IP/port for the active server fields, but MUST NOT change the original ordered list of backup server IP Address and TCP/UDP Port entries.
When using UDP to transport iSNS messages, each UDP datagram MUST contain exactly one iSNS PDU.
iSNSP defines six object types: Network Entity (container for Storage Nodes and Portals), Portal (IP address/port interface), Storage Node (iSCSI or iFCP session endpoint), Portal Group (Portal-to-iSCSI-Node association via PGT), FC Device (Fibre Channel node), Discovery Domain, and Discovery Domain Set.
Registration and Query messages carry four logical sections: Source Attribute (message originator used for DD-scoping and authorization), Message Key Attributes (object identifier), Delimiter Attribute (zero-length TLV separator), and Operating Attributes (fields to register or query).
The Entity Status Inquiry (ESI) message (Function ID 0x000D) is sent by the iSNS server to registered portals to monitor device availability; after a configurable non-response threshold (default 3 messages), the Network Entity is deregistered.
The iSNS Heartbeat message (Function ID 0x000E) is originated by the active iSNS server and sent via IP multicast or broadcast; it carries the active server IP/port, an incrementing counter, and an ordered list of backup server IP addresses and TCP/UDP ports.
The iSNS server assigns persistent non-zero integer index attributes (Entity Index, Portal Index, iSCSI Node Index, etc.) as secondary object identifiers; these SHALL be persistent for as long as the server is active, and index values for recently deregistered objects SHOULD NOT be reused short-term.
The Portal Group (PG) object associates a Portal with an iSCSI Storage Node using a Portal Group Tag (PGT); Portals sharing the same PGT value for a given iSCSI node provide coordinated multi-connection iSCSI session access as defined by the iSCSI specification.
The State Change Notification (SCN) service allows the iSNS server to push notifications about network events to registered clients. Regular SCNs are scoped to shared Discovery Domains; Management SCNs, available only to Control Nodes, are not DD-scoped.
This document creates three IANA registries: Registry of Block Storage Protocols (Section 8.1), Registry of Standard iSNS Attributes (Section 8.2), and Block Structure Descriptor (BSD) Registry (Section 8.3).
Authentication is required for iSNS multicast and broadcast messages (Section 5.5) to prevent spoofed heartbeat attacks. Only Control Nodes are authorized to create or delete Discovery Domains and to register for Management SCNs; authorization for Control Node registration is administratively controlled.
IKE/IPSec is the specified security mechanism for iSNS; per-portal security policies are discovered via the Portal Security Bitmap (Section 6.3.9) and Entity/Portal IKE Phase-1/Phase-2 Proposal attributes stored in the iSNS database.
The Login Control feature allows iSCSI targets to delegate access control policy to the iSNS server; only initiators sharing at least one common active DD with the target and matching iSNS-supplied authorization are permitted to establish sessions.
A backup iSNS server transitions to the active role when it loses connectivity to the active server and all higher-precedence backups; it reverts to backup when a higher-precedence server returns and confirms the database is synchronized before demotion.
A Discovery Domain (DD) is active if and only if it is a member of at least one active Discovery Domain Set (DDS); DDs not belonging to any active DDS are disabled and Storage Nodes within them cannot discover each other via scoped iSNSP queries.
iSNSP payload attributes use Tag-Length-Value (TLV) encoding with mandatory 4-byte alignment; attribute values are padded to the next 4-byte boundary. A 0-length TLV encodes a NULL value (e.g., a NULL Portal Group Tag).
The iSNSP PDU header is 12 bytes in big-endian order: iSNSP Version (2 bytes), Function ID (2 bytes), PDU Length (2 bytes), Flags (2 bytes), Transaction ID (2 bytes), and Sequence ID (2 bytes). All iSNSP frame formats use big-endian network byte order.