IPS Josh Tseng Internet Draft Kevin Gibbons Nishan Systems Standards Track Expires January 2003 Franco Travostino Nortel Networks Curt Du Laney IBM Joe Souza Microsoft July 2002 Internet Storage Name Service (iSNS) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Acknowledgements Numerous individuals contributed to the creation of this draft through their careful review and submissions of comments and recommendations. We acknowledge the following persons for their technical contributions to this document: 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 (SAN Valley), Jack Harwood (EMC), David Black (EMC), David Robinson (Sun), Alan Warwick (Microsoft), Bob Snead (Microsoft), Fa Yoeu (Nishan), Charles Monia (Nishan), Ken Hirata (Vixel), Howard Hall (Pirus), Malikarjun Chadalapaka (HP), Marjorie Krueger (HP), and Vinai Singh (American Megatrends). Gibbons, Tseng, Monia Standards Track [Page 1] Internet Storage Name Service (iSNS) May 2002 Comments Comments should be sent to the IPS mailing list (ips@ece.cmu.edu) or to the authors. Table of Contents Status of this Memo...................................................1 Acknowledgements......................................................1 Comments..............................................................2 1. Abstract.......................................................6 2. About this Document............................................6 2.1 Conventions Used in this Document..............................6 2.2 Purpose of this Document.......................................6 3. iSNS Overview..................................................6 3.1 iSNS Architectural Components..................................7 3.1.1 iSNS Protocol (iSNSP)..........................................7 3.1.2 iSNS Client....................................................7 3.1.3 iSNS Server....................................................7 3.1.4 iSNS Database..................................................7 3.1.5 iSCSI..........................................................7 3.1.6 iFCP...........................................................8 3.2 iSNS Functional Overview.......................................8 3.2.1 Name Registration Service......................................8 3.2.2 Discovery Domain and Login Control Service (Zoning)............8 3.2.3 State Change Notification Service.............................10 3.2.4 Open Mapping Between Fibre Channel and iSCSI Devices..........10 3.3 iSNS Usage Model..............................................11 3.3.1 iSCSI Initiator...............................................11 3.3.2 iSCSI Target..................................................11 3.3.3 iSCSI-FC Gateway..............................................12 3.3.4 iFCP Gateway..................................................12 3.3.5 Management Station............................................12 3.4 Administratively Controlled iSNS Settings.....................12 3.5 iSNS Server Discovery.........................................13 3.5.1 Service Location Protocol (SLP)...............................13 3.5.2 Dynamic Host Configuration Protocol (DHCP)....................14 3.5.3 iSNS Heartbeat Message........................................14 3.6 iSNS and NAT..................................................14 3.7 Transfer of iSNS Database Records between iSNS Servers........14 3.8 Backup iSNS Servers...........................................16 4. iSNS Object Model.............................................18 4.1 NETWORK ENTITY Object.........................................18 4.2 PORTAL Object.................................................18 4.3 STORAGE NODE Object...........................................18 4.4 FC DEVICE Object..............................................19 4.5 DISCOVERY DOMAIN Object.......................................19 4.6 DISCOVERY DOMAIN SET Object...................................19 4.7 iSNS Database Model...........................................19 5. iSNS Implementation Requirements..............................20 5.1 iSCSI Requirements............................................20 5.1.1 Required Attributes for Support of iSCSI......................20 5.1.2 Example iSCSI Object Model Diagrams...........................21 5.1.3 Required Commands and Response Messages for Support of iSCSI..23 Tseng, Gibbons, et al. Standards Track [Page 2] Internet Storage Name Service (iSNS) May 2002 5.2 iFCP Requirements.............................................24 5.2.1 Required Attributes for Support of iFCP.......................24 5.2.2 Example iFCP Object Model Diagram.............................26 5.2.3 Required Commands and Response Messages for Support of iFCP...26 5.3 Use of TCP For iSNS Communication.............................28 5.4 Use of UDP For iSNS Communication.............................28 6. iSNSP Message Format..........................................29 6.1 iSNSP PDU Header..............................................29 6.1.1 iSNSP Version.................................................29 6.1.2 iSNSP Function ID.............................................29 6.1.3 iSNSP PDU Length..............................................30 6.1.4 iSNSP Flags...................................................30 6.1.5 iSNSP Transaction ID..........................................30 6.1.6 iSNSP Sequence ID.............................................30 6.2 iSNSP Message Segmentation and Reassembly.....................30 6.3 iSNSP Message Payload.........................................31 6.3.1 Attribute Value 4-Byte Alignment..............................31 6.4 iSNSP Response Status Codes...................................31 6.5 iSNS Multicast Message Authentication.........................32 6.6 Registration and Query Messages...............................33 6.6.1 Source Attribute..............................................34 6.6.2 Message Key Attributes........................................34 6.6.3 Delimiter Attribute...........................................35 6.6.4 Operating Attributes..........................................35 6.6.5 Registration and Query Request Message Types..................36 6.7 Response Messages.............................................48 6.7.1 Status Code...................................................48 6.7.2 Message Key Attributes in Response............................49 6.7.3 Delimiter Attribute in Response...............................49 6.7.4 Operating Attributes in Response..............................49 6.7.5 Registration and Query Response Message Types.................49 6.8 Vendor Specific Messages......................................53 7. iSNS Message Attributes.......................................53 7.1 iSNS Attribute Summary........................................53 7.2 Entity Identifier-Keyed Attributes............................56 7.2.1 Entity Identifier (EID).......................................56 7.2.2 Entity Protocol...............................................56 7.2.3 Management IP Address.........................................57 7.2.4 Entity Registration Timestamp.................................57 7.2.5 Protocol Version Range........................................57 7.2.6 Registration Period...........................................57 7.2.7 Entity Index..................................................58 7.2.8 Entity ISAKMP Phase-1 Proposals...............................58 7.2.9 Entity Certificate............................................58 7.3 Portal-Keyed Attributes.......................................59 7.3.1 Portal IP-Address.............................................59 7.3.2 Portal TCP/UDP Port...........................................59 7.3.3 Portal Symbolic Name..........................................59 7.3.4 Entity Status Inquiry Interval................................59 7.3.5 ESI Port......................................................60 7.3.6 Portal Group Tag..............................................60 7.3.7 Portal Index..................................................61 7.3.8 SCN Port......................................................61 7.3.9 Portal Security Bitmap........................................61 Tseng, Gibbons, et al. Standards Track [Page 3] Internet Storage Name Service (iSNS) May 2002 7.3.10Portal ISAKMP Phase-1 Proposals...............................62 7.3.11Portal ISAKMP Phase-2 Proposals...............................62 7.3.12Portal Certificate............................................62 7.4 iSCSI Node-Keyed Attributes...................................62 7.4.1 iSCSI Name....................................................63 7.4.2 iSCSI Node Type...............................................63 7.4.3 iSCSI Node Alias..............................................63 7.4.4 iSCSI Node SCN Bitmap.........................................64 7.4.5 iSCSI Node Index..............................................65 7.4.6 WWNN Token....................................................65 7.4.7 iSCSI AuthMethod..............................................66 7.4.8 iSCSI Node Certificate........................................66 7.5 FC Port Name-Keyed Attributes.................................66 7.5.1 FC Port Name (WWPN)...........................................67 7.5.2 Port ID (FC_ID)...............................................67 7.5.3 FC Port Type..................................................67 7.5.4 Symbolic Port Name............................................67 7.5.5 Fabric Port Name (FWWN).......................................67 7.5.6 Hard Address..................................................67 7.5.7 Port IP Address...............................................68 7.5.8 Class of Service (COS)........................................68 7.5.9 FC-4 Types....................................................68 7.5.10FC-4 Descriptor...............................................68 7.5.11FC-4 Features.................................................68 7.5.12iFCP SCN Bitmap...............................................68 7.5.13Port Role.....................................................69 7.5.14Port Certificate..............................................70 7.6 Node-Keyed Attributes.........................................70 7.6.1 FC Node Name (WWNN)...........................................70 7.6.2 Symbolic Node Name............................................70 7.6.3 Node IP Address...............................................70 7.6.4 Node IPA......................................................70 7.6.5 Node Certificate..............................................70 7.6.6 Proxy iSCSI Name..............................................70 7.7 Other Attributes..............................................71 7.7.1 FC-4 Type Code................................................71 7.7.2 iFCP Switch Name..............................................71 7.7.3 iFCP Transparent Mode Commands................................71 7.8 iSNS Server-Specific Attributes...............................72 7.8.1 iSNS Server Vendor OUI........................................72 7.9 Discovery Domain Registration Attributes......................72 7.9.1 DD Set ID Keyed Attributes....................................72 7.9.2 DD ID Keyed Attributes........................................73 7.10 Vendor-Specific Attributes....................................74 7.10.1Vendor-Specific Server Attributes.............................74 7.10.2Vendor-Specific Entity Attributes.............................75 7.10.3Vendor-Specific Portal Attributes.............................75 7.10.4Vendor-Specific iSCSI Node Attributes.........................75 7.10.5Vendor-Specific FC Port Name Attributes.......................75 7.10.6Vendor-Specific FC Node Name Attributes.......................75 7.10.7Vendor-Specific Discovery Domain Attributes...................75 7.10.8Vendor-Specific Discovery Domain Set Attributes...............75 7.10.9Other Vendor-Specific Attributes..............................75 7.11 Standards-Based Extensions....................................76 Tseng, Gibbons, et al. Standards Track [Page 4] Internet Storage Name Service (iSNS) May 2002 8. Security Considerations.......................................76 8.1 iSNS Security Threat Analysis.................................76 8.2 iSNS Security Implementation and Usage Requirements...........76 8.3 Discovering Security Requirements of Peer Devices.............78 8.4 Configuring Security Policies of iFCP/iSCSI Devices...........78 8.5 Resource Issues...............................................79 8.6 iSNS Interaction with IKE and IPSec...........................79 9. Normative References..........................................80 10. Informative References........................................81 11. Author's Addresses............................................82 Full Copyright Statement.............................................83 Appendix A -- iSNS Examples..........................................84 A.1 iSCSI Initialization Example..................................84 A.1.1 Simple iSCSI Target Registration..............................84 A.1.2 Target Registration and DD Configuration......................85 A.1.3 Initiator Registration and Target Discovery...................86 Tseng, Gibbons, et al. Standards Track [Page 5] Internet Storage Name Service (iSNS) May 2002 1. Abstract This document specifies the iSNS protocol, which is used for interaction between iSNS servers and iSNS clients in order to facilitate automated discovery, management, and configuration of iSCSI and Fibre Channel (FCP) devices on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. iSNS also facilitates a seamless integration of IP and Fibre Channel networks, due to its ability to emulate Fibre Channel fabric services, and manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices, or any combination thereof. 2. About this Document 2.1 Conventions Used in this Document iSNS refers to the framework consisting of the storage network model and associated services. 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]. All frame formats are in big endian network byte order. All unused fields and bitmaps, including those that are RESERVED, SHOULD be set to zero. 2.2 Purpose of this Document 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. This document focuses on the interaction between iSNS servers and iSNS clients; interactions among multiple authoritative primary iSNS servers are a potential topic for future work. 3. iSNS Overview iSNS facilitates scalable configuration and management of iSCSI and Fibre Channel (FCP) storage devices in an IP network, by providing a set of services comparable to that available in Fibre Channel networks. iSNS thus allows a commodity IP network to function at comparable level of intelligence to a Fibre Channel fabric. iSNS allows the administrator to go beyond a simple device-by-device management model, where each storage device is manually and individually configured with its own list of known initiators and targets. Using the iSNS, each storage device subordinates its discovery and management responsibilities to the iSNS server. The Tseng, Gibbons, et al. Standards Track [Page 6] Internet Storage Name Service (iSNS) May 2002 iSNS server thereby serves as the consolidated configuration point through which management stations can configure and manage the entire storage network, including both iSCSI and Fibre Channel devices. iSNS can be implemented to support iSCSI and/or iFCP protocols as needed; an iSNS implementation MAY provide support for one or both of these protocols as desired by the implementor. Implementation requirements within each of these protocols is further discussed in section 5. Use of iSNS is OPTIONAL for iSCSI, and REQUIRED for iFCP. 3.1 iSNS Architectural Components 3.1.1 iSNS Protocol (iSNSP) The iSNS Protocol (iSNSP) is a flexible and lightweight protocol that specifies how iSNS clients and servers communicate. It is suitable for various platforms, including switches and targets as well as server hosts. 3.1.2 iSNS Client iSNS clients initiate transactions with iSNS servers using the iSNSP. iSNS clients are processes that are co-resident in the storage device, and can register deviceÆs attribute information, download information about other registered clients in a common Discovery Domain (DD), and receive asynchronous notification of topology events that occur in their DD(s). Management stations are a special type of iSNS client that have access to all DDs stored in the iSNS. 3.1.3 iSNS Server iSNS servers respond to iSNS protocol queries and requests, and initiate iSNS protocol State Change Notifications. Properly authenticated information submitted by a registration request is stored in an iSNS database. 3.1.4 iSNS Database The iSNS database is the information repository for the iSNS server(s). It maintains information about iSNS client attributes. A directory-enabled implementation of iSNS may store client attributes in an LDAP directory infrastructure. 3.1.5 iSCSI iSCSI (Internet SCSI) is an encapsulation of SCSI for a new generation of storage devices interconnected with TCP/IP. Tseng, Gibbons, et al. Standards Track [Page 7] Internet Storage Name Service (iSNS) May 2002 3.1.6 iFCP iFCP (Internet FCP) is a gateway-to-gateway protocol designed to interconnect existing Fibre Channel and SCSI devices using TCP/IP. iFCP maps the existing FCP standard and associated Fibre Channel services to TCP/IP. 3.2 iSNS Functional Overview iSNS Protocol registration and query messages are sent by iSNS clients to servers, while notification messages are sent by iSNS servers to iSNS clients. Messages originating at the client are sent to the iSNS server at the well-known iSNS TCP or UDP port number. There are four main functions of the iSNS: 1) A Name Service Providing Storage Resource Discovery 2) Discovery Domain (DD) and Login Control Service 3) State Change Notification Service 4) Open Mapping of Fibre Channel and iSCSI Devices 3.2.1 Name Registration Service The iSNS provides a registration function to allow all entities in a storage network to register and query the iSNS database. Both targets and initiators can register in the iSNS database, as well as query for information about other initiators and targets. This allows, for example, a client initiator to obtain information about target devices from the iSNS server. This service is modeled on the Fibre Channel Generic Services Name Server described in FC-GS-3, with extensions, operating within the context of an IP network. The naming registration service also provides the ability to obtain a network unique Domain ID for iFCP gateways when required. 3.2.2 Discovery Domain and Login Control Service (Zoning) Zoning is an important function in existing Storage Area Networks that allows storage administrators to partition storage assets into more manageable groups for administrative and management purposes. It also provides important storage network isolation capabilities to prevent interaction among incompatible storage and file systems. iSNS provides zoning capability through the Discovery Domain (DD) Service. The Discovery Domain (DD) Service facilitates the partitioning of iSNS client devices into more manageable groupings for administrative and login control purposes. This allows the administrator to limit the login process to the more appropriate subset of targets registered in the iSNS. iSNS clients must be in Tseng, Gibbons, et al. Standards Track [Page 8] Internet Storage Name Service (iSNS) May 2002 at least one common DD in order to obtain information about each other. iSNS clients can be a member of multiple DD's simultaneously. The DD information stored in the iSNS can be used by various enforcement points in the network to configure security and access control policy. For example, a DD-aware switch can block storage initiators from accessing targets that are not in the same DD, even if the initiator somehow obtained address information for a target outside of its DD. Login Control allows targets to subordinate their access control/authorization policy to 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 required identification and authentication information provided by the iSNS will be allowed access by that target node or device during session establishment. If spoofing of initiator identities is a concern, the target may use the public key certificate of the authorized initiator, obtained from the iSNS server, to authenticate the initiator. DD's can be managed offline through a separate management workstation using the iSNSP or SNMP. If the target opts to use the Login Control feature of the iSNS, the target subordinates management of access control policy (i.e., the list of initiators allowed to login to that target) to the management workstations that are manipulating information in the iSNS database. If administratively authorized, a target can upload its own Login Control list. This is accomplished using the DDReg message and listing the iSCSI Name of each initiator to be registered in the Target's DD. An implementation MAY decide that newly registered devices that have not explicitly been placed into a DD by the management station are be placed into a "default DD" contained in a "default DDS" whose initial DD Set Status value is "enabled". This makes them visible to other devices in the default DD. Other implementations MAY decide that they are registered with no DD, making them inaccessible to source-scoped iSNSP messages. If used, the DD_ID of the "default DD" is 1, and the DDS_ID of the "default DDS" is 1. The iSNS server uses the SOURCE field of each iSNSP message to determine the source of the request and scope the operation to the set of Discovery Domains that the iSNS client is a member of. In addition, the Node Type (specified in the iFCP or iSCSI Node Type bitmap field) may also be used to determine authorization for the specified iSNS operation. For example, only control nodes are authorized to create or delete discovery domains. Valid and active Discovery Domains (DD's) belong to at least one active Discovery Domain Sets (DDS's). Discovery Domains that do not belong to an activated DDS are not enabled. Tseng, Gibbons, et al. Standards Track [Page 9] Internet Storage Name Service (iSNS) May 2002 3.2.3 State Change Notification Service The State Change Notification (SCN) service allows the iSNS Server to issue notifications about network events that affect the operational state of iSNS clients. The iSNS client has the ability to register for these notifications of events detected by the iSNS Server. There are two types of SCN registrations: Regular registrations and a management registrations; management registrations result in management SCN's, while regular registrations result in regular SCN's. The type of registration and SCN message is indicated in the SCN bitmap (see sections 7.4.4 and 7.5.12). A regular SCN registration indicates that the Discovery Domain Service shall be used to control the distribution of SCN messages. Receipt of regular SCN's is limited to the discovery domains in which the SCN-triggering event takes place. Regular SCN's do not contain information about discovery domains. A management SCN registration can only by conducted by control nodes. Management SCN's resulting from management registrations are not bound by the Discovery Domain service. Authorization to conduct management SCN registrations may be administratively controlled. The iSNS server may refuse SCN service by returning a SCN Registration Rejected (Status Code 17). The rejection might occur in situations where the network size or current number of SCN registrations, has passed an implementation-specific threshold. A client not allowed to register for SCNs may decide to monitor its sessions with other storage devices directly. The specific notification mechanism by which the iSNS server learns of the events that trigger SCN's is implementation-specific, but can include examples such as explicit notification messages from an iSNS client to the iSNS server, or a hardware interrupt to a switch- hosted iSNS server as a result of link failure. 3.2.4 Open Mapping Between Fibre Channel and iSCSI Devices The iSNS database stores naming and discovery information about both Fibre Channel and iSCSI devices. This allows the iSNS server to store mappings of a Fibre Channel device to a proxy iSCSI device "image" in the IP network. Similarly, mappings of an iSCSI device to a "proxy WWN" can be stored under the WWNN Token field for that that iSCSI device. Furthermore, through use of iSCSI-FC gateways, Fibre Channel-aware management stations can interact with the iSNS server to retrieve information about Fibre Channel devices, and use this information to manage Fibre Channel devices as well as iSCSI devices. This allows management functions such as Discovery Domains and State Change Notifications to be seamlessly applied for both iSCSI and Fibre Tseng, Gibbons, et al. Standards Track [Page 10] Internet Storage Name Service (iSNS) May 2002 Channel devices, facilitating integration of IP networks with Fibre Channel devices and fabrics. Note that Fibre Channel attributes are stored as iFCP attributes, and the ability to store this information in the iSNS server is useful even if the iFCP protocol is not implemented. In particular, tag 101 can be used to store a "Proxy iSCSI Name" for Fibre Channel devices registered in the iSNS server. This field is used to associate the FC device with an iSCSI registration entry that is used for the Fibre Channel device to communicate with iSCSI devices in the IP network. Conversely, tag 37 (see section 7.1) contains an WWNN Token field, which can be used to store an FC Node Name (WWNN) value used by iSCSI-FC gateways to represent an iSCSI device in the Fibre Channel domain. By storing the mapping between Fibre Channel and iSCSI devices in the iSNS server, this information becomes open to any authorized iSNS client wishing to retrieve and use this information. In many cases, this provides advantages over storing this information internally within an iSCSI-FC gateway, where the mapping is inaccessible to other devices except by proprietary mechanisms. 3.3 iSNS Usage Model The following is a high-level description of how each type of device in a storage network can utilize iSNS. Each type of device interacts with the iSNS server as an iSNS client, and must register itself in the iSNS database in order to access services provided by the iSNS. 3.3.1 iSCSI Initiator An iSCSI initiator will query the iSNS server to discover the presence and location of iSCSI target devices. It may also request state change notifications (SCN's) so that it can be notified of new targets that appear on the network after the initial bootup and discovery. SCN's can also inform the iSCSI initiator of targets that are removed or no longer available in the storage network, so that incomplete storage sessions can be gracefully terminated and resources for non-existent targets can be reallocated. 3.3.2 iSCSI Target An iSCSI target allows itself to be discovered by iSCSI initiators by registering its presence in the iSNS server. It may also register for SCN's in order to detect the addition or removal of initiators for resource allocation purposes. The iSCSI target device may also register for Entity Status Enquiry (ESI) messages, which allow the iSNS to monitor the target device's availability in the storage network. Tseng, Gibbons, et al. Standards Track [Page 11] Internet Storage Name Service (iSNS) May 2002 3.3.3 iSCSI-FC Gateway An iSCSI-FC Gateway bridges devices in a Fibre Channel network to an iSCSI/IP network. It may use the iSNS store FC device attributes discovered in the FC name server, as well as mappings of FC device identifiers to iSCSI device identifiers. iSNS has the capability to store all attributes of both iSCSI and Fibre Channel devices; iSCSI devices are managed through direct interaction using iSNS, while FC devices can be indirectly managed through iSNS interactions with the iSCSI-FC gateway. This allows both iSCSI and Fibre Channel devices to be managed in a seamless management framework. 3.3.4 iFCP Gateway An iFCP Gateway uses iSNS to emulate the services provided by a Fibre Channel name server for FC devices in its gateway region. iSNS provides basic discovery and zoning configuration information to be enforced by the iFCP gateway. When queried, iSNS returns information on the N_Port network address used to establish iFCP sessions between FC devices supported by iFCP gateways. 3.3.5 Management Station A Management Station uses iSNS to monitor storage devices and enable or disable storage sessions by configuring discovery domains. A Management Station usually interacts with the iSNS server as a control node endowed with access to all iSNS database records and special privileges to configure discovery domains. Through manipulation of discovery domains, the Management Station controls the establishment and termination of storage sessions in the storage network. 3.4 Administratively Controlled iSNS Settings Some important operational settings for the iSNS server are configured using administrative means, such as through a configuration file, console port, SNMP, or other implementation- specific method. These administratively controlled settings cannot be configured using the iSNS Protocol. The following is a list of parameters that are administratively controlled for the iSNS server. Tseng, Gibbons, et al. Standards Track [Page 12] Internet Storage Name Service (iSNS) May 2002 Setting Default Setting ------- --------------- ESI Non-Response Threshold 3 Management SCNs (Control Nodes only) enabled 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/A ESI Non-Response Threshold - determines the number of ESI messages sent without receiving a response before the entity is deregistered from the iSNS database. Management SCN for Control Node - determines whether a registered control node is permitted to register to receive Management SCN's. Default DD/DDS - determines whether a newly registered device not explicitly placed into a discovery domain (DD) and discovery domain set (DDS) is placed into a default DD/DDS. DD/DDS Modification - determines whether the specified type of node is allowed to add, delete or update DD's and DDS's. Authorized Control Nodes - a list of nodes identified by iSCSI Name or FC Port Name WWPN that are authorized to register as control nodes. 3.5 iSNS Server Discovery 3.5.1 Service Location Protocol (SLP) The Service Location Protocol (SLP) provides a flexible and scalable framework for providing hosts with access to information about the existence, location, and configuration of networked services, including the iSNS server. SLP can be used by iSNS clients to discover the IP address or FQDN of the iSNS server. To implement 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 requesting the IP address of the iSNS server(s). The SA responds to this request. Optionally, the location of the iSNS server can be stored in the SLP Directory Agent (DA). Note that a complete description and specification of SLP can be found in [RFC2608], and is beyond the scope of this document. Additional details on use of SLP to discover the iSNS server can be found in [iSCSI-SLP]. Tseng, Gibbons, et al. Standards Track [Page 13] Internet Storage Name Service (iSNS) May 2002 3.5.2 Dynamic Host Configuration Protocol (DHCP) The IP address of the iSNS server can be stored in a DHCP server to be downloaded by iSNS clients using a DHCP option. The DHCP option number to be used for distributing the iSNS server location is <>. 3.5.3 iSNS Heartbeat Message The iSNS heartbeat message is described in section 6.6.5.14. It allows iSNS clients within the broadcast or multicast domain of the iSNS server to discover the location of the active iSNS server and any backup servers. 3.6 iSNS and NAT The existence of NAT will have an impact upon information retrieved from the iSNS server. If the iSNS client exists in a different addressing domain than the iSNS server, then IP address information stored in the iSNS server may not be correct when interpreted in the domain of the iSNS client. There are several possible approaches to allow operation of iSNS within a NAT network. The first approach is to require use of the canonical TCP port number by both targets and initiators when addressing targets across a NAT boundary, and for the iSNS client to not query for nominal IP addresses. Rather, the iSNS client initiator queries for the DNS Fully Qualified Domain Name stored in the Entity Identifier field, when seeking addressing information. Once retrieved, the DNS name can be interpreted in each address domain and mapped to the appropriate IP address by local DNS servers. A second approach is to deploy a distributed network of iSNS servers. Local iSNS servers are deployed inside and outside NAT boundaries, with each local server storing relevant IP addresses for their respective NAT domains. Updates among the network of decentralized, local iSNS servers are handled using LDAP and using appropriate NAT translation rules implemented within the update mechanism in each server. The final alternative is to simply disallow use of NAT in communication between the iSNS server and any iSNS client. 3.7 Transfer of iSNS Database Records between iSNS Servers Transfer of iSNS database records between iSNS servers has important applications, including the following: 1) An independent organization needs to transfer storage information to a different organization. Each organization independently maintains its own iSNS infrastructure. To facilitate discovery of storage assets of the peer organization using IP, iSNS database records can be transferred between authoritative iSNS Tseng, Gibbons, et al. Standards Track [Page 14] Internet Storage Name Service (iSNS) May 2002 servers from each organization. This allows storage sessions to be established directly between devices residing in each organization's storage network infrastructure over a common IP network. 2) Multiple iSNS servers are desired for redundancy. Backup servers need to maintain copies of the primary server's dynamically changing database. To support the above applications, information in an iSNS server can be distributed to other iSNS servers either using the iSNS protocol, or through out-of-band mechanisms using non-iSNS protocols. The following examples illustrate possible methods to transfer data records between iSNS servers. In the first example, a back-end LDAP information base is used to support the iSNS server, and the data is transferred using the LDAP protocol. Once the record transfer of the remote device is completed, it becomes visible and accessible to local devices using the local iSNS server. This allows local devices to establish sessions with remote devices (provided 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 B In the above diagram, two business partners wish to share storage "dev C". Using LDAP, the record for "dev C" can be transfered from Network B to Network A. Once accessible to the local iSNS server in Network A, local devices A and B can now discover and connect to "dev C". Tseng, Gibbons, et al. Standards Track [Page 15] Internet Storage Name Service (iSNS) May 2002 +-------------------------+ +-------------------------+ |+------+ 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 B The above diagram illustrates a second example of how iSNS records can be shared. This method uses an SNMP-based management station to manually download the desired record for "dev C", and then directly upload it to the local iSNS server. Once the record is transferred to the local iSNS server in Network A, "dev C" becomes visible and accessible (provided firewall boundaries can be negotiated) to other devices in Network A. Other methods, including proprietary protocols, can be used to transfer device records between iSNS servers. Further discussion and explanation of these methodologies is beyond the scope of this document. 3.8 Backup iSNS Servers This section offers a broad framework for implementation and deployment of iSNS backup servers. Server failover and recovery are topics of continuing research and adequate resolution of issues such as split brain and primary server selection is dependent on the specific implementation requirements and deployment needs. Therefore, it is beyond the scope of this specification to facilitate more than a basic interoperability among failover mechanisms. Further development of redundant iSNS server mechanisms are left to the individual implementation. Multiple iSNS servers can be used to provide redundancy in the event that the active iSNS server fails or is removed from the network. The methods described in section 3.7 above can be used to transfer name server records to backup iSNS servers. Each backup server maintains a redundant copy of the name server database found in the primary iSNS server, and can respond to iSNS protocol messages in the same way as the active server. Each backup server SHOULD Tseng, Gibbons, et al. Standards Track [Page 16] Internet Storage Name Service (iSNS) May 2002 monitor the health and status of the active iSNS server, including checking to make sure its own database is synchronized with the active server's database. How each backup server accomplishes 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, allowing it to receive state change notifications. Generally, the administrator or some automated election process is responsible for initial and subsequent designation of the primary server and each backup server. A maximum of one backup iSNS server SHALL exist at any individual IP address. In addition to proprietary vendor-specific ways of deploying multiple redundant iSNS servers, the iSNS heartbeat can also be used to coordinate designation and selection of primary and backup iSNS servers. Each backup server should note its relative precedence in the active server's list of backup servers. If not already known, each backup server MAY learn its precedence 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 is the first backup listed in the heartbeat message, then its backup precedence is 1. If it is 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 other backup servers of higher precedence, then it shall assume that it is the active server. The method of determining whether connectivity has been lost is implementation- specific. One possible approach is to assume that if the backup server does not receive iSNS hearbeat messages for a period of time, then connectivity to the active server has been lost. Alternately, the backup server may establish TCP connections to the active server and other backup servers, and loss of connectivity determined through non-response to periodic echo 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 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 begins incrementing the counter field from the last known value from 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 other higher-precedence backup server returns, then the existing active server is responsible for ensuring that the new active server's database is up-to-date before demoting itself to its original status as backup. Tseng, Gibbons, et al. Standards Track [Page 17] Internet Storage Name Service (iSNS) May 2002 4. 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 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, DEVICE DISCOVERY DOMAIN, and DISCOVERY DOMAIN SET. Each of these objects are described in greater detail in the following sections. 4.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. All STORAGE NODEs and PORTALs contained within a single NETWORK ENTITY object operate as a logical unit. Note that it is 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 by more than one logical Network Entity. Similarly, it is possible for a logical Network Entity to 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. The multiple gateways collectively can be used to support a single logical NETWORK ENTITY that is used to contain all of the devices in that Fibre Channel network. 4.2 PORTAL Object The PORTAL object is an interface through which access to any STORAGE NODE within the NETWORK ENTITY can be obtained. An IP address and TCP/UDP Port number uniquely distinguish a PORTAL object. A NETWORK ENTITY should have one or more PORTALs, each of which is usable by STORAGE NODEs contained in that NETWORK ENTITY to gain access to, or be accessible from, the IP network. 4.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. Tseng, Gibbons, et al. Standards Track [Page 18] Internet Storage Name Service (iSNS) May 2002 4.4 FC DEVICE Object The FC DEVICE represents the Fibre Channel end node. This object contains information that may be useful in the management of the Fibre Channel device. 4.5 DISCOVERY DOMAIN Object DISCOVERY DOMAINS (DD) are a security and management mechanism used to administer access and connectivity to storage devices. Discovery Domains limit the discovery process to the administrator-configured subset of relevant storage devices, preventing initiators from inappropriately attempting login to devices that they shouldnÆt have access to. A query by an iSNS client SHOULD only return information about objects with which it shares at least one active DD. A DD is considered active if it is a member of at least one active DD Set. DD's that are not members of at least one enabled DDS are considered disabled. A STORAGE NODE can be a member of one or more DD's. 4.6 DISCOVERY DOMAIN SET Object The DISCOVERY DOMAIN SET (DDS) is a container object for DDÆs. DDSÆs may contain one or more DDÆs. Similarly, each DD can be a member of one or more DDSÆs. DDSÆs are a mechanism to store coordinated sets of DD mappings in the iSNS server. Active DD's are members of at least one active DD Set. DDS's are enabled by setting bit 0 in the DDS Status Field. 4.7 iSNS Database Model The following shows the various objects described above and their relationship to each other. +--------------+ +-----------+ | NETWORK |1 *| | | ENTITY |----| PORTAL | | | | | +--------------+ +-----------+ | 1 | | | * +-----------+ +--------------+ +-----------+ +-----------+ | FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY | | DEVICE |----| NODE |----| DOMAIN |----| DOMAIN | | | | | | | | SET | +-----------+ +--------------+ +-----------+ +-----------+ * represents 0 to many possible relationships Tseng, Gibbons, et al. Standards Track [Page 19] Internet Storage Name Service (iSNS) May 2002 5. iSNS Implementation Requirements This section details specific requirements for support of each of these IP storage protocols. Implementation requirements for security are described in section 8. 5.1 iSCSI Requirements Use of iSNS in support of iSCSI is OPTIONAL. iSCSI devices MAY be manually configured with the iSCSI Name and IP address of peer devices, without the aid or intervention of iSNS. iSCSI devices also may use SLP [RFC 2608] to discover peer iSCSI devices. However, iSNS is useful for scaling a storage network to a larger number of iSCSI devices. 5.1.1 Required Attributes for Support of iSCSI The following attributes are available to support iSCSI. Attributes indicated in the REQUIRED TO IMPLEMENT column MUST be supported by an iSNS server used to support iSCSI. Attributes indicated in the REQUIRED TO USE column MUST be supported by an iSCSI device that elects to use the iSNS. A more detailed description of each attribute is found in section 7. Tseng, Gibbons, et al. Standards Track [Page 20] Internet Storage Name Service (iSNS) May 2002 REQUIRED REQUIRED Object Attribute to Implement to Use ------ --------- ------------ -------- 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 Group Tag * Portal Index * SCN Port * Portal Security Bitmap * Portal IKE Phase-1 Proposal Portal IKE Phase-2 Proposal Portal Certificate 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 iSCSI Node Index * DD iSCSI Node Member * DD Features * DISCOVERY DOMAIN DDS Identifier * SET DDS Symbolic Name * Status * DDS Member * All iSCSI user-specified and vendor-specified attributes are optional to implement and use. 5.1.2 Example iSCSI Object Model Diagrams The following diagram models how a simple iSCSI-based initiator and target is represented using database objects stored in the iSNS Tseng, Gibbons, et al. Standards Track [Page 21] Internet Storage Name Service (iSNS) May 2002 server. In this implementation, each target and initiator is attached to a single PORTAL. +----------------------------------------------------------------+ | IP Network | +------------+--------------------------------------+------------+ | | | | +-----+------+------+-----+ +-----+------+------+-----+ | | PORTAL | | | | PORTAL | | | | -IP Addr 1 | | | | -IP Addr 2 | | | | -TCP Port 1 | | | | -TCP Port 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.foo.com" | | "strg2.bar.com" | | -Protocol: iSCSI | | -Protocol: iSCSI | | | | | +-------------------------+ +-------------------------+ The object model can be expanded to describe more complex devices, such as an iSCSI device with more than one storage controller, each controller accessible through any of multiple PORTAL interfaces. The storage controllers on this device can be accessed through alternate PORTAL interfaces, if any original interface should fail. The following diagram describes such a device: Tseng, Gibbons, et al. Standards Track [Page 22] Internet Storage Name Service (iSNS) May 2002 +---------------------------------------------------------------+ | IP Network | +-------------------+-----------------------+-------------------+ | | | | +------------+------+------+---------+------+------+------------+ | | PORTAL | | PORTAL | | | | -IP Addr 1 | | -IP Addr 2 | | | | -TCP Port 1 | | -TCP Port 2 | | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | +---------------+ +---------------------+ +---------------+ | | +-------+ +----------------+ +-------------------+ +------+ | | | | | | | | | | +-------+ +-------+ +------+ +--------+ +--------+ +------+ | | | | | | | | | | | STORAGE NODE | | STORAGE NODE | | STORAGE NODE | | | | -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.foo.com" | | -Protocol: iSCSI | | | +---------------------------------------------------------------+ 5.1.3 Required Commands and Response Messages for Support of iSCSI The following iSNSP messages and responses are available in support of iSCSI. Messages indicated in the REQUIRED TO IMPLEMENT column MUST be implemented in iSNS servers used for iSCSI devices. Messages indicated in the REQUIRED TO USE column must be implemented in iSCSI devices that elect to use the iSNS server. REQUIRED TO: Message Description Abbreviation Func_ID Implement Use ------------------- ------------ ------- --------- --- Register Dev Attr Req RegDevAttr 0x0001 * * Dev Attr Query Request DevAttrQry 0x0002 * * Dev Get Next Request DevGetNext 0x0003 * Deregister Dev Request DeregDev 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 * Tseng, Gibbons, et al. Standards Track [Page 23] Internet Storage Name Service (iSNS) May 2002 Name Service Heartbeat Heartbeat 0x000E NOT USED 0x000F-0x0013 RESERVED 0x0014-0x00FF Vendor Specific 0x0100-0x01FF RESERVED 0x0200-0x8000 The following are iSNSP response messages used in support of iSCSI: REQUIRED TO: Response Message Desc Abbreviation Func_ID Implement Use --------------------- ------------ ------- --------- --- Register Dev Attr Rsp RegDevRsp 0x8001 * * Dev Attr Query Rsp DevAttrQryRsp 0x8002 * * Dev Get Next Rsp DevGetNextRsp 0x8003 * Deregister Dev Rsp DeregDevRsp 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 * NOT USED 0x800E-0x8013 RESERVED 0x8014-0x80FF Vendor Specific 0x8100-0x81FF RESERVED 0x8200-0xFFFF 5.2 iFCP Requirements In iFCP, use of iSNS is REQUIRED. No alternatives exist for support of iFCP Naming & Discovery functions. 5.2.1 Required Attributes for Support of iFCP The following table displays attributes that are used by iSNS to support iFCP. Attributes indicated in the REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server that supports iFCP. Attributes indicated in the REQUIRED TO USE column MUST be supported by iFCP gateways. A more detailed description of each attribute is found in section 7. REQUIRED REQUIRED Object Attribute to Implement to Use ------ --------- ------------ -------- NETWORK ENTITY Entity Identifier * * Entity Protocol * * Management IP Address Timestamp * Protocol Version Range * Registration period Tseng, Gibbons, et al. Standards Track [Page 24] Internet Storage Name Service (iSNS) May 2002 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 * Port Certificate FC DEVICE FC Node Name (WWNN) * * (FC Node) Node Symbolic Name * Node IP Address * Node IPA * Node Certificate Proxy iSCSI Name DISCOVERY DOMAIN DD_ID * * DD_Symbolic Name * DD iFCP Member (WWPN) * DISCOVERY DOMAIN DDS Identifier * SET DDS Symbolic Name * DDS Status * DDS Member * OTHER Switch Name Preferred_ID Assigned_ID Space Identifier Tseng, Gibbons, et al. Standards Track [Page 25] Internet Storage Name Service (iSNS) May 2002 5.2.2 Example iFCP Object Model Diagram The iFCP protocol allows native Fibre Channel devices or Fibre Channel fabrics connected to an iFCP gateway to be directly internetworked using IP. When supporting iFCP, the iSNS server stores Fibre Channel device attributes, iFCP gateway attributes, and Fibre Channel fabric switch attributes that might also be stored in an FC name server. The following diagram shows a representation of a gateway supporting multiple Fibre Channel devices behind it. The two PORTAL objects represent IP interfaces on the iFCP gateway that can be used to access any of the three STORAGE NODE objects behind it. Note that the FC DEVICE object is not contained in the NETWORK ENTITY object. However, each FC DEVICE has a relationship to 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.foo.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 | | | | | +-------------+ +--------------------+ 5.2.3 Required Commands and Response Messages for Support of iFCP The iSNSP messages and responses displayed in the following tables are available to support iFCP gateways. Messages indicated in the REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server used by iFCP gateways. Messages indicated in the REQUIRED TO USE column MUST be supported by the iFCP gateways themselves. Tseng, Gibbons, et al. Standards Track [Page 26] Internet Storage Name Service (iSNS) May 2002 REQUIRED TO: Message Description Abbreviation Func ID Implement Use ------------------- ------------ ------- --------- --- Register Dev Attr Req RegDevAttr 0x0001 * * Dev Attr Query Request DevAttrQry 0x0002 * * Dev Get Next Request DevGetNext 0x0003 * Deregister Dev Request DeregDev 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 Switch ID RqstSwId 0x0011 Release Switch ID RlseSwId 0x0012 Get Switch IDs GetSwIds 0x0013 RESERVED 0x0014-0x00FF Vendor Specific 0x0100-0x01FF RESERVED 0x0200-0x8000 The following are iSNSP response messages in support of iFCP: Tseng, Gibbons, et al. Standards Track [Page 27] Internet Storage Name Service (iSNS) May 2002 REQUIRED TO: Response Message Desc Abbreviation Func_ID Implement Use --------------------- ------------ ------- --------- --- Register Dev Attr Rsp RegDevRsp 0x8001 * * Dev Attr Query Resp DevAttrQryRsp 0x8002 * * Dev Get Next Resp DevGetNextRsp 0x8003 * Deregister Dev Resp DeregDevRsp 0x8004 * * SCN Register Resp SCNRegRsp 0x8005 * SCN Deregister Resp SCNDeregRsp 0x8006 * SCN Event Resp 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 Resp ESIRsp 0x800D * NOT USED 0x800E RESERVED 0x800F-0x8010 Request Switch ID Resp RqstSwIdRsp 0x8011 Release Switch ID Resp RlseSwIdRsp 0x8012 Get Switch IDs GetSwIdRsp 0x0013 RESERVED 0x8014-0x80FF Vendor Specific 0x8100-0x81FF RESERVED 0x8200-0xFFFF 5.3 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. The well-known TCP port used by the iSNS server to receive TCP messages used is 3205. To receive ESI monitoring using TCP, the client registers the Portal ESI Interval and the port number of the TCP port that will be used to receive ESI inquiry messages. 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 SCN's. The TCP connection for SCN's does not necessarily need to be continuously open. It is possible for an iSNS client to use the same TCP connection for SCN, ESI, and iSNS queries. Alternatively, separate connections may be used. 5.4 Use of UDP For iSNS Communication The iSNS server MAY accept UDP messages for client registrations. The iSNS server MUST accept registrations from clients requesting UDP-based ESI and SCN messages. The well-known UDP port used to receive UDP messages is 3205. Tseng, Gibbons, et al. Standards Track [Page 28] Internet Storage Name Service (iSNS) May 2002 To receive UDP-based ESI monitoring messages, the client registers the port number of the UDP port in at least one Portal to be used to receive and respond to ESI messages from the iSNS server. If an entity has multiple Portals with registered ESI UDP Ports, then ESI messages SHALL be delivered to every Portal registered to receive such messages. To receive 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 an entity has multiple Portals with registered SCN UDP Ports, then SCN messages SHALL be delivered to each Portal registered to receive such messages. 6. iSNSP Message Format The iSNSP message format is similar to the format of other common protocols such as DHCP, DNS and BOOTP. An iSNSP message may be sent in one or more iSNS Protocol Data Units (PDU). Each PDU is 4 byte aligned. The following describes the format of the 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 Only) | L Bytes +--------------------------------------------+ Total Length = 12 + N + L 6.1 iSNSP PDU Header The iSNSP header contains the iSNSP VERSION, FUNCTION ID, PDU LENGTH, FLAGS, TRANSACTIONID, and SEQUENCE ID fields as defined below. 6.1.1 iSNSP Version The iSNSP version is currently 0x0001. 6.1.2 iSNSP Function ID The FUNCTION ID defines the type of iSNS message and the operation to be executed. FUNCTION_ID values with the leading bit cleared indicate query and registration messages sent by the iSNS client, while FUNCTION_ID values with the leading bit set indicate response Tseng, Gibbons, et al. Standards Track [Page 29] Internet Storage Name Service (iSNS) May 2002 messages sent by the iSNS server. See section 5 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 PDU's comprising an iSNSP message must have the same FUNCTION_ID and TRANSACTION ID value. 6.1.3 iSNSP PDU Length The iSNS PDU LENGTH specifies the length of the PDU PAYLOAD field in bytes. The payload contains the data/attribute values for the operation. 6.1.4 iSNSP Flags The FLAGS field indicates additional information about the message and the type of iSNS entity that generated the message. The following table displays the valid flags: Bit Field Enabled Means: --------- ------------- 16 Sender is the iSNS client 17 Sender is the iSNS server 18 RESERVED 19 Replace Flag (valid only for RegDevAttr) 20 Last PDU of the iSNS message 21 First PDU of the iSNS message 22-31 RESERVED 6.1.5 iSNSP Transaction ID The TRANSACTION ID is 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 is retransmitted, the same TRANSACTION ID value MUST be used. 6.1.6 iSNSP Sequence ID The SEQUENCE ID has a unique value for each PDU within a single transaction. Each SEQUENCE_ID value in each PDU SHALL be numbered sequentially in the order that the PDU's are transmitted. If a message is retransmitted, then the original SEQUENCE_ID value MUST be used for each PDU's in the message. Note that the two-byte SEQUENCE ID allows for up to 65535 PDU's per iSNS message. 6.2 iSNSP Message Segmentation and Reassembly iSNS messages may be carried in one or more iSNS PDU's. If only one iSNS PDU is used to carry the iSNS message, then bit 21 (First PDU) and bit 20 in the FLAGS field (Last PDU) SHALL both be enabled. If multiple PDUs are used to carry the iSNS message, then bit 21 SHALL be enabled in the first PDU of the message, and bit 20 SHALL be enabled in the last PDU. Tseng, Gibbons, et al. Standards Track [Page 30] Internet Storage Name Service (iSNS) May 2002 All PDU's 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. 6.3 iSNSP Message Payload The MESSAGE PAYLOAD is variable length and contains attributes used for registration and query operations. The attribute data items use a format similar to other protocols, such as DHCP (RFC 2131) options. Each iSNS attribute is specified in the iSNSP message payload using Tag-Length-Value (TLV) data format, as shown below: 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 + N Attribute Tag - a 4-byte tag field that identifies the attribute as defined in section 7.1. This field contains the ID of the indicated attribute. Attribute Length - a 4-byte field that indicates the length, in bytes, of the attribute value to follow. Attribute Value - a variable-length field containing the attribute value. The above format is used to identify each attribute in the iSNS message payload. 6.3.1 Attribute Value 4-Byte Alignment All attribute values are aligned at 4 byte boundaries. For variable length attributes, the value length is increased to the next 4-byte boundary and the value is NULL padded. 6.4 iSNSP Response Status Codes All iSNSP response messages contain a 4-byte Status Code field as the first field in the iSNSP PAYLOAD. If the original iSNSP request message was processed normally by the iSNS server, or the iSNS client for ESI and SCN messages, this field shall contain a status code of 0 (Successful) or 1 (Successful w/Additions or Modifications) Tseng, Gibbons, et al. Standards Track [Page 31] Internet Storage Name Service (iSNS) May 2002 Status Code Status Description ----------- ----------------- 0 Successful 1 Unknown Error 2 Message Format Error 3 Invalid Registration 4 RESERVED 5 Invalid Query 6 Authentication Unknown 7 Authentication Absent 8 Authentication Failed 9 No Such Entry 10 Version Not Supported 11 Internal Error 12 Busy 13 Option Not Understood 14 Invalid Update 15 Message Not Supported 16 SCN Event Rejected 17 SCN Registration Rejected 18 Attribute not Implemented 19 SWITCH_ID not available 20 SWITCH_ID not allocated 21 ESI Not Available 22 And Above RESERVED 6.5 iSNS Multicast Message Authentication For iSNS multicast messages, the iSNSP provides authentication capability. The following section details the iSNS Authentication Block, which is identical in format to the SLP authentication block [RFC2608]. iSNS unicast messages SHOULD NOT include the authentication block, but rather should rely upon IPSec security mechanisms. If a PKI is available with an X.509 certificate authority, then public key authentication of the iSNS server is possible. The authentication block leverages the DSA with SHA-1 algorithm, which can easily integrate into a public key infrastructure. The authentication block contains a digital signature for the multicast message. The digital signature is calculated on a per-PDU basis. The authentication block contains the following information: 1. A time stamp, to prevent replay attacks 2. A structured authenticator containing a signature calculated over the time stamp and the message being secured 3. An indicator of the cryptographic algorithm that was used to calculate the signature. 4. An indicator of the keying material and algorithm parameters, used to calculate the signature. The authentication block is described in the following figure: Tseng, Gibbons, et al. Standards Track [Page 32] Internet Storage Name Service (iSNS) May 2002 Byte MSb LSb Offset 0 1 2 3 4 5 6 7 +----------------------------------+ 0 | BLOCK STRUCTURE DESCRIPTOR | 2 Bytes +----------------------------------+ 2 | AUTHENTICATION BLOCK LENGTH | 2 Bytes +----------------------------------+ 4 | TIMESTAMP | 4 Bytes +----------------------------------+ 8 | SPI STRING LENGTH | 1 Byte +----------------------------------+ 9 | SPI STRING | N Bytes +----------------------------------+ 9 + N | STRUCTURED AUTHENTICATOR | M Bytes +----------------------------------+ Total Length = 9 + N + M BLOCK STRUCTURE DESCRIPTOR (BSD) - Defines the structure and algorithm to use for the STRUCTURED AUTHENTICATOR. Currently, the only defined value for BSD is 0x0002, which represents DSA with SHA- 1. Details on DSA can be found in [DSS]. BSD values from 0x0000 to 0x7FFF are assigned by IANA, while 0x8000 to 0x8FFF are for private use. The BSD value 0x0002 is compatible with the X.509 PKI specification, allowing easy integration of the STRUCTURED AUTHENTICATOR format with an existing PKI infrastructure. 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 a 4-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 of 0x0002, this field contains the binary ASN.1 encoding of output values from the DSA with SHA-1 signature calculation. 6.6 Registration and Query Messages The iSNSP registration and query message payloads contain a list of attributes, and have the following format: Tseng, Gibbons, et al. Standards Track [Page 33] Internet Storage Name Service (iSNS) May 2002 MSb LSb 0 31 +----------------------------------------+ | Source Attribute (Requests Only) | +----------------------------------------+ | Message Key Attribute[1] (if present) | +----------------------------------------+ | Message Key Attribute[2] (if present) | +----------------------------------------+ | Message Key Attribute[3] (if present) | +----------------------------------------+ | . . . | +----------------------------------------+ | - Delimiter Attribute - | +----------------------------------------+ | Operating Attribute[1] | +----------------------------------------+ | Operating Attribute[2] (if present) | +----------------------------------------+ | Operating Attribute[3] (if present) | +----------------------------------------+ | . . . | +----------------------------------------+ iSNS Registration and Query messages, sent by iSNS Clients, are sent to the iSNS IP-Address and TCP/UDP Port. The iSNS Responses will be sent to the iSNS Client IP-Address and the originating TCP/UDP Port used for the associated registration and query message. 6.6.1 Source Attribute The source attribute is used to identify the iSNS client to the iSNS server for queries and other messages that require source identification. The source attribute uniquely identifies the source of the message. Valid source attribute types are shown below. Valid Source Attributes ----------------------- iSCSI Name FC Port Name WWPN For a query operation, the source attribute is used to limit the scope of the specified operation to the Discovery Domains of which the source is a member. Special control nodes, identified by the Source Attribute, may be administratively configured to perform the specified operation on all objects in the iSNS database without scoping to Discovery Domains. 6.6.2 Message Key Attributes Message Key attributes are used to identify pre-existing objects in the iSNS database for iSNS query and registration messages. If the object identified by the Message Key attributes are not found in the iSNS database, then an Status Code of 9 (no such entry) shall be Tseng, Gibbons, et al. Standards Track [Page 34] Internet Storage Name Service (iSNS) May 2002 returned by the iSNS server. When registering a new NETWORK ENTITY object that did not previously exist in the iSNS database, no Message Key attribute should be used. Non-key attributes MUST NOT be listed among the Message Key Attributes. 6.6.3 Delimiter Attribute The Delimiter Attribute separates the key attributes from the operating attributes in a message payload. 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. 6.6.4 Operating Attributes The Operating Attributes are a list of one or more key and non-key attributes related 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. The tag value distinguishes the attribute as an object key attribute (i.e., tag=16&17, 32, 64, and 96) or non-key attribute. The ordering of operating attributes in the message is important in determining the relationships among objects and their ownership of non-key attributes. iSNS protocol messages that violate these ordering rules SHALL be rejected with the Status Code of 2 (Message Format Error). 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 describing an object keyed by more than one key attribute, each and every object key attribute of that object MUST be listed sequentially by tag value in the message before non-key attributes of that object, and key attributes of the next object. Non-key attributes that immediately follow a set of one or more object key attributes MUST be attributes of the object referenced by that set of object key attributes. All non-key attributes of an object MUST be listed before the object key attributes introducing the next object. Objects and their attributes MUST be listed in their order of inheritance hierarchy. STORAGE NODE and PORTAL objects and their respective attributes MUST follow the NETWORK ENTITY object to which they have a relationship. Similarly, FC DEVICE objects MUST follow the STORAGE NODE object to which they have a relationship. Vendor-specific objects defined by tag values in the range 1537-2048 have the same requirements described above. Tseng, Gibbons, et al. Standards Track [Page 35] Internet Storage Name Service (iSNS) May 2002 6.6.4.1 Operating Attributes for Query and Get Next Requests In Query and Get Next request messages, TLV attributes with length value of 0 are used to indicate which operating attributes are to be returned in the corresponding response. Operating Attribute values that match the TLV attributes in the original message are returned in the response message. 6.6.5 Registration and Query Request Message Types The following describes each query and message type. 6.6.5.1 Register Device Attribute Request (RegDevAttr) The RegDevAttr message type is 0x0001. The RegDevAttr message provides an iSNS client with the means to register objects and attributes. Depending on the setting of the Replace bit in the FLAGS field, the Operating attribute values in the RegDevAttr message will either replace existing attributes, or be added to existing attributes. See section 6.6.5.1.1 below for a complete description of the Replace Flag. The operating attributes represent new objects and attributes that are to be registered. Multiple objects and attributes can be registered in one RegDevAttr message. The ordering of the objects in this message indicate the structure of associations among the objects to be created in the iSNS server. To create a relationships between a parent ENTITY object and its PORTAL and STORAGE NODE objects, the registration message SHALL list the key and operating attributes of the ENTITY object, followed by the attributes of each PORTAL and STORAGE NODE object to be linked to that ENTITY. Similarly, FC DEVICE object attributes that follow a STORAGE NODE object are considered to have a subordinate relationship with that STORAGE NODE. A maximum of one new ENTITY object can be created with a single RegDevAttr message; there is no limit to the number of PORTAL, STORAGE NODE, and FC DEVICE objects that can be created for the ENTITY registered by the RegDevAttr message. A RegDevAttr message with no Message Key Attribute results in creation of a new NETWORK ENTITY object. If the EID attribute (with non-zero length) is included among the operating attributes in the RegDevAttr message, then the new NETWORK ENTITY SHALL be assigned the value contained in that EID attribute. Otherwise, if the EID attribute is not contained among the operating attributes of the RegDevAttr message, or if the EID is an operating attribute with TLV length of 0, then the iSNS server SHALL create the EID for the new NETWORK ENTITY that is registered in the iSNS database and returned in the RegDevAttr Response message. A registration message that creates a new NETWORK ENTITY object that does not contain at least one PORTAL and one STORAGE NODE shall be Tseng, Gibbons, et al. Standards Track [Page 36] Internet Storage Name Service (iSNS) May 2002 considered invalid. Invalid registrations shall return a response with Status Code of 3 (Invalid Registration). Note that the iSNS server may modify or reject the registration of certain attributes, such as ESI Interval. In addition, the iSNS server may assign values for additional operating attributes that are not registered in the original RegDevAttr message, such as the Portal Group Tag. The values for such attributes are returned in the operating attributes of the corresponding RegDevRsp message. 6.6.5.1.1 Replace Flag The Replace Flag, contained in the message header FLAGS field, indicates whether the registration is a replacement of, or update to, an existing object. If the object key attributes of a registration message do not match an existing object in the iSNS database, then the Replace flag is irrelevant; a new object is created regardless of whether the Replace flag is enabled or not. If the object key attributes match an existing object in the iSNS database, and the Replace flag is enabled, then the registration will replace the existing entry in the iSNS database. The existing object(s) specified in the RegDevAttr message shall be de- registered. A new registration shall be created with the new attribute value(s) in the registration request. Existing associations between objects will be updated to reflect the new information. For example, an existing STORAGE NODE object may be de-registered and reregistered with a different NETWORK ENTITY object with a single registration message. If the object key attributes match an existing object in the iSNS database, and the Replace flag is not enabled, then the new attribute value(s) in the registration request SHALL update existing values and may add new, additional attributes for the object key entry. Only non-key attributes can be updated. Existing associations between objects will be maintained and SHALL NOT be changed if the Replace flag is not enabled. If a registration update of the existing object would cause a change in associations, then the error ôInvalid Updateô SHALL be returned. For example, if a RegDevAttr message with an Entity Identifier key for one NETWORK ENTITY object contains a STORAGE NODE object attribute associated with different NETWORK ENTITY object, then an error shall be returned. 6.6.5.2 Device Attribute Query Request (DevAttrQry) The DevAttrQry message type is 0x0002. The DevAttrQry message provides an iSNS client with the means to query the iSNS server for objects and attributes. The source is used to scope the query to the Discovery Domains that the source attribute is a member of. Tseng, Gibbons, et al. Standards Track [Page 37] Internet Storage Name Service (iSNS) May 2002 The Message Key Attribute(s) follow the source attribute in the message payload. The attributes returned by the query will be from objects WHERE the Message Key Attribute(s) match the object. The Message Key Attributes map to a type of object. If no operating attributes are included in the DevAttrQry, then all operating attributes of the object and sub-objects identified by the message key attribute(s) SHALL be returned in the response message. For queries by non-control nodes, any objects matching the Message Key Attributes that are not in the same Discovery Domain as the Source Attribute SHALL NOT be included in the response message. Registration and query messages for iSNS server-specific attributes (i.e., tags in the range 132 to 384) shall be formatted using the identifying key attribute of the STORAGE NODE originating the query (i.e., iSCSI Name or FC Port Name WWPN) for both the source attribute and message key attribute. Operating attributes shall include the TLV of the server-specific attribute being requested. 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 IP-Address, Portal TCP/UDP Port iSCSI Node Type iSCSI Identifier FC Port Name WWPN FC Port Type FC-4 Type Source Attribute (for server-specific attributes) Switch Name (FC Device WWNN--for space identifier queries) 6.6.5.3 Device Get Next Request (DevGetNext) The DevGetNext message type is 0x0003. This message provides the iSNS client with the means to retrieve each and every Entity, Portal, iSCSI Node, FC Port Name, or FC Node Name attribute from DD's to which the client has access. The source attribute is used to scope the retrieval process to the Discovery Domains that the source attribute is a member of. The Message Key Attribute follows the source attribute in the message payload. The Message Key Attribute may be an Entity Identifier (EID), iSCSI Name, Portal IP Address and TCP/UDP Port, FC Node Name WWNN, or FC Port Name WWPN. If the key TLV length value entered is zero, signifying an empty key value field, then the first accessible Entity Identifier, iSCSI Name, Portal IP Address and TCP/UDP Port, FC Node name, or FC Port Name instance shall be returned to the client. DevGetNext SHALL return the object that is Tseng, Gibbons, et al. Standards Track [Page 38] Internet Storage Name Service (iSNS) May 2002 stored after the object matching the key provided. If the key provided matches the last object instance, then the Status Code of 9 (No Such Entry) SHALL be returned in the response. The values of the matching Operating Attributes listed in the original DevGetNext message SHALL be returned in the DevGetNext response. 6.6.5.4 Deregister Device Request (DeregDev) The DeregDev message type is 0x0004. An iSNS client port or device is removed from the iSNS database by using DeregDev. Upon receiving the DeregDev, the iSNS server removes all object registrations associated with the Message Key Attribute in the payload. The DeregDev request message payload contains a Source Attribute and Message Key Attribute(s). Valid Key Attributes are shown below: Valid Message Key Attributes for DeregDev ----------------------------------------- Entity Identifier Portal IP-Address Portal IP-Address, Portal TCP/UDP Port iSCSI Name FC Port Name WWPN FC Node Name WWNN The removal of the object will initiate an SCN message to registered iSNS clients that are in the same DD as the removed device or port. After removing the port or device, the iSNS server sends back an acknowledgement to the iSNS client. If all nodes associated with an entity are deregistered from that entity, then the entity SHALL also be removed UNLESS the entity (through one or more Portals) is responding to ESI's. If all Portals associated with an entity are deregistered from that entity, then that entity and all associated nodes SHALL be removed from the iSNS database. 6.6.5.5 SCN Register Request (SCNReg) The SCNReg message type is 0x0005. The State Change Notification Registration Request (SCNReg) message allows an iSNS client to register a STORAGE NODE to receive State Change Notification (SCN) messages. SCN messages are sent to each indicated UDP or TCP Port specified in the SCN Port field (tag 23) of each PORTAL object. The SCN notifies the iSNS client of changes within the DD or network. Note that while SCNReg sets the SCN Bitmap field, the RegDevAttr message registers the UDP or TCP Port used by each Portal to receive SCN messages. If no SCN Port fields of any Portals of the iSNS client Tseng, Gibbons, et al. Standards Track [Page 39] Internet Storage Name Service (iSNS) May 2002 are registered to receive SCN messages, then the SCNReg message SHALL be rejected with Status Code 17 (SCN Registration Rejected). The SCNReg request message payload contains a Source Attribute, a Message Key Attribute(s), and an Operating Attribute. Valid Message Key Attributes for an SCNReg are shown below: Valid Message Key Attributes for SCNReg --------------------------------------- iSCSI Name FC Port Name WWPN Nodes with iSCSI Name or FC Port Name WWPN attributes that match the Message Key Attributes in the SCNReg message are registered to receive SCNs using the specified SCN bitmap. The SCN Bitmap is the only operating attribute of this message, and it always overwrites the previous contents of this field in the iSNS database. The bitmap indicates those INTERESTED EVENT TYPES the node is registering for. Note that the settings of this bitmap determine whether the SCN registration is for a regular SCN's or management SCN's. Only control nodes MAY conduct registrations for management SCN's; iSNS clients that are not control nodes MUST NOT conduct mangement SCN registrations. Note that control nodes that register for management SCN's receive a copy of every SCN message generated by the iSNS server. Therefore, management registrations should be used sparingly in order to conserve iSNS server resources, and the control nodes that conduct such registrations should be prepared to receive the anticipated volume of SCN message traffic. 6.6.5.6 SCN Deregister Request (SCNDereg) The SCNDereg message type is 0x0006. The SCNDereg message allows an iSNS client to disable State Change Notification (SCN) messages. The SCNDereg request message payload contains a Source Attribute and Message Key Attribute(s). Valid Message Key Attributes for an SCNDereg are shown below: Valid Message Key Attributes for SCNDereg ----------------------------------------- iSCSI Name FC Port Name WWPN Nodes with iSCSI Name or FC Port Name WWPN attributes that match the Message Key Attributes in the SCNDereg message are deregistered for SCNs. The SCN bitmap field of such nodes are cleared, and no SCN messages shall be sent for changes to that node. There are no Delimiter or Operating Attributes in the SCNDereg message. Tseng, Gibbons, et al. Standards Track [Page 40] Internet Storage Name Service (iSNS) May 2002 6.6.5.7 SCN Event (SCNEvent) The SCNEvent message type is 0x0007. The SCNEvent is a message sent by an iSNS client to request generation of a State Change Notification (SCN) message by the iSNS server. The SCN, sent by the iSNS server, then notifies iFCP, iSCSI, and control nodes within the affected DD of the change indicated in the SCNEvent. Most SCNs are automatically generated by the iSNS server when nodes are registered or deregistered from the directory database. SCNs are also generated when a network management application makes changes to the DD membership in the iSNS server. However, an iSNS client can trigger an SCN by using SCNEvent. The SCNEvent message payload contains a Source Attribute, Message Key Attribute, and Operating Attribute. Valid Key Attributes for an SCNEvent are shown below: Valid Message Key Attributes for SCNEvent ----------------------------------------- iSCSI Name FC Port Name WWPN The Operating Attributes section SHALL contain the SCN Event Bitmap attribute. The bitmap indicates the event that caused the SCNEvent to be generated. 6.6.5.8 State Change Notification (SCN) The SCN message type is 0x0008. The SCN is a message generated by the iSNS server, notifying a registered iFCP, iSCSI, or control node of changes. There are two types of SCN registrations: regular registrations and management registrations. Regular SCN's notify iSNS clients of events within the discovery domain. Management SCN's notify control nodes that register for management SCN's of events occuring anywhere in the network. The SCN message is sent to each Portal of the registered STORAGE NODE that has a registered TCP or UDP Port value in the SCN Port field. The types of events that can trigger an SCN message, and the amount of information contained in the SCN message, depend on the registered SCN Event Bitmap for the iSNS client. The format of the SCN payload is shown below: Tseng, Gibbons, et al. Standards Track [Page 41] Internet Storage Name Service (iSNS) May 2002 +----------------------------------------+ | 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 payload attributes are in TLV format. The Destination Attribute is the node identifier that is receiving the SCN. The Destination Attribute can be an iSCSI Name, or FC Port Name. The Timestamp field, using the Timestamp TLV format, indicates the time the SCN was generated. The Source Attributes describe the object(s) that are affected by the event causing the SCN to be generated. For regular SCN messages, the Source Attributes can be an iSCSI Name or FC Port Name WWPN. For management SCN messages, the Source Attributes can be an iSCSI Name, DD ID, DDS ID, or FC Port Name WWPN. The provided source attribute can then be used by the iSNS client in a follow-up query to more fully learn of the changes in the iSNS database that triggered the SCN. For example, a management SCN to notify 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. A regular SCN to notify an iSNS client of a new PORTAL available for particular iSCSI target would contain the iSCSI Name of the target device among the source attributes. The Source SCN Bitmap field indicates the type of SCN notification (i.e., regular or management SCN), and the type of event that caused the SCN to be generated; it does not necessarily correlate with the original SCN bitmap registered in the iSNS server. This field is also used as a delimiter between information about multiple objects, if the SCN message is providing multiple SCN notifications. See sections 7.4.4 and 7.5.12 for additional information on the SCN Bitmap. Tseng, Gibbons, et al. Standards Track [Page 42] Internet Storage Name Service (iSNS) May 2002 6.6.5.9 DD Register (DDReg) The DDReg message type is 0x0009. This message is used to create a new Discovery Domain (DD), update an existing DD Symbolic Name, and/or add DD members. DDs are uniquely defined using DD_IDs. DD registration attributes are described in section 7.9. The DDReg message payload contains the Source Attribute, and optionally Key and Operating Attributes. A DDReg message with no Message Key Attribute results in creation of a new Discovery Domain (DD). If the DD_ID attribute (with non-zero length) is included among the operating attributes in the DDReg message, then the new Discovery Domain SHALL be assigned the value contained in that DD_ID attribute. Otherwise, if the DD_ID attribute is not contained among the operating attributes of the DDReg message, or if the DD_ID is an operating attribute with TLV length of 0, then the iSNS server SHALL assign the DD_ID value that is returned in the DDReg Response message. The Operating Attributes can contain the iSCSI Node Identifier or iFCP WWPN of iSNS clients to be added to the DD. It may also contain the DD_Symbolic_Name of the DD. This message shall add any DD members listed as operating attributes to the Discovery Domain specified by the DD_ID. In addition, if the DD_Symbolic_Name is an operating attribute, then it will be stored in the iSNS database as the DD_Symbolic_Name for the specified Discovery Domain. 6.6.5.10 DD Deregister (DDDereg) The DDDereg message type is 0x000A. This message allows an iSNS client to deregister an existing Discovery Domain (DD) or remove members from an existing DD. DDs are uniquely defined using DD_IDs. DD registration attributes are described in section 7.9. The DDDereg message payload contains a Source Attribute, Message Key Attribute, and Operating Attributes. The Message Key Attribute for a DDDereg message is the DD ID for the domain being removed, or having members removed. If the DD ID matches an existing DD, and there are no operating attributes, then the DD will be removed and a success Status Code returned. If the Message Key Attribute does not match an existing DD then the Status Code 9 (No Such Entry) will be returned. If the DD ID matches an existing DD, and there are operating attributes matching DD members, then the DD members identified by the operating attributes SHALL be removed from the DD and a Tseng, Gibbons, et al. Standards Track [Page 43] Internet Storage Name Service (iSNS) May 2002 successful Status Code (0 or 1) returned. If any of the operating attributes do not match existing DD members, then the Status Code 9 (No Such Entry) will be returned, and no DD members shall be removed. 6.6.5.11 DDS Register (DDSReg) The DDSReg message type is 0x000B. This message allows an iSNS client to create a new Discovery Domain Set (DDS), update an existing DDS Symbolic Name, or add DDS members. DDSÆs are uniquely defined using DDS_IDÆs. DDS registration attributes are described in section 7.9.1. The DDSReg message payload contains the Source Attribute, and optionally, Message Key and Operating Attributes. A DDSReg message with no Message Key Attribute results in creation of a new Discovery Domain Set (DDS). If the DDS_ID attribute (with non-zero length) is included among the operating attributes in the DDSReg message, then the new Discovery Domain Set SHALL be assigned the value contained in that DDS_ID attribute. Otherwise, if the DDS_ID attribute is not contained among the operating attributes of the DDSReg message, or if the DDS_ID is an operating attribute with TLV length of 0, then the iSNS server SHALL assign the DDS_ID value that is returned in the DDSReg Response message. The Operating Attributes can contain the DDS_Symbolic_Name and the DD_IDÆs of Discovery Domains to be added to the DDS. This message shall add any DDS members listed as operating attributes to the Discovery Domain Set specified by the DDS_ID Message Key Attribute. In addition, if the DDS_Symbolic_Name is an operating attribute, then it will be stored in the iSNS database as the DDS_Symbolic_Name for the specified Discovery Domain Set. 6.6.5.12 DDS Deregister (DDSDereg) The DDSDereg message type is 0x000C. This message allows an iSNS client to deregister an existing Discovery Domain Set (DDS) or remove some DDÆs from an existing DDS. The DDSDereg message payload contains a Source Attribute, Message Key Attribute, and Operating Attributes. The Message Key Attribute for a DDSDereg message is the DDS ID for the set being removed, or having members removed. If the DDS ID matches an existing DDS, and there are no operating attributes, then the DDS will be removed and a success Status Code returned. If the Message Key Attribute does not match an existing DDS then the Status Code 9 (No Such Entry) will be returned. If the DDS ID matches an existing DDS, and there are operating attributes matching DDS members, then the DDS members will be Tseng, Gibbons, et al. Standards Track [Page 44] Internet Storage Name Service (iSNS) May 2002 removed from the DDS and a success Status Code returned. If any of the operating attributes do not match existing DDS members, then the Status Code 9 (No Such Entry) will be returned and no DDS members shall be removed. 6.6.5.13 Entity Status Inquiry (ESI) The ESI message type is 0x000D. This message is sent by the iSNS server, and is used to verify that an iSNS client portal is reachable and available. The ESI message is sent to the ESI UDP port provided during registration, or the TCP connection used for ESI registration, depending on which communication type that is being used. The ESI message payload contains several attributes in TLV format, including the current iSNS timestamp, the EID, the Portal IP Address, and Portal TCP/UDP Port. The ESI response message payload contains the Attributes from the original ESI message. If the iSNS client portal fails to respond to an administratively- determined number of consecutive ESI messages, then the iSNS server SHALL remove that client portal from the iSNS database. If there are no other remaining ESI monitored portals for the associated entity, then the entity SHALL also be removed. The appropriate State Change Notifications, if any, SHALL be triggered. 6.6.5.14 Name Service Heartbeat (Heartbeat) This message SHOULD only be sent by the active iSNS server. It allows iSNS clients and backup servers listening to the broadcast or multicast address to discover the IP address of the primary and backup iSNS servers. It also allows concerned parties to monitor 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. Tseng, Gibbons, et al. Standards Track [Page 45] Internet Storage Name Service (iSNS) May 2002 MSb LSb 0 31 +------------------------------------------------+ | Active Server IP-Address | +------------------------------------------------+ | iSNS TCP Port | iSNS UDP Port | +------------------------------------------------+ | Interval | +------------------------------------------------+ | Counter | +------------------------------------------------+ | RESERVED | Backup Servers | +------------------------------------------------+ | Primary Backup Server IP Address(if any) | +------------------------------------------------+ |Backup TCP Port(if any)|Backup UDP Port(if any) | +------------------------------------------------+ | 2nd Backup Server IP Address(if any) | +------------------------------------------------+ |Backup TCP Port(if any)|Backup UDP Port(if any) | +------------------------------------------------+ | . . . | +------------------------------------------------+ | VENDOR SPECIFIC | +------------------------------------------------+ The heartbeat payload contains: Active Server IP-Address: the IP_Address of the active iSNS server in IPv6 format. 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 monotonically incrementing count of heartbeats sent 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 list 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. 6.6.5.15 Request Switch ID (RqstSwId) The RqstSwId message type is 0x0011. This message is used for iFCP Transparent Mode to allocate non-overlapping SWITCH_ID values Tseng, Gibbons, et al. Standards Track [Page 46] Internet Storage Name Service (iSNS) May 2002 between 1 and 239. The iSNS server becomes the address assignment authority for the entire iFCP fabric. To obtain multiple SWITCH_ID values, this request must be repeated multiple times to the iSNS server. iSNS clients that acquire SWITCH_ID values from an iSNS server MUST register for ESI monitoring from that iSNS server. The RqstSwId payload contains three TLV attributes in the following order: the requesting Switch Name (WWN) as the source attribute, the Space Identifier as the Message Key Attribute, and Preferred ID as the operating attribute. The Space Identifier is a string identifying the domain space for which the iSNS server shall allocate non-overlapping integer SWITCH_ID values between 1 and 239. The Preferred_ID is the nominal SWITCH_ID value requested by the iSNS client. If the Preferred_ID value is available and has not been already allocated for the Space_Identifier specified in the message, the iSNS server shall return the requested Preferred_ID value as the Assigned_ID to the requesting client. The RqstSwId response contains an Status Code, and the TLV attribute Assigned ID, which contains the integer value in the space requested. If no further unallocated values are available from this space, the iSNS server SHALL respond with the Status Code 18 "SWITCH_ID not available". Once a SWITCH_ID value has been allocated to an iSNS client by the iSNS server for a given Space_Identifier, that SWITCH_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 objects for that client are removed from the iSNS database. The iSNS server and client SHALL use TCP to transmit and receive RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages. 6.6.5.16 Release Switch ID (RlseSwId) The RlseSwId message type is 0x0012. This message may be used by iFCP Transparent Mode to release integer identifier values used to assign 3-byte Fibre Channel PORT_ID values. The RlseSwId message contains three TLV attributes in the following order: the requesting entity EID as the source attribute, the Space_Identifier as the Message Key Attribute, and Assigned_ID as the operating attribute. Upon receiving the RlseSwId message, the iSNS server shall deallocate the SWITCH_ID value contained in the Assigned_ID attribute for the Space_Identifier attribute specified. Upon deallocation, that SWITCH_ID value can now be requested by, and assigned to, a different iSNS client. The iSNS server and client SHALL use TCP to transmit and receive RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages. Tseng, Gibbons, et al. Standards Track [Page 47] Internet Storage Name Service (iSNS) May 2002 6.6.5.17 Get Switch IDs (GetSwIds) The GetSwIds message type is 0x0013. This message is used to learn the currently-allocated SWITCH_ID values for a given Space_Identifier. The GetSwIds message payload contains a Source Attribute and Message Key Attribute. The Message Key Attribute for the GetSwIds message is the Space_Identifier. The response to this message returns all of the SWITCH_ID values that have been allocated for the Space_Identifier specified. 6.7 Response Messages The iSNSP response message payloads contain an 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) | +----------------------------------------+ | Message Key Attribute[3] (if present) | +----------------------------------------+ | . . . | +----------------------------------------+ | - Delimiter Attribute - (if present) | +----------------------------------------+ | Operating Attribute[1] (if present) | +----------------------------------------+ | Operating Attribute[2] (if present) | +----------------------------------------+ | Operating Attribute[3] (if present) | +----------------------------------------+ | . . . | +----------------------------------------+ The iSNS Response messages will be sent to the iSNS Client IP Address and the originating TCP/UDP Port that was used for the associated registration and query message. 6.7.1 Status Code The first field in an iSNSP response message payload is the Status Code for the operation that was performed. The Status Code encoding is defined in section 6.4. Tseng, Gibbons, et al. Standards Track [Page 48] Internet Storage Name Service (iSNS) May 2002 6.7.2 Message Key Attributes in Response Depending on the specific iSNSP request, the response message will 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. Non-key attributes MUST NOT be listed among the Message Key Attributes. 6.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. 6.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. 6.7.5 Registration and Query Response Message Types The following describes each query and message type. 6.7.5.1 Register Device Attribute Response (RegDevRsp) The RegDevRsp message type is 0x8001. The RegDevRsp message contains the results for the RegDevAttr message with the same TRANSACTION ID. The Status Code contains the operation results. If the registration completed successfully, then the code of "SUCCESS" is returned. If an error occurred then the appropriate code will be returned. The Message Key Attributes contain the set of key attributes identifying the objects registered by the Register Device Attribute message. These key attributes are listed in their order of inheritance hierarchy. 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 RegDevRsp message contain the affected objects and attributes that have been modified or added by the iSNS server. These attributes include key and non-key attributes identifying the object and the modified or added attribute. Note that key attributes should be among listed among the Message Key Attributes. Among the operating attributes, each modified or added non-key attribute shall be listed followin