RFC 4171
Internet Storage Name Service (iSNS)
Part 1 of 28 🎀
Title Block 💖
Okay bestie, this is RFC 4171, all about the Internet Storage Name Service (iSNS) 🌸 It's on the Standards Track 🔥 and it was published in September 2005. It comes from the Network Working Group 🧚
The authors are:
- J. Tseng from Riverbed Technology ✨
- K. Gibbons from McDATA Corporation 💅
- F. Travostino from Nortel 🦋
- C. Du Laney from Rincon Research Corporation 🫶
- J. Souza from Microsoft 👑
The title block doesn't list anything this RFC obsoletes or updates, so nothing gets replaced or patched here 🙈
Status of This Memo 🍓
So this document is an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and send ideas for making it better 💜 If you want to know where the protocol stands officially, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 Also, distribution of this memo is unlimited 🌈
Copyright Notice ⭐
Copyright (C) The Internet Society (2005). 💅
Abstract 🦋
Okay, so the abstract is the big picture 😭 This document specifies the Internet Storage Name Service (iSNS) protocol, which is used for talking between iSNS servers and iSNS clients 🫶 It helps with automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network ✨
iSNS gives you intelligent storage discovery and management services that are comparable to what you find in Fibre Channel networks 🔥 That means a regular commodity IP network can act kind of like a storage area network 🧚
It's also a seamless way to integrate IP and Fibre Channel networks, because iSNS can emulate Fibre Channel fabric services and manage both iSCSI and Fibre Channel devices at the same time 💖 So iSNS is valuable in any storage network made of iSCSI devices, Fibre Channel devices (using iFCP gateways), or a mix of both 👑 Literally main character energy 💅✨
Table of Contents 🎀
1. Introduction................................................... 6
1.1. Conventions Used in This Document........................ 6
1.2. Purpose of This Document................................. 6
2. iSNS Overview.................................................. 6
2.1. iSNS Architectural Components ........................... 7
2.1.1. iSNS Protocol (iSNSP) ........................... 7
2.1.2. iSNS Client...................................... 7
2.1.3. iSNS Server...................................... 7
2.1.4. iSNS Database ................................... 7
2.1.5. iSCSI............................................ 7
2.1.6. iFCP............................................. 7
2.2. iSNS Functional Overview................................. 8
2.2.1. Name Registration Service........................ 8
2.2.2. Discovery Domain and Login Control Service....... 8
2.2.3. State Change Notification Service............... 10
2.2.4. Open Mapping between
Fibre Channel and iSCSI Devices................. 11
2.3. iSNS Usage Model........................................ 11
2.3.1. iSCSI Initiator................................. 12
2.3.2. iSCSI Target.................................... 12
2.3.3. iSCSI-FC Gateway................................ 12
2.3.4. iFCP Gateway.................................... 12
2.3.5. Management Station.............................. 12
2.4. Administratively Controlled iSNS Settings............... 13
2.5. iSNS Server Discovery .................................. 14
2.5.1. Service Location Protocol (SLP)................. 14
2.5.2. Dynamic Host Configuration Protocol (DHCP)...... 14
2.5.3. iSNS Heartbeat Message.......................... 14
2.6. iSNS and Network Address Translation (NAT).............. 14
2.7. Transfer of iSNS Database Records between iSNS Servers.. 15
2.8. Backup iSNS Servers..................................... 17
2.9. Transport Protocols..................................... 19
2.9.1. Use of TCP for iSNS Communication............... 19
2.9.2. Use of UDP for iSNS Communication............... 20
2.9.3. iSNS Multicast and Broadcast Messages........... 20
2.10. Simple Network Management Protocol (SNMP) Requirements.. 21
3. iSNS Object Model............................................. 21
3.1. Network Entity Object .................................. 22
3.2. Portal Object .......................................... 22
3.3. Storage Node Object..................................... 22
3.4. Portal Group Object..................................... 23
3.5. FC Device Object........................................ 24
3.6. Discovery Domain Object................................. 24
3.7. Discovery Domain Set Object............................. 24
3.8. iSNS Database Model..................................... 24
4. iSNS Implementation Requirements.............................. 251. Introduction ✨
1.1. Conventions Used in This Document
okay so first things first, bestie 🎀 "iSNS" is the name for the storage network model and its associated services, as covered in the text of this document. that's the whole vocab check 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. these are the special words that carry real weight in the spec, so read them carefully 🫶
ngl the byte order is a big deal too 🦋 All frame formats are in big endian network byte order.
And for the unused stuff: All unused fields and bitmaps, including those that are RESERVED, SHOULD be set to zero when sending and ignored when receiving. so even the leftover bits you aren't using are supposed to get the zero treatment when you send, and get ignored when you receive 😭✨
1.2. Purpose of This Document
okay this part is giving main character energy 👑 This is a standards track document containing normative text specifying the iSNS Protocol, used by iSCSI and iFCP devices to communicate with the iSNS server. basically it's the rulebook for how the devices chat with the iSNS server 💜
the focus is the vibe between iSNS servers and iSNS clients 🌸 interactions among multiple authoritative primary iSNS servers are a potential topic for future work, so that's a maybe-later plot twist 👀
2. iSNS Overview ✨
okay so iSNS is basically the group chat manager for storage devices 💅 It handles scalable setup and management of iSCSI and Fibre Channel (FCP) storage devices running over an IP network, and it gives you the same kind of services you'd get in a Fibre Channel network 🌸 The result is that a boring commodity IP network can act with the smarts of a Fibre Channel fabric 🧠✨
Here's the glow-up part, bestie. Without iSNS, the admin has to go device by device and hand-type each storage box's list of initiators and targets 😩 With iSNS, every storage device hands its discovery and management jobs over to the iSNS server 🫶 That server becomes the one central place where management stations can configure and manage the whole storage network, iSCSI and Fibre Channel devices included 👑
iSNS can be built to support iSCSI and/or iFCP, depending on what you need 🦋 An iSNS implementation MAY provide support for one or both of these protocols, whatever the implementor wants 💖 The implementation requirements for each protocol get more detail in Section 5. iSNS is OPTIONAL for iSCSI and REQUIRED for iFCP 🔥
2.1. iSNS Architectural Components
2.1.1. iSNS Protocol (iSNSP)
The iSNS Protocol (iSNSP) is a flexible and lightweight protocol that defines how iSNS clients and servers talk to each other 🦋 It's built to run on all sorts of platforms, including switches, targets, and server hosts 🖥️✨
2.1.2. iSNS Client
iSNS clients start the conversations with iSNS servers using the iSNSP 💬 They're processes that live right on the storage device, and they can register device attribute info, download info about other registered clients in a shared Discovery Domain (DD), and get async notifications when events happen in their DD(s) 🔔 Management stations are a special kind of iSNS client with access to every DD stored in the iSNS, so they're giving main character energy 👑
2.1.3. iSNS Server
iSNS servers answer iSNS protocol queries and requests, and they also start iSNS protocol State Change Notifications 📣 Registration requests get properly authenticated first, and then the info is stored in an iSNS database 🔐
2.1.4. iSNS Database
The iSNS database is the info repository for the iSNS server(s) 🗄️ It keeps track of iSNS client attributes 🌈 A directory-enabled version of iSNS may store those client attributes in an LDAP directory infrastructure, which is pretty iconic 🧚
2.1.5. iSCSI
iSCSI (Internet SCSI) is an encapsulation of SCSI made for a new generation of storage devices that are linked together over TCP/IP [iSCSI] 🍓
2.1.6. iFCP
iFCP (Internet FCP) is a gateway-to-gateway protocol built to connect existing Fibre Channel and SCSI devices using TCP/IP 🌉 It maps the existing FCP standard and its Fibre Channel services onto TCP/IP [iFCP] 💜
2.2. iSNS Functional Overview
There are four main functions of the iSNS, and I'm obsessed with how they're organized 😭
- A Name Service Providing Storage Resource Discovery
- Discovery Domain (DD) and Login Control Service
- State Change Notification Service
- Open Mapping of Fibre Channel and iSCSI Devices
2.2.1. Name Registration Service
The iSNS gives every entity in a storage network a registration function, so they can register with and query the iSNS database 📝 Targets and initiators can both register in the iSNS database, and they can both query for info about other initiators and targets 🔍 So, for example, a client initiator can get info about target devices from the iSNS server 🎯 This service is modeled on the Fibre Channel Generic Services Name Server described in FC-GS-4, with extensions, and it runs within the context of an IP network 🌐
The naming registration service also lets you get a network-unique Domain ID for iFCP gateways whenever one is needed 🆔✨
2.2.2. Discovery Domain and Login Control Service
The Discovery Domain (DD) Service helps split Storage Nodes into more manageable groups for admin and login control purposes 🗂️ It lets the admin limit each host's login process to the most appropriate subset of targets registered in the iSNS 🎀 This matters a lot for cutting down on unnecessary logins (iSCSI logins or Fibre Channel Port Logins), and for limiting how long a host spends setting up login relationships as the storage network scales up 📈 Storage Nodes need to be in at least one common enabled DD before they can get info about each other 🤝 Devices are allowed to be members of multiple DDs at the same time 💅
Login Control lets targets hand off their access control and authorization policies to the iSNS server 🫶 This fits perfectly with the goal of centralizing management of those storage devices on the iSNS server 👑 The target node or device downloads the list of authorized initiators from the iSNS 📥 Each node or device is uniquely identified by an iSCSI Name or FC Port Name 🪪 Only initiators that match the identification and authorization the iSNS provides will be allowed access by that target Node during session establishment 🚪 Literally the bouncer of the storage world 💀
Placing Portals of a Network Entity into Discovery Domains lets admins pick the preferred IP Portal interface that storage traffic should use to reach specific Storage Nodes of that Network Entity 🛣️ If none of a Network Entity's Portals have been placed into a DD, then queries scoped to that DD SHALL report all Portals of that Network Entity 📋 If one or more Portals of a Network Entity have been placed into a DD, then queries scoped to that DD SHALL report only those Portals that were explicitly placed in the DD 🎯 Very precise, very iconic 🙈
DDs can be managed offline through a separate management workstation using the iSNSP or SNMP 🖥️ If the target opts into the Login Control feature of the iSNS, then the target delegates management of its access control policy (i.e., the list of initiators allowed to log in to that target) to the management workstations that manage the configuration in the iSNS database 🔑
If it's administratively authorized, a target can upload its own Login Control list 📤 This is done with the DDReg message, which lists the iSCSI name of each initiator to be registered in the target's DD 📝
An implementation MAY decide that newly registered devices that haven't been explicitly placed into a DD by the management station get put into a "default DD" inside a "default DDS" whose initial DD Set Status value is "enabled" 🏠 That makes them visible to other devices in the default DD 👀 Other implementations MAY decide that those devices are registered with no DD at all, which makes them inaccessible to source-scoped iSNSP messages 🙅♀️
The iSNS server uses the Source Attribute of each iSNSP message to figure out who sent the request and to scope the operation to a set of Discovery Domains 🕵️♀️ The Node Type (specified in the iFCP or iSCSI Node Type bitmap field) may also help determine authorization for the requested iSNS operation 🔐 For example, only Control Nodes are authorized to create or delete discovery domains 👑
Valid and active Discovery Domains (DDs) belong to at least one active Discovery Domain Set (DDS) ✅ DDs that don't belong to an activated DDS are not enabled 🚫 The iSNS server MUST maintain the state of DD membership for all Storage Nodes, even for the ones that have been deregistered 🧠 DD membership sticks around whether or not a Storage Node is actively registered in the iSNS database 💖
2.2.3. State Change Notification Service
The State Change Notification (SCN) service lets the iSNS Server send notifications about network events that affect the operational state of Storage Nodes 📣 The iSNS client may register for notifications on behalf of its Storage Nodes, so they hear about events the iSNS Server detects 👂 SCNs tell iSNS clients about explicit or implicit changes to the iSNS database 🗃️ They don't necessarily tell you the connectivity state of peer storage devices on the network 🛜 How a storage device responds to an SCN is implementation-specific, and the policy for responding to SCNs is outside the scope of this document 🤷♀️
There are two types of SCN registrations: regular registrations and management registrations 💜 Management registrations result in management SCNs, and regular registrations result in regular SCNs 🎀 The type of registration and SCN message is shown in the SCN bitmap (see Sections 6.4.4 and 6.6.12) 🔍
A regular SCN registration means the Discovery Domain Service SHALL be used to control how SCN messages get distributed 🎯 Receiving regular SCNs is limited to the discovery domains where the SCN-triggering event happens 🚧 Regular SCNs don't contain any info about discovery domains 🙅♀️
Only Control Nodes can request a management SCN registration 👑 Management SCNs that come from management registrations are not bound by the Discovery Domain service 🌈 Authorization to request management SCN registrations may be administratively controlled 🛡️
The iSNS server SHOULD be built with enough hardware and software resources to support the expected number of iSNS clients 💪 But if resources get unexpectedly exhausted, the iSNS server MAY refuse SCN service by returning an SCN Registration Rejected (Status Code 17) ❌ That rejection might happen when the network size or the current number of SCN registrations has passed an implementation-specific threshold 📊 A client that isn't allowed to register for SCNs may decide to monitor its sessions with other storage devices directly 👀✨
The specific notification mechanism the iSNS server uses to learn about the events that trigger SCNs is implementation-specific 🛠️ It can include things like explicit notification messages from an iSNS client to the iSNS server, or a hardware interrupt to a switch-hosted iSNS server caused by a link failure ⚡🔌
2.2.4. Open Mapping between Fibre Channel and iSCSI Devices ✨
okay so the iSNS database stores naming and discovery info for BOTH Fibre Channel and iSCSI devices 🫶 which means the iSNS server can keep track of a Fibre Channel device as a proxy iSCSI device "image" out on the IP network 🦋 and an iSCSI device can get a "proxy WWN" stored under the WWNN Token field for itself. the way that it all connects is so clean 💅
and it gets even better, bestie. through iSCSI-FC gateways, Fibre Channel-aware management stations can talk to the iSNS server to pull up info about FC devices and then manage both FC and iSCSI devices with it 🔥 that means stuff like Discovery Domains and State Change Notifications can be applied seamlessly to both iSCSI and Fibre Channel devices 🌈 which is basically IP networks and FC devices and fabrics integrating with each other, iconic 👑
quick note: Fibre Channel attributes are stored as iFCP attributes, and storing this info in the iSNS server is still useful even if the iFCP protocol isn't implemented 🧚 tag 101 can hold a "Proxy iSCSI Name" for FC devices registered in the iSNS server. that field links the FC device to an iSCSI registration entry, and that entry is what the FC device uses to talk to iSCSI devices in the IP network 💜 and tag 37 (see Section 6.1) has a WWNN Token field, which can store an FC Node Name (WWNN) value that iSCSI-FC gateways use to represent an iSCSI device in the Fibre Channel domain 🎀
the main payoff: once the mapping lives in the iSNS server, ANY authorized iSNS client can go grab it and use it 😭 in lots of cases that beats storing the info inside an iSCSI-FC gateway, where the mapping is locked away from other devices except through proprietary mechanisms 💀
2.3. iSNS Usage Model 🌸
okay this part is a high-level look at how each kind of device in a storage network can use iSNS 💖 every device acts as an iSNS client, and each one has to register itself in the iSNS database before it can get into the services iSNS provides 🫶
2.3.1. iSCSI Initiator 🦋
an iSCSI initiator asks the iSNS server to find out where iSCSI target devices are and whether they're around 🔍 it can also ask for state change notifications (SCNs) so it hears about new targets that show up on the network after the first boot and discovery ✨ SCNs can also tell the initiator about targets that got removed or aren't available in the storage network anymore, so half-finished storage sessions can be ended gracefully and resources for targets that don't exist can get reallocated 🧹
2.3.2. iSCSI Target 🎀
an iSCSI target lets initiators discover it by registering its presence in the iSNS server 💅 it can also register for SCNs to find out when initiators get added or removed, which helps with resource allocation 🌈 the iSCSI target device can register for Entity Status Inquiry (ESI) messages too, and those let iSNS keep an eye on how available the target is in the storage network 👀
2.3.3. iSCSI-FC Gateway 🌉
an iSCSI-FC gateway bridges devices in a Fibre Channel network to an iSCSI/IP network 🔗 it can use the iSNS server to store FC device attributes it found in the FC name server, plus mappings of FC device identifiers to iSCSI device identifiers 🗂️ iSNS can store ALL the attributes of both iSCSI and Fibre Channel devices 🤯 iSCSI devices get managed by talking to iSNS directly, while FC devices get managed indirectly through iSNS interactions with the iSCSI-FC gateway 💜 so both kinds of devices live in one seamless management framework, slay 👑
2.3.4. iFCP Gateway 🦢
an iFCP gateway uses iSNS to act like the services a Fibre Channel name server provides, but for FC devices in its gateway region 💫 iSNS gives basic discovery and zoning configuration info that the iFCP gateway enforces 🔐 when something queries iSNS, it returns info about the N_Port network address used to set up iFCP sessions between FC devices supported by iFCP gateways 🧚
2.3.5. Management Station 👑
a management station uses iSNS to keep tabs on storage devices and to turn storage sessions on or off by configuring discovery domains 📊 usually it talks to the iSNS server as a Control Node that has access to ALL the iSNS database records and special privileges for configuring discovery domains 🔑 by manipulating discovery domains, the management station controls how much of the network iSNS clients can discover when they query the server 🎯
2.4. Administratively Controlled iSNS Settings 🔧
some important operational settings for the iSNS server get configured through administrative means, like a configuration file, a console port, SNMP, or some other implementation-specific method 🛠️ these admin-controlled settings can't be configured through the iSNS Protocol, so the iSNS server implementation MUST provide an administrative control interface for them 🚨
here's the list of parameters that are administratively controlled for the iSNS server 📝 if the administrator doesn't provide alternative settings, the default settings below MUST be used 💅
Setting Default Setting
------- ---------------
ESI Non-Response Threshold 3 (see 5.6.5.13)
Management SCNs (Control Nodes only) enabled (see 5.6.5.8)
Default DD/DDS disabled
DD/DDS Modification
- Control Node enabled
- iSCSI Target Node Type disabled
- iSCSI Initiator Node Type disabled
- iFCP Target Port Role disabled
- iFCP Initiator Port Role disabled
Authorized Control Nodes N/Ahere's what each one actually does 🧐
- ESI Non-Response Threshold: decides how many ESI messages can go out without a response before the network entity gets deregistered from the iSNS database 📉
- Management SCN for Control Node: decides whether a registered Control Node is allowed to register to receive Management SCNs 📡
- Default DD/DDS: decides whether a newly registered device that isn't explicitly placed into a discovery domain (DD) and discovery domain set (DDS) gets dropped into a default DD/DDS 🪣
- DD/DDS Modification: decides whether the specified type of Node is allowed to add, delete or update DDs and DDSs ✏️
- Authorized Control Nodes: a list of Nodes identified by iSCSI Name or FC Port Name WWPN that are authorized to register as Control Nodes 🗝️
2.5. iSNS Server Discovery 🔭
2.5.1. Service Location Protocol (SLP) 🌟
the Service Location Protocol (SLP) gives hosts a flexible and scalable framework for finding out about the existence, location, and configuration of networked services, including the iSNS server 🧭 iSNS clients can use SLP to find the IP address or FQDN of the iSNS server 💖 to set up discovery through SLP, a Service Agent (SA) should be cohosted in the iSNS server, and a User Agent (UA) should be in each iSNS client 🫶 each client multicasts a discovery message asking for the IP address of the iSNS server(s), and the SA answers that request 📣 optionally, the location of the iSNS server can also be stored in the SLP Directory Agent (DA) 📂
quick heads up: the full description and spec of SLP can be found in [RFC2608], and it's out of scope for this doc 📚 a service template for using SLP to locate iSNS servers is in [iSCSI-SLP] 🎁
2.5.2. Dynamic Host Configuration Protocol (DHCP) 🏠
the IP address of the iSNS server can be stored in a DHCP server so iSNS clients can download it using a DHCP option 📥 the DHCP option number for distributing the iSNS server location is in [iSNSOption] 🔢
2.5.3. iSNS Heartbeat Message 💓
the iSNS heartbeat message is described in Section 5.6.5.14 🫀 it lets iSNS clients inside the broadcast or multicast domain of the iSNS server find where the active iSNS server is, plus any backup servers 🔎
2.6. iSNS and Network Address Translation (NAT) 🌍
NAT is going to affect the info you get back from the iSNS server 🙈 if the iSNS client is in a different addressing domain than the iSNS server, the IP address info stored in the iSNS server might not be correct when the iSNS client reads it in its own domain 😬
there are a few ways to get iSNS working inside a NAT network 💅 the first one is to require that both targets and initiators use the canonical TCP port number when addressing targets across a NAT boundary, and for the iSNS client not to query for nominal IP addresses 🚫 instead, the iSNS client queries for the DNS Fully Qualified Domain Name stored in the Entity Identifier field when it needs addressing info 🏷️ once it has that DNS name, it can be interpreted in each address domain and mapped to the right IP address by local DNS servers 🧚
the second approach is a distributed network of iSNS servers 🌐 local iSNS servers get deployed inside and outside NAT boundaries, and each local server stores the relevant IP addresses for its own NAT domain 🗺️ updates across the network of decentralized, local iSNS servers are handled using LDAP, plus whatever NAT translation rules are implemented inside the update mechanism of each server 🔄
last but not least, an iSNS server in the private addressing domain behind a NAT boundary can exclusively support iSNS clients operating in the global IP addressing domain ✨ if that's the setup, the administrator only needs to make sure the right mappings are configured on the NAT gateways so iSNS clients can start iSNSP sessions to the iSNS server 🚪 all the registered addresses in the iSNS server are then public IP addresses for use outside the NAT boundary 🌸 and be careful: make sure there are no iSNS clients querying the server from inside the NAT boundary ⚠️
heads up bestie: this is the part where a stray query from inside the NAT boundary can mess up what the server hands out, so keep those clients on the outside 🙏
2.7. Transfer of iSNS Database Records between iSNS Servers ✨
Okay so, moving iSNS database records between iSNS servers is a big deal, and there are two main reasons it's so iconic 💅
- An independent organization needs to pass storage info over to a different organization. Each org runs its own iSNS setup, so to help the other side discover their storage assets over IP, iSNS database records can be transferred between the authoritative iSNS servers from each organization. This lets storage sessions connect directly between devices in each org's storage network over a shared IP network 🦋
- Multiple iSNS servers are wanted for redundancy 🛟 Backup servers need to keep copies of the primary server's database, which is always changing, so it's giving constant syncing energy ✨
So information in an iSNS server can be spread to other iSNS servers either through the iSNS protocol itself, or through out-of-band mechanisms that use non-iSNS protocols. The examples below show some possible ways to move data records between iSNS servers 🎀 In the first one, a back-end LDAP information base supports the iSNS server, and the data gets moved over the LDAP protocol. Once the remote device's record transfer is finished, it shows up and becomes accessible to local devices through the local iSNS server. That means local devices can set up sessions with remote devices, as long as firewall boundaries can be negotiated 🧚
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +--+---+ | WAN | +---+--+ |
|.dev C'. | | Link | | |
|........ | ============= | |
| | | | | |
| +--+---+ | | +---+--+ |
| | local|<--- <--- <--- <-|remote| |
| | LDAP | | LDAP: | | LDAP | |
| +------+ Xfer "dev C"| +------+ |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network BIn the diagram above, two business partners want to share storage "dev C" 🤝 Using LDAP, the record for "dev C" can be transferred from Network B over to Network A. Once it's accessible to the local iSNS server in Network A, local devices A and B can discover and connect to "dev C" 💖
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +------+ | WAN | +---+--+ |
|.dev C'. ^ | Link | | |
|........ | ============= v |
| | | | |SNMP |
| | | | | |
| +--+----+ | | v |
| | SNMP |<--- <--- <--- <---- |
| | Mgmt | | SNMP: Xfer "dev C" |
| |Station| | | |
| +-------+ | | |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network BThe diagram above shows a second way iSNS records can be shared 🌈 This one uses an SNMP-based management station to manually GET the record for "dev C" and then SET it directly on the local iSNS server. Once the record lands on the local iSNS server in Network A, "dev C" becomes visible and accessible to other devices in Network A (again, as long as firewall boundaries can be negotiated) 🌸
Other methods, including proprietary protocols, can also move device records between iSNS servers 💅 Digging deeper into these methods is beyond the scope of this document, so we'll leave it there 🫶
2.8. Backup iSNS Servers 🛟
This section gives a broad framework for setting up and deploying iSNS backup servers 🦋 Server failover and recovery are still topics of ongoing research, and whether issues like split brain and primary server selection get resolved well depends on the specific implementation requirements and deployment needs. The failover mechanisms discussed here focus on how iSNS clients and iSNS servers interact 💜 Specifically, this document covers the following:
- iSNS client behavior and the iSNS protocol interaction between the client and multiple iSNS servers, some of which are backup servers.
- Required failover behaviors of the collection of iSNS servers that includes active and backup servers.
However, note that this document does not specify the complete functional failover requirements of each iSNS server ⚠️ In particular, it does not specify the complete set of protocol interactions among the iSNS servers that are needed to achieve stable failover operation in an interoperable manner.
For the purposes of this discussion, the backup mechanisms specified here apply to interaction among different logical iSNS servers 🧩 It's possible to create multiple physical iSNS servers that form a single logical iSNS server cluster, which distributes iSNS transaction processing among multiple physical servers. But a more detailed discussion of how physical servers interact inside a logical iSNS server cluster is beyond the scope of this document 🙈
Multiple logical iSNS servers can provide redundancy in case the active iSNS server fails or gets removed from the network ✨ The methods described in Section 2.7 above can be used to transfer name server records to backup iSNS servers. Each backup server keeps a redundant copy of the name server database found in the primary iSNS server, and can respond to iSNS protocol messages the same way the active server does 👑 Each backup server SHOULD monitor the health and status of the active iSNS server, including checking that its own database is synchronized with the active server's database. How each backup server does this is implementation-dependent, and may (or may not) include using the iSNS protocol. If the iSNS protocol is used, then the backup server MAY register itself in the active server's iSNS database as a Control Node, which lets it receive state-change notifications 🔔
Generally, the administrator or some automated election process is responsible for the initial and later designation of the primary server and each backup server 🗳️
A maximum of one logical backup iSNS server SHALL exist at any individual IP address, so that multiple servers listening on the same canonical iSNS TCP or UDP port number don't cause conflicts 🚫
The iSNS heartbeat can also be used to coordinate the designation and selection of primary and backup iSNS servers 💓
Each backup server MUST note its relative precedence in the active server's list of backup servers. If its precedence isn't already known, each backup server MAY learn it from the iSNS heartbeat message, by noting the position of its IP address in the ordered list of backup server IP addresses 📋 For example, if it's the first backup listed in the heartbeat message, then its backup precedence is 1. If it's the third backup server listed, then its backup precedence is 3 🔢
If a backup server establishes that it has lost connectivity to the active server and to other backup servers of higher precedence, then it SHOULD assume that it is the active server 👀 The method for determining whether connectivity has been lost is implementation-specific. One possible approach is to assume that if the backup server doesn't receive iSNS heartbeat messages for a period of time, then connectivity to the active server has been lost. Alternatively, the backup server may establish TCP connections to the active server and other backup servers, with loss of connectivity determined through non-response to periodic echo or polling messages (using iSNSP, SNMP, or other protocols) 📡
When a backup server becomes the active server, it SHALL assume all active server responsibilities, including (if used) transmission of the iSNS heartbeat message 👑 If it's transmitting the iSNS heartbeat, the backup server replaces the active Server IP Address and TCP/UDP Port entries with its own IP address and TCP/UDP Port, and starts incrementing the counter field from the last known value of the previously active iSNS server. However, it MUST NOT change the original ordered list of backup server IP Address and TCP/UDP Port entries 🙅♀️ If the primary backup server or another higher-precedence backup server comes back, then the existing active server is responsible for making sure the new active server's database is up to date before it demotes itself to its original status as a backup 🔄
Since the primary and backup iSNS servers maintain a coordinated database, no re-registration by an iSNS Client is required when a backup server takes on the active server role 💖 Likewise, no re-registration by an iSNS Client is required when the previous primary server returns to the active server role 🥰
2.9. Transport Protocols 🚚
The iSNS Protocol is transport-neutral 🫶 Query and registration messages are transported over TCP or UDP. iSNS heartbeat messages are transported using IP multicast or broadcast 📣
2.9.1. Use of TCP for iSNS Communication 🌷
It MUST be possible to use TCP for iSNS communication ✨ The iSNS server MUST accept TCP connections for client registrations. To receive Entity Status Inquiry (ESI) (see Section 5.6.5.13) monitoring that uses TCP, the client registers the Portal ESI Interval and the port number of the TCP port that will be used to receive ESI messages. The iSNS server initiates the TCP connection used to deliver the ESI message. This TCP connection does not need to be continuously open 🧚
To receive SCN notifications using TCP, the client registers the iSCSI or iFCP SCN Bitmap and the port number of the TCP port in the Portal used to receive SCNs 🔔 The iSNS server initiates the TCP connection used to deliver the SCN message. This TCP connection does not need to be continuously open 💅
It's possible for an iSNS client to use the same TCP connection for SCN, ESI, and iSNS queries. Alternatively, separate connections may be used 🦋
2.9.2. Use of UDP for iSNS Communication ✨
okay so the iSNS server MAY accept UDP messages for client registrations 🫶 but it MUST accept registrations from clients asking for UDP-based ESI and SCN messages. no cap, that's the bare minimum 💅
to get UDP-based ESI monitoring messages, the client registers the port number of the UDP port in at least one Portal that'll be used to receive and respond to ESI messages from the iSNS server. if a Network Entity has multiple Portals with registered ESI UDP Ports, then ESI messages SHALL be delivered to every Portal registered to receive such messages. every single portal gets its moment 👑
same energy for UDP-based SCN notification messages. the client registers the port number of the UDP port in at least one Portal to be used to receive SCN messages from the iSNS server. if a Network Entity has multiple Portals with registered SCN UDP Ports, then SCN messages SHALL be delivered to each Portal registered to receive such messages.
when you're using UDP to transport iSNS messages, each UDP datagram MUST contain exactly one iSNS PDU (see Section 5). one datagram, one PDU, periodt 🦋
2.9.3. iSNS Multicast and Broadcast Messages 🌈
iSNS multicast messages are transported using IP multicast or broadcast. the iSNS heartbeat is the only iSNS multicast or broadcast message 🧚 it's originated by the iSNS server and sent to all iSNS clients that are listening on the IP multicast address allocated for the iSNS heartbeat.
2.10. Simple Network Management Protocol (SNMP) Requirements 🎀
okay this section is giving admin energy 🙈 The iSNS Server may be managed via the iSNS MIB [iSNSMIB] using an SNMP management framework [RFC3411]. for a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. the iSNS MIB gives you the ability to configure and monitor an iSNS server without using the iSNS protocol directly. SNMP management frameworks have several requirements for object indexing in order for objects to be accessed or added.
SNMP uses an Object Identifier (OID) for object identification. the size of each OID is restricted to a maximum of 128 sub-identifiers. both the iSCSI and iFCP protocol contain identifiers, such as the iSCSI Name, that are greater the 128 characters in length. using such identifiers as an index would result in more than 128 sub-identifiers per OID 😭 so to support objects whose key identifiers are longer than the maximum SNMP-supported length, the iSNS server provides secondary non-zero integer index identifiers. these indexes SHALL be persistent for as long as the server is active. furthermore, index values for recently deregistered objects SHOULD NOT be reused in the short term. object attributes, including indexes, are described in detail in Section 6.
for SNMP based management applications to create a new entry in a table of objects, a valid OID must be available to specify the table row. the iSNS server handles this by providing, for each type of object that can be added via SNMP, an object attribute that returns the next available non-zero integer index. this lets an SNMP client request an OID to be used for registering a new object in the server. object attributes, including next available index attributes, are described in detail in Section 6 💖
3. iSNS Object Model 🍓
iSNS provides the framework for the registration, discovery, and management of iSCSI devices and Fibre Channel-based devices (using iFCP). this architecture framework provides the elements needed to describe various storage device objects and attributes that may exist on an IP storage network. objects defined in this architecture framework include Network Entity, Portal, Storage Node, FC Device, Discovery Domain, and Discovery Domain Set. each of these objects is described in greater detail in the following sections.
3.1. Network Entity Object 🦋
the Network Entity object is a container of Storage Node objects and Portal objects. it represents the infrastructure supporting access to a unique set of one or more Storage Nodes. the Entity Identifier attribute uniquely distinguishes a Network Entity, and it's the key used to register a Network Entity object in an iSNS server. all Storage Nodes and Portals contained within a single Network Entity object operate as a cohesive unit 🫶
note that it's possible for a single physical device or gateway to be represented by more than one logical Network Entity in the iSNS database. for example, one of the Storage Nodes on a physical device may be accessible from only a subset of the network interfaces (i.e., Portals) available on that device. in this case, a logical network entity (i.e., a "shadow entity") is created and used to contain the Portals and Storage Nodes that can operate cooperatively. no object (Portals, Storage Nodes, etc.) can be contained in more than one logical Network Entity 🙅♀️
similarly, a logical Network Entity can be supported by more than one physical device or gateway. for example, multiple FC-iSCSI gateways may be used to bridge FC devices in a single Fibre Channel network. collectively, the multiple gateways can support a single logical Network Entity that is used to contain all the devices in that Fibre Channel network 🌸
3.2. Portal Object 🌷
the Portal object is an interface through which access to Storage Nodes within the Network Entity can be obtained. the IP address and TCP/UDP Port number attributes uniquely distinguish a Portal object, and combined they're the key used to register a Portal object in an iSNS server. a Portal is contained in one and only one Network Entity, and may be contained in one or more DDs (see Section 3.6) ✨
3.3. Storage Node Object 💜
the Storage Node object is the logical endpoint of an iSCSI or iFCP session. in iFCP, the session endpoint is represented by the World Wide Port Name (WWPN). in iSCSI, the session endpoint is represented by the iSCSI Name of the device. for iSCSI, the iSCSI Name attribute uniquely distinguishes a Storage Node, and it's the key used to register a Storage Node object in an iSNS Server. for iFCP, the FC Port Name (WWPN) attribute uniquely distinguishes a Storage Node, and it's the key used to register a Storage Node object in the iSNS Server. a Storage Node is contained in only one Network Entity object and may be contained in one or more DDs (see Section 3.6) 🎀
3.4. Portal Group Object 🧚
the Portal Group (PG) object represents an association between a Portal and an iSCSI Node. each Portal and iSCSI Storage Node registered in an Entity can be associated using a Portal Group (PG) object. the PG Tag (PGT), if non-NULL, indicates that the associated Portal provides access to the associated iSCSI Storage Node in the Entity. all Portals that have the same PGT value for a specific iSCSI Storage Node allow coordinated access to that node 👑
a PG object MAY be registered when a Portal or iSCSI Storage Node is registered. each Portal to iSCSI Node association is represented by one and only one PG object. in order for a Portal to provide access to an iSCSI Node, the PGT of the PG object MUST be non-NULL. if the PGT value registered for a specified Portal and iSCSI Node is NULL, or if no PGT value is registered, then the Portal does not provide access to that iSCSI Node in the Entity 🙈
the PGT value indicates whether access to an iSCSI Node can be coordinated across multiple Portals. all Portals that have the same PGT value for a specific iSCSI Node can provide coordinated access to that iSCSI Node. according to the iSCSI Specification, coordinated access to an iSCSI node indicates the capability of coordinating an iSCSI session with connections that span these Portals [iSCSI].
the PG object is uniquely distinguished by the iSCSI Name, Portal IP Address, and Portal TCP Port values of the associated Storage Node and Portal objects. these are represented in the iSNS Server by the PG iSCSI Name, PG Portal IP Address, and PG Portal TCP/UDP Port attributes, respectively. the PG object is also uniquely distinguished in the iSNS Server by the PG Index value 🦋
a new PG object can only be registered by referencing its associated iSCSI Storage Node or Portal object. a pre-existing PG object can be modified or queried by using its Portal Group Index as the message key, or by referencing its associated iSCSI Storage Node or Portal object. a 0-length Tag, Length, Value TLV is used to register a PGT NULL value 🍓
the PG object is deregistered if and only if its associated iSCSI Node and Portal objects are both removed 💀
3.5. Device Object 🌈
the FC Device represents the Fibre Channel Node. this object contains information that may be useful in the management of the Fibre Channel device. the FC Node Name (WWNN) attribute uniquely distinguishes an FC Device, and it's the key used to register an FC Device object in the iSNS Server.
the FC Device is contained in one or more Storage Node objects 💅
3.6. Discovery Domain Object 🫧
Discovery Domains (DD) are a security and management mechanism used to administer access and connectivity to storage devices. for query and registration purposes, they're considered containers for Storage Node and Portal objects. a query by an iSNS client that is not from a Control Node only returns information about objects with which it shares at least one active DD. the only exception to this rule is with Portals: if Storage Nodes of a Network Entity are registered in the DD without Portals, then all Portals of that Network Entity are implicit members of that DD. the Discovery Domain ID (DD_ID) attribute uniquely distinguishes a Discovery Domain object, and it's the key used to register a Discovery Domain object in the iSNS Server 🔥
a DD is considered active if it is a member of at least one active DD Set. DDs that are not members of at least one enabled DDS are considered disabled. a Storage Node can be a member of one or more DDs. an enabled DD establishes connectivity among the Storage Nodes in that DD 🌸
3.7. Discovery Domain Set Object 👑
the Discovery Domain Set (DDS) is a container object for Discovery Domains (DDs). DDSs may contain one or more DDs. similarly, each DD can be a member of one or more DDSs. DDSs are a mechanism to store coordinated sets of DD mappings in the iSNS server. active DDs are members of at least one active DD Set. multiple DDSs may be considered active at the same time. the Discovery Domain Set ID (DDS_ID) attribute uniquely distinguishes a Discovery Domain Set object, and it's the key used to register a Discovery Domain Set object in the iSNS Server 💖
3.8. Database Model 🗂️
Okay so, from the iSNS client's point of view, every object of a given type in the iSNS database MUST have an implicit internal linear ordering based on that object type's key(s). ✨ This ordering is what lets the server answer DevGetNext queries (see Section 5.6.5.3). Bestie, the ordering of objects in the iSNS database SHOULD NOT be changed relative to that implied ordering when objects get inserted or deleted. The relative order of the surviving object entries SHOULD be preserved, so the DevGetNext message gets generally reasonable behavior 💅
Here's a diagram of the objects we just covered and how they're connected 👀
+--------------+ +-----------+
| NETWORK |1 *| |
| ENTITY |----| PORTAL |
| | | |
+--------------+ +-----------+
|1 |1 |*
| | |
| |* |
| +----------+ |
| | PORTAL | |
| | GROUP | |
| +----------+ |
| |* |
| | |
|* |1 |*
+-----------+ +--------------+ +-----------+ +-----------+
| FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY |
| DEVICE |----| NODE |----| DOMAIN |----| DOMAIN |
| | | | | | | SET |
+-----------+ +--------------+ +-----------+ +-----------+
* represents 0 to many possible relationships4. iSNS Implementation Requirements ✨
This section is where we get into the specific requirements for supporting each of these IP storage protocols 🧚 Security implementation requirements live in Section 7, so don't skip ahead without them 🔐
4.1. iSCSI Requirements 💖
Using iSNS for iSCSI is OPTIONAL 🌸 iSCSI devices MAY be configured by hand with the iSCSI Name and IP address of their peers, no iSNS aid or intervention needed. iSCSI devices can also use SLP [RFC2608] to find peer iSCSI devices. But honestly? iSNS is super useful when you need to scale a storage network out to a whole lot more iSCSI devices 📈
4.1.1. Required Attributes for Support of iSCSI 🎀
These are the attributes that support iSCSI. Any attribute marked REQUIRED for Server MUST be implemented by an iSNS server that supports iSCSI. Any attribute marked REQUIRED for Client MUST be implemented by an iSCSI device that chooses to use iSNS. The K (Key) column marks the attributes that uniquely identify the object type in the iSNS Server. For a more detailed description of each attribute, check out Section 6 🦋
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address *
Timestamp *
Protocol Version Range *
Registration Period *
Entity Index *
Entity IKE Phase-1 Proposal
Entity Certificate
PORTAL IP Address * * *
TCP/UDP Port * * *
Portal Symbolic Name *
ESI Interval *
ESI Port *
Portal Index *
SCN Port *
Portal Security Bitmap *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
Portal Certificate
PORTAL GROUP PG iSCSI Name * * *
PG IP Address * * *
PG TCP/UDP Port * * *
PG Tag * *
PG Index *
STORAGE NODE iSCSI Name * * *
iSCSI Node Type * *
Alias *
iSCSI SCN Bitmap *
iSCSI Node Index *
WWNN Token
iSCSI AuthMethod
iSCSI Node Certificate
DISCOVERY DOMAIN DD ID * * *
DD Symbolic Name *
DD Member iSCSI Node Index *
DD Member iSCSI Name *
DD Member Portal Index *
DD Member Portal IP Addr *
DD Member Portal TCP/UDP *
DD Features *
DISCOVERY DOMAIN DDS Identifier * *
SET DDS Symbolic Name *
DDS Status *And the last bit, the user-specified and vendor-specified iSCSI attributes, are totally OPTIONAL to implement and use. No pressure, bestie 🫶
4.1.2. Examples: iSCSI Object Model Diagrams 🧜♀️
okay so this is where the object model finally gets real 🎀 the diagram below shows how a simple iSCSI-based initiator and target get stored as database objects inside the iSNS server. in this setup, each target and initiator is attached to a single Portal, so no sharing 🦋
+----------------------------------------------------------------+
| IP Network |
+------------+--------------------------------------+------------+
| |
| |
+-----+------+------+-----+ +-----+------+------+-----+
| | PORTAL | | | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | |
| | -TCP Port 1 | | | | -TCP Port 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | PORTAL GROUP| | | | PORTAL GROUP| |
| | -Prtl Tag 1 | | | | -Prtl Tag 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| +--------+ +--------+ | | +-------+ +--------+ |
| | | | | | | |
| | STORAGE NODE | | | | STORAGE NODE | |
| | -iSCSI Name | | | | -iSCSI Name | |
| | -Alias: "server1"| | | | -Alias: "disk1"| |
| | -Type: initiator | | | | -Type: target | |
| | | | | | | |
| +-------------------+ | | +------------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (FQDN): | | -Entity ID (FQDN): |
| "strg1.example.com" | | "strg2.example.net" |
| -Protocol: iSCSI | | -Protocol: iSCSI |
| | | |
+-------------------------+ +-------------------------+the object model can be stretched to describe fancier devices too 💅 like an iSCSI device with more than one storage controller, where each controller can be reached through any of several Portal interfaces, possibly using multiple Portal Groups. if one interface goes down, the storage controllers can still be reached through the alternate Portal interfaces ✨ here's what that device looks like:
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL 1 | | PORTAL 2 | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| +-------+ +----------------+ +-------------------+ +------+ |
| | | | | | | |
| +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
| | | | | | | |
| | STORAGE NODE 1 | | STORAGE NODE 2 | | STORAGE NODE 3 | |
| | -iSCSI Name 1 | | -iSCSI Name 2 | | -iSCSI Name 3 | |
| | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| |
| | -Type: target | | -Type: target | | -Type: target | |
| | | | | | | |
| +-----------------+ +-----------------+ +-----------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (FQDN): "dev1.example.com" |
| -Protocol: iSCSI |
| |
| Portal Group Object Table |
| Storage-Node Portal Portal-Group-Tag |
| 1 1 10 |
| 1 2 NULL (no access permitted) |
| 2 1 20 |
| 2 2 20 |
| 3 1 30 |
| 3 2 10 |
| |
+---------------------------------------------------------------+Storage Node 1 is reachable via Portal 1 with a PGT of 10. it doesn't have a Portal Group Tag (PGT) assigned for Portal 2, so Storage Node 1 can't be accessed via Portal 2 🙈
Storage Node 2 can be accessed via both Portal 1 and Portal 2. since it has the same PGT value on both, in this case 20, coordinated access via the Portals is available [iSCSI] 🫶
Storage Node 3 can be accessed via Portal 1 or Portal 2. however, since it has different PGT values for each Portal, in this case 10 and 30, access is not coordinated [iSCSI] 💀 PGTs are assigned within the context of a Storage Node, so the PGT value of 10 used for Storage Node 1 and Storage Node 3 are not interrelated 🌸
4.1.3. Required Commands and Response Messages for Support of iSCSI 📋
these are the iSNSP messages and responses that you'll use for iSCSI ✨ the ones marked in the REQUIRED for Server column MUST be implemented in iSNS servers used for iSCSI devices. the ones marked in the REQUIRED for Client column MUST be implemented in iSCSI devices that elect to use the iSNS server 💜
REQUIRED for:
Message Description Abbreviation Func_ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
Device Attr Reg Request DevAttrReg 0x0001 * *
Dev Attr Query Request DevAttrQry 0x0002 * *
Dev Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DevDereg 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 * *
DD Deregister DDDereg 0x000A * *
DDS Register DDSReg 0x000B * *
DDS Deregister DDSDereg 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E
RESERVED 0x000F-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFFhere are the iSNSP response messages used in support of iSCSI 🦋
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
Device Attr Register Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Dereg Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
SCN Deregister Rsp SCNDeregRsp 0x8006 *
SCN Event Rsp SCNEventRsp 0x8007 *
SCN Response SCNRsp 0x8008 *
DD Register Rsp DDRegRsp 0x8009 * *
DD Deregister Rsp DDDeregRsp 0x800A * *
DDS Register Rsp DDSRegRsp 0x800B * *
DDS Deregister Rsp DDSDeregRsp 0x800C * *
Entity Stat Inquiry Rsp ESIRsp 0x800D *
RESERVED 0x800E-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF4.2. iFCP Requirements 🌈
for iFCP, use of iSNS is REQUIRED 👑 there are no alternatives for supporting the iFCP Naming & Discovery functions, so iSNS is the only way to go 💅
4.2.1. Required Attributes for Support of iFCP ✨
okay so this table is the attribute checklist for iFCP 💅. Anything marked REQUIRED for Server MUST be implemented by the iSNS server that supports iFCP, and anything marked REQUIRED for Client MUST be supported by iFCP gateways 🫶. The K (Key) column is the one that uniquely identifies each object type in the iSNS Server 🔑. More details live in Section 6 🦋.
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address *
Timestamp *
Protocol Version Range *
Registration period
Entity Index
Entity IKE Phase-1 Proposal
Entity Certificate
PORTAL IP Address * * *
TCP/UDP Port * * *
Symbolic Name *
ESI Interval *
ESI Port *
SCN Port *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
Portal Certificate
Security Bitmap *
STORAGE NODE FC Port Name (WWPN) * * *
(FC Port) Port_ID * *
FC Port Type * *
Port Symbolic Name *
Fabric Port Name (FWWN) *
Hard Address *
Port IP Address *
Class of Service *
FC FC-4 Types *
FC FC-4 Descriptors *
FC FC-4 Features *
SCN Bitmap *
iFCP Port Role *
Permanent Port Name *
FC DEVICE FC Node Name (WWNN) * * *
(FC Node) Node Symbolic Name *
Node IP Address *
Node IPA *
Proxy iSCSI Name
DISCOVERY DOMAIN DD ID * * *
DD Symbolic Name *
DD Member FC Port Name *
DD Member Portal Index *
DD Member Portal IP Addr *
DD Member Portal TCP/UDP *
DISCOVERY DOMAIN DDS ID * *
SET DDS Symbolic Name *
DDS Status *
OTHER Switch Name
Preferred_ID
Assigned_ID
Virtual_Fabric_IDAll iFCP user-specified and vendor-specified attributes are OPTIONAL to implement and use 🌈. No pressure, bestie 💖.
4.2.2. Example: iFCP Object Model Diagram 🌸
so the iFCP protocol lets native Fibre Channel devices, or Fibre Channel fabrics hooked up to an iFCP gateway, get internetworked over IP 🌐✨.
When it's doing iFCP, the iSNS server stores Fibre Channel device attributes, iFCP gateway attributes, and Fibre Channel fabric switch attributes. Some of these might also be stored in an FC name server 🧠.
The diagram below is a gateway with a bunch of Fibre Channel devices sitting behind it 🍓. The two Portal objects are IP interfaces on the iFCP gateway, and they can be used to get to any of the three Storage Node objects behind them. Notice that the FC Device object is NOT inside the Network Entity object 👀. Still, each FC Device has a relationship with one or more Storage Node objects 💅.
+--------------------------------------------------------+
| IP Network |
+--------+-----------------+-----------------------------+
| |
+-+------+------+---+------+------+----------------------+
| | PORTAL | | PORTAL | NETWORK ENTITY |
| | -IP Addr 1 | | -IP Addr 2 | -Entity ID (FQDN): |
| | -TCP Port 1 | | -TCP Port 2 | "gtwy1.example.com" |
| +-----+ +-----+ +-----+ +-----+ -Protocol: iFCP |
| | | | | |
| +-----+ +---------------+ +----------------------+ |
| +-----+ +---------------+ +-------------+ +------+ |
| | | | | | | |
| +-----+ +-----+ +----+ +------+ +----+ +------+ |
| |STORAGE NODE | |STORAGE NODE | |STORAGE NODE | |
| | -WWPN 1 | | -WWPN 2 | | -WWPN 3 | |
| | -Port ID 1 | | -Port ID 2 | | -Port ID 3 | |
| | -FWWN 1 | | -FWWN 2 | | -FWWN 3 | |
| | -FC COS | | -FC COS | | -FC COS | |
| +------+------+ +-------+-----+ +----+--------+ |
+--------|-------------------|------------|--------------+
| | |
+------+------+ +---+------------+---+
| FC DEVICE | | FC DEVICE |
| -WWNN 1 | | -WWNN 2 |
| | | |
+-------------+ +--------------------+4.2.3. Required Commands and Response Messages for Support of iFCP 🧚
these are the iSNSP messages and responses you'll need for iFCP gateways 💜. Anything in the REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server that iFCP gateways use, and anything in the REQUIRED TO USE column MUST be supported by the iFCP gateways themselves 🔥.
REQUIRED for:
Message Description Abbreviation Func ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
Device Attr Reg Request DevAttrReg 0x0001 * *
Device Attr Query Request DevAttrQry 0x0002 * *
Device Get Next Request DevGetNext 0x0003 *
Device Dereg Request DevDereg 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 * *
DD Deregister DDDereg 0x000A * *
DDS Register DDSReg 0x000B * *
DDS Deregister DDSDereg 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E *
Reserved Reserved 0x000F-0x0010
Request FC_DOMAIN_ID RqstDomId 0x0011
Release FC_DOMAIN_ID RlseDomId 0x0012
Get FC_DOMAIN_IDs GetDomId 0x0013
RESERVED 0x0014-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFFThe following are iSNSP response messages for iFCP 🦋:
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
Device Attr Reg Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Deregister Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
SCN Deregister Rsp SCNDeregRsp 0x8006 *
SCN Event Rsp SCNEventRsp 0x8007 *
SCN Rsp SCNRsp 0x8008 *
DD Register Rsp DDRegRsp 0x8009 * *
DD Deregister Rsp DDDeregRsp 0x800A * *
DDS Register Rsp DDSRegRsp 0x800B * *
DDS Deregister Rsp DDSDeregRsp 0x800C * *
Entity Status Inquiry Rsp ESIRsp 0x800D *
NOT USED 0x800E
RESERVED 0x800F-0x8010
Request FC_DOMAIN_ID Rsp RqstDomIdRsp 0x8011
Release FC_DOMAIN_ID Rsp RlseDomIdRsp 0x8012
Get FC_DOMAIN_IDs GetDomIdRsp 0x0013
RESERVED 0x8014-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF5. iSNSP Message Format 🎀
the iSNSP message format is basically a cousin of other classic protocols like DHCP, DNS and BOOTP 👑. An iSNSP message can be sent in one or more iSNS Protocol Data Units (PDU) 💌. Each PDU is 4-byte aligned 📐. Here's the layout of an iSNSP PDU:
Byte MSb LSb
Offset 0 15 16 31
+---------------------+----------------------+
0 | iSNSP VERSION | FUNCTION ID | 4 Bytes
+---------------------+----------------------+
4 | PDU LENGTH | FLAGS | 4 Bytes
+---------------------+----------------------+
8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes
+---------------------+----------------------+
12 | |
| PDU PAYLOAD | N Bytes
| ... |
+--------------------------------------------+
12+N | AUTHENTICATION BLOCK (Multicast/Broadcast) | L Bytes
+--------------------------------------------+
Total Length = 12 + N + L5.1. iSNSP PDU Header 🩷
the iSNSP PDU header holds the iSNSP VERSION, FUNCTION ID, PDU LENGTH, FLAGS, TRANSACTION ID, and SEQUENCE ID fields, defined below 📝.
5.1.1. iSNSP Version 🌟
the iSNSP version in this document is 0x0001. All other values are RESERVED 🙈. The iSNS server MAY reject messages for iSNSP version numbers it doesn't support 🤷♀️.
5.1.2. iSNSP Function ID 🦋
the FUNCTION ID tells you what kind of iSNS message it is and which operation to run 🎯. FUNCTION_ID values with the leading bit cleared are for query, registration, and notification messages 🔍, while FUNCTION_ID values with the leading bit set are for response messages 📬.
See Section 4 under the appropriate protocol (i.e., iSCSI or iFCP) for a mapping of the FUNCTION_ID value to the iSNSP Command or Response message 🗺️. All PDUs making up one iSNSP message must have the same FUNCTION_ID value 💜.
5.1.3. iSNSP PDU Length 🎀
okay so the iSNS PDU Length tells you how many bytes the PDU PAYLOAD field is holding 📦. And the PDU Payload is where all the TLV attributes for the operation live 💖.
Response messages also carry a success/failure code ✨. One non-negotiable: the PDU Length MUST be 4-byte aligned 🫶. no exceptions, bestie.
5.1.4. iSNSP Flags 🚩
The FLAGS field is giving "here's extra info about this message" 💅. It also tells you what kind of Network Entity sent it. Here's the valid flags table:
Bit Position Enabled (1) means:
------------ -----------------
16 Sender is the iSNS client
17 Sender is the iSNS server
18 Authentication block is present
19 Replace flag (for DevAttrReg)
20 Last PDU of the iSNS message
21 First PDU of the iSNS message
22-31 RESERVED5.1.5. iSNSP Transaction ID 🦋
The TRANSACTION ID MUST be set to a unique value for each concurrently outstanding request message 💜. Replies MUST use the same TRANSACTION ID value as the associated iSNS request message 🫶. If a message gets retransmitted, the original TRANSACTION ID value MUST be used 🔁. And every PDU in an iSNSP message must have the same TRANSACTION ID value 🎀.
5.1.6. iSNSP Sequence ID 🔢
The SEQUENCE ID is unique for each PDU inside a single transaction ✨. The SEQUENCE_ID value of the first PDU sent in a given iSNS message MUST be zero (0) 🌸, and each SEQUENCE_ID value in each PDU MUST be numbered sequentially, in the order the PDUs are transmitted 📈. Also, the two-byte SEQUENCE ID allows for up to 65536 PDUs per iSNS message 🧚.
5.2. iSNSP Message Segmentation and Reassembly 🧩
iSNS messages may be carried in one or more iSNS PDUs 💖. If only one iSNS PDU carries the message, then bit 21 (First PDU) and bit 20 in the FLAGS field (Last PDU) SHALL both be set 🔥. If multiple PDUs carry the iSNS message, then bit 21 SHALL be set in the first PDU of the message, and bit 20 SHALL be set in the last PDU 🫶.
All PDUs comprising the same iSNSP message SHALL have the same FUNCTION_ID and TRANSACTION_ID values 💜. Each PDU comprising an iSNSP message SHALL have a unique SEQUENCE_ID value ✨.
5.3. iSNSP PDU Payload 🎁
The iSNSP PDU PAYLOAD is variable length and holds the attributes used for registration and query operations 🌈. The attribute data items use a format that's similar to other protocols, like DHCP [RFC2131] options 💅. Each iSNS attribute gets specified in the PDU Payload using Tag-Length-Value (TLV) data format, which looks like this:
Byte MSb LSb
Offset 0 31
+--------------------------------------------+
0 | Attribute Tag | 4 Bytes
+--------------------------------------------+
4 | Attribute Length (N) | 4 Bytes
+--------------------------------------------+
8 | |
| Attribute Value | N Bytes
| |
+--------------------------------------------+
Total Length = 8 + NAttribute Tag: a 4-byte field that identifies the attribute as defined in Section 6.1. This field contains the tag value from the indicated table. 🏷️Attribute Length: a 4-byte field that indicates the length, in bytes, of the value field to follow in the TLV. For variable-length attributes, the value field MUST contain padding bytes, if necessary, in order to achieve 4-byte alignment. A "zero-length TLV" contains only the attribute tag and length fields. 📏Attribute Value: a variable-length field containing the attribute value and padding bytes (if necessary). 🧁
The format above is what identifies each attribute in the PDU Payload 🔍. Heads up: TLV boundaries don't need to line up with PDU boundaries, so PDUs may carry one or more TLVs, or any fraction of one 🧩. The Response Status Code, which lives in response message PDU Payloads (more on it below), is not in TLV format 🙈. And PDU Payloads for messages without iSNS attributes, like the Name Service Heartbeat, don't use the TLV format either ⭐.
5.3.1. Attribute Value 4-Byte Alignment 📐
All attribute values are aligned to 4-byte boundaries 💜. For variable length attributes, if necessary, the TLV length MUST be increased to the next 4-byte boundary through padding with bytes containing zero (0) 🫧. If an attribute value gets padded, the combination of the tag and attribute value itself is used to figure out the actual value length and number of pad bytes 🕵️♀️. There's no explicit count of the pad bytes in the TLV, so you gotta work it out yourself 💀.
5.4. iSNSP Response Status Codes 🚦
Every iSNSP response message has a 4-byte Status Code field as the first field in the iSNSP PDU PAYLOAD 🎀. If the original iSNSP request was processed normally by the iSNS server, or by the iSNS client for ESI and SCN messages, then this field SHALL contain a status code of 0 (Successful) ✅. A non-zero status code means the entire iSNS client request message got rejected 😭.
Status Code Status Description
----------- -----------------
0 Successful
1 Unknown Error
2 Message Format Error
3 Invalid Registration
4 RESERVED
5 Invalid Query
6 Source Unknown
7 Source Absent
8 Source Unauthorized
9 No Such Entry
10 Version Not Supported
11 Internal Error
12 Busy
13 Option Not Understood
14 Invalid Update
15 Message (FUNCTION_ID) Not Supported
16 SCN Event Rejected
17 SCN Registration Rejected
18 Attribute Not Implemented
19 FC_DOMAIN_ID Not Available
20 FC_DOMAIN_ID Not Allocated
21 ESI Not Available
22 Invalid Deregistration
23 Registration Feature Not Supported
24 and above RESERVED5.5. Authentication for iSNS Multicast and Broadcast Messages 🔐
For iSNS multicast and broadcast messages (see Section 2.9.3), the iSNSP gives you authentication capability 🛡️. The iSNS Authentication Block is up next, and it's identical in format to the SLP authentication block [RFC2608] 👯. iSNS unicast messages SHOULD NOT include the authentication block, and instead should rely upon IPSec security mechanisms 🔒.
If a message contains an authentication block, then the "Authentication block present" bit in the iSNSP PDU header FLAGS field SHALL be enabled ✨.
If a PKI is available with an [X.509] Certificate Authority (CA), then public key authentication of the iSNS server is possible 🔑. The authentication block uses the DSA with SHA-1 algorithm, which can easily fit into a public key infrastructure 🧠.
The authentication block holds a digital signature for the multicast message 💌. The digital signature is calculated on a per-PDU basis 📦. The authentication block contains the following information:
- A time stamp, to prevent replay attacks. ⏰
- A structured authenticator containing a signature calculated over the time stamp and the message being secured. ✍️
- An indicator of the cryptographic algorithm that was used to calculate the signature. 🧮
- An indicator of the keying material and algorithm parameters, used to calculate the signature. 🗝️
The authentication block is laid out in this figure:
Byte MSb LSb
Offset 0 31
+----------------------------------+
0 | BLOCK STRUCTURE DESCRIPTOR | 4 Bytes
+----------------------------------+
4 | AUTHENTICATION BLOCK LENGTH | 4 Bytes
+----------------------------------+
8 | TIMESTAMP | 8 Bytes
+----------------------------------+
16 | SPI STRING LENGTH | 4 Bytes
+----------------------------------+
20 | SPI STRING | N Bytes
+----------------------------------+
20 + N | STRUCTURED AUTHENTICATOR | M Bytes
+----------------------------------+
Total Length = 20 + N + MBLOCK STRUCTURE DESCRIPTOR (BSD): Defines the structure and algorithm to use for the STRUCTURED AUTHENTICATOR. BSD values from0x00000000to0x00007FFFare assigned by IANA, while values0x00008000to0x00008FFFare for private use. 🏗️AUTHENTICATION BLOCK LENGTH: Defines the length of the authentication block, beginning with the BSD field and running through the last byte of the STRUCTURED AUTHENTICATOR. 📏TIMESTAMP: This is an 8-byte unsigned, fixed-point integer giving the number of seconds since 00:00:00 GMT on January 1, 1970. ⏳SPI STRING LENGTH: The length of the SPI STRING field. 🔢SPI STRING (Security Parameters Index): Index to the key and algorithm used by the message recipient to decode the STRUCTURED AUTHENTICATOR field. 🗂️STRUCTURED AUTHENTICATOR: Contains the digital signature. For the default BSD value of0x0002, this field SHALL contain the binary ASN.1 encoding of output values from the DSA with SHA-1 signature calculation, as specified in Section 2.2.2 of [RFC3279]. 💎
5.6. Registration and Query Messages ✨
okay bestie, registration and query messages are where the magic happens 🔮 The iSNSP registration and query message PDU Payloads carry a whole list of attributes, and it's laid out like this:
+----------------------------------------+
| Source Attribute (Requests Only) |
+----------------------------------------+
| Message Key Attribute[1] (if present) |
+----------------------------------------+
| Message Key Attribute[2] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| - Delimiter Attribute - |
+----------------------------------------+
| Operating Attribute[1] (if present) |
+----------------------------------------+
| Operating Attribute[2] (if present) |
+----------------------------------------+
| Operating Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+Every Source, Message Key, Delimiter, and Operating attribute gets written into the PDU Payload using the Tag-Length-Value (TLV) data format 💖 iSNS Registration and Query messages are sent by iSNS Clients to the iSNS server IP Address and well-known TCP/UDP Port. The iSNS Responses go back to the iSNS Client IP address and TCP/UDP port number that came in on the original request message 💌
5.6.1. Source Attribute
The Source Attribute is how a Storage Node introduces itself to the iSNS server 🫶 It's used for queries and other messages that need source identification, and it uniquely identifies where the message is coming from. These are the valid Source Attribute types:
Valid Source Attributes
-----------------------
iSCSI Name
FC Port Name WWPNFor a query, the Source Attribute limits the operation to the Discovery Domains the source belongs to 🌸 Special Control Nodes, which the Source Attribute identifies, can be administratively configured to run the operation on all objects in the iSNS database without being scoped to Discovery Domains. Main character energy, fr 👑
For messages that change what's in the iSNS database, the iSNS server MUST verify that the Source Attribute identifies either a Control Node or a Storage Node that is a part of the Network Entity containing the added, deleted, or modified objects 🔥 This one is a big deal, so don't skip it!
5.6.2. Message Key Attributes
Message Key attributes are how you find the matching objects in the iSNS database for query and registration messages 🔍 If a Message Key is present, it MUST be a Registration or Query Key for an object, as described in Sections 5.6.5 and 6.1. You don't need a Message Key when a query covers the entire set of objects available to the Source, or when a registration is for a brand-new Entity 🦋
iSCSI Names used in the Message Key MUST be normalized according to the stringprep template [STRINGPREP]. Entity Identifiers (EIDs) used in the Message Key MUST be normalized according to the nameprep template [NAMEPREP] 💅
5.6.3. Delimiter Attribute
The Delimiter Attribute is the divider that separates the Message Key attributes from the Operating Attributes in a PDU Payload 🎀 It has a tag value of 0 and a length value of 0. It's always 8 bytes long, a 4-byte tag field plus a 4-byte length field, and both are all zeros 🧚 If a message doesn't need a Message Key, the Delimiter Attribute comes right after the Source Attribute, no drama.
5.6.4. Operating Attributes
Operating Attributes are a list of one or more key and non-key attributes tied to the actual iSNS registration or query operation being performed 🌈
Operating Attributes include object key attributes and non-key attributes. Object key attributes uniquely identify iSNS objects 🗝️ Key attributes MUST precede the non-key attributes of each object in the Operating Attributes. The tag value tells you whether an attribute is an object key attribute (i.e., tag=1, 16&17, 32, 64, and 96) or a non-key attribute. iSCSI Names used in the Operating Attributes MUST be normalized according to the stringprep template [STRINGPREP]. Entity Identifiers (EIDs) used in the Operating Attributes MUST be normalized according to the nameprep template [NAMEPREP] 💜
The ordering of Operating Attributes matters a LOT, because it's how you figure out how objects relate to each other and who owns which non-key attributes 😭 iSNS protocol messages that break these ordering rules SHALL be rejected with the Status Code of 2 (Message Format Error). Check the message descriptions for the proper operating attribute ordering requirements 🙈
Some objects are keyed by more than one object key attribute value. For example, the Portal object is keyed by attribute tags 16 and 17. When you describe an object keyed by more than one key attribute, every object key attribute of that object MUST be listed sequentially by tag value in the message, before that object's non-key attributes and before the key attributes of the next object. A group of key attributes like this is treated as a single logical key attribute when you're identifying an object 🦋
Non-key attributes that come right after key attributes MUST be attributes of the object those key attributes reference. All non-key attributes of an object MUST be listed before the object key attributes that introduce the next object ✨
Objects MUST be listed in inheritance order, according to their containment order. Storage Node and Portal objects, along with their respective attributes, MUST follow the Network Entity object they relate to. Similarly, FC Device objects MUST follow the Storage Node object they relate to 🌸
Vendor-specific objects defined by tag values in the range 1537-2048 have the same requirements described above 🧁
5.6.4.1. Operating Attributes for Query and Get Next Requests
In Query and Get Next request messages, TLV attributes with a length value of 0 are used to indicate which Operating Attributes should come back in the matching response 💫 Operating Attribute values that match the TLV attributes in the original message are returned in the response message.
5.6.5. Registration and Query Request Message Types
Here's the rundown on each query and message type 💖 Let's go!
5.6.5.1. Device Attribute Registration Request (DevAttrReg) ✨
okay bestie, the DevAttrReg message type is 0x0001 💖 and it's the one you use to update existing objects or register brand-new ones 🎀. The replace bit in the FLAGs field decides whether DevAttrReg updates an existing registration or fully replaces it 🦋.
The Source Attribute tells everyone which Node is starting the registration request 🫶.
The Message Key is how the message finds its target object 🔑. It MUST contain the key attribute(s) that identify an object 💅. That object MUST also carry every attribute, plus the attributes of its related subordinate objects, that will show up in the Operating Attributes of the DevAttrReg PDU Payload ✨. And the key attribute(s) identifying that object MUST be listed among the Operating Attributes too 🌸. (Yes, the key has to appear twice. It's giving redundancy 😭.)
Now let's talk about the outcomes, because this part is so cute 🧚.
- If the Message Key contains an EID and no pre-existing objects match it, the DevAttrReg message SHALL create a new Entity with that EID, plus any new objects the Operating Attributes specify 🌈. The replace bit SHALL be ignored 🙈.
- If the Message Key does not contain an EID and no pre-existing objects match it, the DevAttrReg message SHALL be rejected with a status code of
3(Invalid Registration) 💀. - If the Message Key is not present at all, DevAttrReg implicitly registers a new Network Entity ✨. In this case the replace bit SHALL be ignored, and a new Network Entity SHALL be created 🍓. Existing entities, their objects, and their relationships stay unchanged 🫶.
The replace bit is the decider for what happens to the object named in the Message Key 👑. It only applies to DevAttrReg, and it gets ignored for every other message type 🙅♀️. (Main character energy, but only for this one message 💜.)
- Replace bit set: the objects, attributes, and relationships in the Operating Attributes SHALL replace the object named by the Message Key 🔥. The object and all of its subordinate objects SHALL be deregistered, and the iSNS server SHALL send the appropriate SCNs for the deregistered objects 😭. Then the objects listed in the Operating Attributes get used to replace the just-deregistered ones 🦋. Extra SCNs SHALL also be sent for the newly-registered objects, if appropriate ✨. Anything that isn't identified, or that's subordinate to the Message Key object, MUST NOT be affected or changed 🛡️.
- Replace bit not set: the message just updates the attributes of the object named by the Message Key and its subordinate objects 🌷. Existing object containment relationships MUST NOT be changed 🚫. For existing objects, key attributes MUST NOT be modified, but new subordinate objects MAY be added 🌸.
The Operating Attributes are the objects, attributes, and relationships you want registered 🎀. You're allowed to register multiple related objects and attributes in one DevAttrReg message, since MAY means it's optional but totally allowed 💖. The order of objects in the message tells the server how they're structured and how they connect 🧩.
Some ordering rules, because the vibe is strict here:
- At least one object MUST be listed in the Operating Attributes 🌟.
- Any additional objects (if there are any) MUST be subordinate to the first object listed 🪆.
- Key attributes MUST come before non-key attributes for each object 🔑.
- A given object may only appear a maximum of once in the Operating Attributes of a message ☝️.
- If the Node named in the Source Attribute is not a Control Node, the objects in the Operating Attributes MUST be members of the same Network Entity as the Source Node 🏠.
Here's an example, because examples are everything 🥰. To link a Network Entity object to its Portal and Storage Node objects, you list the key and non-key attributes of the Network Entity first. After that, you list the key and non-key attributes of each Portal and Storage Node you want linked to it 💜. Same idea for an FC Device object: if it follows a Storage Node object, it's considered subordinate to that Storage Node ✨.
PG objects get some love too 💅. New PG objects are registered whenever an associated Portal or iSCSI Node object gets registered 🌈. You also MAY explicitly register a PG object right after a Portal or iSCSI Node object in a DevAttrReg message 🎀.
For Portals, the Portal attributes MAY be immediately followed by a PGT attribute 🦋. The PGT attribute SHALL then be followed by the set of PG iSCSI Names that represent the nodes that will be associated with the Portal using that PGT value 🫶. You MAY add more sets of PGTs and PG iSCSI Names to associate with the registered Portal after that 🌸. The PGT values get assigned to the PG object tied to the newly registered Portal, and to the iSCSI Storage Node(s) referenced right after the PGT attribute in the Operating Attributes 🧚.
For iSCSI Storage Nodes, it works the same way with a twist 💖. The Storage Node attributes MAY be immediately followed by a PGT attribute 🍓. The PGT attribute SHALL then be followed by the set of PG Portal IP-Address and PG TCP/UDP Port pairs that represent the Portal objects to be associated with the Storage Node using that PGT value ✨. More sets of PGTs and PG Portal IP-Address PG TCP/UDP Port pairs MAY follow to be associated with the registered Storage Node 🌷. The PGT values get assigned to the PG object tied to the newly registered iSCSI Storage Node and the Portal object(s) referenced right after the PGT attribute 🎀.
Now the PGT defaults, which are very specific, so pay attention 🙈.
- If the PGT value isn't included in the Storage Node or Portal object registration, and no PGT value was previously registered for that relationship, the PGT for the matching PG object SHALL be registered with a value of
0x00000001🔢. - If the PGT attribute is included in the registration message as a 0-length TLV, the PGT value for the matching PG object SHALL be registered as NULL 🫥.
- A 0-length TLV for the PGT in an update registration message overwrites the previous PGT value with NULL 💀. That signals there's no relationship between the Storage Node and Portal anymore 💔.
Quick limits, because the server has boundaries too 🚧. A maximum of one Network Entity object can be created or updated with a single DevAttrReg message 🏰. That means the Operating Attributes MUST NOT contain more than one Network Entity object 🙅♀️. There's no cap on how many Portal, Storage Node, and FC Device objects you can list, as long as they're all subordinate to the listed Network Entity object 🌈.
EIDs are their own whole saga 🦋. If the Message Key and Operating Attributes don't include an EID attribute, or the EID attribute has a length of 0, then a new Network Entity object SHALL be created and the iSNS server SHALL supply a unique EID value for it ✨. That assigned EID value SHALL be included in the DevAttrReg Response message 💌. If the Message Key and Operating Attributes contain an EID that doesn't match any existing Network Entity in the iSNS database, a new Network Entity SHALL be created and assigned the value in that EID attribute 🌱. And if they contain an EID that matches an existing object in the iSNS database, then the objects, attributes, and relationships in the Operating Attributes SHALL be appended to the existing Network Entity identified by that EID 🫶.
Last but not least, the rules for creating a new Network Entity 🎀. A registration message that creates a new Network Entity object MUST contain at least one Portal or one Storage Node 🌟. If it doesn't, the message SHALL be considered invalid and get a response with Status Code 3 (Invalid Registration) 😭.
If an iSNS Server doesn't support a registration feature, like explicit PG object registration, the server SHALL return a Status Code of 23 (Registration Feature Not Supported) 🙈.
Finally, a little heads-up 👑. The iSNS server may modify or reject the registration of certain attributes, like ESI Interval 🫣. It may also assign values for extra Operating Attributes that weren't explicitly registered in the original DevAttrReg message, like the EID and WWNN Token 🧚. So the server gets some say in the final result, and that's just how it be sometimes 💅✨.
5.6.5.2. Device Attribute Query Request (DevAttrQry) 🔥
okay bestie, the DevAttrQry message type is 0x0002 💖 and it's how an iSNS client asks the iSNS server for object attributes. it's literally the "tell me about this stuff" message ✨
The Source Attribute tells the server which Node is doing the asking 🫶. If the asker is a non-Control Node, the query is scoped to the Discovery Domains it belongs to, so it only gets to see its own DD crew 💅. The DevAttrQry message SHALL only return information on Storage Nodes and their related parent and subordinate objects, where the Storage Node has a common Discovery Domain with the Node identified in the Source Attribute. no sneaking into other people's DDs 🙈
The Message Key may contain key or non-key attributes, or no attributes at all 🧚. If you use more than one attribute as the Message Key, they MUST all come from the same object type. for example, IP address and TCP/UDP Port are both attributes of the Portal object type 🌸. A Message Key with non-key attributes may match multiple instances of that object type. A Message Key with zero-length TLV(s) is scoped to every object of the type those TLV(s) indicate. and an empty Message Key field means the query is scoped to the entire database the source Node can access 👑
The DevAttrQry response returns attributes of objects listed in the Operating Attributes that relate to the Message Key of the original DevAttrQry message 🦋. The Operating Attributes of a DevAttrQry message contain zero-length TLVs that name the attributes to be sent back in the DevAttrQryRsp message. a Message Key containing zero-length TLVs means the set of attributes listed in the Operating Attributes gets returned for each object matching the type the Message Key indicates ✨
If the Message Key contains non-zero-length TLVs, then Operating Attributes for the object matching the Message Key SHALL be returned in the DevAttrQryRsp message 💜. Each attribute type (that is, each zero-length TLV) in the Operating Attributes names an attribute to return, either from the object matching the Message Key or from other objects in the same Entity that have a relationship with that object. The ordering of the object keys and associated attributes returned in the DevAttrQry response message SHALL be the same as in the original query message. If no objects match the Message Key, then the DevAttrQryRsp message SHALL NOT return any operating attributes. Such a message and its corresponding response SHALL NOT be considered an error 🙌
The Portal Group object decides whether a relationship exists between a given Storage Node and a Portal object 🌈. If the PGT of the Portal Group is not NULL, a relationship exists between the indicated Storage Node and Portal. if the PGT is NULL, no relationship exists. so the value of the PGT attribute (NULL or not NULL) on each Portal Group object controls the structure and ordering of the DevAttrQry response to a query for Storage Nodes and Portals 💅
For example, an iSNS database contains a Network Entity with two Portals and two Nodes 🍓. Each Storage Node has two Portal Groups: one with a NULL PGT value for one Portal, and another with a non-NULL PGT value for the other Portal. The DevAttrQry message has a Message Key entry matching one of the Nodes, and Operating Attributes with zero-length TLVs listing the Node attributes first, then the Portal attributes, and then the PG attributes. The response message SHALL therefore return first the matching Node object, then the requested attributes of the one Portal object that can be used to access that Storage Node (as indicated by the PGT), and finally the requested attributes of the PG object used to access that Storage Node. The order in which each object's attributes are listed matches the order of that object's attributes in the Operating Attributes of the original request message 🎀
If the Message Key Attribute contains zero-length TLV(s), then the query returns the requested attributes for all objects matching the Message Key type (DD restrictions SHALL apply for non-Control Nodes) 🫧. If multiple objects match the Message Key type, then the attributes for each matching object MUST be listed before the attributes for the next matching object are listed in the query response. in other words, the process above must be repeated in the response for each object matching the type specified by the zero-length TLV(s) 🔁
For example, an iSNS database contains only one Network Entity with two Portals and three Nodes. All PG objects in the Entity have a PGT value of 0x00000001. In the DevAttrQry message, the Message Key contains a zero-length TLV specifying a Node type, and the Operating Attributes list the Node attributes first, then the Portal attributes. The response will return, in this order, the attributes for the first, next, and last Node objects, with each Node followed by the attributes of both Portals 🦋. If that same DevAttrQry message had instead contained a zero-length TLV specifying the Network Entity type, the response would return the attributes of all three Node objects first, followed by the attributes of the two Portals 💖
If there is no Message Key Attribute, then the query returns all attributes in the iSNS database (once again, DD restrictions SHALL apply for non-Control Nodes) 🌸. All attributes matching the type specified by each zero-length TLV in the Operating Attributes SHALL be listed. All attributes of each type SHALL be listed before the attributes matching the next zero-length TLV are listed ✨
For example, an iSNS database contains two Entities, each with two Nodes and two Portals. The DevAttrQry message has no Message Key attribute, and its Operating Attributes list the Portal attributes first, then the Node attributes. The response's Operating Attributes will return attributes from each of the four Portals, followed by attributes from each of the four Nodes 🧚
If a DevAttrQry message requests an attribute for which the iSNS server has no value, the server SHALL NOT return the requested attribute in the query response. Such query and response messages SHALL NOT be considered errors 🙃
Registration and query messages for iSNS server-specific attributes (that is, tags in the range 132 to 384) SHALL be formatted using the identifying key attribute of the Storage Node that originates the query (iSCSI Name or FC Port Name WWPN) for both the Source Attribute and the Message Key attribute. The Operating Attributes SHALL include the TLV of the server-specific attribute being requested 🔑
DD membership can be discovered through the DevAttrQry message in two ways 🍭. You can include either the DD member attributes (DD Member iSCSI Index, DD Member iSCSI Node, DD Member iFCP Node, DD Member Portal Index, DD Member Portal IP Addr, and DD Member Portal TCP/UDP), or the object key of the Storage Node or Portal (iSCSI Name, iSCSI Index, Portal IP Addr, Portal TCP/UDP Port, and Portal Index) in the Operating Attributes. Using DD member attributes SHALL return both registered and unregistered member Storage Nodes and/or Portals of a DD. DevAttrQry messages that use the Storage Node and/or Portal object key SHALL return only member Storage Nodes or Portals that are currently registered in the iSNS database 💜
The DevAttrQry message SHALL support the following minimum set of Message Key Attributes 🌈:
Valid Message Key Attributes for Queries
----------------------------------------
Entity Identifier
Entity Protocol
Portal IP-Address & Portal TCP/UDP Port
Portal Index
iSCSI Node Type
iSCSI Name
iSCSI Index
PG Index
FC Port Name WWPN
FC Port Type
FC-4 Type
Discovery Domain ID
Discovery Domain Set ID
Source Attribute (for server-specific attributes)
Switch Name (FC Device WWNN--for Virtual_Fabric_ID queries)5.6.5.3. Device Get Next Request (DevGetNext) 🦋
the DevGetNext message type is 0x0003 🌷 and it lets the iSNS client retrieve each and every instance of an object type exactly once. no repeats, no misses, very organized 💅
The Source Attribute identifies the Node that starts the DevGetNext request 🫶. It's also used to scope the retrieval process to the Discovery Domains that the initiating Node belongs to.
The Message Key Attribute may be an Entity Identifier (EID), iSCSI Name, iSCSI Index, Portal IP Address and TCP/UDP Port, Portal Index, PG Index, FC Node Name WWNN, or FC Port Name WWPN ✨. If the TLV length of the Message Key Attribute(s) is zero, then the first object entry in the iSNS database that matches the Message Key type SHALL be returned in the Message Key of the corresponding DevGetNextRsp message. If the Message Key contains non-zero-length TLV attributes, then the DevGetNext response message SHALL return the next object stored after the object identified by the Message Key in the original DevGetNext request message 🧚
If the Message Key provided matches the last object instance in the iSNS database, then the Status Code of 9 (No Such Entry) SHALL be returned in the response 🙈
The Operating Attributes can be used to set the scope of the DevGetNext request, and to specify which attributes of the next object are returned in the DevGetNext response message 🍓. All Operating Attributes MUST be attributes of the object type identified by the Message Key. for example, if the Message Key is an Entity_ID attribute, then the Operating Attributes MUST NOT contain attributes of Portals 🚫
Non-zero-length TLV attributes in the Operating Attributes are used to scope the DevGetNext message. Only the next object whose attribute values match the non-zero-length TLV attributes SHALL be returned in the DevGetNext response message 🎯
Zero-length TLV attributes MUST be listed after the non-zero-length attributes in the Operating Attributes of the DevGetNext request message 💜. Zero-length TLV attributes specify the attributes of the next object that are to be returned in the DevGetNext response message.
Note that there are no specific requirements about the order in which object entries are retrieved from the iSNS database 🌀. The retrieval order of object entries using the DevGetNext message is implementation specific, so don't count on any particular order 🤷♀️
The iSNS client is responsible for making sure that information gathered through the DevGetNext message is accurate and up-to-date 📝. There is no assurance that the iSNS database won't change between successive DevGetNext request messages. If the Message Key provided does not match an existing database entry, then the attributes for the next object key following the provided Message Key SHALL be returned 🌊. For example, an object entry may have been deleted between successive DevGetNext messages, which can produce a DevGetNext request whose Message Key doesn't match any existing object entry. In this case, the attributes for the next object stored in the iSNS database are returned 💖
5.6.5.4. Device Deregister Request (DevDereg) 🧹
The DevDereg message type is 0x0004. This is the "okay bye, delete me from the database" message 💅 It removes object entries from the iSNS database, and one DevDereg message can remove more than one object at a time ✨ Heads up: deregistered Storage Node objects keep their membership in their Discovery Domain(s) until someone explicitly deregisters the membership(s) or the Discovery Domain(s) 👀
When the iSNS server gets a DevDereg, it removes every object named by the Operating Attribute(s), plus any subordinate objects that only depend on those identified objects 🫧 For example, removing a Network Entity also removes all the Portal, Portal Group, Storage Node, and FC Device objects associated with that Network Entity 💀 FC Device objects SHALL not be deregistered this way unless all the Storage Nodes associated with them have already been deregistered 🙅♀️
The DevDereg request PDU Payload has a Source Attribute and Operating Attribute(s), but no Message Key Attributes 🎀 If the Node identified by the Source Attribute is not a Control Node, it MUST be from the same Network Entity as the object(s) identified for removal by the Operating Attribute(s) 🔒 Here are the valid Operating Attributes:
Valid Operating Attributes for DevDereg
---------------------------------------
Entity Identifier
Portal IP-Address & Portal TCP/UDP Port
Portal Index
iSCSI Name
iSCSI Index
FC Port Name WWPN
FC Node Name WWNNRemoving an object may trigger SCN messages to the appropriate iSNS clients 🔔 Trying to deregister entries that don't exist SHALL not be considered an error 🙈
If all the Nodes and Portals associated with a Network Entity are deregistered, the Network Entity SHALL also be removed 🌫️
If both the Portal and iSCSI Storage Node objects associated with a Portal Group object are removed, that Portal Group object SHALL also be removed 🌸 The Portal Group object SHALL remain registered as long as either its associated Portal or iSCSI Storage Node object is still registered 🧚 And if a deleted Storage Node or Portal gets re-registered later, the relationship between the re-registered object and an existing Portal or Storage Node object registration (indicated by the PG object) SHALL be restored 🦋
5.6.5.5. SCN Register Request (SCNReg) 📣
The SCNReg message type is 0x0005. The State Change Notification Registration Request (SCNReg) message lets an iSNS client register a Storage Node so it can receive State Change Notification (SCN) messages 🔔
The SCN tells the Storage Node about changes to any Storage Nodes inside any DD it's a member of 🏠 If the Storage Node is a Control Node, it SHALL receive SCN notifications for changes across the entire network 👑 Note that SCNReg sets the SCN Bitmap field, while the DevAttrReg message registers the UDP or TCP Port each Portal uses to receive SCN messages 🎯 If none of the Storage Node's Portals have an SCN Port field registered to receive SCN messages, the SCNReg message SHALL be rejected with Status Code 17 (SCN Registration Rejected) 💔
The SCNReg request PDU Payload has a Source Attribute, a Message Key Attribute, and an Operating Attribute 🎀 Valid Message Key Attributes for a SCNReg are shown below:
Valid Message Key Attributes for SCNReg
---------------------------------------
iSCSI Name
FC Port Name WWPNThe node whose iSCSI Name or FC Port Name WWPN matches the Message Key in the SCNReg message gets registered to receive SCNs using the specified SCN bitmap 🎯 A maximum of one Node SHALL be registered for each SCNReg message 🙅♀️
The SCN Bitmap is the only operating attribute in this message, and it always overwrites the previous contents of that field in the iSNS database ✨ The bitmap shows which SCN event types the Node is signing up for 📋
The bitmap settings also decide whether the registration is for regular SCNs or management SCNs 🧐 Control Nodes MAY conduct registrations for management SCNs, but iSNS clients that don't support Control Nodes MUST NOT conduct registrations for management SCNs 🚫 Control Nodes that register for management SCNs get a copy of every SCN message the iSNS server generates 📬 It is recommended that management registrations be used only when needed, so you don't waste iSNS server resources 💅 And a Control Node doing this should be ready for the anticipated volume of SCN message traffic 🌊
5.6.5.6. SCN Deregister Request (SCNDereg) 🛑
The SCNDereg message type is 0x0006. The SCNDereg message lets an iSNS client stop receiving State Change Notification (SCN) messages 🙌
The SCNDereg request message PDU Payload has a Source Attribute and Message Key Attribute(s) 🎀 Valid Message Key Attributes for a SCNDereg are shown below:
Valid Message Key Attributes for SCNDereg
-----------------------------------------
iSCSI Name
FC Port Name WWPNThe node with an iSCSI Name or FC Port Name WWPN attribute that matches the Message Key Attributes in the SCNDereg message is deregistered for SCNs 👋 Its SCN bitmap field gets cleared 🧹 A maximum of one Node SHALL be deregistered for each SCNDereg message 🚫
There are no Operating Attributes in the SCNDereg message 🫶
5.6.5.7. SCN Event (SCNEvent) ⚡
The SCNEvent message type is 0x0007. The SCNEvent is a message an iSNS client sends to ask the iSNS server to generate a State Change Notification (SCN) message 🔥 The SCN, sent by the iSNS server, then notifies iFCP, iSCSI, and Control Nodes within the affected DD about the change indicated in the SCNEvent 🧚
Most SCNs are generated automatically by the iSNS server when Nodes are registered or deregistered from the directory database 🪄 SCNs also show up when a network management application or Control Node changes DD membership in the iSNS server 💜 But an iSNS client can trigger an SCN itself by using SCNEvent ✨
The SCNEvent message PDU Payload has a Source Attribute, a Message Key Attribute, and an Operating Attribute 🎀 Valid Key Attributes for a SCNEvent are shown below:
Valid Message Key Attributes for SCNEvent
-----------------------------------------
iSCSI Name
FC Port Name WWPNThe Operating Attributes section SHALL contain the SCN Event Bitmap attribute 🎯 The bitmap shows the event that caused the SCNEvent to be generated 💖
5.6.5.8. State Change Notification (SCN) 💌
The SCN message type is 0x0008. The SCN is a message the iSNS server generates to notify a registered Storage Node of changes 📨 There are two types of SCN registrations: regular and management 🌈 Regular SCNs tell iSNS clients about events within the discovery domain 🏠 Management SCNs tell Control Nodes that registered for them about events happening anywhere in the network 🌍
If there's no active TCP connection to the SCN recipient, the SCN message SHALL be sent to one Portal of the registered Storage Node that has a registered TCP or UDP Port value in the SCN Port field 📮 If more than one Portal of the Storage Node has a registered SCN Port value, the SCN SHALL be delivered to any one of the indicated Portals, provided that the selected Portal is not the subject of the SCN 🫧
The types of events that can trigger an SCN message, and how much information the SCN message contains, depend on the registered SCN Event Bitmap for the Storage Node 🧠 The iSCSI Node SCN Bitmap is described in Section 6.4.4. The iFCP SCN Bitmap is described in Section 6.6.12. 📖
The format of the SCN PDU Payload is shown below:
+----------------------------------------+
| Destination Attribute |
+----------------------------------------+
| Timestamp |
+----------------------------------------+
| Source SCN Bitmap 1 |
+----------------------------------------+
| Source Attribute [1] |
+----------------------------------------+
| Source Attribute [2](if present) |
+----------------------------------------+
| Source Attribute [3](if present) |
+----------------------------------------+
| Source Attribute [n](if present) |
+----------------------------------------+
| Source SCN Bitmap 2 (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+All PDU Payload attributes are in TLV format 🧩
The Destination Attribute is the Node identifier that's receiving the SCN 📬 It can be an iSCSI Name or FC Port Name.
The Timestamp field, using the Timestamp TLV format described in Section 6.2.4, shows when the SCN was generated ⏰
The Source SCN Bitmap field shows the type of SCN notification (regular or management) and the type of event that caused the SCN to be generated 🔍 It doesn't necessarily match the original SCN bitmap registered in the iSNS server 🙃
Following the timestamp, the SCN message SHALL list the SCN bitmap, followed by the key attribute (iSCSI Name or FC Port Name) of the Storage Node affected by the SCN event 🎯 If the SCN is a Management SCN, the SCN message SHALL also list the DD_ID and/or DDS_ID of the Discovery Domains and Discovery Domain Sets (if any) that caused the change in state for that Storage Node 🌷 These additional attributes (i.e., DD_ID and/or DDS_ID) shall immediately follow the iSCSI Name or FC Port Name and precede the next SCN bitmap for the next notification message (if any) 🧁 The SCN bitmap works as a delineator for SCN messages that provide multiple state change notifications ✂️
For example, a regular SCN notifying an iSNS client of a new Portal available for a particular iSCSI target would contain the SCN bitmap, followed by the iSCSI Name of the target device as the source attribute 🎯 If the SCN were a management SCN, the iSCSI Name would be followed by the DD_ID(s) of the shared Discovery Domains that let the destination Storage Node see the affected Storage Node 👀 If a Discovery Domain Set (DDS) was enabled to provide that visibility, the appropriate DDS_ID would be included as well 🫶
A management SCN is also generated to notify a Control Node of the creation, deletion, or modification of a Discovery Domain or Discovery Domain Set 🛠️ In this case, the DD_ID and/or DDS_ID of the affected Discovery Domain and/or Discovery Domain Set would follow the SCN bitmap 💅
For example, a management SCN notifying a Control Node of a new DD within a Discovery Domain Set would contain both the DD_ID and the DDS_ID of the affected Discovery Domain and Discovery Domain Set among the Source Attributes 🌟
See Sections 6.4.4 and 6.6.12 for additional information on the SCN Bitmap 📚
5.6.5.9. DD Register (DDReg) 🎀
okay so the DDReg message type is 0x0009 🫶 and bestie, this one is the message that makes a brand new Discovery Domain (DD), updates an existing DD Symbolic Name and/or DD Features attribute, and adds DD members. 💅 DDs are uniquely defined using DD_IDs, and the DD registration attributes are in Section 6.11 if you want the deets ✨
The DDReg message PDU Payload carries the Source Attribute, plus optional Message Key and Operating Attributes. 🍓
The Message Key (if you use one) holds the DD_ID of the Discovery Domain you're registering. If that DD_ID already belongs to a DD entry in the iSNS database, the DDReg message SHALL attempt to update that existing entry 🔥 But if the DD_ID in the Message Key doesn't match any existing DD entry, the iSNS server SHALL reject the DDReg message with a status code of 3 (Invalid Registration) 💀 And if the DD_ID shows up in both the Message Key and the Operating Attributes, the DD_ID value in the Message Key MUST be the same as the DD_ID value in the Operating Attributes. no exceptions, it's giving consistency 🙈
A DDReg message with no Message Key SHALL result in the attempted creation of a new Discovery Domain (DD). If the DD_ID attribute (with non-zero length) is in the Operating Attributes, the new DD SHALL be assigned the value in that DD_ID attribute ✨ Otherwise, if the DD_ID attribute isn't in the Operating Attributes, or if the DD_ID is an operating attribute with a TLV length of 0, the iSNS server SHALL assign a DD_ID value 🧚 That assigned DD_ID then gets sent back in the DDReg Response message. The Operating Attributes can also carry the DD Member iSCSI Node Index, DD Member iSCSI Name, DD Member FC Port Name, DD Member Portal IP Address, DD Member Portal TCP/UDP Port Number, or DD Member Portal Index for members you want to add to the DD. They may also include the DD_Symbolic_Name and/or DD_Features of the DD. 💖
This message SHALL add any DD members listed as Operating Attributes to the Discovery Domain named by the DD_ID 🌈 If the DD_Features attribute is an Operating Attribute, it SHALL be stored in the iSNS server as the feature list for that DD. If the DD_Symbolic_Name is an operating attribute and its value is unique (meaning it doesn't match the registered DD_Symbolic_Name for another DD), the value SHALL be stored in the iSNS database as the DD_Symbolic_Name for that Discovery Domain. But if the value isn't unique, the iSNS server SHALL reject the attempted DD registration with a status code of 3 (Invalid Registration) 😭
When creating a new DD, if the DD_Symbolic_Name isn't in the Operating Attributes, or it's there with a zero-length TLV, the iSNS server SHALL provide a unique DD_Symbolic_Name value for the new DD ✨ That assigned DD_Symbolic_Name SHALL be returned in the DDRegRsp message. 🦋
Also when creating a new DD, if the DD_Features attribute isn't in the Operating Attributes, the iSNS server SHALL assign the default value. The default value for DD_Features is 0. simple and iconic 👑
DD Member iSCSI Name, DD Member iFCP Node, DD Member Portal IP Address, and DD Member TCP/UDP Port Number attributes in the Operating Attributes don't have to match entries that already exist in the iSNS database. this is lowkey so useful, because it means a Storage Node can get added to a DD even if it isn't registered in the iSNS database yet 🫶 A Storage Node or Portal can be added to a DD right when the DD gets created, even if it isn't active in the storage network at the moment 🌸
If the Operating Attributes have a DD Member iSCSI Name for a Storage Node that isn't currently registered in the iSNS database, the iSNS server MUST allocate an unused iSCSI Node Index for that Storage Node 🔥 The assigned iSCSI Node Index SHALL be returned in the DDRegRsp message as the DD Member iSCSI Node Index. And the allocated iSCSI Node Index value SHALL be assigned to the Storage Node if and when it registers in the iSNS database. 🧚
If the Operating Attributes have a DD Member Portal IP Addr and DD Member Portal TCP/UDP value for a Portal that isn't currently registered in the iSNS database, the iSNS server MUST allocate an unused Portal Index value for that Portal. The assigned Portal Index value SHALL be returned in the DDRegRsp message as the DD Member Portal Index. And the allocated Portal Index value SHALL be assigned to the Portal if and when it registers in the iSNS database. 💜
Here's the strict part, so pay attention 👀 DD Member iSCSI Node Index and DD Member Portal Index attributes that show up in the Operating Attributes MUST match a corresponding iSCSI Node Index or Portal Index of an existing Storage Node or Portal entry in the iSNS database. And the DD Member iSCSI Node Index and DD Member Portal Index SHALL NOT be used to add Storage Nodes or Portals to a DD unless those Storage Nodes or Portals are actively registered in the iSNS database. not me being strict, it's just the rule 💅
5.6.5.10. DD Deregister (DDDereg) 🦋
The DDDereg message type is 0x000A. This message lets an iSNS client deregister an existing Discovery Domain (DD) and remove members from an existing DD ✨
DDs are uniquely identified using DD_IDs, and the DD registration attributes are in Section 6.11 🌈
The DDDereg message PDU Payload contains a Source Attribute, a Message Key Attribute, and optional Operating Attributes. 🍓
The Message Key Attribute for a DDDereg message is the DD ID of the Discovery Domain being removed or having members removed. If the DD ID matches an existing DD and there are no Operating Attributes, the DD SHALL be removed and a success Status Code returned. Any existing members of that DD SHALL remain in the iSNS database without membership in the just-removed DD 🧚
If the DD ID matches an existing DD and there are Operating Attributes matching DD members, the DD members identified by the Operating Attributes SHALL be removed from the DD, and a successful Status Code returned 💖
If a DD Member iSCSI Name in the Operating Attributes contains an iSCSI Name for a Storage Node that isn't currently registered in the iSNS database or contained in another DD, then the association between that Storage Node and its pre-assigned iSCSI Node Index SHALL be removed. The pre-assigned iSCSI Node Index value no longer links to a specific iSCSI Name, so it can be re-assigned now 🔥
If a DD Member Portal IP Address and DD Member TCP/UDP Port identified in the Operating Attributes reference a Portal that isn't currently registered in the iSNS database or contained in another DD, then the association between that Portal and its pre-assigned Portal Index SHALL be removed. The pre-assigned Portal Index value can now be reassigned ✨
The attempted deregistration of non-existent DD entries SHALL not be considered an error. no drama, it's fine 🌸
5.6.5.11. DDS Register (DDSReg) 💜
The DDSReg message type is 0x000B. This message lets an iSNS client create a new Discovery Domain Set (DDS), update an existing DDS Symbolic Name and/or DDS Status, or add DDS members 🫶
DDSs are uniquely defined using DDS_IDs, and the DDS registration attributes are in Section 6.11.1 🎀
The DDSReg message PDU Payload contains the Source Attribute and, optionally, a Message Key and Operating Attributes. 🍓
The Message Key (if used) contains the DDS_ID of the Discover Domain Set to be registered or modified. If the Message Key contains a DDS_ID of an existing DDS entry in the iSNS database, the DDSReg message SHALL attempt to update that existing entry ✨ If the DDS_ID in the Message Key (if used) doesn't match an existing DDS entry, the iSNS server SHALL reject the DDSReg message with a status code of 3 (Invalid Registration) 💀 And if the DDS_ID is in both the Message Key and the Operating Attributes, the DDS_ID value in the Message Key MUST be the same as the DDS_ID value in the Operating Attributes 🙈
A DDSReg message with no Message Key SHALL result in the attempted creation of a new Discovery Domain Set (DDS). If the DDS_ID attribute (with non-zero length) is among the Operating Attributes in the DDSReg message, the new Discovery Domain Set SHALL be assigned the value in that DDS_ID attribute. Otherwise, if the DDS_ID attribute isn't among the Operating Attributes of the DDSReg message, or if the DDS_ID is an operating attribute with a TLV length of 0, the iSNS server SHALL assign a DDS_ID value 🧚 The assigned DDS_ID value is then returned in the DDSReg Response message. The Operating Attributes can also contain the DDS_Symbolic_Name, the DDS Status, and the DD_IDs of Discovery Domains to be added to the DDS 👑
When creating a new DDS, if the DDS Symbolic Name is in the Operating Attributes and its value is unique (meaning it doesn't match the registered DDS Symbolic Name for another DDS), the value SHALL be stored in the iSNS database as the DDS Symbolic Name for that DDS. If the value isn't unique, the iSNS server SHALL reject the attempted DDS registration with a status code of 3 (Invalid Registration) 😭
When creating a new DDS, if the DDS Symbolic Name isn't in the Operating Attributes, or it's there with a zero-length TLV, the iSNS server SHALL provide a unique DDS Symbolic Name value for the created DDS. The assigned DDS Symbolic Name value SHALL be returned in the DDSRegRsp message ✨
This message SHALL add any DD_IDs listed as Operating Attributes to the Discovery Domain Set named by the DDS_ID Message Key Attribute. On top of that, if the DDS_Symbolic_Name is an operating attribute and its value is unique, it SHALL be stored in the iSNS database as the DDS_Symbolic_Name for the specified Discovery Domain Set 🌈
If a DD_ID in the Operating Attributes doesn't match an existing DD, a new DD using that DD_ID SHALL be created. In that case, for the new DD, the iSNS server SHALL assign a unique value for the DD Symbolic Name and SHALL set the DD Features attribute to the default value of 0. Those assigned values SHALL be returned in the DDSRegRsp message 🦋
5.6.5.12. DDS Deregister (DDSDereg) 🌸
The DDSDereg message type is 0x000C. This message lets an iSNS client deregister an existing Discovery Domain Set (DDS), or remove some DDs from an existing DDS 💅
The DDSDereg message PDU Payload contains a Source Attribute, a Message Key Attribute, and optional Operating Attributes. 🍓
The Message Key Attribute for a DDSDereg message is the DDS ID of the DDS being removed or having members removed. If the DDS ID matches an existing DDS and there are no Operating Attributes, the DDS SHALL be removed and a success Status Code returned. Any existing members of that DDS SHALL remain in the iSNS database without membership in the just-removed DDS ✨
If the DDS ID matches an existing DDS, and there are Operating Attributes matching DDS members, the DDS members SHALL be removed from the DDS and a success Status Code returned 🧚
The attempted deregistration of non-existent DDS entries SHALL not be considered an error. 🫶
5.6.5.13. Entity Status Inquiry (ESI) ✨
okay so the ESI message type is 0x000D 🦋. The iSNS server sends it to check that an iSNS client Portal is still reachable and available 💅. It goes to the ESI UDP port that was provided during registration, or to the TCP connection used for ESI registration, depending on which communication type is in use 🎀.
The ESI PDU Payload has four attributes in TLV format, in this exact order: the current iSNS timestamp, the EID, the Portal IP Address, and the Portal TCP/UDP Port. Here's the layout:
+----------------------------------------+
| Timestamp |
+----------------------------------------+
| Entity_ID |
+----------------------------------------+
| Portal IP Address |
+----------------------------------------+
| Portal TCP/UDP Port |
+----------------------------------------+The ESI response PDU Payload has a status code, followed by the Attributes from the original ESI message 🫶.
Now the dramatic part 😭. If the Portal fails to respond to an administratively-determined number of consecutive ESI messages, the iSNS server SHALL remove that Portal from the iSNS database. If there are no other remaining ESI-monitored Portals for the associated Network Entity, the Network Entity SHALL also be removed. The appropriate State Change Notifications, if any, SHALL be triggered.
this is the server cleaning up the ghosts 👻 no cap
5.6.5.14. Name Service Heartbeat (Heartbeat) 💜
this one's giving broadcast energy 📢. This message, if used, is only sent by the active iSNS server. It lets iSNS clients and backup servers that are listening on a broadcast or multicast address find the IP address of the primary and backup iSNS servers. It also lets concerned parties keep an eye on the health and status of the primary iSNS server 👀.
This message is not in TLV format. There is no response message to the Name Service Heartbeat 🙈.
MSb LSb
0 31
+------------------------------------------------+
| Active Server IP-Address | 16 Bytes
+------------------------------------------------+
| iSNS TCP Port | iSNS UDP Port | 4 Bytes
+------------------------------------------------+
| Interval | 4 Bytes
+------------------------------------------------+
| Counter | 4 Bytes
+------------------------------------------------+
| RESERVED | Backup Servers | 4 Bytes
+------------------------------------------------+
| Primary Backup Server IP Address(if any) | 16 Bytes
+------------------------------------------------+
|Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes
+------------------------------------------------+
| 2nd Backup Server IP Address(if any) | 16 Bytes
+------------------------------------------------+
|Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes
+------------------------------------------------+
| . . . |
+------------------------------------------------+
| VENDOR SPECIFIC |
+------------------------------------------------+The heartbeat PDU Payload contains the following:
- Active Server IP Address: the IP Address of the active iSNS server in IPv6 format. When this field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to
0x00, with the next two bytes set to0xFFFF[RFC2373]. When this field contains an IPv6 value, the entire 16-byte field is used. - Active TCP Port: the TCP Port of the server currently in use.
- Active UDP Port: the UDP Port of the server currently in use, otherwise 0.
- Interval: the interval, in seconds, of the heartbeat.
- Counter: a count that begins at 0 when this server becomes active. The count increments by one for each heartbeat sent since this server became active.
- Backup Servers: the number of iSNS backup servers. The IP address, TCP Port, and UDP Port of each iSNS backup server follow this field. Note that if backup servers are used, then the active iSNS server SHOULD be among the list of backup servers.
The content of the remainder of this message after the list of backup servers is vendor-specific. Vendors may use additional fields to coordinate between multiple iSNS servers, and/or to identify vendor-specific features 🧚.
5.6.5.15. Request FC_DOMAIN_ID (RqstDomId) 🌈
the RqstDomId message type is 0x0011 🍓. This message is used for iFCP Transparent Mode to allocate non-overlapping FC_DOMAIN_ID values between 1 and 239. The iSNS server becomes the address assignment authority for the entire iFCP fabric 👑. To get multiple FC_DOMAIN_ID values, this request must be repeated to the iSNS server multiple times. iSNS clients that acquire FC_DOMAIN_ID values from an iSNS server MUST register for ESI monitoring from that iSNS server 🔥.
The RqstDomId PDU Payload has three TLV attributes in this order: the requesting Switch Name (WWN) as the Source Attribute, the Virtual_Fabric_ID as the Message Key Attribute, and Preferred ID as the operating attribute. The Virtual_Fabric_ID is a string that identifies the domain space in which the iSNS server SHALL allocate non-overlapping integer FC_DOMAIN_ID values between 1 and 239. The Preferred_ID is the nominal FC_DOMAIN_ID value that the iSNS client requested. If the Preferred_ID value is available and has not already been allocated for the Virtual_Fabric_ID in the message, the iSNS server SHALL return the requested Preferred_ID value as the Assigned_ID to the requesting client ✨.
The RqstDomId response has a Status Code and the TLV attribute Assigned ID, which holds the integer value from the space that was requested. If no further unallocated values are available from this space, the iSNS server SHALL respond with the Status Code 18 "FC_DOMAIN_ID Not Available" 💀.
Once a FC_DOMAIN_ID value has been allocated to an iSNS client by the iSNS server for a given Virtual_Fabric_ID, that FC_DOMAIN_ID value SHALL NOT be reused until it has been deallocated, or until ESI monitoring detects that the iSNS client no longer exists on the network and the objects for that client are removed from the iSNS database 🥹.
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages 🛤️.
5.6.5.16. Release FC_DOMAIN_ID (RlseDomId) 🦋
the RlseDomId message type is 0x0012. This message may be used by iFCP Transparent Mode to release the integer identifier values that were used to assign 3-byte Fibre Channel PORT_ID values 🔓.
The RlseDomId message contains three TLV attributes in this order: the requesting EID as the Source Attribute, the Virtual_Fabric_ID as the Message Key Attribute, and Assigned_ID as the operating attribute. When the iSNS server receives the RlseDomId message, it SHALL deallocate the FC_DOMAIN_ID value contained in the Assigned_ID attribute for the Virtual_Fabric_ID attribute specified. Once that deallocation happens, the FC_DOMAIN_ID value can then be requested by, and assigned to, a different iSNS client 🎀.
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages 🫶.
5.6.5.17. Get FC_DOMAIN_IDs (GetDomId) 🧚
the GetDomId message type is 0x0013. This message is used to learn the currently-allocated FC_DOMAIN_ID values for a given Virtual_Fabric_ID 🔍.
The GetDomId message PDU Payload contains a Source Attribute and a Message Key Attribute.
The Message Key Attribute for the GetDomId message is the Virtual_Fabric_ID. The response to this message returns all the FC_DOMAIN_ID values that have been allocated for the Virtual_Fabric_ID specified 💜.
5.7. Messages 💅
The iSNSP response message PDU Payloads contain a Status Code, followed by a list of attributes, and have the following format:
MSb LSb
0 31
+----------------------------------------+
| 4-byte STATUS CODE |
+----------------------------------------+
| Message Key Attribute[1] (if present) |
+----------------------------------------+
| Message Key Attribute[2] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| - Delimiter Attribute - (if present) |
+----------------------------------------+
| Operating Attribute[1] (if present) |
+----------------------------------------+
| Operating Attribute[2] (if present) |
+----------------------------------------+
| Operating Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+The iSNSP Response messages SHALL be sent to the iSNS Client IP Address and the originating TCP/UDP Port that was used for the associated registration and query message 📬.
5.7.1. Status Code 🌸
The first field in an iSNSP response message PDU Payload is the Status Code for the operation that was performed. The Status Code encoding is defined in Section 5.4 ✅.
5.7.2. Message Key Attributes in Response 🎀
Depending on the specific iSNSP request, the response message MAY contain Message Key Attributes. Message Key Attributes generally contain the interesting key attributes that are affected by the operation specified in the original iSNS registration or query message 🔑.
5.7.3. Delimiter Attribute in Response 🍓
The Delimiter Attribute separates the key and Operating Attributes in a response message, if they exist. The Delimiter Attribute has a tag value of 0 and a length value of 0. The Delimiter Attribute is effectively 8 bytes long: a 4-byte tag containing 0x00000000, and a 4 Byte length field containing 0x00000000 🧩.
5.7.4. Operating Attributes in Response 🌷
The Operating Attributes in a response are the results related to the iSNS registration or query operation being performed. Some response messages will not have Operating Attributes 📊.
5.7.5. Registration and Query Response Message Types 🌈
The following sections describe each query and message type 🫶.
5.7.5.1. Device Attribute Registration Response (DevAttrRegRsp) 💖
okay so the DevAttrRegRsp message type is 0x8001 🎀 it's the reply to a DevAttrReg, and they're matched up by the same TRANSACTION ID, so they're literally a pair 🫶
The Message Key in the DevAttrRegRsp message SHALL return the Message Key from the original registration message. If the iSNS server assigned the Entity Identifier for a Network Entity, then the Message Key Attribute field SHALL contain the assigned Entity Identifier. ✨
The Operating Attributes of the DevAttrRegRsp message SHALL contain the affected object's key and non-key attributes that were explicitly modified or created by the original DevAttrReg message. Among the Operating Attributes, each modified or added non-key attribute SHALL be listed after its key attribute(s) in the DevAttrRegRsp message. Implicitly registered attributes MUST NOT be returned in the DevAttrRegRsp message 🙅♀️ these are the ones the iSNS server gives a fixed default value or secondary index value, so they stay out of the reply.
Implicitly registered PG objects (the PG objects that aren't explicitly included in the registration or replace message) MUST NOT have their key or non-key attributes returned in the DevAttrRegRsp message. BUT explicitly registered PG objects (the ones with PGT values that are explicitly included in the registration or replace message) SHALL have their PGT values returned in the DevAttrRegRsp message 🌸
Let's say three Portals get registered in the original DevAttrReg request. The iSNS server is running low on resources, so it needs to change the registered ESI Interval value of one of those Portals 😭 To do that, it sends back the key attributes identifying that Portal, followed by the modified non-key ESI Interval attribute value, as Operating Attributes of the matching DevAttrRegRsp message. Iconic behaviour 💅
If the iSNS server rejects a registration because of invalid attribute values or types, then the indicated status code SHALL be 3 (Invalid Registration) 🚫 If this happens, the iSNS server MAY include the list of invalid attributes in the Operating Attributes of the DevAttrRsp message.
Some attribute values (like ESI Interval or Registration Period) in the original registration message MAY be modified by the iSNS server 🦋 This can only happen for a limited set of attribute types, as indicated in the table in Section 6.1. When it does, the registration SHALL be considered a success (with status code 0), and the changed value(s) get listed in the Operating Attributes of the DevAttrRsp message. 🎉
5.7.5.2. Device Attribute Query Response (DevAttrQryRsp) 🧚
the DevAttrQryRsp message type is 0x8002 🌈 it's the answer to a DevAttrQry message with the same TRANSACTION ID.
The Message Key in the DevAttrQryRsp message SHALL return the Message Key from the original query message ✨
If no Operating Attributes are included in the original query, then all Operating Attributes SHALL be returned in the response. Main character energy, no notes 💁♀️
For a successful query result, the DevAttrQryRsp Operating Attributes SHALL contain the results of the original DevAttrQry message. 🫧
5.7.5.3. Device Get Next Response (DevGetNextRsp) 🍓
the DevGetNextRsp message type is 0x8003 💜 it answers the DevGetNext message with the same TRANSACTION ID.
The Message Key Attribute field returns the object keys for the next object after the Message Key Attribute from the original DevGetNext message 👀
The Operating Attribute field returns the Operating Attributes of that next object, as requested in the original DevGetNext message. The values of those Operating Attributes are the ones tied to the object identified by the Message Key Attribute field of the DevGetNextRsp message. Little chain of trust moment 🔗
5.7.5.4. Deregister Device Response (DevDeregRsp) 🌙
the DevDeregRsp message type is 0x8004 🦄 it's the response to the DevDereg request.
This message doesn't have a Message Key, but it MAY contain Operating Attributes 🎀
If something goes wrong, this response carries the right status code plus a list of objects from the original DevDereg message that didn't get deregistered from the iSNS database. That list lives in the Operating Attributes of the DevDeregRsp message 😭 Quick heads-up though: trying to deregister something that doesn't exist is NOT an error 🙃 so those non-existent entries SHALL not be returned in the DevDeregRsp message. Lowkey the most relatable rule in the whole doc 💀
5.7.5.5. SCN Register Response (SCNRegRsp) 🫶
the SCNRegRsp message type is 0x8005 💖 it answers the SCNReg request.
The SCNRegRsp message doesn't contain any Message Key or Operating Attributes. Simple and clean, so iconic ✨
5.7.5.6. SCN Deregister Response (SCNDeregRsp) 🍓
the SCNDeregRsp message type is 0x8006 💅 it answers the SCNDereg request.
The SCNDeregRsp message doesn't contain any Message Key or Operating Attributes. Same energy as the last one, honestly 🙈
5.7.5.7. SCN Event Response (SCNEventRsp) ⭐
the SCNEventRsp message type is 0x8007 🌸 it answers the SCNEvent request.
The SCNEventRsp message doesn't contain any Message Key or Operating Attributes 🧚
5.7.5.8. SCN Response (SCNRsp) 🦋
the SCNRsp message type is 0x8008 🔥 this one is sent by an iSNS client, and it confirms that the SCN message was received and processed. Confirmation receipt, bestie 📬
The SCNRsp response contains the SCN Destination Attribute, which represents the Node identifier that received the SCN 👑
5.7.5.9. DD Register Response (DDRegRsp) 🌈
the DDRegRsp message type is 0x8009 💖 it's the response to the DDReg request.
The Message Key in the DDRegRsp message SHALL return the Message Key from the original query message 🤔 (yes, the doc says "query" here, we're keeping it as written.) If the original DDReg message didn't have a Message Key, then the DDRegRsp message SHALL not have a Message Key either ✨
If the DDReg operation is successful, the DD ID of the DD that was created or updated SHALL be returned as an operating attribute of the message 🎀
If the DD Symbolic Name attribute or DD Features attribute was assigned or updated during the DDReg operation, then any new values SHALL be returned as an operating attribute of the DDRegRsp message 🦄
If the iSNS server rejects a DDReg because of invalid attribute values or types, then the indicated status code SHALL be 3 (Invalid Registration). If this happens, the iSNS server MAY include the list of invalid attributes in the Operating Attributes of the DDRegRsp message 🚫
5.7.5.10. DD Deregister Response (DDDeregRsp) 🌙
the DDDeregRsp message type is 0x800A 🫧 it answers the DDDereg request.
The DDDeregRsp message doesn't contain any Message Key or Operating Attributes. Pure vibes, no extras 🧚♀️
5.7.5.11. DDS Register Response (DDSRegRsp) 🍓
the DDSRegRsp message type is 0x800B 💜 it's the response to the DDSReg request.
The Message Key in the DDSRegRsp message SHALL contain the Message Key of the original DDSReg message. If the original DDSReg message didn't have a Message Key, then the DDSRegRsp message SHALL NOT have a Message Key 🙅♀️
If the DDSReg operation is successful, the DDS ID of the DDS that was created or updated SHALL be returned as an operating attribute of the message 🎀
If the DDS Symbolic Name attribute or DDS Status attribute was assigned or updated during the DDSRegRsp operation, then any new values SHALL be returned as an operating attribute of the DDSRegRsp message ✨
If the iSNS server rejects a DDSReg because of invalid attribute values or types, then the indicated status code SHALL be 3 (Invalid Registration). If this happens, the iSNS server MAY include the list of invalid attributes in the Operating Attributes of the DDSRegRsp message 🚫
5.7.5.12. DDS Deregister Response (DDSDeregRsp) 🌸
the DDSDeregRsp message type is 0x800C 💅 it answers the DDSDereg request.
The DDSDeregRsp message doesn't contain any Message Key or Operating Attributes. Simple, clean, iconic 💖
5.7.5.13. Entity Status Inquiry Response (ESIRsp) 🫶
the ESIRsp message type is 0x800D 🌈 this one is sent by an iSNS client, and it confirms that the ESI message was received and processed ✅
The ESIRsp response message PDU Payload contains the attributes from the original ESI message. These attributes represent the Portal that's responding to the ESI 🧚 The ESIRsp Attributes show up in the same order they were given in the original ESI message.
When the iSNS server gets the ESIRsp from the iSNS client, it SHALL update the timestamp attribute for that Network Entity and Portal ⏰ okay that's the whole plot twist.
5.7.5.14. Request FC_DOMAIN_ID Response (RqstDomIdRsp) 👑
the RqstDomIdRsp message type is 0x8011 💖 it's the response for RqstDomId.
The RqstDomId response contains a Status Code and the TLV attribute Assigned ID, which holds the integer value from the space that was requested. If there are no more unallocated values left in that space, the iSNS server SHALL respond with Status Code 19 "FC_DOMAIN_ID Not Available" 😭
Once the iSNS server allocates a FC_DOMAIN_ID value, it SHALL NOT be reused until the iSNS client it was assigned to deallocates it, or until the ESI message detects that the iSNS client isn't on the network anymore 🚫 no ghosting allowed 👻
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages. 🛣️
5.7.5.15. Release FC_DOMAIN_ID Response (RlseDomIdRsp) 🦋
the RlseDomIdRsp message type is 0x8012 🎀 it's the response for RlseDomId. It carries an Error that tells you whether the request worked 💁♀️
If the Assigned_ID value in the original RlseDomId message isn't allocated, then the iSNS server SHALL respond with this message using Status Code 20 "FC_DOMAIN_ID Not Allocated" 🙈
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages. Yep, same TCP rule as before, no cap 🫶
5.7.5.16. Get FC_DOMAIN_IDs Response (GetDomIdRsp) 🧚
the GetDomIdRsp message type is 0x8013 🌈 this one figures out which FC_DOMAIN_ID values have been allocated for the Virtual_Fabric_ID named in the original GetDomId request message 🔍
The GetDomId response message PDU Payload contains a Status Code that says whether the request worked, plus a list of the Assigned IDs from the requested space. The Assigned_ID attributes are listed in TLV format 📦
5.8. Vendor-Specific Messages 🌸
okay so vendor-specific iSNSP messages have a functional ID between 0x0100 and 0x01FF, and vendor-specific responses have a functional ID between 0x8100 and 0x81FF 💜 The first Message Key Attribute in a vendor-specific message SHALL be the company OUI (tag=256), which identifies the original creator of that proprietary iSNSP message 🏢 The rest of the message is vendor-specific, so it's up to them 🎀
6. iSNS Attributes 🧚
Attributes can be stored in the iSNS server using iSNSP registration messages, and they can be retrieved using iSNSP query messages 💖 Unless otherwise indicated, these attributes are supplied by iSNS clients using iSNSP registration messages 🫶
6.1. iSNS Attribute Summary 💅
okay so the full registry of iSNS attributes lives with IANA 🌸, but this table is the snapshot of the starter set that was available when this doc was published. bestie, look at all those tags 😭✨
Attributes Length Tag Reg Key Query Key
---------- ------ --- ------- ---------
Delimiter 0 0 N/A N/A
Entity Identifier (EID) 4-256 1 1 1|2|16&17|32|64
Entity Protocol 4 2 1 1|2|16&17|32|64
Management IP Address 16 3 1 1|2|16&17|32|64
Timestamp 8 4 -- 1|2|16&17|32|64
Protocol Version Range 4 5 1 1|2|16&17|32|64
Registration Period 4 6 1 1|2|16&17|32|64
Entity Index 4 7 1 1|2|16&17|32|64
Entity Next Index 4 8 -- 1|2|16&17|32|64
Entity ISAKMP Phase-1 var 11 1 1|2|16&17|32|64
Entity Certificate var 12 1 1|2|16&17|32|64
Portal IP Address 16 16 1 1|16&17|32|64
Portal TCP/UDP Port 4 17 1 1|16&17|32|64
Portal Symbolic Name 4-256 18 16&17 1|16&17|32|64
ESI Interval 4 19 16&17 1|16&17|32|64
ESI Port 4 20 16&17 1|16&17|32|64
Portal Index 4 22 16&17 1|16&17|32|64
SCN Port 4 23 16&17 1|16&17|32|64
Portal Next Index 4 24 -- 1|16&17|32|64
Portal Security Bitmap 4 27 16&17 1|16&17|32|64
Portal ISAKMP Phase-1 var 28 16&17 1|16&17|32|64
Portal ISAKMP Phase-2 var 29 16&17 1|16&17|32|64
Portal Certificate var 31 16&17 1|16&17|32|64
iSCSI Name 4-224 32 1 1|16&17|32|33
iSCSI Node Type 4 33 32 1|16&17|32
iSCSI Alias 4-256 34 32 1|16&17|32
iSCSI SCN Bitmap 4 35 32 1|16&17|32
iSCSI Node Index 4 36 32 1|16&17|32
WWNN Token 8 37 32 1|16&17|32
iSCSI Node Next Index 4 38 -- 1|16&17|32
iSCSI AuthMethod var 42 32 1|16&17|32
PG iSCSI Name 4-224 48 32|16&17 1|16&17|32|52
PG Portal IP Addr 16 49 32|16&17 1|16&17|32|52
PG Portal TCP/UDP Port 4 50 32|16&17 1|16&17|32|52
PG Tag (PGT) 4 51 32|16&17 1|16&17|32|52
PG Index 4 52 32|16&17 1|16&17|32|52
PG Next Index 4 53 -- 1|16&17|32|52
FC Port Name WWPN 8 64 1 1|16&17|64|66|96|128
Port ID 4 65 64 1|16&17|64
FC Port Type 4 66 64 1|16&17|64
Symbolic Port Name 4-256 67 64 1|16&17|64
Fabric Port Name 8 68 64 1|16&17|64
Hard Address 4 69 64 1|16&17|64
Port IP-Address 16 70 64 1|16&17|64
Class of Service 4 71 64 1|16&17|64
FC-4 Types 32 72 64 1|16&17|64
FC-4 Descriptor 4-256 73 64 1|16&17|64
FC-4 Features 128 74 64 1|16&17|64
iFCP SCN bitmap 4 75 64 1|16&17|64
Port Role 4 76 64 1|16&17|64
Permanent Port Name 8 77 -- 1|16&17|64
FC-4 Type Code 4 95 -- 1|16&17|64
FC Node Name WWNN 8 96 64 1|16&17|64|96
Symbolic Node Name 4-256 97 96 64|96
Node IP-Address 16 98 96 64|96
Node IPA 8 99 96 64|96
Proxy iSCSI Name 4-256 101 96 64|96
Switch Name 8 128 128 128
Preferred ID 4 129 128 128
Assigned ID 4 130 128 128
Virtual_Fabric_ID 4-256 131 128 128
iSNS Server Vendor OUI 4 256 -- SOURCE Attribute
Vendor-Spec iSNS Srvr 257-384 -- SOURCE Attribute
Vendor-Spec Entity 385-512 1 1|2|16&17|32|64
Vendor-Spec Portal 513-640 16&17 1|16&17|32|64
Vendor-Spec iSCSI Node 641-768 32 16&17|32
Vendor-Spec FC Port Name 769-896 64 1|16&17|64
Vendor-Spec FC Node Name 897-1024 96 64|96
Vendor-Specific DDS 1025-1280 2049 2049
Vendor-Specific DD 1281-1536 2065 2065
Other Vendor-Specific 1537-2048
DD_Set ID 4 2049 2049 1|32|64|2049|2065
DD_Set Sym Name 4-256 2050 2049 2049
DD_Set Status 4 2051 2049 2049
DD_Set_Next_ID 4 2052 -- 2049
DD_ID 4 2065 2049 1|32|64|2049|2065
DD_Symbolic Name 4-256 2066 2065 2065
DD_Member iSCSI Index 4 2067 2065 2065
DD_Member iSCSI Name 4-224 2068 2065 2065
DD_Member FC Port Name 8 2069 2065 2065
DD_Member Portal Index 4 2070 2065 2065
DD_Member Portal IP Addr 16 2071 2065 2065
DD_Member Portal TCP/UDP 4 2072 2065 2065
DD_Features 4 2078 2065 2065
DD_ID Next ID 4 2079 -- 2065here's what the columns mean, so you can read the table like a pro 🧚
- Length: the attribute length in bytes used for the TLV format. Variable-length identifiers are NULL-terminated and 4-byte aligned, and the NULLs count toward the length 🎀
- Tag: the IANA-assigned integer that identifies the attribute. every undefined tag value is reserved 🔒
- Reg Key: the tag values allowed as the object key in DevAttrReg messages, which is how you register a new attribute value in the database. these are the attributes defined as object keys in Section 4 🗝️
- Query Key: the possible tag values for the Message Key and object key used in DevAttrQry messages when you want to pull a stored value out of the iSNS database 🔍
and here's the tag-range summary for stuff that's still up for grabs at publication time 🦋
Tag Values Reg Key Query Key
---------- ------- ---------
9-10, 13-15 1 1|2|16&17|32|64
21, 25-26, 30 16&17 1|16&17|32|64
39-41, 44-47 32 1|16&17|32
54-63 32|16&17 1|16&17|32|52
78-82, 85-94 64 1|16&17|64
102-127 96 64|96
132-255 -- SOURCE Attribute
2053-2064 2049 2049
2073-2077 2065 2065
2080-65535 To be assigned To be assignedthe tags from 2080 to 65535 get their registration and query keys documented in whichever RFC introduces the new attributes, and IANA keeps the registry going as that RFC requires 📜
new iSNS attributes with any of the tags above MAY also be marked as "read-only" attributes 👀 and the RFC introducing them as read-only SHALL say so, with IANA recording their Reg Keys as "--" 💖
6.2. Entity Identifier-Keyed Attributes 🌈
these attributes get stored in the iSNS server with the Entity Identifier attribute as the key 🔑
6.2.1. Entity Identifier (EID) 🪪
the EID is a variable-length, UTF-8 encoded, NULL-terminated text description of a Network Entity 🌸 it's the key attribute that makes each registered Network Entity unique in the iSNS server. the attribute length runs from 4 to 256 bytes (NULL termination included), and it has to be unique within the server 💅
if the iSNS client doesn't send an EID during registration, the iSNS server SHALL generate one that's unique in the iSNS database. when the EID is going to be generated, the EID attribute in the registration message SHALL be empty (0 length), and the generated EID SHALL come back in the registration response ✨
heads up bestie: FQDNs longer than 255 bytes MUST NOT be used. no exceptions 🙅♀️
when the iSNS server is hooked up to a DNS setup, the Entity Identifier can hold the Fully Qualified Domain Name (FQDN) of the iSCSI or iFCP device 🌐 and if you're not using FQDNs, the iSNS server can make EIDs for you. EIDs generated by the server MUST begin with the string "isns:", and iSNS clients MUST NOT generate and register EIDs that start with "isns:" 🚫
before an EID gets stored in the iSNS database, it MUST be normalized using the nameprep template [NAMEPREP] 🧼
6.2.2. Entity Protocol 🛠️
the Entity Protocol is a 4-byte integer attribute that tells you which block storage protocol the registered NETWORK ENTITY uses 🧱 the values are assigned and maintained by IANA. here's the starter set supported by iSNS:
Value Entity Protocol Type
----- --------------------
1 No Protocol
2 iSCSI
3 iFCP
All others To be assigned by IANA'No Protocol' means the Network Entity doesn't support an IP block storage protocol. a Control Node or monitoring Node would probably use this value, though not always 🙈
this attribute is required when the Network Entity first registers 📝
6.2.3. Management IP Address 🏠
this field holds the IP Address you can use to manage the Network Entity and all the Storage Nodes inside it, through the iSNS MIB [iSNSMIB] 🖥️ some implementations may also use this address for vendor-specific proprietary management protocols 🔧
the Management IP Address is a 16-byte field that can hold an IPv4 or IPv6 address 🌈 when it holds an IPv4 value, it's stored as an IPv4-mapped IPv6 address. so the most significant 10 bytes are 0x00, and the next two bytes are 0xFFFF [RFC2373] 🎀 when it holds an IPv6 value, the whole 16-byte field gets used 💜
if this field isn't set, in-band management through the IP address of one of the Portals of the Network Entity is assumed 🦋
6.2.4. Entity Registration Timestamp ⏰
this field records the most recent time the Network Entity was registered, or when one of its associated object attributes was updated or queried by the iSNS client doing the registering ⏳ the time format is, in seconds, the update period since the standard base time of 00:00:00 GMT on January 1, 1970 🕛
this field can't be explicitly registered 🙅♀️ and this timestamp TLV format is also used in the SCN and ESI messages 📨
6.2.5. Protocol Version Range 🎀
okay so this field holds the minimum and maximum version of the block storage protocol that the Network Entity supports 💅 the most significant two bytes hold the maximum version supported, and the least significant two bytes hold the minimum version supported. if a range isn't registered, the Network Entity is assumed to support all versions of the protocol 🦋 the value 0xffff is a wildcard that means no minimum or maximum (iconic, honestly). and if the Network Entity doesn't support a protocol at all, this field SHALL be set to 0 💀
6.2.6. Registration Period 🍓
this one is a 4-byte unsigned integer and it tells you the maximum period, in seconds, that the server SHALL keep the registration alive without hearing anything from the iSNS client that registered the Network Entity 🕰️ entities that aren't registered for ESI monitoring MUST have a non-zero Registration Period, no exceptions bestie 🙅♀️ if the iSNS client didn't ask for a Registration Period and ESI messages aren't enabled for that client, then the iSNS server SHALL set the Registration Period to a non-zero value. that implementation-specific value SHALL be returned in the registration response to the iSNS client ✨ the Registration Period may be set to zero, which means it's not being used, but only if ESI messages are enabled for that Network Entity.
the registration SHALL be removed from the iSNS database if no iSNS Protocol message shows up from the iSNS client before the registration period runs out 😭 receiving any iSNS Protocol message from the iSNS client automatically refreshes the Entity Registration Period and the Entity Registration Timestamp, so it's giving "I'm still here" energy 🫶 to keep a registration from expiring, the iSNS client should send an iSNS Protocol message to the iSNS server at intervals shorter than the registration period. and honestly the message can be super simple, like a query for one of its own attributes, using its associated iSCSI Name or FC Port Name WWPN as the Source attribute 🧚
for an iSNS client supporting a Network Entity with multiple Storage Node objects, getting an iSNS message from any Storage Node of that Network Entity is enough to refresh the registration for all the Storage Node objects of that Network Entity 👑
if ESI support is requested as part of a Portal registration, the ESI Response message that the iSNS server receives from the iSNS client SHALL refresh the registration 🔥
6.2.7. Entity Index 🌈
the Entity Index is an unsigned non-zero integer that uniquely identifies each Network Entity registered in the iSNS server 🪪 when a Network Entity first registers, the iSNS server assigns it an unused value for the Entity Index. each Network Entity in the iSNS database MUST be assigned an Entity Index value that isn't assigned to any other Network Entity, full stop 🚫 also, Entity Index values for recently deregistered Network Entities SHOULD NOT be reused in the short term, so nobody gets confused about who's who 🙈
the Entity Index MAY be used to represent the Network Entity when the Entity Identifier is too long or otherwise inappropriate ✨ one example is when SNMP is used for management, as described in Section 2.10.
6.2.8. Entity Next Index 🍓
this is a virtual attribute holding a 4-byte integer that tells you the next available (aka unused) Entity Index value 🔮 this attribute may only be queried. if a client tries to register a value for it, the iSNS server SHALL return an error code of 3 (Invalid Registration) to that client, no cap 🙅♀️ a Message Key isn't required when you're only querying for this attribute.
the Entity Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10 🎀
6.2.9. Entity ISAKMP Phase-1 Proposals 🔐
this field holds the IKE Phase-1 proposal, listing (in decreasing order of preference) the protection suites that are acceptable for protecting all IKE Phase-2 messages sent and received by the Network Entity 🛡️ that includes Phase-2 SAs from the iSNS client to the iSNS server, as well as to peer iFCP and/or iSCSI devices. this attribute contains the SA payload, proposal payload(s), and transform payload(s) in the ISAKMP format defined in [RFC2408].
this field should be used if the implementer wants to define a single phase-1 SA security configuration that protects all phase-2 IKE traffic 💖 if the implementer instead wants a different phase-1 SA security configuration to protect each Portal interface, then the Portal Phase-1 Proposal (Section 6.3.10) should be used.
6.2.10. Entity Certificate 📜
this attribute contains one or more X.509 certificates bound to the Network Entity 🔏 clients who want other clients to be able to authenticate themselves and access the services that Network Entity offers upload and register this certificate with the iSNS server. the format of the X.509 certificate is found in [RFC3280]. this certificate MUST contain a Subject Name with an empty sequence, and it MUST contain a SubjectAltName extension encoded with the dNSName type 🙌 the Entity Identifier (Section 6.2.1) of the identified Entity MUST be stored in the SubjectAltName field of the certificate. no skipping steps!! 💅
6.3. Portal-Keyed Attributes 🦋
the following Portal attributes are registered in the iSNS database using the combined Portal IP-Address and Portal TCP/UDP Port as the key 🗝️ each Portal is associated with one Entity Identifier object key.
6.3.1. Portal IP Address 🌐
this attribute is the IP address of the Portal that a Storage Node can use to send and receive storage data 💌 the Portal IP Address is a 16-byte field that can hold an IPv4 or IPv6 address. when it holds an IPv4 address, it's stored as an IPv4-mapped IPv6 address. that means the most significant 10 bytes are set to 0x00, with the next 2 bytes set to 0xFFFF [RFC2373] ✨ when the field holds an IPv6 address, the entire 16-byte field gets used. the Portal IP Address and the Portal TCP/UDP Port number (see 6.3.2 below) work together as a key to identify a Portal uniquely 🔑 it's a required attribute for registering a Portal.
6.3.2. Portal TCP/UDP Port 🔌
this is the TCP/UDP port of the Portal that a Storage Node can use to send and receive storage data 💜 bits 16 to 31 represent the TCP/UDP port number. bit 15 represents the port type: if bit 15 is set, the port type is UDP, and otherwise it's TCP. bits 0 to 14 are reserved, so hands off 🚧
if the field value is 0, then the port number is the implied canonical port number and type of the protocol indicated by the associated Entity Type 🧠
the Portal IP Address and the Portal TCP/UDP Port number are used as a key to identify a Portal uniquely 🗝️ it's a required attribute for registering a Portal.
6.3.3. Portal Symbolic Name 🏷️
this is a variable-length, UTF-8 encoded, NULL-terminated text description of up to 256 bytes 📝 the Portal Symbolic Name is a human-readable description of the Portal entry in the iSNS server, so you can actually tell what you're looking at 🥰
6.3.4. Entity Status Inquiry Interval ⏱️
this field indicates the requested time, in seconds, between Entity Status Inquiry (ESI) messages sent from the iSNS server to this Network Entity 💬 ESI messages can be used to verify that a Portal registration is still valid. to request monitoring by the iSNS server, an iSNS client registers a non-zero value for this Portal attribute using a DevAttrReg message. the client MUST register an ESI Port on at least one of its Portals to receive the ESI monitoring 🫡
if the iSNS server doesn't get an expected response to an ESI message, it SHALL attempt an administratively configured number of re-transmissions of that ESI message 🔁 the ESI Interval period begins when the iSNS server receives the last ESI Response. all re-transmissions MUST be sent before twice the ESI Interval period has passed ⏳ if no response comes back from any of the ESI messages, then the Portal SHALL be deregistered. just a heads up, only Portals that have registered a value in their ESI Port field can be deregistered this way 🙈
if all the Portals associated with a Network Entity that registered for ESI messages get deregistered due to non-response, AND no registrations have come in from the client for at least two ESI Interval periods, then the Network Entity and all of its associated objects (including Storage Nodes) SHALL be deregistered 💀
if the iSNS server can't support ESI messages or the ESI Interval requested, it SHALL either reject the ESI request by returning an "ESI Not Available" Status Code, or modify the ESI Interval attribute by picking its own suitable value and returning that value in the Operating Attributes of the registration response message 🙃
if at any point an iSNS client registered for ESI messages hasn't received an ESI message to any of its Portals as expected, then the client MAY attempt to query the iSNS server using a DevAttrQry message with its Entity_ID as the key 🔍 if the query result is the error "no such entry", then the client SHALL close all remaining TCP connections to the iSNS server and assume it's no longer registered in the iSNS database. a client like that MAY attempt re-registration 🔄
6.3.5. ESI Port 🚪
this field contains the TCP or UDP port used for ESI monitoring by the iSNS server at the Portal IP Address 🛎️ bits 16 to 31 represent the port number. if bit 15 is set, the port type is UDP, and otherwise the port is TCP. bits 0 to 14 are reserved 🚧
if the iSNS client registers a valid TCP or UDP port number in this field, then the client SHALL allow ESI messages to be received at the indicated TCP or UDP port 📬 if a TCP port is registered and there isn't already a pre-existing TCP connection from that TCP port to the iSNS server, then the iSNS client SHALL accept new TCP connections from the iSNS server at the indicated TCP port 🤝
the iSNS server SHALL return an error if a Network Entity is registered for ESI monitoring and none of its Portals has an entry for the ESI Port field 🚨 if multiple Portals have a registered ESI port, then the ESI message may be delivered to any one of the indicated Portals 🎲
6.3.6. Portal Index 🪧
the Portal Index is a 4-byte non-zero integer that uniquely identifies each Portal registered in the iSNS database 🧾 when a Portal first registers, the iSNS server assigns it an unused value for the Portal Index. each Portal in the iSNS database MUST be assigned a Portal Index value that isn't assigned to any other Portal 🙅♀️ also, Portal Index values for recently deregistered Portals SHOULD NOT be reused in the short term, same energy as the Entity Index 💅
the Portal Index MAY be used to represent a registered Portal in situations where the Portal IP-Address and Portal TCP/UDP Port is unwieldy to use. one example is when SNMP is used for management, as described in Section 2.10 🌸
6.3.7. SCN Port ✨
okay so this field holds the TCP or UDP port the iSNS client uses to catch SCN messages from the iSNS server 📬 when a value is registered, an SCN message can land on that port for ANY of the Storage Nodes the Portal supports 🦋 the port number lives in bits 16 to 31, and if bit 15 is set, the port type is UDP. otherwise it's TCP 💅 bits 0 to 14 are reserved, so hands off 🙅♀️
If the iSNS client registers a valid TCP or UDP port number here, then the client SHALL allow SCN messages to be received on that port. 🎀 if a TCP port is registered and there's no pre-existing TCP connection from that port to the iSNS server, then the iSNS client SHALL accept new TCP connections from the iSNS server on that port. it's giving open door policy 🚪🌸
the iSNS server SHALL return an error if an SCN registration message comes in and none of the Portals of the Network Entity has an entry for the SCN Port 💀 if multiple Portals have a registered SCN Port, then the SCN SHALL be delivered to any one of the indicated Portals of that Network Entity. so it just picks one, no drama 🫶
6.3.8. Portal Next Index ✨
this is a virtual attribute holding a 4-byte integer that tells you the next available (aka unused) Portal Index value 🔢 it may only be queried. if a client tries to register a value for it, the iSNS server SHALL return an error code of 3 (Invalid Registration) 🙅♀️ and a Message Key isn't required when you're only querying this one 🔑
the Portal Next Index MAY be used by an SNMP client to create an entry in the iSNS server. for the SNMP stuff, check out Section 2.10 🧚
6.3.9. Portal Security Bitmap ✨
this 4-byte field holds flags for the Portal's security attribute settings 🔐 bit 31 (the Lsb) must be 1 (enabled) for this field to hold anything meaningful. if bit 31 is enabled, it means the iSNS server can be used to store and distribute security policies and settings for iSNS clients (aka iSCSI devices) 💜 bit 30 must be 1 for bits 25 to 29 to mean anything. everything else is reserved for non-IKE/IPSec security mechanisms that might get specified later 🌈
the bit map is giving very precise energy, so here's the whole thing:
Bit Position Flag Description
------------ ----------------
25 1 = Tunnel Mode Preferred; 0 = No Preference
26 1 = Transport Mode Preferred; 0 = No Preference
27 1 = Perfect Forward Secrecy (PFS) Enabled;
0 = PFS Disabled
28 1 = Aggressive Mode Enabled; 0 = Disabled
29 1 = Main Mode Enabled; 0 = MM Disabled
30 1 = IKE/IPSec Enabled; 0 = IKE/IPSec Disabled
31 (Lsb) 1 = Bitmap VALID; 0 = INVALID
All others RESERVED6.3.10. Portal ISAKMP Phase-1 Proposals ✨
this field has the IKE Phase-1 proposal list, sorted from most to least preferred, of the protection suites that are acceptable for protecting all IKE Phase-2 messages sent and received by the Portal 🦋 that covers Phase-2 SAs going from the iSNS client to the iSNS server, and also to peer iFCP and/or iSCSI devices 💅 this attribute carries the SA payload, proposal payload(s), and transform payload(s), all in the ISAKMP format from [RFC2408] 🧁
this field should be used if the implementer wants to set phase-1 SA security config per Portal, instead of per Network Entity 🌸 if they want one single phase-1 SA security config to protect all phase-2 traffic no matter which interface is used, then the Entity Phase-1 Proposal (Section 6.2.9) should be used instead ✨
6.3.11. Portal ISAKMP Phase-2 Proposals ✨
this field is the IKE Phase-2 proposal, in ISAKMP format [RFC2408], listing (most to least preferred) the security proposals that are acceptable for protecting traffic sent and received by the Portal 🔥 it's only used if bits 31, 30, and 29 of the Security Bitmap (see 6.3.9) are enabled 🫶 this attribute carries the SA payload, proposal payload(s), and associated transform payload(s), in the ISAKMP format from [RFC2408] 💜
6.3.12. Portal Certificate ✨
this attribute holds one or more X.509 certificates that act as a credential of the Portal 🪪 the certificate is used to identify and authenticate communications to the IP address and TCP/UDP Port the Portal supports 🔐 the X.509 format is specified in [RFC3280] 📜 this certificate MUST contain a Subject Name with an empty sequence, and it MUST contain a SubjectAltName extension encoded with the iPAddress type 💀 the Portal IP Address (Section 6.3.1) of the identified Portal SHALL be stored in the SubjectAltName field of the certificate 🦋
6.4. iSCSI Node-Keyed Attributes 🌈
these attributes get stored in the iSNS database using the iSCSI Name attribute as the key 🔑 each set of Node-Keyed attributes is tied to one Entity Identifier object key 🧚
even though the iSCSI Name key is tied to one Entity Identifier, it's unique across the ENTIRE iSNS database 👑
6.4.1. iSCSI Name ✨
this is a variable-length UTF-8 encoded, NULL-terminated text description of up to 224 bytes 📝 this key attribute is required for iSCSI Storage Nodes and gets provided by the iSNS client 🫶 the registered iSCSI Name MUST conform to the format described in [iSCSI] for iSCSI Names 💅 the maximum size for an iSCSI Name is 223 bytes. counting the NULL character and the 4-byte alignment (see Section 5.3.1), the maximum iSCSI Name field size is 224 bytes 🔢
if an iSCSI Name gets registered without an EID key, then a Network Entity SHALL be created and an EID assigned 🆔 the assigned EID SHALL be returned in the registration response as an operating attribute 🎀
this field MUST be normalized according to the stringprep template [STRINGPREP] before it's stored in the iSNS database 🧼
6.4.2. iSCSI Node Type ✨
this required 32-bit field is a bitmap that shows the type of iSCSI Storage Node 🍓 the bit positions are below, and a set bit (1) means the Node has that characteristic 💖
Bit Position Node Type
------------ ---------
29 Control
30 Initiator
31 (Lsb) Target
All others RESERVEDif the Target bit is set to 1, then the Node represents an iSCSI target 🎯 the Target bit MAY be set by iSNS clients using the iSNSP 🦋
if the Initiator bit is set to 1, then the Node represents an iSCSI initiator 🚀 the Initiator bit MAY be set by iSNS clients using the iSNSP 🌸
if the control bit is set to 1, then the Node represents a gateway, a management station, a backup iSNS server, or some other device that isn't an initiator or target, but still needs to send and receive iSNSP messages, including state change notifications 👑 setting the control bit is an administrative task that MUST be performed on the iSNS server 🛠️ iSNS clients SHALL NOT be allowed to change this bit using the iSNSP 🙅♀️
this field MAY be used by the iSNS server to tell apart permissions for different iSCSI Node types when they access various iSNS functions 🧠 more than one Node Type bit can be enabled at the same time, bestie 🫶
6.4.3. iSCSI Node Alias ✨
this is a variable-length UTF-8 encoded, NULL-terminated text description of up to 256 bytes 💜 the Alias is a user-readable description of the Node entry in the iSNS database 🧁
6.4.4. iSCSI Node SCN Bitmap ✨
the iSCSI Node SCN Bitmap shows which events the registering iSNS client wants to get a notification about 🔔 the table below lists the events that trigger notifications, and the bit in the SCN Bitmap that, when enabled, gives you the matching notification 🦋
heads up, this field is dual-use, which is so iconic: it's used in the SCN registration process to define which events will trigger an SCN message, and it's also inside every SCN message to show what type of event set it off 💅 a set bit (1) means that type of SCN 🌈
Bit Position Flag Description
------------ ----------------
24 INITIATOR AND SELF INFORMATION ONLY
25 TARGET AND SELF INFORMATION ONLY
26 MANAGEMENT REGISTRATION/SCN
27 OBJECT REMOVED
28 OBJECT ADDED
29 OBJECT UPDATED
30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
All others RESERVEDDD/DDS MEMBER REMOVED means an existing member of a Discovery Domain and/or Discovery Domain Set got removed 🗑️
DD/DDS MEMBER ADDED means a new member was added to an existing DD and/or DDS ✨
OBJECT REMOVED, OBJECT ADDED, and OBJECT UPDATED mean a Network Entity, Portal, Storage Node, FC Device, DD, and/or DDS object was removed from, added to, or updated in the Discovery Domain or in the iSNS database (Control Nodes only) 🧩
regular SCNs tell you about objects that get updated in, added to, or removed from Discovery Domains that the Storage Node is a member of 🏠 an SCN or SCN registration counts as a regular one if the MANAGEMENT REGISTRATION/SCN flag is cleared 🧹 all iSNS clients can register for regular SCNs 🫶
management SCNs tell you about ALL changes to the network, no matter the discovery domain membership 🌍 registering for management SCNs means setting bit 26 to 1 👑 only Control Nodes may register for management SCNs 🛡️ bits 30 and 31 may only be enabled if bit 26 is set to 1 🔒
TARGET AND SELF INFORMATION ONLY SCNs (bit 25) only tell you about changes to target devices, or if the iSCSI Storage Node itself has changed 🎯 similarly, INITIATOR AND SELF INFORMATION ONLY SCNs (bit 24) only tell you about changes to initiator Nodes, or to the target itself 🚀
6.4.5. iSCSI Node Index ✨
the iSCSI Node Index is a 4-byte non-zero integer that works as a key to uniquely identify each iSCSI Storage Node registered in the iSNS database 🔢 when an iSCSI Storage Node first registers, the iSNS server assigns an unused value for the iSCSI Node Index 🎀 each iSCSI Node MUST be assigned an iSCSI Node Index value that isn't assigned to any other iSCSI Storage Node 💅 and recently deregistered iSCSI Storage Nodes' index values SHOULD NOT be reused in the short term 🙈
the iSCSI Node Index can be used as a key to represent a registered Node when the iSCSI Name is too long to work as a key 🧠 an example is when SNMP is used for management, as described in Section 2.10 🦋
the value assigned for the iSCSI Node Index SHALL persist for as long as the iSCSI Storage Node is registered in the iSNS database or a member of a Discovery Domain 💖 an iSCSI Node Index value assigned to a Storage Node SHALL NOT be used for any other Storage Node while the original node is still registered in the iSNS database or a member of a Discovery Domain 🔒 no sharing, no caring 💜
6.4.6. WWNN Token ✨
okay so this field holds a globally unique 64-bit integer 🔢 that stands in for the World Wide Node Name of the iSCSI device inside a Fibre Channel fabric 🌐. it's used during the device registration process, and it MUST conform to the requirements in [FC-FS] 💅
the FC-iSCSI gateway reads whatever's in here to register the iSCSI device in the Fibre Channel name server 📇. the iSNS server stores it too, so nothing clashes when "proxy" WWNN values get handed out to iSCSI initiators that are setting up storage sessions to devices in the FC fabric 🦋
if the iSNS client doesn't assign a WWNN Token, the iSNS server SHALL provide one when the iSCSI Storage Node first registers 🎀. the process by which the iSNS server assigns the WWNN Token MUST conform to the following requirements 👑:
- The assigned WWNN Token value MUST be unique among all WWN entries in the existing iSNS database, and among all devices that can potentially be registered in the iSNS database.
- Once the value is assigned, the iSNS server MUST persistently save the mapping between the WWNN Token value and the registered iSCSI Name. so if the same iSCSI Name keeps re-registering, the original mapping to its WWNN Token value stays put in the iSNS server 🔒. the mapping SHALL be persistent across iSNS server reboots too. once it's assigned, it can only change if a DevAttrReg message from an authorized iSNS client explicitly provides a different WWNN Token value.
- Once a WWNN Token value has been assigned and mapped to an iSCSI name, that WWNN Token value SHALL NOT be reused or mapped to any other iSCSI name 🚫.
- The assigned WWNN Token value MUST conform to the formatting requirements of [FC-FS] for World Wide Names (WWNs) 🌸.
an iSNS client, like an FC-iSCSI gateway or the iSCSI initiator, MAY register its own WWNN Token value or overwrite the iSNS Server-supplied WWNN Token value 💖, if it wants to supply its own iSCSI-FC name mapping. this happens with the DevAttrReg message, using the WWNN Token (tag=37) as an operating attribute ✨. once it's overwritten, the new WWNN Token value MUST be stored and saved by the iSNS server, and all requirements specified above continue to apply. if an iSNS client tries to register a value for this field that isn't unique in the iSNS database, or that's otherwise invalid, then the registration SHALL be rejected with an Status Code of 3 (Invalid Registration) 🙈.
there MAY be matching records in the iSNS database for the Fibre Channel device specified by the WWNN Token 🧚. those records may hold device attributes for that FC device registered in the Fibre Channel fabric name server.
6.4.7. iSCSI Node Next Index
this is a virtual attribute holding a 4-byte integer that tells you the next available (aka unused) iSCSI Node Index value 🔮. you can only query it. the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that tries to register a value for this attribute 🙅♀️. and you don't need a Message Key when you're only querying for this one 💜.
the iSCSI Node Next Index MAY be used by an SNMP client to create an entry in the iSNS server 🦋. SNMP requirements are described in Section 2.10.
6.4.8. iSCSI AuthMethod
this attribute holds a NULL-terminated string of UTF-8 text that lists the iSCSI authentication methods enabled for this iSCSI Storage Node, in order of preference 👑. the text values that name the authentication methods are embedded in this string and separated by a comma 🎀. they match the ones in the main iSCSI document [iSCSI], and extra vendor-specific text values are possible too 🌈.
Text Value Description Reference
---------- ----------- ---------
KB5 Kerberos V5 [RFC1510]
SPKM1 Simple Public Key GSS-API [RFC2025]
SPKM2 Simple Public Key GSS-API [RFC2025]
SRP Secure Remote Password [RFC2945]
CHAP Challenge Handshake Protocol [RFC1994]
none No iSCSI Authentication6.5. Portal Group (PG) Object-Keyed Attributes
these attributes are used to link Portal and iSCSI Storage Node objects together 🔗. PG objects are stored in the iSNS database using the PG iSCSI Name, the PG Portal IP Address, and the PG Portal TCP/UDP Port as keys 🗝️. new PG objects get implicitly or explicitly created when the matching Portal and/or iSCSI Storage Node objects get registered 💅. Section 3.4 has a general chat about PG usage, and for more on Portal Groups, check out [iSCSI] 📚.
6.5.1. Portal Group iSCSI Name
this is the iSCSI Name for the iSCSI Storage Node that's linked to the PG object 🧸. this name MAY represent an iSCSI Storage Node that isn't registered in the server right now.
6.5.2. PG Portal IP Addr
this is the Portal IP Address attribute for the Portal linked to the PG object 🌐. this Portal IP Address MAY be one for a Portal that isn't registered in the server right now.
6.5.3. PG Portal TCP/UDP Port
this is the Portal TCP/UDP Port attribute for the Portal linked to the PG object 🔌. this Portal TCP/UDP Port MAY belong to a Portal that isn't registered in the server right now.
6.5.4. Portal Group Tag (PGT)
this field groups Portals together so connections in a session can be coordinated across Portals to a specified iSCSI Node 🫶. the PGT is a value in the range of 0-65535, or NULL 🍓. a NULL PGT value gets registered by putting 0 in the length of the TLV during registration. the two least significant bytes of the value hold the PGT for the object, and the two most significant bytes are reserved 🌙. if no PGT value is explicitly registered for an iSCSI Storage Node and Portal pair, then the PGT value SHALL be implicitly registered as 0x00000001 ✨.
6.5.5. Portal Group Index
the PG Index is a 4-byte non-zero integer value that works as a key and uniquely identifies each PG object registered in the iSNS database 🪪. when a PG object is first registered, the iSNS server MUST assign an unused value for the PG Index 🔥. also, PG Index values for recently deregistered PG objects SHOULD NOT be reused in the short term ⏳.
the PG Index MAY be used as the key to reference a registered PG in situations where a unique index for each PG object is required 💜. it MAY also be used as the message key in an iSNS message to query or update a pre-existing PG object. an example is when SNMP is used for management, as described in Section 2.10 🦋. the value assigned for the PG Index SHALL persist as long as the server is active 👑.
6.5.6. Portal Group Next Index
the PG Next Index is a virtual attribute holding a 4-byte integer that shows the next available (aka unused) PG Index value 🔮. you can only query it, and the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that tries to register a value for this attribute 🙅♀️. you don't need a Message Key when you're just querying for this one 🌸.
the Portal Group Next Index MAY be used by an SNMP client to create an entry in the iSNS server 🧚. SNMP requirements are described in Section 2.10.
6.6. FC Port Name-Keyed Attributes
these attributes are registered in the iSNS database using the FC Port World Wide Name (WWPN) attribute as the key 🗝️. each set of FC Port-Keyed attributes is associated with one Entity Identifier object key 💅.
even though the FC Port World Wide Name is tied to one Entity Identifier, it's also globally unique 🌈.
6.6.1. FC Port Name (WWPN)
this 64-bit identifier uniquely defines the FC Port, and it's the World Wide Port Name (WWPN) of the matching Fibre Channel device 🎀. this attribute is the key for the iFCP Storage Node. this globally unique identifier is used during the device registration process, and its value conforms to IEEE EUI-64 [EUI-64] ✨.
6.6.2. Port ID (FC_ID)
the Port Identifier is a Fibre Channel address identifier assigned to an N_Port or NL_Port during fabric login 🛰️. the format of the Port Identifier is defined in [FC-FS]. the least significant 3 bytes contain this address identifier, and the most significant byte is RESERVED 🌙.
6.6.3. FC Port Type
this indicates the type of FC port 🔌. the encoded values for this field are listed in the following table 💖:
Type Description
---- -----------
0x0000 Unidentified/Null Entry
0x0001 Fibre Channel N_Port
0x0002 Fibre Channel NL_Port
0x0003 Fibre Channel F/NL_Port
0x0004-0080 RESERVED
0x0081 Fibre Channel F_Port
0x0082 Fibre Channel FL_Port
0x0083 RESERVED
0x0084 Fibre Channel E_Port
0x0085-00FF RESERVED
0xFF11 RESERVED
0xFF12 iFCP Port
0xFF13-FFFF RESERVED6.6.4. Symbolic Port Name
this is a variable-length UTF-8 encoded NULL-terminated text description of up to 256 bytes 📝. it's associated with the iSNS-registered FC Port Name in the network 🫧.
6.6.5. Fabric Port Name (FWWN)
this 64-bit identifier uniquely defines the fabric port 🌐. if the port of the FC Device is attached to a Fibre Channel fabric port with a registered Port Name, then that fabric Port Name SHALL be indicated in this field 💜.
6.6.6. Hard Address
this field holds the requested hard address 24-bit NL Port Identifier, and it's included in the iSNSP for compatibility with Fibre Channel Arbitrated Loop devices and topologies 🧸. the least significant 3 bytes of this field contain the address, and the most significant byte is RESERVED 🍓.
6.6.7. Port IP Address
this is the Fibre Channel IP address associated with the FC Port 🌊. when this field has an IPv4 value, it's stored as an IPv4-mapped IPv6 address. that means the most significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF [RFC2373] 🦋. when an IPv6 value is in this field, the entire 16-byte field is used 🌈.
6.6.8. Class of Service (COS)
this 32-bit bit-map field shows which Fibre Channel Class of Service types the registered port supports 💅. in the table below, a set bit (1) means that Class of Service is supported ✨.
Bit Position Description
------------ -----------
29 Fibre Channel Class 2 Supported
28 Fibre Channel Class 3 Supported6.6.9. FC-4 Types
this 32-byte field indicates the FC-4 protocol types the associated port supports 🎀. it can be used to support Fibre Channel devices and is consistent with FC-GS-4 🫶.
6.6.10. FC-4 Descriptor
this is a variable-length UTF-8 encoded NULL-terminated text description of up to 256 bytes 📖. it's associated with the iSNS-registered device port in the network 🔥. this field can be used to support Fibre Channel devices and is consistent with FC-GS-4 👑.
6.6.11. FC-4 Features ✨
okay so this one is a 128-byte array 💅 with 4 bits per type, covering the FC-4 protocol types that the port supports. it's there so Fibre Channel devices can use it, and it lines up with FC-GS-4 [FC-GS-4] 🫶
6.6.12. iFCP SCN Bitmap 🔥
this field tells you which events the iSNS client is into 👀 Those events can trigger SCNs. SCNs are the updates about objects that get changed, added, or removed in Discovery Domains where the source and destination are both members. Management SCNs cover every change on the network 😭 A set bit (1) means that type of SCN is on, and here's how the positions line up:
Bit Position Flag Description
------------ ----------------
24 INITIATOR AND SELF INFORMATION ONLY
25 TARGET AND SELF INFORMATION ONLY
26 MANAGEMENT REGISTRATION/SCN
27 OBJECT REMOVED
28 OBJECT ADDED
29 OBJECT UPDATED
30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
All others RESERVEDfor more on how these bit positions get used, check out Section 6.4.4 🎀
6.6.13. Port Role 👑
this is a required 32-bit field that's a bitmap showing what kind of iFCP Storage Node you're dealing with 💖 The bits are below, and when one is set to 1, the node has that trait ✨
Bit Position Node Type
------------ ---------
29 Control
30 FCP Initiator
31 (Lsb) FCP Target
All Others RESERVEDso if the 'Target' bit is 1, the port is an FC target 🎯 Setting that bit is something iSNS clients MAY do through the iSNSP 🦋
same deal for the 'Initiator' bit: 1 means the port is an FC initiator, and iSNS clients MAY set it through the iSNSP 🌸
if the 'Control' bit is 1, the port is a gateway, a management station, an iSNS backup server, or some other device 🧚
Control is usually a special device that's neither an initiator nor a target, but it needs to send and receive iSNSP messages, including state-change notifications 💜 Setting the control bit is an admin job: it MUST be administratively configured on the iSNS server, and iSNS clients SHALL NOT be allowed to change it through the iSNSP 🙈
the iSNS server MAY use this field to tell apart what different iSNS clients are allowed to do 🔥 For example, a server could be set up so only targets get ESIs, or so only Control Nodes can add, modify, or delete discovery domains 💅
6.6.14. Permanent Port Name (PPN) 🌈
the Permanent Port Name can support Fibre Channel devices, and it lines up with the PPN description in FC-GS-4 [FC-GS-4] 🫶 The PPN is formatted exactly like the FC Port Name WWPN attribute 🎀
6.7. Node-Keyed Attributes 🌸
these attributes are registered in the iSNS database using the FC Node Name (WWNN) attribute as the key 🔑 Each set of FC Node-Keyed attributes stands for one device, and that device can be linked to lots of FC Ports ✨
the FC Node Name is unique across the entire iSNS database 💖
6.7.1. FC Node Name (WWNN) 💜
the FC Node Name is a 64-bit identifier, the World Wide Node Name (WWNN) of the Fibre Channel device it belongs to 🧚 This attribute is the key for the FC Device. It's globally unique and gets used during device registration. The value follows IEEE EUI-64 [EUI-64] 🦋
6.7.2. Symbolic Node Name 🍓
this is a variable-length, UTF-8 encoded, NULL-terminated text description of up to 256 bytes 📝 It's tied to the iSNS-registered FC Device on the network ✨
6.7.3. Node IP Address 🌊
this IP address belongs to the device Node on the network 🌐 The field is there for compatibility with Fibre Channel. When it holds an IPv4 value, that value gets stored as an IPv4-mapped IPv6 address 🤓 That means the most significant 10 bytes are 0x00, and the next two bytes are 0xFFFF [RFC2373]. When it holds an IPv6 value, the whole 16-byte field gets used 💅
6.7.4. Node IPA 🐣
this is the 8-byte Fibre Channel Initial Process Associator (IPA) tied to the device Node 🫧 The initial process associator is how Fibre Channel devices talk to each other 💬
6.7.5. Proxy iSCSI Name 🔗
this is a variable-length, UTF-8 encoded, NULL-terminated text field with the iSCSI Name used to represent the FC Node on the IP network 🌉 It works as a pointer to the matching iSCSI Name entry in the iSNS server. Usually an FC-iSCSI gateway registers this value, the one connecting the IP network to the fabric that holds the FC device 🔌
heads up: if this field is used, there SHOULD be a matching entry in the iSNS database for the iSCSI device named by the iSCSI name 🧠 That entry should carry the full range of iSCSI attributes needed to discover and manage the "iSCSI proxy image" of the FC device 🦋
6.8. Other Attributes 🎀
these aren't attributes of the objects we've already covered 💅
6.8.1. FC-4 Type Code 🍒
this is a 4-byte field used to give an FC-4 type during an FC-4 Type query 🔍 The FC-4 types match the ones defined in FC-FS. Byte 0 holds the FC-4 type, and all the other bytes are reserved 💜
6.8.2. iFCP Switch Name 🏠
the iFCP Switch Name is a 64-bit World Wide Name (WWN) that uniquely identifies one specific iFCP gateway on the network 🌟 This globally unique identifier is used during switch registration and the FC_DOMAIN_ID assignment process 🪄 The iFCP Switch Name value MUST conform to the requirements stated in [FC-FS] for World Wide Names 📜 The iSNS server SHALL track the state of every FC_DOMAIN_ID value allocated to each iFCP Switch Name 👀 And if an iFCP Switch Name gets deregistered from the iSNS database, every FC_DOMAIN_ID allocated to it SHALL be returned to the unused pool 🫧
6.8.3. iFCP Transparent Mode Commands 🦋
6.8.3.1. Preferred ID 🌷
this is a 4-byte unsigned integer field, and it's the value the iSNS client would like to use for the FC_DOMAIN_ID 💌 The iSNS server SHALL grant that requested value as the FC_DOMAIN_ID, as long as it hasn't already been allocated 🎉 If it's not available, the iSNS server SHALL return a different value that hasn't been allocated 🙃
6.8.3.2. Assigned ID 🧚
this is a 4-byte unsigned integer field an iFCP gateway uses to reserve its own unique FC_DOMAIN_ID value from the range 1 to 239 🌈 When an FC_DOMAIN_ID isn't needed anymore, the iFCP gateway SHALL release it using the RlseDomId message 🗑️ The iSNS server MUST use the Entity Status Inquiry message to check whether an iFCP gateway is still on the network 🔎
6.8.3.3. Virtual_Fabric_ID 🧩
this is a variable-length, UTF-8 encoded, NULL-terminated text field of up to 256 bytes 🌸 The Virtual_Fabric_ID string works as a key attribute to identify a range of non-overlapping FC_DOMAIN_ID values to be allocated using RqstDomId 🗝️ Each Virtual_Fabric_ID string an iSNS client submits SHALL get its own range of non-overlapping FC_DOMAIN_ID values to hand out to iSNS clients 🫶
6.9. iSNS Server-Specific Attributes 💎
access to these attributes may be administratively controlled 🔐 They're specific to the iSNS server instance, so every iSNS client that talks to the server gets the same value 🤝 Only query messages can be performed on them. If someone tries to register a value for one of these attributes, the server SHALL return a status code of 3 (Invalid Registration) 🚫
a query for an iSNS Server-Specific attribute MUST include the identifying key attribute (that's the iSCSI Name or the FC Port Name WWPN) of the Node that's sending the registration or query message, as both the Source and Message Key attributes 🗝️ The Operating Attributes are the server-specific attributes being registered or queried 💅
6.9.1. iSNS Server Vendor OUI 🏷️
this attribute is the OUI (Organizationally Unique Identifier) [802-1990] that identifies the vendor who made the iSNS server 🏭 It can only be queried. iSNS clients SHALL NOT be allowed to register a value for the iSNS Server Vendor OUI 🙅♀️
6.10. Vendor-Specific Attributes 🌈
iSNS server implementations MAY define vendor-specific attributes for private use 🕵️♀️ These attributes MAY hold optional data that iSNS clients register or query so they can unlock optional features ✨ Any vendor-specific attributes in the iSNS server SHALL NOT impose any kind of mandatory behavior on the iSNS client 🫶
the tag values for vendor-specific and user-specific use are defined in Section 6.1 🏷️ To avoid misreading proprietary attributes, the vendor's own OUI (Organizationally Unique Identifier) MUST be placed in the upper three bytes of the attribute value field itself 🔖
the OUI is defined in IEEE Std 802-1990, and it's the same constant used to make 48-bit Universal LAN MAC addresses 🤯 That way a vendor's own iSNS implementation can spot its OUI in the attribute field and handle the attribute its own special way 💖
6.10.1. Vendor-Specific Server Attributes 🖥️
attributes with tags from 257 to 384 are vendor-specific or site-specific attributes of the iSNS server ✨ The vendor providing the iSNS server implementation sets their values administratively. Query access to these attributes may be administratively controlled 🔒 They're unique for each logical iSNS server instance. Query messages for these attributes SHALL use the key identifier (iSCSI Name or FC Port Name WWPN) for both the Source attribute and the Message Key attribute 🗝️ These attributes can only be queried. iSNS clients SHALL NOT be allowed to register a value for server attributes 🚫
6.10.2. Vendor-Specific Entity Attributes 🧁
attributes in the range 385 to 512 are vendor-specific or site-specific attributes that describe the Network Entity object 🌐 They're keyed by the Entity Identifier attribute (tag=1) 🔑
6.10.3. Vendor-Specific Portal Attributes 🚪
attributes in the range 513 to 640 are vendor-specific or site-specific attributes that describe the Portal object 🌉 They're keyed by the Portal IP-Address (tag=16) and the Portal TCP/UDP Port (tag=17) 🗝️
6.10.4. Vendor-Specific iSCSI Node Attributes 🍭
attributes in the range 641 to 768 are vendor-specific or site-specific attributes that describe the iSCSI Node object 🧸 They're keyed by the iSCSI Name (tag=32) 🏷️
6.10.5. Vendor-Specific FC Port Name Attributes 🦩
attributes in the range 769 to 896 are vendor-specific or site-specific attributes that describe the N_Port Port Name object 🔌 They're keyed by the FC Port Name WWPN (tag=64) 🎯
6.10.6. Vendor-Specific FC Node Name Attributes ✨
Okay so attributes in the range 897 to 1024 are the vendor-specific or site-specific ones 💅 They describe the FC Node Name object, and they're keyed by the FC Node Name WWNN (tag=96). Main character energy for WWNN 🦋
6.10.7. Vendor-Specific Discovery Domain Attributes 🌸
Attributes in the range 1025 to 1280 are vendor-specific or site-specific too, and they describe the Discovery Domain object 🧚 These are keyed by the DD_ID (tag=104).
6.10.8. Vendor-Specific Discovery Domain Set Attributes 🎀
Next up, attributes in the range 1281 to 1536 are vendor-specific or site-specific, and they describe the Discovery Domain Set object 💜 They're keyed by the DD Set ID (tag=101).
6.10.9. Other Vendor-Specific Attributes 🌈
Attributes in the range 1537 to 2048 can be used for key and non-key attributes that describe new vendor-specific objects. These are specific to the vendor's iSNS server implementation, so it's totally up to the vendor what goes here 🫶
6.11. Discovery Domain Registration Attributes 👑
6.11.1. DD Set ID Keyed Attributes 🍓
6.11.1.1. Discovery Domain Set ID (DDS ID) 🔥
Okay, the DDS ID is an unsigned non-zero integer. The iSNS directory database uses it as a key to pin down one Discovery Domain Set uniquely 🔑 A DDS is a collection of Discovery Domains that a management station can enable or disable. This value is the key for DDS attribute queries. When a Discovery Domain gets registered, it's initially not in any DDS, so it starts out solo ✨
If the iSNS client doesn't provide a DDS_ID in a DDS registration request message, the iSNS server SHALL generate a DDS_ID value that's unique within the iSNS database for that new DDS. The created DDS ID SHALL be returned in the response message, so the client knows what it got 💖 The DDS ID value of 0 is reserved, and the DDS ID value of 1 is used for the default DDS (see Section 2.2.2). Iconic 😭
6.11.1.2. Discovery Domain Set Symbolic Name 🦋
This is a variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. It's the user-readable name that helps a network admin keep track of the DDS function 📝 When a client registers a DDS symbolic name, the iSNS server SHALL verify that it's unique. If the name isn't unique, then the DDS registration SHALL be rejected with an "Invalid Registration" Status Code. The invalid attribute(s), in this case the DDS symbolic name, SHALL be included in the response, so the client can see exactly what went wrong 🙈
6.11.1.3. Discovery Domain Set Status 🌸
The DDS_Status field is a 32-bit bitmap showing the status of the DDS. Bit 0 says whether the DDS is Enabled (1) or Disabled (0). The default value for the DDS Enabled flag is Disabled (0), so nothing is on until someone turns it on 💅
Bit Position DDS Status
------------ ---------
31 (Lsb) DDS Enabled (1) / DDS Disabled (0)
All others RESERVED6.11.1.4. Discovery Domain Set Next ID 🧚
This is a virtual attribute holding a 4-byte integer that tells you the next available (i.e., unused) Discovery Domain Set Index value 🔮 It may only be queried. If a client tries to register a value for it, the iSNS server SHALL return an error code of 3 (Invalid Registration) to that client. You don't need a Message Key when you're only querying this one, which is lowkey convenient 🫶
The Discovery Domain Set Next Index MAY be used by an SNMP client to create an entry in the iSNS server. The SNMP requirements are described in Section 2.10 🎀
6.11.2. DD ID Keyed Attributes 💜
6.11.2.1. Discovery Domain ID (DD ID) 🌈
The DD ID is an unsigned non-zero integer identifier. The iSNS directory database uses it as a key to identify one Discovery Domain uniquely 🗝️ This value is the key for any DD attribute query. If the iSNS client doesn't provide a DD_ID in a DD registration request message, the iSNS server SHALL generate a DD_ID value that's unique within the iSNS database for that new DD. That just means the iSNS client gets registered in a brand new DD, lowkey the cutest fresh start ✨ The created DD ID SHALL be returned in the response message. The DD ID value of 0 is reserved, and the DD ID value of 1 is used for the default DD (see Section 2.2.2). Periodt 💖
6.11.2.2. Discovery Domain Symbolic Name 🍓
This is a variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. When a client registers a DD symbolic name, the iSNS server SHALL verify that it's unique. If the name isn't unique, the DD registration SHALL be rejected with an "Invalid Registration" Status Code. The invalid attribute(s), in this case the DD symbolic name, SHALL be included in the response 🫶
6.11.2.3. Discovery Domain Member: iSCSI Node Index 🦋
This is the iSCSI Node Index of a Storage Node that's a member of the DD. A DD may have a list of 0 to n members. The iSCSI Node Index is one way to represent DD membership, and the other way is the iSCSI Name 🔥 The Discovery Domain iSCSI Node Index is a 4-byte non-zero integer value.
The iSCSI Node Index comes in clutch when the iSCSI Name is too long to use. An example is when SNMP is used for management, as described in Section 2.10 🙌
The iSCSI Node Index and the iSCSI Name stored as a member in a DD SHALL be consistent with the iSCSI Node Index and iSCSI Name attributes registered for the Storage Node object in the iSNS server. No mismatches allowed, bestie 💅
6.11.2.4. Discovery Domain Member: iSCSI Name 🌸
This is a variable-length UTF-8 encoded NULL-terminated text-based field of up to 224 bytes. It shows membership for the specified iSCSI Storage Node in the Discovery Domain 💖 Heads up, the referenced Storage Node doesn't need to be actively registered in the iSNS database before the iSNS client uses this attribute. There's no limit to how many members a DD can have, which is giving abundance 🌈 Membership is represented by the iSCSI Name of the iSCSI Storage Node.
6.11.2.5. Discovery Domain Member: FC Port Name 🧚
This 64-bit identifier attribute shows membership for an iFCP Storage Node (FC Port) in the Discovery Domain ✨ Again, the referenced Storage Node doesn't need to be actively registered in the iSNS database before the iSNS client uses it. No limit on members either. Membership is represented by the FC Port Name (WWPN) of the iFCP Storage Node 🎀
6.11.2.6. Discovery Domain Member: Portal Index 👑
This attribute shows membership in the Discovery Domain for a Portal. It's an alternative to representing Portal membership with the Portal IP Address and Portal TCP/UDP Port. The referenced Portal MUST be actively registered in the iSNS database before the iSNS client uses this attribute. This one is strict, no cap 🚫
6.11.2.7. Discovery Domain Member: Portal IP Address 🍓
This attribute and the Portal TCP/UDP Port attribute together show membership in the Discovery Domain for the specified Portal 🦋 The referenced Portal doesn't need to be actively registered in the iSNS database before the iSNS client uses this attribute. Way more relaxed than the Portal Index one 💜
6.11.2.8. Discovery Domain Member: Portal TCP/UDP Port 🌈
This attribute and the Portal IP Address attribute together show membership in the Discovery Domain for the specified Portal ✨ Same deal: the referenced Portal doesn't need to be actively registered in the iSNS database before the iSNS client uses this attribute 🫶
6.11.2.9. Discovery Domain Features 🔮
The Discovery Domain Features is a bitmap showing the features of this DD. The bit positions are defined below. A bit set to 1 means the DD has that characteristic 💅
Bit Position DD Feature
------------ ----------
31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)
All others RESERVEDBoot List: this feature shows that the target(s) in this DD provide boot capabilities for the member initiators, as described in [iSCSI-boot]. Boot list energy is so real 🥹
6.11.2.10. Discovery Domain Next ID 💖
This is a virtual attribute holding a 4-byte integer that tells you the next available (i.e., unused) Discovery Domain Index value 🧚 It may only be queried. If a client tries to register a value for it, the iSNS server SHALL return an error code of 3 (Invalid Registration) to that client. A Message Key isn't required when you're only querying this attribute 🎀
7. Security Considerations 💀
7.1. iSNS Security Threat Analysis 🚨
Okay, serious moment, bestie. When the iSNS protocol is deployed, the interaction between iSNS server and iSNS clients is subject to the following security threats:
a) An attacker could alter iSNS protocol messages, such as to direct iSCSI and iFCP devices to establish connections with rogue peer devices, or to weaken/eliminate IPSec protection for iSCSI or iFCP traffic. Absolutely not 😤
b) An attacker could masquerade as the real iSNS server using false iSNS heartbeat messages. This could cause iSCSI and iFCP devices to use rogue iSNS servers. That's a whole villain arc 💀
c) An attacker could gain knowledge about iSCSI and iFCP devices by snooping iSNS protocol messages. Such information could help an attacker mount a direct attack on iSCSI and iFCP devices, such as a denial-of-service attack or outright physical theft. Not it 🙅♀️
To address these threats, the following capabilities are needed:
a) Unicast iSNS protocol messages may need to be authenticated. To guard against threat c), confidentiality support is desirable and is REQUIRED when certain functions of the iSNS server are utilized. Lock it down 🔒
b) Multicast iSNS protocol messages, such as the iSNS heartbeat message, may need to be authenticated. These messages don't need to be confidential since they don't leak critical information, so that's a relief 🫶
7.2. iSNS Security Implementation and Usage Requirements ✨
okay bestie, if the iSNS server is handing out authorizations for communication between iFCP and iSCSI peers, then IPsec ESP with null transform MUST be implemented 🔐, and a non-null transform MAY be implemented too. If you do go non-null, the DES encryption algorithm SHOULD NOT be used 🙅♀️ (DES is so last decade).
If the iSNS server is distributing security policy for iFCP and iSCSI devices, then authentication, data integrity, and confidentiality MUST be supported and used 💖. When confidentiality is desired or required, IPSec ESP with non-null transform SHOULD be used, and the DES encryption algorithm SHOULD NOT be used either. Same energy as before, no cap.
If the iSNS server is providing the boot list for clients, as described in Section 6.11.2.9, then the iSCSI boot client SHOULD implement a secure iSNS connection 🧚.
To protect against an attacker pretending to be an iSNS server 👀, client devices MUST support the ability to authenticate broadcast or multicast messages, like the iSNS heartbeat. The iSNS authentication block (which is identical in format to the SLP authentication block) SHALL be used for this 🎀. iSNS clients MUST implement the iSNS authentication block and MUST support BSD value 0x002. If the iSNS server supports broadcast or multicast iSNS messages (aka the heartbeat), then the server MUST implement the iSNS authentication block and MUST support BSD value 0x002 as well. Also, the authentication block is only for iSNS broadcast or multicast messages, so it MUST NOT be used in unicast iSNS messages 🙈.
There is no requirement that the communicating identities in iSNS protocol messages be kept confidential. Specifically, the identity and location of the iSNS server is not considered confidential 🌸.
For protecting unicast iSNS protocol messages, iSNS servers supporting security MUST implement ESP in tunnel mode and MAY implement transport mode 🦋.
All iSNS implementations supporting security MUST support the replay protection mechanisms of IPsec. No replay drama allowed 💅.
iSNS security implementations MUST support both IKE Main Mode and Aggressive Mode for authentication, negotiation of security associations, and key management, using the IPSec DOI [RFC2407] 🔑.
Manual keying SHOULD NOT be used, since it does not provide the necessary rekeying support 🙅♀️. Conforming iSNS security implementations MUST support authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKEs Sections 5.2 and 5.3 [RFC2409] SHOULD NOT be supported 🫶.
Conforming iSNS implementations MUST support both IKE Main Mode and Aggressive Mode, again, because it's that important 🔥. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers use dynamically assigned IP addresses. Main Mode with pre-shared key authentication is pretty secure in lots of cases, but dynamically assigned addresses force a group pre-shared key, and that group key is vulnerable to man-in-the-middle attack 😭. IKE Identity Payload ID_KEY_ID MUST NOT be used 🚫.
When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used ✨. In every case, access to locally stored secret information (the pre-shared key or the private key for digital signing) MUST be suitably restricted, because if that secret leaks, the security properties of the IKE/IPsec protocols are totally nullified 💀.
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted under its local policy 🎀. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures 🔍.
When the iSNS server is used without security, IP block storage protocol implementations MUST support a negative cache for authentication failures 🧠. This lets implementations avoid constantly contacting discovered endpoints that fail authentication, whether within IPsec or at the application layer (in the case of iSCSI Login). The negative cache doesn't have to live inside the IPsec implementation; it can live within the IP block storage protocol implementation instead 🦋.
7.3. Discovering Security Requirements of Peer Devices 🕵️♀️
Once communication between iSNS clients and the iSNS server has been secured with IPSec, the iSNS client devices can discover the security settings they need for their peer-to-peer communications using the iSCSI and/or iFCP protocols 🌈. This gives a potential scaling advantage over configuring each iSCSI and iFCP device's security policies one by one. Big brain move 🧠✨.
The iSNS server stores security settings for each iSCSI and iFCP device interface. These settings can be retrieved by authorized hosts, and they include use or non-use of IPSec, IKE, Main Mode, and Aggressive Mode. For example, IKE might not be enabled for a particular interface of a peer device. If a peer device can learn that in advance by checking the iSNS server, it won't waste time and resources trying to start an IKE phase 1 session with that peer device interface 🙌.
If iSNS is used for this purpose, the minimum information that should be learned from the iSNS server is whether each iFCP or iSCSI peer device interface uses IKE and IPSec. This information is encoded in the Security Bitmap field of each Portal of the peer device, and it applies on a per-interface basis for that peer device 🍓. iSNS queries for acquiring security configuration data about peer devices MUST be protected by IPSec/ESP authentication 🔐.
7.4. Configuring Security Policies of iFCP/iSCSI Devices 🛠️
Using iSNS to distribute security policies can cut down on the manual device configuration burden, and it can lower the chance of communication failures caused by incompatible security policies 💜. If iSNS is used to distribute security policies, then IPSec authentication, data integrity, and confidentiality MUST be used to protect all iSNS protocol messages 🔒.
The complete IKE/IPSec configuration of each iFCP and/or iSCSI device can be stored in the iSNS server, including policies used for IKE Phase 1 and Phase 2 negotiations between client devices 👑. The IKE payload format includes a series of one or more proposals that the iSCSI or iFCP device will use when negotiating the appropriate IPsec policy to protect iSCSI or iFCP traffic.
The iSCSI Authentication Methods used by each iSCSI device can also be stored in the iSNS server. The iSCSI AuthMethod field (tag=42) contains a null-terminated string with text values that indicate the iSCSI authentication methods that device should use 🎀.
Note that iSNS distribution of security policy isn't necessary if the security settings can be figured out some other way, like manual configuration or IPsec security policy distribution 🌸. If a network entity has already obtained its security configuration through other mechanisms, then it MUST NOT request security policy via iSNS 🙅♀️.
7.5. Resource Issues 💻
The iSNS protocol is lightweight and won't generate a significant amount of traffic 🪶. iSNS traffic is mostly occasional registration, notification, and update messages that don't eat up much bandwidth. Even software-based IPSec implementations should not have a problem handling the traffic loads the iSNS protocol makes 💅.
To fulfill iSNS security requirements, the only extra resources needed beyond what iSCSI and iFCP already require are on the iSNS server side 🖥️. Because iSCSI and iFCP end nodes are already required to implement IKE and IPSec, those existing requirements can also be used to cover IKE and IPSec for iSNS clients. Efficiency is iconic 🦋.
7.6. iSNS Interaction with IKE and IPSec 🔗
When IPSec security is enabled, each iSNS client with at least one Storage Node that is registered in the iSNS database SHALL maintain at least one phase-1 security association with the iSNS server 🤝. All iSNS protocol messages between iSNS clients and the iSNS server SHALL be protected by a phase-2 security association 🔐.
When a Network Entity is removed from the iSNS database, the iSNS server SHALL send a phase-1 delete message to the associated iSNS client IKE peer, and tear down all phase-1 and phase-2 SAs associated with that iSNS client 💔. Bye bye, clean exit 👋.
8. IANA Considerations 📋
The well-known TCP and UDP port number for iSNS is 3205 🎀.
This standards action creates two registries for IANA to maintain in support of iSNSP, and it assigns initial values for both. The first registry is of Block Storage Protocols supported by iSNS. The second is a detailed registry of standard iSNS attributes that can be registered to and queried from the iSNS server 🗂️. Note that this RFC uses the registry created for Block Structure Descriptor (BSD) in Section 15 of Service Location Protocol, Version 2 [RFC2608] 🌈.
8.1. Registry of Block Storage Protocols 🧱
To maintain a registry of block storage protocols supported by iSNSP, IANA will assign a 32-bit unsigned integer number for each block storage protocol supported by iSNS. This number is stored in the iSNS database as the Entity Protocol. The initial set of values IANA maintains for Entity Protocol is in the table in Section 6.2.2 🍭. Additional values for new block storage protocols supported by iSNS SHALL be assigned by the IPS WG Chairperson, or by a Designated Expert [RFC2434] appointed by the IETF Transport Area Director 🧚.
8.2. Registry of Standard iSNS Attributes 📚
IANA is responsible for creating and maintaining the Registry of Standard iSNS Attributes. The initial list of iSNS attributes is described in Section 6. For each iSNS attribute, this information MUST include its tag value, the attribute length, and the tag values for the set of permissible registration and query keys that can be used for that attribute 💖. The initial list of iSNS attributes IANA maintains is indicated in Section 6.1.
Additions of new standard attributes to the Registry of Standard iSNS Attributes SHALL require IETF Consensus [RFC2434] 🗳️. The RFC required for this process SHALL specify use of tag values reserved for IANA allocation in Section 6.1. The RFC SHALL specify, as a minimum, the new attribute tag value, attribute length, and the set of permissible registration and query keys for the new attribute. The RFC SHALL also include a discussion of the reasons for the new attribute(s) and how they are to be used 🌸.
As part of getting IETF Consensus, the proposed RFC and its supporting documentation SHALL be made available to the IPS WG mailing list or, if the IPS WG is disbanded at that time, to a mailing list designated by the IETF Transport Area Director 📬. The review and comment period SHALL last at least three months before the IPS WG Chair or a person designated by the IETF Transport Area Director decides either to reject the proposal or to forward the draft to the IESG for publication as an RFC ⏳. When the specification is published as an RFC, IANA will register the new iSNS attribute(s) and make the registration available to the community 🦋✨.
8.3. Block Structure Descriptor (BSD) Registry 💅✨
okay so IANA is already in charge of the values for the Block Structure Descriptor for the iSNS Authentication Block 🔐 (go peek at Section 5.5 if you want the deets). and for how new BSD values get allocated, you go to Section 15 of [RFC2608] 🦋
9. Normative References 📚💖
bestie, these are the normative references, the docs this one really leans on 🫶 every one is listed below with all its details
- [iSCSI] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
- [iFCP] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and M. Edwards, "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005.
- [iSNSOption] Monia, C., Tseng, J., and K. Gibbons, The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service, RFC 4174, September 2005.
- [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2 ", RFC 2608, June 1999.
- [iSCSI-SLP] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T. Sperry, "Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLP), RFC 4018, April 2005.
- [iSCSI-boot] Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Samll Computer System Interface (iSCSI) Protocol", RFC 4173, September 2005.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [STRINGPREP] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
- [NAMEPREP] Hoffman, P. Nameprep: A Stringprep Profile for Internationalized Domain Names, July 2002.
- [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
- [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [EUI-64] Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority, May 2001, IEEE
- [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [802-1990] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, Technical Committee on Computer Communications of the IEEE Computer Society, May 31, 1990
- [FC-FS] Fibre Channel Framing and Signaling Interface, NCITS Working Draft Project 1331-D
10. Informative References 🌸🧚
these ones are the informative extras 🍓 handy to have around, not the core must-reads
- [iSNSMIB] Gibbons, K., et al., "Definitions of Managed Objects for iSNS (Internet Storage name Service)", Work in Progress, July 2003.
- [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997
- [FC-GS-4] Fibre Channel Generic Services-4 (work in progress), NCITS Working Draft Project 1505-D
- [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
- [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
- [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
- [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
Appendix A: iSNS Examples 🎀
okay the examples time 🤩 this bit is where it all clicks
A.1. iSCSI Initialization Example 🦋
this example assumes an SLP Service Agent (SA) has been implemented on the iSNS host, and an SLP User Agent (UA) has been implemented on the iSNS initiator. see [RFC2608] for further details on SAs and UAs. it also assumes that the target is configured to use the iSNS server, and have its access control policy subordinated to the iSNS server.
A.1.1. Simple iSCSI Target Registration 🌈
in this one, a simple target with a single iSCSI name registers with the iSNS server 💖 the target is represented in the iSNS by an Entity containing one Storage Node, one Portal, and an implicitly registered Portal Group that provides a relationship between the Storage Node and Portal. the target has not been assigned a Fully Qualified Domain Name (FQDN) by the administrator. because a PG object is not explicitly registered here, a Portal Group with a PGT of 1 is implicitly registered. in this example SLP is used to discover the location of the iSNS Server. an alternative is to use the iSNS DHCP option [iSNSOption] to discover the iSNS server. ✨
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS Server |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP------->| |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.0.2.100 | authorized to view|
| | | all DDs. Device |
| DevAttrReg--------->| | NAMEabcd was |
|Src:(tag=32) "NAMEabcd" | | previously placed |
|Key: <none present> | | into DDabcd along |
|Oper Attrs: | | with devpdq and |
|tag=1: NULL | | devrst. |
|tag=2: "iSCSI" | | |
|tag=16: 192.0.2.5 | | |
|tag=17: 5001 | | |
|tag=32: "NAMEabcd" | | |
|tag=33: target | | |
|tag=34: "disk 1" | | |
| |<---DevAttrRegRsp | |
| |SUCCESS | |
| |Key:(tag=1) "isns:0001" |
| |Oper Attrs: | |
| |tag=1: "isns:0001"| |
| |tag=2: "iSCSI" | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
| |tag=33: target | |
| |tag=34: "disk 1" | |
| | | |
| | SCN-------->| |
| |(or SNMP notification) |
| |dest:(tag=32):"MGMTname1" |
| |time:(tag=4): <current time> |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEabcd"| |
| | |<-------SCNRsp |
| DevAttrQry--------->| | |
|Src:(tag=32) "NAMEabcd" | | |
|Key:(tag=33) "initiator" | | |
|Oper Attrs: | | |
|tag=16: NULL | | |
|tag=17: NULL | | |
|tag=32: NULL | | |
|/*Query asks for all initr| | |
|devices' IP address, port |<---DevAttrQryRsp | |
|number, and Name*/ |SUCCESS | |
| |tag=16:192.0.2.1 | |
| |tag=17:50000 | |
| |tag=32:"devpdq" | |
| |tag=16:192.0.2.2 | |
| |tag=17:50000 | |
| |tag=32:"devrst" | |
|/*************************| |<-----DevAttrQry |
|Our target "NAMEabcd" | |src: "MGMTname1" |
|discovers two initiators | key:(tag=32)"NAMEabcd"
|in shared DDs. It will | |Op Attrs: |
|accept iSCSI logins from | |tag=16: NULL |
|these two identified | |tag=17: NULL |
|initiators presented by | |tag=32: NULL |
|iSNS | | |
|*************************/| DevAttrQryRsp--->| |
| |SUCCESS | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
+--------------------------+------------------+-------------------+A.1.2. Target Registration and DD Configuration 🎀
okay so this one is the main character example 💅 A more complex target shows up with two Storage Nodes and two Portals using ESI monitoring, and it registers with the iSNS server. 🦋 It's been set up with a Fully Qualified Domain Name (FQDN) in the DNS servers, and the user wants to use that name as the device's identifier. 🌸 The target explicitly registers Portal Groups, which is how it describes which Portal gives access to which Storage Node. 🧚 One Storage Node allows coordinated access through both Portals, and the other Storage Node allows access through both Portals but not coordinated access. 👑
Here's the whole flow, step by step:
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS Server |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.0.2.100 | authorized to view|
| DevAttrReg--> | | all DDs */ |
|Src: | | |
|tag=32: "NAMEabcd" | | |
|Msg Key: | | |
|tag=1: "jbod1.example.com"| | |
|Oper Attrs: | | |
|tag=1: "jbod1.example.com"| | |
|tag=2: "iSCSI" | | |
|tag=16: 192.0.2.4 | | |
|tag=17: 5001 | | |
|tag=19: 5 | | |
|tag=20: 5002 | | |
|tag=16: 192.0.2.5 | | |
|tag=17: 5001 | | |
|tag=19: 5 | | |
|tag=20: 5002 | | |
|tag=32: "NAMEabcd" | | |
|tag=33: "Target" | | |
|tag=34: "Storage Array 1" | | |
|tag=51: 10 | | |
|tag=49: 192.0.2.4 | | |
|tag=50: 5001 | | |
|tag=49: 192.0.2.5 | | |
|tag=50: 5001 | | |
|tag=32: "NAMEefgh" | | |
|tag=33: "Target" | | |
|tag=34: "Storage Array 2" |/*****************| |
|tag=51: 20 |jbod1.example.com is |
|tag=49: 192.0.2.4 |now registered in | |
|tag=50: 5001 |iSNS, but is not | |
|tag=51: 30 |in any DD. Therefore, |
|tag=49: 192.0.2.5 |no other devices | |
|tag=50: 5001 |can "see" it. | |
| |*****************/| |
| |<--DevAttrRegRsp | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=1: "jbod1.example.com" |
| |Oper Attrs: | |
| |tag=1: "jbod1.example.com" |
| |tag=2: "iSCSI" | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=19: 5 | |
| |tag=20: 5002 | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=19: 5 | |
| |tag=20: 5002 | |
| |tag=32: "NAMEabcd"| |
| |tag=33: "Target" | |
| |tag=34: "Storage Array 1" |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.4 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.5 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| |tag=32: "NAMEefgh"| |
| |tag=33: "Target" | |
| |tag=34: "Storage Array 2" |
| |tag=43: X.509 cert| |
| |tag=48: "NAMEefgh"| |
| |tag=49: 192.0.2.4 | |
| |tag=50: 5001 | |
| |tag=51: 20 | |
| |tag=48: "NAMEefgh"| |
| |tag=49: 192.0.2.5 | |
| |tag=50: 5001 | |
| |tag=51: 30 | |
| | | |
| | SCN------> | |
| | (or SNMP notification) |
| |dest:(tag=32)"mgmt.example.com" |
| |time:(tag=4): <current time> |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEabcd"| |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEefgh"| |
| | |<--SCNRsp |
| | |SUCCESS |
| | tag=32:"mgmt.example.com"|
| | | |
| | |<--DevAttrQry |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=32: "NAMEabcd" |
| | |Oper Attrs: |
| | |tag=16: <0-length> |
| | |tag=17: <0-length> |
| | |tag=32: <0-length> |
| | | |
| | DevAttrQryRsp--> | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=32: "NAMEabcd"| |
| |Oper Attrs: | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEabcd" | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEabcd" | |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=32: "NAMEefgh" |
| | |Oper Attrs: |
| | |tag=16: <0-length> |
| | |tag=17: <0-length> |
| | |tag=32: <0-length> |
| | | |
| | DevAttrQryRsp--> | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=32: "NAMEefgh"| |
| |Oper Attrs: | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEefgh" | |
| |tag=16: 192.0.2.5 |/**Mgmt Station ***|
| |tag=17: 5001 |displays device, |
| |tag=32:"NAMEefgh" |the operator decides
| | |to place "NAMEabcd"|
| | |into Domain "DDxyz"|
|/*************************| |******************/|
|Target is now registered | | |
|in iSNS. It is then placed| |<--DDReg |
|in a pre-existing DD with | |Src: |
|DD_ID 123 by a management | tag=32:"mgmt.example.com"
|station. | |Msg Key: |
|*************************/| |tag=2065: 123 |
| | |Oper Attrs: |
| | |tag=2068: "NAMEabcd"
| | DDRegRsp-----> | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=2065: 123 | |
| |Oper Attrs: | |
| |tag=2065: 123 | |
+--------------------------+------------------+-------------------+The big takeaway? jbod1.example.com pops up in iSNS first, but it isn't in any DD yet, so nobody else can "see" it 🙈 It only becomes visible after the management station drops "NAMEabcd" into DD 123. Iconic plot twist, honestly 😭✨
A.1.3. Initiator Registration and Target Discovery 🧚
okay next up we've got a brand new initiator registering with the iSNS and going looking for the target NAMEabcd from A.1.2. 🦋 This is the "new kid finds the popular girl" storyline and I'm obsessed 💖
okay bestie, this is the whole storyline in one picture 🧚✨ the initiator, the iSNS server, and the management station all take turns talking 💖
+--------------------------+------------------+-------------------+
| iSCSI Initiator | iSNS |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.36.53.1 | authorized to view|
|DevAttrReg--> | | all DDs ********/ |
|Src: | | |
|tag=32: "NAMEijkl" | | |
|Msg Key: | | |
|tag=1: "svr1.example.com" | | |
|Oper Attrs: | | |
|tag=1: "svr1.example.com" | | |
|tag=2: "iSCSI" | | |
|tag=16: 192.20.3.1 |/*****************| |
|tag=17: 5001 |Device not in any | |
|tag=19: 5 |DD, so it is | |
|tag=20: 5002 |inaccessible by | |
|tag=32: "NAMEijkl" |other devices | |
|tag=33: "Initiator" |*****************/| |
|tag=34: "Server1" | | |
|tag=51: 11 | | |
|tag=49: 192.20.3.1 | | |
|tag=50: 5001 | | |
| |<--DevAttrRegRsp | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=1: "svr1.example.com" |
| |Oper Attrs: | |
| |tag=1: "svr1.example.com" |
| |tag=2: "iSCSI" | |
| |tag=16: 192.20.3.1| |
| |tag=17: 5001 | |
| |tag=19: 5 | |
| |tag=20: 5002 | |
| |tag=32: "NAMEijkl"| |
| |tag=33: "Initiator" |
| |tag=34: "Server1" | |
| |tag=48: "NAMEijkl"| |
| |tag=49: 192.20.3.1| |
| |tag=50: 5001 | |
| |tag=51: 11 | |
| | | |
| | SCN------> | |
| | (or SNMP notification) |
| |dest:(tag=32)"mgmt.example.com" |
| |time:(tag=4): <current time> |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEijkl"| |
| | | |
| | |<------SCNRsp |
| | |SUCCESS |
| | tag=32:"mgmt.example.com"
| | | |
|SCNReg--> | | |
|Src: | | |
|tag=32: "NAMEijkl" | | |
|Msg Key: | | |
|tag=32: "NAMEijkl" | | |
|Oper Attrs: | | |
|tag=35: <TARG&SELF, OBJ-RMV/ADD/UPD> | |
| |<--SCNRegRsp | |
| |SUCCESS | |
| | | |
| | |<----DevAttrQry |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=32: "NAMEijkl" |
| | |Oper Attrs: |
| | |tag=16: <0-length> |
| | |tag=17: <0-length> |
| | |tag=32: <0-length> |
| | DevAttrQryRsp--->| |
| |SUCCESS | |
| |Msg Key: | |
| |tag=32: "NAMEijkl"| |
| |Oper Attrs: | |
| |tag=16:192.20.3.1 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEijkl" | |
| | |/**Mgmt Station ***|
| | |displays device, the
| | |operator decides to|
| | |place "NAMEijkl" into
| | |pre-existing Disc |
| | |Domain "DDxyz" with|
| | |device NAMEabcd |
| | |******************/|
| | |<--DDReg |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=2065: 123 |
| | |Oper Attrs: |
| | |tag=2068: "NAMEijkl"
| | | |
| | DDRegRsp---->| |
| |SUCCESS | |
| |Msg Key: | |
| |tag=2065: 123 | |
| |Oper Attrs: | |
| |tag=2065: 123 |/******************|
| | |"NAMEijkl" has been|
| | |moved to "DDxyz" |
| | |******************/|
| | SCN------>| |
| |dest:(tag=32)"mgmt.example.com" |
| |time:(tag=4): <current time> |
| |tag=35: <MGT-SCN, DD/DDS-MBR-ADD> |
| |tag=2065: 123 | |
| |tag=2068: "NAMEijkl" |
| | | |
| | |<------SCNRsp |
| | |SUCCESS |
| | tag=32:"mgmt.example.com"
| |<-----SCN | |
| |dest:(tag=32)"NAMEijkl" |
| |time:(tag=4): <current time> |
| |tag=35: <TARG&SELF, OBJ-ADD> |
| |tag=32: "NAMEijkl"| |
| SCNRsp------> | | |
|SUCCESS | | |
|tag=32:"NAMEijkl" | | |
| | | |
| |/*****************| |
| |Note that NAMEabcd| |
| |also receives an | |
| |SCN that NAMEijkl | |
| |is in the same DD | |
| |*****************/| |
| (to "NAMEabcd")|<-----SCN | |
| |dest:(tag=32)"NAMEabcd" |
| |time:(tag=4): <current time> |
| |tag=35: <INIT&SELF, OBJ-ADD> |
| |tag=32: "NAMEijkl"| |
| SCNRsp------> | | |
|SUCCESS | | |
|tag=32:"NAMEabcd" | | |
| | | |
| DevAttrQry----------->| | |
|Src: | | |
|tag=32: "NAMEijkl" | | |
|Msg Key: | | |
|tag=33: "Target" | | |
|Oper Attrs: | | |
|tag=16: <0-length> | | |
|tag=17: <0-length> | | |
|tag=32: <0-length> | | |
|tag=34: <0-length> | | |
|tag=43: <0-length> | | |
|tag=48: <0-length> | | |
|tag=49: <0-length> | | |
|tag=50: <0-length> | | |
|tag=51: <0-length> | | |
| |<--DevAttrQryRsp | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=33:"Target" | |
| |Oper Attrs: | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
| |tag=34: "Storage Array 1" |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
| |tag=34: "Storage Array 1" | | |tag=43: X.509 cert| |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.4 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.5 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| | | |
|/***The initiator has discovered | |
|the target, and has everything | |
|needed to complete iSCSI login | |
|The same process occurs on the | |
|target side; the SCN prompts the | |
|target to download the list of | |
|authorized initiators from the | |
|iSNS (i.e., those initiators in the | |
|same DD as the target.************/ | |
+--------------------------+------------------+-------------------+Acknowledgements ✨
Okay bestie, so a huge thank-you to everyone who helped make this doc happen 🫶 Tons of people reviewed it carefully and sent in comments and recommendations, and we're giving a shoutout to these legends for their technical contributions: Mark Bakke (Cisco), John Hufferd (IBM), Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe Czap (IBM), John Dowdy (IBM), Tom McSweeney (IBM), Jim Hafner (IBM), Chad Gregory (Intel), Yaron Klein (Sanrad), Larry Lamers (Adaptec), Jack Harwood (EMC), David Black (EMC), David Robinson (Sun), Alan Warwick (Microsoft), Bob Snead (Microsoft), Fa Yoeu (Intransa), Joe White (McDATA), Charles Monia (McDATA), Larry Hofer (McDATA), Ken Hirata (Vixel), Howard Hall (Pirus), Malikarjun Chadalapaka (HP), Marjorie Krueger (HP), Siva Vaddepuri (McDATA), and Vinai Singh (American Megatrends). 💜 Iconic, every one of them.
Authors' Addresses 🎀
Here are the authors and where to find them. Their details are below, exactly as written.
Josh Tseng 🌸
Josh Tseng
Riverbed Technology
501 2nd Street, Suite 410
San Francisco, CA 94107
Phone: (650)274-2109
EMail: joshtseng@yahoo.comKevin Gibbons 🦋
Kevin Gibbons
McDATA Corporation
4555 Great America Parkway
Santa Clara, CA 95054-1208
Phone: (408) 567-5765
EMail: kevin.gibbons@mcdata.comFranco Travostino 🧚
Franco Travostino
Nortel
600 Technology Park Drive
Billerica, MA 01821 USA
Phone: (978) 288-7708
EMail: travos@nortel.comCurt du Laney 🍓
Curt du Laney
Rincon Research Corporation
101 North Wilmot Road, Suite 101
Tucson AZ 85711
Phone: (520) 519-4409
EMail: cdl@rincon.comJoe Souza 👑
Joe Souza
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Phone: (425) 706-3135
EMail: joes@exmsft.comFull Copyright Statement 💅
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🌈
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🫶
Acknowledgement ⭐
Funding for the RFC Editor function is currently provided by the Internet Society. ✨ And that's a wrap, bestie! 🦋
📦 where this page comes from
- ietf: rfc4171 2005-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms