Internet Draft Kevin Gibbons <draft-ietf-ips-isns-04.txt> Josh Tseng Expires December 2001 Charles Monia Nishan Systems Franco Travostino Nortel Networks Ken Hirata Vixel Corporation Mark Bakke Cisco Systems John Dowdy IBM Howard Hall Pirus Networks June 2001 iSNS Internet Storage Name Service Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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: John Hufferd (IBM), Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe Czap (IBM), Jim Gibbons, Tseng, Monia Standards Track iSNS June 2001 Hafner (IBM), Yaron Klein (Sanrad), Larry Lamers (SAN Valley), Jack Harwood (EMC), David Black (EMC), David Robinson (Sun), and Marjorie Krueger (HP). 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. Conventions used in 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.........................................................7 3.2 iSNS Functional Components...................................7 3.2.1 Name Registration Service....................................8 3.2.2 Discovery Domain and Login Control Service...................8 3.2.3 State Change Notification Service............................9 3.3 iSNS and Domain Name System (DNS)...........................10 3.4 iSNS and LDAP...............................................10 3.5 iSNS Server Discovery.......................................11 3.6 iSNS and NAT................................................11 3.7 Interactions Between iSNS Infrastructures...................12 3.8 Deployment Architecture Diagram.............................14 4. iSNS Object Model...........................................14 4.1 NETWORK ENTITY Object.......................................15 4.2 PORTAL Object...............................................15 4.3 STORAGE NODE Object.........................................15 4.4 FC DEVICE Object (iFCP Only)................................15 4.5 DISCOVERY DOMAIN Object.....................................15 4.6 DISCOVERY DOMAIN SET Object.................................15 4.7 iSNS Database Model.........................................15 5. iSNS Implementation Requirements............................16 5.1 iSCSI Requirements..........................................16 5.1.1 Required Attributes for Support of iSCSI....................16 5.1.2 Attribute Descriptions for iSCSI Storage Systems............17 5.1.3 Example iSCSI Object Model Diagrams.........................18 5.1.4 Required Commands and Response Messages for Support of iSCSI20 Gibbons, Tseng, Monia Standards Track 2 iSNS June 2001 5.2 iFCP Requirements...........................................21 5.2.1 Required Attributes for Support of iFCP.....................21 5.2.2 Attribute Descriptions for iFCP Gateways and FC devices.....22 5.2.3 iFCP Attribute Requirements.................................24 5.2.3.1 Port_ID.....................................................24 5.2.4 Example iFCP Object Model Diagram...........................24 5.2.5 Required Commands and Response Messages for Support of iFCP.25 5.3 Attribute Descriptions for Discovery Domain Registration....26 5.4 Use of TCP For iSNS Communication...........................27 5.5 Use of UDP For iSNS Communication...........................28 6. iSNS Message Attributes.....................................28 6.1 iSNS Attribute Summary......................................28 6.2 Entity Identifier-Keyed Attributes..........................30 6.2.1 Entity Identifier (EID).....................................30 6.2.2 Entity Protocol.............................................31 6.2.3 Management IP Address.......................................31 6.2.4 Entity Registration Timestamp...............................31 6.2.5 Protocol Version Range......................................31 6.2.6 Registration Period.........................................32 6.2.7 Entity Certificate..........................................32 6.3 Portal-Keyed Attributes.....................................32 6.3.1 Portal IP-Address...........................................32 6.3.2 Portal TCP/UDP Port.........................................32 6.3.3 Portal Symbolic Name........................................33 6.3.4 Entity Status Inquiry Interval..............................33 6.3.5 ESI/SCN UDP Port............................................33 6.3.6 Portal Group................................................34 6.3.7 Portal Certificate..........................................34 6.4 iSCSI Node-Keyed Attributes.................................34 6.4.1 iSCSI Name..................................................34 6.4.2 iSCSI Node Type.............................................34 6.4.3 iSCSI Node Alias............................................35 6.4.4 iSCSI Node SCN Bitmap.......................................35 6.4.5 iSCSI Node Certificate......................................35 6.5 iFCP Node-Keyed Attributes..................................35 6.5.1 iFCP Node Port Name (WWPN)..................................36 6.5.2 Port ID.....................................................36 6.5.3 Port Type...................................................36 6.5.4 iFCP Node Port Symbolic Name................................36 6.5.5 iFCP Node Fabric Port Name (FWWN)...........................37 6.5.6 FC Hard Address.............................................37 6.5.7 FC Port IP Address..........................................37 6.5.8 FC Class of Service (COS)...................................37 6.5.9 FC FC-4 Types...............................................37 6.5.10 FC FC-4 Descriptor..........................................37 6.5.11 FC FC-4 Features............................................38 6.5.12 iFCP Node SCN Bitmap........................................38 Gibbons, Tseng, Monia Standards Track 3 iSNS June 2001 6.5.13 iFCP Node Certificate.......................................38 6.5.14 iFCP Node Type.............................................38 6.6 iFCP FC Device Node-Keyed Attributes........................38 6.6.1 iFCP FC Device Node Name (WWNN).............................39 6.6.2 iFCP FC Device Symbolic Name................................39 6.6.3 FC Device IP Address........................................39 6.6.4 FC Device IPA...............................................39 6.6.5 FC Device Certificate.......................................39 6.7 Other Attributes............................................39 6.7.1 FC-4 Type Code..............................................39 6.7.2 Preferred ID................................................40 6.7.3 Assigned ID.................................................40 6.7.4 Space_Identifier............................................40 6.8 Discovery Domain Registration Attributes....................40 6.8.1 iSNS Discovery Domain Attribute Summary.....................40 6.8.2 DD Set ID Keyed Attributes..................................41 6.8.2.1 Discovery Domain Set ID (DDS ID)............................41 6.8.2.2 Discovery Domain Set Symbolic Name..........................41 6.8.2.3 Discovery Domain Set Status.................................41 6.8.2.4 Discovery Domain Set Member.................................42 6.8.3 DD ID Keyed Attributes......................................42 6.8.3.1 Discovery Domain ID (DD ID).................................42 6.8.3.2 Discovery Domain Symbolic Name..............................42 6.8.3.3 Discovery Domain iSCSI Node Member..........................42 6.8.2.4 Discovery Domain iFCP Node Member...........................42 6.9 Vendor-Specific Attributes..................................42 6.10 Company OUI.................................................43 7. iSNSP Message Format........................................43 7.1 iSNSP PDU Header............................................43 7.1.1 iSNSP Version...............................................43 7.1.2 iSNSP Function ID...........................................43 7.1.3 iSNSP PDU Length............................................44 7.1.4 iSNSP Flags.................................................44 7.1.5 iSNSP Transaction ID........................................44 7.1.6 iSNSP Sequence ID...........................................44 7.2 iSNSP Message Segmentation and Reassembly...................44 7.3 iSNSP Message Payload.......................................45 7.3.1 Attribute Value 4-Byte Alignment............................45 7.4 iSNSP Response Error Codes..................................45 7.5 Message Authentication......................................46 7.6 Registration and Query Messages.............................47 7.6.1 Source Attribute............................................48 7.6.2 Key Attributes..............................................49 7.6.3 Delimiter Attribute.........................................49 7.6.4 Operating Attributes........................................49 7.6.4.1 Operating Attributes for Query and Get Next Requests........49 7.6.5 Registration and Query Message Types........................50 Gibbons, Tseng, Monia Standards Track 4 iSNS June 2001 7.6.5.1 Register Device Attribute Request (RegDevAttr)..............50 7.6.5.1.1 Update Flag................................................51 7.6.5.2 Device Attribute Query Request (DevAttrQry).................51 7.6.5.3 Device Get Next Request (DevGetNext)........................52 7.6.5.4 Deregister Device Request (DeregDev)........................52 7.6.5.5 SCN Register Request (SCNReg)...............................53 7.6.5.6 SCN Deregister Request (SCNDereg)...........................54 7.6.5.7 SCN Event (SCNEvent)........................................54 7.6.5.8 State Change Notification (SCN).............................55 7.6.5.9 DD Register (DDReg).........................................56 7.6.5.10 DD Deregister (DDDereg).....................................56 7.6.5.11 DDS Register (DDSReg).......................................57 7.6.5.12 DDS Deregister (DDSDereg)...................................57 7.6.5.13 Entity Status Inquiry (ESI).................................58 7.6.5.14 Name Service Heartbeat (Heartbeat)..........................58 7.6.5.15 Request Switch ID (RqstSwId)................................59 7.6.5.16 Release Switch ID (RlseSwId)................................60 7.6.5.17 Get Switch IDs (GetSwIds)...................................60 7.7 Response Messages...........................................60 7.7.1 Error Code..................................................61 7.7.2 Key Attributes in Response..................................61 7.7.3 Delimiter Attribute in Response.............................61 7.7.4 Operating Attributes in Response............................61 7.7.5 Registration and Query Message Types........................62 7.7.5.1 Register Device Attribute Response (RegDevRsp)..............62 7.7.5.2 Device Attribute Query Response (DevAttrQryRsp).............62 7.7.5.3 Device Get Next Response (DevGetNextRsp)....................62 7.7.5.4 Deregister Device Response (DeregDevRsp)....................63 7.7.5.5 SCN Register Response (SCNRegRsp)...........................63 7.7.5.6 SCN Deregister Response (SCNDeregRsp).......................63 7.7.5.7 SCN Event Response (SCNEventRsp)............................63 7.7.5.8 SCN Response (SCNRsp).......................................63 7.7.5.9 DD Register Response (DDRegRsp).............................64 7.7.5.10 DD Deregister Response (DDDeregRsp).........................64 7.7.5.11 DDS Register Response (DDSRegRsp)...........................64 7.7.5.12 DDS Deregister Response (DDSDeregRsp).......................64 7.7.5.13 Entity Status Inquiry Response (ESIRsp).....................64 7.7.5.14 Request Switch ID Response (RqstSwIdRsp)....................65 7.7.5.15 Release Switch ID Response (RlseSwIdRsp)....................65 7.7.5.16 Get Switch IDs Response (GetSwIdRsp)........................65 7.8 Vendor Specific Messages....................................65 8. Security Considerations.....................................66 8.1 Data Integrity and Authentication...........................66 8.2 Confidentiality.............................................66 8.3 Security Model..............................................66 9. References..................................................66 10. Author's Addresses..........................................67 Gibbons, Tseng, Monia Standards Track 5 iSNS June 2001 Full Copyright Statement.............................................68 A.1 iSCSI Initialization Example................................69 A.1.1 Simple iSCSI Target Registration............................70 A.1.2 Target Registration and DD Configuration....................71 A.1.3 Initiator Registration and Target Discovery.................72 1. Abstract This document provides a generic framework centering around use of the iSNS for discovery and management of iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS is an application that stores iSCSI and FC device attributes and monitors their availability and reachability in an integrated IP storage network. Due to its role as a consolidated information repository, iSNS provides for more efficient and scalable management of storage devices in an IP network. 2. 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 RFC-2119 [2]. All frame formats are in big endian network byte order. 3. iSNS Overview The objective of iSNS is to facilitate scalable configuration and management of iSCSI and Fibre Channel (FCP) storage devices in an IP network. 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 iSNS server thereby serves as the consolidated management contact through which administrator workstations can configure and manage the entire storage network. 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 implementer. Implementation requirements within each of these protocols is further discussed in section 5. Use of iSNS is OPTIONAL for iSCSI, and REQUIRED for iFCP. When used to support both iSCSI and iFCP protocols, iSNS can be implemented to facilitate the discovery and management of both iSCSI and FC devices in an integrated IP/Fibre Channel environment. Gibbons, Tseng, Monia Standards Track 6 iSNS June 2001 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 the iSNS server using the iSNSP. iSNS clients are applications that are co-resident in the storage device, and can register deviceÆs attribute information, download information about other registered clients in a common 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 The iSNS server responds to iSNS protocol queries and requests, and initiates iSNS protocol State Change Notifications. Properly authenticated information submitted by a registration request is stored in an internal or external 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. 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 Components There are three main functional components of the iSNS: Gibbons, Tseng, Monia Standards Track 7 iSNS June 2001 1) A Name Service Providing Storage Resource Discovery 2) Discovery Domain (DD) and Login Control Service 3) State Change Notification Service 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 directory. Both targets and initiators can register in the iSNS, 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. In order to maintain consistency between DNS Name-to-IP address mappings stored in the iSNS, and the same mappings which may exist in DNS servers, a common backend database storing such mappings may be implemented to support both DNS and iSNS. This backend database can be based upon a standard network directory service such as LDAP. 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 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 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. This functionality is the equivalent of the ôHard Zoningö functionality in a Fibre Channel network. Login Control allows targets to subordinate their access control policy to the iSNS. The target node or device downloads the list of authorized initiator nodes or devices from the iSNS. Each node or device is uniquely identified by an iSCSI Name or Port Name (iFCP). Only initiator nodes or devices that match the required identification and authenticating 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. Gibbons, Tseng, Monia Standards Track 8 iSNS June 2001 DD's can be managed offline by a separate management workstation, through the iSNSP or through 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. Depending on the implementation, newly registered devices that have not explicitly been placed into a DD by the management station MAY be placed into a "default DD" where they are visible to other devices in that DD. Other implementations MAY decide that they are registered with no DD, making them inaccessible to source-scoped iSNSP messages. The SOURCE field of every iSNS query and registration message is used 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. If the SOURCE field contains NULL, the iSNS query and registration message SHALL BE scoped to the entire contents of the iSNS, regardless of the configuration of Discovery Domains. Enabled 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. 3.2.3 State Change Notification Service The State Change Notification (SCN) service allows the iSNS 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. The types of events for which SCNs can be sent include change in Discovery Domain (DD) membership and device registration updates. The State Change Notification service utilizes the Discovery Domain Service to control the distribution of notification messages. Notifications about changes within a DD are limited to members of that DD. If the iSNS is unable to service an SCN registration it SHALL reject the SCN registration request, returning a SCN Registration Rejected error code. The rejection might occur in situations where the network size, or current level of SCN registrations, has passed an implementation-specific threshold. A client not allowed to register for SCNs SHOULD monitor its sessions with other storage devices directly. Gibbons, Tseng, Monia Standards Track 9 iSNS June 2001 The specific notification mechanism by which the iSNS learns of the events 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 as a result of link failure. The iSNS is equivalent to the Fibre Channel State Change Notification service, with extensions, operating within the context of an IP network. 3.3 iSNS and Domain Name System (DNS) A directory-enabled iSNS implementation may use LDAP to store iSNS client attributes. If this is the case, then LDAP can be used to support both the iSNS and DNS server infrastructures, maintaining consistency in Domain Name-to-IP address mappings used by DNS and iSNS. A detailed description of the Domain Name System (DNS) protocol is found in [RFC 1035], and is beyond the scope of this document. If a common LDAP information base is used to support both DNS and iSNS servers, then Domain-Name-to-IP address mappings for storage devices can be obtained from either DNS servers or the iSNS. 3.4 iSNS and LDAP LDAP is a generic protocol to access directory services through the network. It is a passive service designed to deliver scalable directory services using a get/set model. Applications designed and tailored to specific user requirements interact with LDAP for their generic directory service needs. On the other hand, iSNS is an application that goes beyond the simple get/set model, and provides specific capabilities needed to monitor and manage an enterprise- scale storage network. iSNS is one example of an application that can leverage the services of LDAP. By layering iSNS on top of LDAP, the capabilities of both iSNS and LDAP can be leveraged to manage and scale the enterprise IP storage network. The iSNS application provides capabilities that LDAP alone is not designed to achieve. This includes the following: 1) Client Attribute Awareness - The iSNS server application interprets attribute values submitted by clients in registration messages, and can take appropriate action based upon specific registered attribute values. The iSNS server is conscious of the state of each client. 2) State Change Notification - An iSNS server may initiate notification messages to clients in the event of a change in the network, such as the non-availability or reachability of a storage device, or a specific change in the value of a client attribute. 3) Monitoring of Clients - iSNS provides a Entity Status Inquiry message to verify the availability and reachability of storage devices. Gibbons, Tseng, Monia Standards Track 10 iSNS June 2001 4) Lightweight - iSNSP is a simple and lightweight protocol suitable for implementation on embedded devices such as switches and targets. There are no unused or "wasted" features that may bog down the performance of the host device. 3.5 iSNS Server Discovery 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 MAY be used by iSNS clients to discover the IP address 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 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 iSNS can be found in the document draft-bakke-iscsi-slp-00.txt. If SLP is not used, then the IP address of the iSNS server can be stored in a DHCP server to be downloaded using a DHCP option, such as any of the reserved site-specific option codes (from 128 to 255). Another approach is to configure each iSNS client to listen to the iSNS Name Service Heartbeat message (see section 7.6.5.14). A final approach would be to manually configure the IP address of the iSNS server in each iSNS client. 3.6 iSNS and NAT The existence of NAT will have an impact upon information retrieved from the iSNS. 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, an iSNS client initiator SHALL query for the DNS Fully Qualified Domain Name (i.e., Entity Identifier) 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 Gibbons, Tseng, Monia Standards Track 11 iSNS June 2001 decentralized, local iSNS servers are handled using LDAP and using appropriate NAT translation rules implemented within the update mechanism in each server. A final approach is to simply disallow use of NAT in between communication between the iSNS server and any iSNS client. 3.7 Interactions Between iSNS Infrastructures Each individual iSNS deployment is designed to be operated in networks under the control of a single administrative authority. This administrative authority facilitates a seamless, integrated policy for iSNS usage, including security, naming and registration of storage assets, and management of Discovery Domains. Through leverage of an Internet-based database framework such as LDAP, the iSNS not only scales to large storage networks, but also to support interactions among multiple independently managed storage infrastructures, each managed by its own administrative authority. The information registered in the iSNS can be shared with other iSNS servers managed by other administrative authorities through out-of- band, non-iSNS protocols. By importing registration information from a remote iSNS server, storage connectivity can be established to devices managed by that server. The following examples illustrate possible methods to transfer iSNS records of devices between autonomous, independently-administered iSNS servers. In the first example, a back-end LDAP information base is used to support the iSNS server. The following diagram illustrates use of the LDAP protocol to import iSNS registration information from one iSNS server to another. Once the record transfer of the remote device is completed, it becomes visible and accessible to local devices on the local iSNS server. This allows local devices to establish sessions with remote devices (provided firewall boundaries can be negotiated). Gibbons, Tseng, Monia Standards Track 12 iSNS June 2001 +-------------------------+ +-------------------------+ |+------+ iSNSP | | iSNSP +-----+ | ||dev A |<----->+------+ | | +------+<----->|dev C| | |+------+ | | | | | | +-----+ | |+------+ iSNSP |local | | | |remote| iSNSP +-----+ | ||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| | |+------+ | | | | | | +-----+ | |........ +--+---+ | 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 in Network A, local devices A and B can now discover and connect to "dev C". +-------------------------+ +-------------------------+ |+------+ iSNSP | | iSNSP +-----+ | ||dev A |<----->+------+ | | +------+<----->|dev C| | |+------+ | | | | | | +-----+ | |+------+ iSNSP |local | | | |remote| iSNSP +-----+ | ||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| | |+------+ | | | | | | +-----+ | |........ +------+ | 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. In this case, the iSNS servers are not using LDAP to store records. 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. Once the record is transfered to the local iSNS in Network A, "dev C" becomes visible and accessible Gibbons, Tseng, Monia Standards Track 13 iSNS June 2001 (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 independently-administered iSNS servers. Further discussion and explanation of these methodologies is beyond the scope of this document. 3.8 Deployment Architecture Diagram The following diagram displays examples of where and how iSNS can be deployed, and of the various IP-based storage entities that it can support. +------------+ +-----------+ +-----------+ | | LDAP | Directory | LDAP | iSNS | | DNS Server |<-------->| Database |<-------->| Server | | | | | | | +------+-----+ +-----+-----+ +-----+-----+ | | | | DNS | LDAP iSNSP | |Queries | | +------+----------------------+----------------------+---------+ | | | IP Network | | | +----+-----------+----------+---------------+------------------+ | | | | | | +-----+-----+ +------+-----+ | | |iSCSI-/ | |iFCP / | | | | FC /iSNS | |Switch/iSNS | | | |Gtwy/Server| | /Server| | | +----+------+ +-+-------+--+ | | | | | +----+----+ +----+---+ +---+----+ +----+-+ +---+----+ | iSCSI | | iSCSI | | Fibre | | FC | | Fibre | |Initiator| | Target | |Channel | |Device| |Channel | +---------+ +--------+ |Network | +------+ |Network | +--------+ +--------+ 4. iSNS Object Model iSNS provides the framework for the registration and discovery of iSCSI devices and Fibre Channel-based devices (using iFCP). This architecture defines common objects that can be used to represent components referenced by each of these protocols. 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 SAN, NETWORK ENTITY, PORTAL, STORAGE NODE, STORAGE DEVICE DISCOVERY DOMAIN, and DISCOVERY DOMAIN SET. Each of these objects are described in greater detail in the following sections. Gibbons, Tseng, Monia Standards Track 14 iSNS June 2001 4.1 NETWORK ENTITY Object The NETWORK ENTITY object is a container of STORAGE NODE objects and PORTAL objects. It represents a device or gateway that is accessible from the IP network. All STORAGE NODEs and PORTALs contained in a NETWORK ENTITY object operate in a coordinated manner. 4.2 PORTAL Object The PORTAL object is an IP interface through which access to any STORAGE NODE within the NETWORK ENTITY can be obtained. A NETWORK ENTITY must 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 connection 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. 4.4 FC DEVICE Object (iFCP Only) The FC DEVICE represents the Fibre Channel end node. Although mostly unused in support of the iFCP storage connection, 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 partition storage resources. 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. When queried, the iSNS server will provide information only for storage entities that share at least one common DD. Initiators will not be able to "see" devices with which they do not have at least one common DD. 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. 4.7 iSNS Database Model The following shows the the various objects described above and their relationship to each other. Gibbons, Tseng, Monia Standards Track 15 iSNS June 2001 +--------------+ +-----------+ | NETWORK |1 *| | | ENTITY |----| PORTAL | | | | | +--------------+ +-----------+ | 1 | | | * +-----------+ +--------------+ +-----------+ +-----------+ | FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY | | DEVICE |----| NODE |----| DOMAIN |----| DOMAIN | |(iFCP Only)| | | | | | SET | +-----------+ +--------------+ +-----------+ +-----------+ * represents 0 to many possible relationships 5. iSNS Implementation Requirements iSNS can be implemented with features to support iSCSI and/or iFCP. Implementation of support for either or both of these protocols is OPTIONAL. IF iSNS is implemented to support a particular protocol, then a minimum set of attributes and iSNSP commands is REQUIRED for support of that protocol. This section details specific requirements for support of each of these IP storage protocols. 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, for scaling a storage network to a larger number of iSCSI devices, use of iSNS is RECOMMENDED. 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. Gibbons, Tseng, Monia Standards Track 16 iSNS June 2001 REQUIRED REQUIRED Object Attribute to Implement to Use ------ --------- ------------ -------- NETWORK ENTITY Entity Identifier * * Entity Protocol * * Management IP Address Timestamp * Protocol Version Range * Entity Certificate * PORTAL IP Address * * TCP/UDP Port * * Portal Symbolic Name * ESI Interval * ESI Port * Portal Group * Portal Certificate * STORAGE NODE iSCSI Name * * Node Type * * Alias/Symbolic Node Name * SCN Event Bitmap * Node Certificate * DISCOVERY DOMAIN DD_ID * * DD_Symbolic Name * DISCOVERY DOMAIN DDS Identifier * SET DDS Symbolic Name * Status * All iSCSI user-specified and vendor-specified attributes are optional to implement and use. 5.1.2 Attribute Descriptions for iSCSI Storage Systems The iSNS attributes used to represent iSCSI Storage Systems are shown and described in the following diagram: Gibbons, Tseng, Monia Standards Track 17 iSNS June 2001 - iSCSI NETWORK ENTITY | - Entity Identifier | By convention this is the DNS name of the | Portal IP-Address(es). If it is not registered | the iSNS will assign a unique alphanumeric | identifier to it. - Entity Protocol | Indicates this is an iSCSI registration - Mgt IP-Address | If it is not registered then in-band management | is assumed. - Timestamp | Timestamp of last registration update - Protocol Version Range | Indicates the iSCSI versions supported - Entity Certificate | X.509 certificate bound to the Entity (FQDN) - PORTAL (1 - n per ENTITY) | | | - IP-Address | - TCP/UDP Port | | The IP-Addr and Port together uniquely | | define a portal. | - Portal Symbolic Name | - Entity Status Inquiry Interval | | If 0, no ESI is used to this Portal | - Entity Status Inquiry Port | | The port used to receive ESIs | - Portal Group | | The aggregation group this portal is a member of | - Portal Certificate | - STORAGE NODE (1 - m per ENTITY) | - iSCSI Name - Node Type (initiator / target / ...) - Alias/Symbolic Node Name - SCN Event Bitmap | Indicates current SCN state - Node Certificate 5.1.3 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. In this implementation, each target and initiator is attached to a single PORTAL. Since the devices shown are iSCSI, the FC DEVICE object does not apply. All required attributes are also shown in this diagram: Gibbons, Tseng, Monia Standards Track 18 iSNS June 2001 +----------------------------------------------------------------+ | 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 which can be accessed through alternate PORTAL interfaces, if any original interface should fail. The following diagram describes such a device: Gibbons, Tseng, Monia Standards Track 19 iSNS June 2001 +---------------------------------------------------------------+ | 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.4 Required Commands and Response Messages for Support of iSCSI The following are 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. Gibbons, Tseng, Monia Standards Track 20 iSNS June 2001 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 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. iSNS is integral to the operation of iFCP, in order to allow iFCP gateways to execute Fibre Channel S_ID and D_ID address mappings to remote gateways. 5.2.1 Required Attributes for Support of iFCP Gibbons, Tseng, Monia Standards Track 21 iSNS June 2001 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. REQUIRED REQUIRED Object Attribute to Implement to Use ------ --------- ------------ -------- NETWORK ENTITY Entity Identifier * * Entity Protocol * * Management IP Address Timestamp * Protocol Version Range * Entity Certificate * PORTAL IP Address * * TCP/UDP Port * * Portal Symbolic Name * ESI Interval * ESI Port * Portal Group * Portal Certificate * STORAGE NODE Port Name (WWPN) * * Port_ID * * Port Type * * Port Symbolic Name * FC Fabric Port Name (FWWN) * FC Hard Address * FC Port IP Address * FC Class of Service * FC FC-4 Types * FC FC-4 Descriptors * FC FC-4 Features * SCN Event Bitmap * Node Certificate * FC DEVICE Port Name (WWPN) * * Node Type * * Alias/Node Symbolic Name * FC Node IP Address * FC Node IPA * DISCOVERY DOMAIN DD_ID * * DD_Symbolic Name * DISCOVERY DOMAIN DDS Identifier * SET DDS Symbolic Name * Status * 5.2.2 Attribute Descriptions for iFCP Gateways and FC devices Gibbons, Tseng, Monia Standards Track 22 iSNS June 2001 The iSNS attributes used to support iFCP gateways are shown and described in the following figure: - iSNS Server-Specific - Preferred_ID - Assigned_ID - Space_Identifier - iFCP NETWORK ENTITY | - Entity Identifier | By convention this is the DNS name of the | Portal IP-Address(es). If it is not registered | the iSNS will assign a unique alphanumeric | identifier to it. - Entity Protocol | Indicates this is an iFCP registration - Management IP-Address | If it is not registered then in-band management | is assumed. - Timestamp | Last registration update. Maintained by the iSNS. - Protocol Version Range | Indicates the iFCP versions supported - Entity Certificate | X.509 certificate bound to the Entity (FQDN) | - PORTAL (1 - n per ENTITY) | | | - IP-Address | - TCP/UDP Port | | The IP-Address and Port combined uniquely | | define a portal. | - Portal Symbolic Name | - Entity Status Inquiry Interval | | 0 if no status inquiry is used | - Entity Status Inquiry Port | | The port used to receive ESIs | - Portal Group | | The aggregation group this portal is a member of | - Portal Certificate | - STORAGE NODE (1 - k per ENTITY) | - Port Name (WWPN) - Port ID - Port Type - Port Symbolic Name - FC Fabric Port Name (FWWN) - FC Hard Address - FC Port IP Address - FC Class of Service - FC FC-4 Types - FC FC-4 Descriptors Gibbons, Tseng, Monia Standards Track 23 iSNS June 2001 - FC FC-4 Features - SCN Bitmap - Node Certificate - FC DEVICE (1 - m per ENTITY) | - Node Name (WWNN) - Node Symbolic Name - FC Node IP-Address - FC Node IPA - FC Device Certificate 5.2.3 iFCP Attribute Requirements 5.2.3.1 Port_ID Port_ID assignments for each STORAGE NODE object within a single NETWORK ENTITY SHALL be unique. For each NETWORK ENTITY (i.e., iFCP gateway), no more than one STORAGE NODE can be assigned a given PORT_ID value. 5.2.4 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 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. Gibbons, Tseng, Monia Standards Track 24 iSNS June 2001 +--------------------------------------------------------+ | 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.5 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. Gibbons, Tseng, Monia Standards Track 25 iSNS June 2001 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: 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 Attribute Descriptions for Discovery Domain Registration Gibbons, Tseng, Monia Standards Track 26 iSNS June 2001 Discovery Domains are logical groupings of initiators and targets that are used to limit the login process to the appropriate subset of devices registered in the iSNS. Support for Discovery Domains is required for all protocols. The iSNS attributes for Discovery Domain, and Discovery Domain Set, registration are shown in the following figure: DISCOVERY DOMAIN SET | - DD Set_ID - DD Set_Symbolic Name - DD Set Enabled/Disabled DD SET_MEMBER | - DD Set_ID - DD_ID DISCOVERY DOMAIN | - DD_ID - DD_Symbolic Name DD_MEMBER | - DD_ID - Entity Identifier, iSCSI Name, or WWPN Members of a Discovery Domain can be defined by registering one of the following storage entity attributes in a Discovery Domain: - iSCSI Name : this places the individual iSCSI storage node in the Discovery Domain - WWPN : this places the iFCP Storage Node in the Discovery Domain 5.4 Use of TCP For iSNS Communication TCP can be used for all iSNS communication. The iSNS server SHALL accept TCP connections for client registrations. The TCP port used by the iSNS server to receive TCP messages used SHALL be <<TBD>>. The client can also use multiple streams to register attributes and communicate with the server. To register for ESI monitoring using TCP, the client SHALL register the Portal ESI Interval using the TCP connection that will be used to receive ESI inquiry messages. To register for SCN notifications using TCP, the client SHALL register the iSCSI/iFCP SCN Bitmap using the TCP connection that SHALL be used to receive SCN notification messages. Gibbons, Tseng, Monia Standards Track 27 iSNS June 2001 This allows the client to be flexible about how many and which connections will be used for each feature. Using the above method, a client can optionally open one stream and use it for SCN, ESI, and iSNS queries. A client may also open up 3 sessions: one for ESI, one for SCN, and another for iSNS queries. If a TCP connection supporting ESI or SCN messages goes down, and the client creates a new connection for the ESI or SCN messages, then the client must reregister for ESI's and/or SCN's on the new connection. 5.5 Use of UDP For iSNS Communication The iSNS server MAY accept UDP messages for client registrations. The iSNS server SHALL accept registrations from clients requesting UDP-based ESI and SCN messages. The UDP port used to receive messages SHALL be <<TBD>>. To register for UDP-based ESI monitoring messages, the client SHALL register the Portal ESI/SCN UDP Port to be used for communication of ESI messages from the server to the client. To register for UDP-based SCN notifications messages, the client SHALL register at least one Portal ESI/SCN UDP port to be used for communication of SCN messages from the server to the client. If an entity has multiple Portals with registered ESI/SCN UDP Ports, then ESI and SCN messages SHALL be delivered to each Portal registered to receive such messages. 6. iSNS Message Attributes When an iSNS client registers with the iSNS server, it provides attribute values to describe the entity characteristics and capabilities. The iSNS server also returns the attributes in response to queries. 6.1 iSNS Attribute Summary The following table lists all iSNSP message attributes for device registration and queries: T Entity Attributes Length Tag Reg Key Query Key - ----------------------- ------ --- ------- ----------- Delimiter 0-256 0 N/A N/A ^ Entity Identifier (EID) 0-256 1 1|@ @|1|2|16,17|32|64 & Entity Protocol 4 2 1 @|1|2|16,17|32|64 Mgt IP Address 16 3 1 @|1|2|16,17|32|64 = Timestamp 8 4 1 @|1|2|16,17|32|64 Protocol Version Range 4 5 1 @|1|2|16,17|32|64 Registration Period 4 6 1 @|1|2|16,17|32|64 Gibbons, Tseng, Monia Standards Track 28 iSNS June 2001 * Entity Certificate var 15 1 @|1|2|16,17|32|64 # Portal IP-Address 16 16 1 @|1|16,17|32|64 $ Portal TCP/UDP Port 4 17 1 @|1|16,17|32|64 Portal Symbolic Name 0-256 18 16,17 @|1|16,17|32|64 ESI Interval 4 19 16,17 @|1|16,17|32|64 ESI/SCN UDP Port 4 20 16,17 @|1|16,17|32|64 Portal Group 4 21 16,17 @|1|16,17|32|64 * Portal Certificate var 31 16,17 @|1|16,17|32|64 # iSCSI Name 4-256 32 1% @|1|16,17|32|33 & iSCSI Node Type 4 33 32 @|1|16,17|32 Alias 0-256 34 32 @|1|16,17|32 iSCSI SCN Bitmap 4 35 32 @|1|16,17|32 * iSCSI Node Certificate var 40 32 @|1|16,17|32 # iFCP Node WWPN 8 64 1% @|1|16,17|64|66|96|128 Port_ID 4 65 64 @|1|16,17|64 Port_Type 4 66 64 @|1|16,17|64 Port_Symbolic Name 0-256 67 64 @|1|16,17|64 FC Fabric Port Name 8 68 64 @|1|16,17|64 FC Hard Address 4 69 64 @|1|16,17|64 FC Port IP-Address 16 70 64 @|1|16,17|64 FC Class of Service 4 71 64 @|1|16,17|64 FC FC-4 Types 32 72 64 @|1|16,17|64 FC FC-4 Descriptor 0-256 73 64 @|1|16,17|64 FC FC-4 Features 128 74 64 @|1|16,17|64 iFCP Node SCN bitmap 4 75 32 @|1|16,17|64 * iFCP Node Certificate var 80 64 @|1|16,17|64 iFCP Node Type 4 81 64 @|1|16,17|64 FC-4 Type Code 4 95 Query Key only # FC Device WWNN 8 96 @ @|64|96 FC Device Sym Node Name 0-256 97 96 @|64|96 FC Device IP-Address 16 98 96 @|64|96 FC Device IPA 8 99 96 @|64|96 * FC Device Certificate var 100 96 @|64|96 Preferred ID 4 128 Switch ID msgs only Assigned ID 4 129 Switch ID msgs only Space_Identifier 0-256 130 Switch ID msgs only RESERVED for iSNS server-specific tags in range 131-255 Company OUI 4 256 * Vendor-Spec iSNS Srvr var - tags in range 257-383 * Vendor-Spec Entity var - tags in range 384-511 * Vendor-Spec Portal var - tags in range 512-639 * Vendor-Spec iSCSI Node var - tags in range 640-767 * Vendor-Spec iFCP Node var - tags in range 768-895 * Vendor-Spec iFCP FC Node var - tags in range 896-1023 * Vendor-Specific DD var - tags in range 1024-1279 * Other Vendor-Specific var - tags in the range 1280-2047 RESERVED 2048-65535 The following is a description of the columns used in the above table: Attribute Type (T) -------------------------------------------------------------- # : Required key for object registration. Gibbons, Tseng, Monia Standards Track 29 iSNS June 2001 ^ : Required key for object registration, unique value is assigned by the iSNS if value not provided during initial registration. $ : Required as part of the key, and the canonical value is used if one is not registered. & : Attribute required during initial registration that is not a key. * : Optional to implement in the iSNS. = : Cannot be used as a query key or be explicitly registered. The value is assigned by the iSNS at registration / update. @ : if no key is present then a new entry is created, or all entries of the operating attributes are returned. | : used to separate the different sets of possible keys in the table. % : If an iSCSI Name or iFCP Node WWPN is registered without an EID key, then an Entity will be created and an EID assigned. The assigned EID will be returned in the response as an Operating attribute. Length - indicates the attribute length. Variable-length identifiers are NULL character terminated, which is included in the length. Tag - the integer tag value used to identify the attribute. All undefined tag values are reserved. Value û a description of the data. Implementation Notes: -------------------------------------------------------------- A well-formed registration contains the key of the object to register, or no key if it can be generated by the iSNS. If an attribute is present as a key, then it cannot be an operating attribute. The registration response will contain the key for each object registered, including any key values that were assigned by the iSNS as part of the registration. For example, if an entity, two portals, and one iFCP node was registered, then the response message key attributes section would contain the keys for each. The key attributes, returned in the response, may be in a different order they appeared in the registration. iSNS client attributes are defined below. 6.2 Entity Identifier-Keyed Attributes The following attributes are registered in the iSNS using the Entity Identifier attribute as the key. 6.2.1 Entity Identifier (EID) The Entity Identifier is a variable length identifier that uniquely identifies each network entity registered in the iSNS. The Gibbons, Tseng, Monia Standards Track 30 iSNS June 2001 attribute length varies from 4 to 256 bytes, and is a unique value within the iSNS. If the iSNS client does not provide an EID during registration the iSNS shall generate one that is unique within the iSNS. If an EID is to be generated, then the EID attribute value in the registration message shall be empty (0 length). The generated EID shall be returned in the registration response. By convention, iSNS generated EIDs begin with the string ôiSNS:ö. If an EID is registered by a client beginning with the string ôiSNS:ö, then the iSNS server SHALL not assign the value to another entity. 6.2.2 Entity Protocol Entity Protocol is a required 4-byte attribute that indicates the protocol of network entity that is being registered and is provided by the iSNS client. The valid types are defined as below: Type Value Entity Type ---------_ ----------- 1 iSCSI 2 iFCP All Others RESERVED 6.2.3 Management IP Address This optional field is provided by the iSNS client. It contains the IP Address used to manage the entity. The Management IP Address is a 16-byte field that may contain either a 32-bit IPv4 or 128-bit IPv6 address. When this field contains an IPv4 value, the most significant 12 bytes are set to 0x00. If the network entity is capable of being managed and this field is not set, then in-band management is assumed. 6.2.4 Entity Registration Timestamp This field is updated by the iSNS. It cannot be used as a query key or be explicitly registered. It indicates the time the entity registration occurred, an associated object was updated, or the time of the most recent response to an Entity Status Inquiry message, whichever is later. The time format is, in seconds, the update period since the standard base time of 00:00:00 GMT on January 1, 1970. 6.2.5 Protocol Version Range This optional field is provided by the iSNS client. This field contains the minimum and maximum version of the protocol supported by the entity. The most significant two bytes contain the maximum version supported, and the least significant two bytes contain the minimum version supported. If a range is not registered then the entity is assumed to support all versions of the protocol. Gibbons, Tseng, Monia Standards Track 31 iSNS June 2001 6.2.6 Registration Period This required field, provided by the iSNS client, indicates the maximum period, in seconds, that the entity registration will be maintained by the server without an update or ESI response from the client. If the Registration Period is set to 0, then the Entity SHALL NOT be deregistered as a result of no update messages from the client. To refresh the registration, the iSNS client may perform a re- registration with the update flag set, which updates any field of the registration. Byte 0 and 1 represents the entity registration period, in seconds. Byte 2 and 3 are reserved. If ESI support is requested as part of a portal registration, the ESI Response message received by the server SHALL act as an alternative to an update of the entity registration. If ESI messages are not requested by an entity and the Registration Period is not set to 0, then the entity registration SHALL be removed if the client does not update the registration before the registration period has expired. 6.2.7 Entity Certificate This attribute contains an X.509 certificate that is bound to the NETWORK ENTITY of the iSNS client. This certificate is uploaded and registered to the iSNS by clients wishing to allow other clients to authenticate themselves and access the services offered by that NETWORK ENTITY. This certificate MAY also be used to set up the TLS association between the iSNS client and server, as well as to key the authentication block in the iSNSP. The maximum size of this variable length field is implementation dependent. 6.3 Portal-Keyed Attributes The following portal attributes are registered in the iSNS using the combined Portal IP-Address and Portal TCP/UDP Port as the key. Each portal is associated with one Entity Identifier object key. 6.3.1 Portal IP-Address The IP address of the PORTAL through which a STORAGE NODE can transmit and receive storage data. This required field is provided by the iSNS client. When an IPv4 value is contained in this field, the most significant 12 bytes are set to 0x00. The Portal IP Address along with the Portal TCP/UDP Port number uniquely identifies a Portal. 6.3.2 Portal TCP/UDP Port Gibbons, Tseng, Monia Standards Track 32 iSNS June 2001 The TCP/UDP port of the PORTAL through which a STORAGE NODE can transmit and receive storage data. This required 4 byte field is provided by the iSNS client. Bit 0 to 15 represents the TCP/UDP port number. Bit 16 represents the port type. If bit 16 is set the port type is UDP. Otherwise it is TCP. Bits 17 to 31 are reserved. If the field value is 0, then the port number is the implied canonical port number and type of the protocol indicated by the associated Entity Protocol. The Portal IP-Address along with the Portal TCP/UDP Port number uniquely identifies a Portal. 6.3.3 Portal Symbolic Name This is an optional, variable-length text-based value from 0 to 256 bytes. The text field contains user-readable UTF-8 text, and is terminated with at least one NULL character. The Portal Symbolic Name is a user-readable description of the Portal entry in the iSNS. 6.3.4 Entity Status Inquiry Interval This optional field is provided by the iSNS client. It indicates the minimum time, in seconds, between Entity Status Inquiry (ESI) messages sent from the iSNS to this entity portal. ESI messages can be used to verify that a Portal registration continues to be valid. To request monitoring by the iSNS, an iSNS client registers a non- zero value for this portal attribute using a RegDevAttr message. If the iSNS does not receive an ESI response message from a Portal after having sent no more than three ESI messages, then the Portal SHALL be deregistered. If all Portals associated with an entity that have registered for ESI messages are deregistered due to non-response, then the entity SHALL be deregistered. If the iSNS is unable to support ESI messages, it SHALL reject the ESI request by returning an "ESI Not Available" error code. The rejection might occur in situations where the resulting frequency of ESI messages being issued to clients would pass an implementation- specific threshold. 6.3.5 ESI/SCN UDP Port This optional field is provided by the iSNS client. If the client requires UDP based ESI monitoring or SCN notification, it SHALL register the UDP port to be used for communication from the server to a client Portal. Bit 0 to 15 represents the UDP port number. Bits 16 to 31 are reserved. If an entity node registers for SCN notifications with a UDP message, at least one entity portal shall have a registered ESI/SCN UDP port number. The iSNS server will return an error for an SCN Gibbons, Tseng, Monia Standards Track 33 iSNS June 2001 registration if no ESI/SCN port has been registered. If multiple Portals have a registered ESI/SCN UDP port, then SCN data MAY be delivered to any of the available registered portals. 6.3.6 Portal Group This optional field is provided by the iSNS client. The Portal Group is used to group portals into aggregation groups. All entity portals that belong to the same Portal Group can provide connections to the same STORAGE NODE. This allows multiple sessions to be established to a node through multiple portals. The least significant two bytes contain the Portal Group for the Portal. The most significant two bytes are reserved. 6.3.7 Portal Certificate This attribute contains an X.509 certificate that is bound to the PORTAL of the iSNS client. This certificate is used to identify and authenticate communications to the IP address supported by the Portal. This certificate MAY be used to set up the authenticating SA supporting the authentication block for iSNSP messages originated from the Portal IP Address. 6.4 iSCSI Node-Keyed Attributes The following attributes are registered in the iSNS using the iSCSI Name attribute as the key. Each set of Node-Keyed attributes is associated with one Entity Identifier object key. Although the iSCSI Name key is associated with one Entity Identifier, it is unique across the entire iSNS. 6.4.1 iSCSI Name This identifier uniquely defines an iSCSI STORAGE NODE, and is a variable-length text-based value from 0 to 256 bytes. This field is required for iSCSI STORAGE NODEs, and is provided by the iSNS client. If an iSCSI Name is registered without an EID key, then an Entity will be created and an EID assigned. The assigned EID will be returned in the registration response as an operating attribute. 6.4.2 iSCSI Node Type This required 32-bit field is a bitmap indicating the type of iSCSI STORAGE NODE. The bit fields are defined below. An enabled bit indicates the node has the corresponding characteristics. Gibbons, Tseng, Monia Standards Track 34 iSNS June 2001 Bit Field Node Type --------- --------- 0 (Lsb) Target 1 Initiator 2 Control All Others RESERVED If the 'Target' bit is set, then the node represents an iSCSI target. If the 'Initiator' bit is set, then the node represents an iSCSI initiator. If the control bit is set, then the node represents a gateway, management station, or other device which is not an initiator or target that requires the ability to send and receive iSNSP messages, including state change notifications. 6.4.3 iSCSI Node Alias This is an optional, variable-length text-based value from 0 to 256 bytes. The text field contains user-readable UTF-8 text, and is terminated with at least one NULL character. The Alias is a user- readable description of the node entry in the iSNS. 6.4.4 iSCSI Node SCN Bitmap This optional field is provided by the iSNS client. It indicates the events that the iSCSI Node is interested in. These events can cause a State Change Notification (SCN) to be generated. Bit Field Flag Description --------- ---------------- 0 CHANGE IN DD MEMBERSHIP 1 CHANGE IN NETWORK 2 CHANGE IN CLIENT REGISTRATION PARAMETERS 3 CLIENT ADDED 4 CLIENT REMOVED All others reserved. 6.4.5 iSCSI Node Certificate This optional attribute contains an X.509 certificate that is bound to the iSCSI STORAGE NODE of the iSNS client. For example, this X.509 certificate may have the Node Identifier of the target device. This certificate is uploaded and registered to the iSNS by clients wishing to allow other clients to authenticate themselves and access the STORAGE NODE. This certificate SHOULD NOT be used to set up the authenticating SA supporting the iSNSP authentication block. 6.5 iFCP Node-Keyed Attributes The following attributes are registered in the iSNS using the iFCP Node World Wide Port Name (WWPN) attribute as the key. Each set of Gibbons, Tseng, Monia Standards Track 35 iSNS June 2001 iFCP Node-Keyed attributes is associated with one Entity Identifier object key. Although the iFCP Node WWPN is associated with one Entity Identifier, it is globally unique. 6.5.1 iFCP Node Port Name (WWPN) This 64-bit identifier uniquely defines the iFCP Node, and is the World Wide Port Name (WWPN) of the corresponding Fibre Channel device. This globally unique identifier is used during the device registration process, and uses a value conforming to IEEE Naming Assignment Authority (NAA) type 1, 2, 5, or 6. This format is found in ANSI/IEEE Std 802-1990 [802-1990]. 6.5.2 Port ID Along with the IP Address, this field uniquely identifies a native Fibre Channel device port in the network, and maps one-to-one to a specific Port Name (WWPN) entry. The Port ID is used for iFCP based storage devices. 6.5.3 Port Type Indicates the type of iFCP node port. This is provided by the iSNS client. Encoded values for this field are listed in the following table: Type Description ---- ----------- 0x0000 Unidentified/Null Entry 0x0001 Fibre Channel N_Port 0x0002 Fibre Channel NL_Port 0x0003 Fibre Channel F/NL_Port 0x0004-0080 RESERVED 0x0081 Fibre Channel F_Port 0x0082 Fibre Channel FL_Port 0x0083 RESERVED 0x0084 Fibre Channel E_Port 0x0085-00FF RESERVED 0xFF11 mFCP Port 0xFF12 iFCP Port 0xFF13-FFFF RESERVED 6.5.4 iFCP Node Port Symbolic Name A variable-length text-based description of up to 255 bytes, that is associated with the iSNS-registered iFCP Node in the network. The text field contains user-readable UTF-8 text and is terminated with at least one NULL character. This optional field is normally provided by the iSNS client during registration. However, network management application can update this field as required. Gibbons, Tseng, Monia Standards Track 36 iSNS June 2001 6.5.5 iFCP Node Fabric Port Name (FWWN) This 64-bit identifier uniquely defines the fabric port. If the iSNS client is attached to a Fibre Channel fabric port with a registered Port Name, then that fabric Port Name shall be indicated in this field. This field is included in the iSNSP for compatibility with Fibre Channel fabric devices and topologies. The Fabric Port may itself be registered as a port in the iSNS. In that case, the Fabric Port Name (FWWN) attribute of fabric attached ports will match the Port Name (WWPN) of the Fabric Port registration. 6.5.6 FC Hard Address This optional field is the requested hard address 24-bit NL Port Identifier, included in the iSNSP for compatibility with Fibre Channel Arbitrated Loop devices and topologies. 6.5.7 FC Port IP Address The Fibre Channel IP address associated with the iFCP Node. This optional field is included for compatibility with Fibre Channel. When an IPv4 value is contained in this field, the most significant 12 bytes are set to 0x00. This value is provided by the iSNS client. 6.5.8 FC Class of Service (COS) This 32-bit bit-map field indicates the Fibre Channel COS types that are supported by the registered port. This field is provided by a Fibre Channel-based iSNS client. The COS values are equivalent to Fibre Channel COS values. The valid COS types, and associated bit- map, are listed in the following table: Class of Service Description Bit-Map ---------------- ----------- --------- 2 Delivery Confirmation Provided bit 2 set 3 Delivery Confirmation Not Provided bit 3 set RESERVED other 6.5.9 FC FC-4 Types This 32-byte field indicates the FC-4 protocol types supported by the associated port. This field for iFCP Node is provided by the iSNS client. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4. 6.5.10 FC FC-4 Descriptor A variable-length text-based description of up to 256 bytes, that is associated with the iSNS-registered device port in the network. This optional field for iFCP ports is provided by the iSNS client. This field can be used to support Fibre Channel devices. This field Gibbons, Tseng, Monia Standards Track 37 iSNS June 2001 can be used to support Fibre Channel devices and is consistent with FC-GS-4. 6.5.11 FC FC-4 Features This is a 128-byte array, 4 bits per type, for the FC-4 protocol types supported by the associated port. This optional field for iFCP ports is provided by the iSNS client. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4. 6.5.12 iFCP Node SCN Bitmap This optional field is provided by the iSNS client. It indicates the events that the iFCP Node is interested in. These events can cause SCN to be generated. Bit Field Flag Description --------- ---------------- 0 CHANGE IN DD MEMBERSHIP 1 CHANGE IN NETWORK 2 CHANGE IN CLIENT REGISTRATION PARAMETERS 3 CLIENT ADDED 4 CLIENT REMOVED All others reserved. 6.5.13 iFCP Node Certificate This optional attribute contains an X.509 certificate that is bound to the iFCP STORAGE NODE of the iSNS client. For example, this X.509 certificate may have the Node Identifier of the target device. This certificate is uploaded and registered to the iSNS by clients wishing to allow other clients to authenticate themselves and access the STORAGE NODE. This certificate SHOULD NOT be used to set up the authenticating SA supporting the iSNSP authentication block. 6.5.14 iFCP Node Type This required 32-bit field is a bitmap indicating the type of iFCP STORAGE NODE. The bit fields are defined below. An enabled bit indicates the node has the corresponding characteristics. Bit Field Node Type --------- --------- 0 (Lsb) Target 1 Initiator 2 Control All Others RESERVED 6.6 iFCP FC Device Node-Keyed Attributes The following attributes are registered in the iSNS using the iFCP FC Node World Wide Node Name (WWNN) attribute as the key. Each set of iFCP FC Node-Keyed attributes represents a single device, and can be associated with many iFCP Node Ports. Gibbons, Tseng, Monia Standards Track 38 iSNS June 2001 The iFCP Node WWNN is unique across the entire iSNS. 6.6.1 iFCP FC Device Node Name (WWNN) Node Name is a 64-bit identifier that uniquely identifies the iFCP FC device node in the network, and is the World Wide Node Name (WWNN) of the corresponding Fibre Channel device. This globally unique identifier is used during the device registration process, and uses a value conforming to IEEE Naming Assignment Authority (NAA) type 1, 2, 5, or 6. This format is found in ANSI/IEEE Std 802-1990 [802-1990]. 6.6.2 iFCP FC Device Symbolic Name A variable-length text-based description of up to 256 bytes, that is associated with the iSNS-registered FC Device in the network. The text field contains user-readable UTF-8 text and is terminated with at least one NULL character. This optional field is normally provided by the iSNS client during registration. However, network management application can update this field as required. 6.6.3 FC Device IP Address This optional IP address is associated with the device node in the network. This field is included for compatibility with Fibre Channel. When an IPv4 value is contained in this field, the most significant 12 bytes are set to 0x00. This value is provided by the iSNS client. 6.6.4 FC Device IPA This optional 8 byte Fibre Channel Initial Process Associator (IPA) is associated with the device node in the network. This field is included for compatibility with Fibre Channel, and is provided by a Fibre Channel-based iSNS client entity. The initial process associator can be used for communication between Fibre Channel devices. 6.6.5 FC Device Certificate This optional attribute contains an X.509 certificate that is bound to the FC DEVICE of the iSNS client. 6.7 Other Attributes The following are not attributes of the previously-defined objects. 6.7.1 FC-4 Type Code This is a 4-byte field, and is used to provide a FC-4 type during a FC-4 Type query. The FC-4 types are consistent with the FC-4 Types as defined in FC-PH. Byte 0 contains the FC-4 type. All other bytes are reserved. Gibbons, Tseng, Monia Standards Track 39 iSNS June 2001 6.7.2 Preferred ID This is a 4-byte unsigned integer field, and is the requested value that the iSNS client wishes to use for the SWITCH_ID. The iSNS server SHALL grant the iSNS client the use of the requested value as the SWITCH_ID, if the requested value has not been already allocated. If the requested value is not available, the iSNS server SHALL return a different value that has not been allocated. 6.7.3 Assigned ID This is a 4-byte unsigned integer field that is used to support iFCP Transparent Mode. When operating in iFCP Transparent Mode, the RqstSwId message SHALL be used by each iFCP gateway to reserve its own unique SWITCH_ID value from the range 1 to 239. When a Switch ID is no longer required, it SHALL be released by the iFCP gateway using the RlseSwId message. The iSNS MAY use the Entity Status Inquiry message to determine if an iFCP gateway is still present on the network. 6.7.4 Space_Identifier This is a UTF-8 encoded string. The Space_Identifier string is used as a key attribute to identify a range of non-overlapping SWITCH_ID values to be allocated using RqstSwId. Each Space_Identifier string submitted by iSNS clients shall have its own range of non- overlapping SWITCH_ID values to be allocated to iSNS clients. 6.8 Discovery Domain Registration Attributes iSNS STORAGE NODE objects can be placed into Discovery Domains. Only objects that share the same enabled Discovery Domain can query for information about each other. Discovery Domains can overlap, so an iSCSI node may be a member of many DDÆs. Enabled Discovery Domains are members of one or more enabled Discovery Domain Sets (DDS). Discovery Domains that are not members of at least one enabled DDS are disabled. Therefore, Discovery Domains are not directly enabled, but rather are enabled through their association with one or more enabled Discovery Domain Sets (DDS). Discovery Domain Sets are enabled by setting bit 0 in the DDS Status field. 6.8.1 iSNS Discovery Domain Attribute Summary The following table lists the iSNSP DD attributes: Gibbons, Tseng, Monia Standards Track 40 iSNS June 2001 Attribute Name Size(bytes) ID Reg Key Query Key -------------- ----------- -- ------- --------- DD_Set ID 4 101 @ 1,32,64,101,104 DD_Set Sym Name 4-256 102 101 101 DD_Set Status 4 103 101 101 DD_ID 4 104 @|101* 1,32,64,101,104 DD_Symbolic Name 4-256 105 104 104 DD_iSCSI Node Member 0-256 107 104 104 DD_iFCP Member (WWPN) 8 108 104 104 @ = no key required during registration | = either key can be used during registration * = When a DD ID is placed into a DD Set by using the DDS ID as a key All undefined tag values are reserved. 6.8.2 DD Set ID Keyed Attributes 6.8.2.1 Discovery Domain Set ID (DDS ID) The DDS ID is a unique integer identifier used in the iSNS directory database to indicate a Discovery Domain Set. A DDS is a collection of Discovery Domains that can be enabled or disabled by a management station. This value is used as a key for DDS attribute queries. When a Discovery Domain is registered it is initially not in any DDS. If the iSNS client does not provide a DDS_ID in a DDS registration request message, the iSNS shall generate a DDS_ID value that is unique within the iSNS database for that new DDS. The created DDS ID shall be returned in the response message. The DDS ID value of 0 is reserved. 6.8.2.2 Discovery Domain Set Symbolic Name The DDS_Symbolic Name is a UTF-8, variable-length, NULL-terminated string. This is an user-readable field used to assist a network administrator in tracking the DDS function. When registered by a client, the DDS symbolic name SHALL be verified unique by the iSNS. If the DDS symbolic name is not unique, then the DDS registration SHALL be rejected with an ôInvalid Registrationö error code. The invalid attribute(s), in this case the DDS symbolic name, SHALL be included in the response. 6.8.2.3 Discovery Domain Set Status The DDS_Status field is a 32-bit bitmap indicating the status of the DDS. Bit 0 of the bitmap indicates whether the DDS is Enabled (1) or Disabled (0). The default value for the DDS Enabled flag is Disabled (0). Gibbons, Tseng, Monia Standards Track 41 iSNS June 2001 Bit Field DDS Status --------- --------- 0 (Lsb) DDS Enabled (1) / DDS Disabled (0) All Others RESERVED 6.8.2.4 Discovery Domain Set Member The Discovery Domain Set Member is a DD ID for a previously registered Discovery Domain. The DD ID tag value is used to represents membership. 6.8.3 DD ID Keyed Attributes 6.8.3.1 Discovery Domain ID (DD ID) The DD ID is a unique identifier used in the iSNS directory database to indicate the DD. This value is used as the key for any DD attribute query. If the iSNS client does not provide a DD_ID in a DD registration request message, the iSNS shall generate a DD_ID value that is unique within the iSNS database for that new DD (i.e., the iSNS client will be registered in a new DD). The created DD ID shall be returned in the response message. The DD ID value of 0 is reserved. 6.8.3.2 Discovery Domain Symbolic Name The DD_Symbolic Name is a UTF-8 encoded, variable-length, NULL- terminated string. When registered by a client, the DD symbolic name SHALL be verified unique by the iSNS. If the DD symbolic name is not unique, then the DD registration SHALL be rejected with an ôInvalid Registrationö error code. The invalid attribute(s), in this case the DD symbolic name, SHALL be included in the response. 6.8.3.3 Discovery Domain iSCSI Node Member The iSCSI Name of an iSNS client that is a member of the DD. The DD may have a list of 0 to n members. The iSCSI Name of the iSNS client represents membership. 6.8.2.4 Discovery Domain iFCP Node Member The iFCP Node Port Name of an iSNS client that is a member of the DD. The DD may have a list of 0 to n members. Membership is represented by the iFCP Node Port Name (WWPN) of the iSNS client being listed. 6.9 Vendor-Specific Attributes Specific iSNS implementations MAY define vendor-specific attributes for private use. The tag values reserved for vendor-specific and user-specific use are defined in section 6.1. To avoid misinterpreting proprietary attributes, it is RECOMMENDED that the vendor's own OUI (Organizationally Unique Identifier) be placed in the upper three bytes of the attribute field itself. If the OUI is Gibbons, Tseng, Monia Standards Track 42 iSNS June 2001 not used, then some other unique marker recognizable by the vendor SHOULD be used. The OUI is defined in IEEE Std 802-1990, and is the same constant used to generate 48 bit Universal LAN MAC addresses. A vendor's own iSNS implementation will then be able to recognize the OUI in the vendor-specific or user-specific attribute field, and be able to execute vendor-specific handling of the attribute. 6.10 Company OUI This attribute is the OUI (Organizationally Unique Identifier) identifying the specific vendor implementing the iSNS. It is used to identify the original creator of a vendor-specific iSNSP message. 7. 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 31 0 +---------------------+----------------------+ 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 (if present) | L Bytes +--------------------------------------------+ Total Length = 12 + N 7.1 iSNSP PDU Header The iSNSP header contains the iSNSP VERSION, FUNCTION ID, PDU LENGTH, FLAGS, TRANSACTIONID, and SEQUENCE ID fields as defined below. 7.1.1 iSNSP Version The iSNSP version is currently 0x0001. 7.1.2 iSNSP Function ID The FUNCTION ID defines the type of iSNS message and the function the message is supporting. 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 Gibbons, Tseng, Monia Standards Track 43 iSNS June 2001 comprising an iSNSP message must have the same FUNCTION_ID and TRANSACTION ID value. 7.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. 7.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: --------- ------------- 0-9 RESERVED 10 First PDU of the iSNS message 11 Last PDU of the iSNS message 12 Update Flag (used only for registrations) 13 Authentication Block Present 14 Sender is the iSNS server 15 Sender is the iSNS client 7.1.5 iSNSP Transaction ID The TRANSACTION ID is set to a unique random value for each 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. 7.1.6 iSNSP Sequence ID The SEQUENCE ID is set to 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 same SEQUENCE_ID value MUST be used for all PDU's in the message. 7.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 10 (First PDU) and bit 11 in the FLAGS field (Last PDU) SHALL both be enabled. If multiple PDUs are used to carry the iSNS message, then bit 10 SHALL be enabled in the first PDU of the message, and bit 11 SHALL be enabled in the last PDU. 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. Gibbons, Tseng, Monia Standards Track 44 iSNS June 2001 The authentication operation described in section 7.5 SHALL be performed on a per-PDU basis. 7.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 31 0 +--------------------------------------------+ 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 6.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. Each iSNSP request message contains several attributes in the above format to identify the requesting iSNS client and register or query for attribute values in the iSNS server. 7.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. 7.4 iSNSP Response Error Codes All iSNSP response messages contain a 4-byte ERROR 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, the field SHALL contain 0x00000000 (NO ERROR). Gibbons, Tseng, Monia Standards Track 45 iSNS June 2001 Error Code Error Description ---------- ----------------- 0 No Error 1 Unknown Error 2 Message Format Error 3 Invalid Registration 4 Requested ESI Period Too Short 5 Invalid Query 6 Authentication Unknown 7 Authentication Absent 8 Authentication Failed 9 No Such Entry 10 Version Not Supported 11 Internal Bus Error 12 Busy Now 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 All undefined Error Code values are RESERVED. 7.5 Message Authentication iSNSP provides an optional PDU authentication capability. Network interactions using iSNSP occur in short transactions, and are generally not session based. The iSNS client connects to the iSNS server only when information needs to be registered or queried. The authentication mechanism described here is compatible with that used in Service Location Protocol version 2 [RFC2608]. Public Key Encryption MAY be used for message authentication. If a public key infrastructure is not available, a shared secret algorithm MAY alternatively be used. A shared secret mechanism may leverage a Kerberos server, or may involve manual distribution of a private key to the iSNS server and each iSNS client. If a PKI is available with an X.509 certificate authority, then public key authentication of clients is possible. The authentication block leverages the DSA with SHA-1 algorithm, which can easily integrate into a public key infrastructure. The SNSP optional authentication block is a digital signature for the iSNSP PDU. 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 Gibbons, Tseng, Monia Standards Track 46 iSNS June 2001 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: Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 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. 7.6 Registration and Query Messages Gibbons, Tseng, Monia Standards Track 47 iSNS June 2001 The iSNSP registration and query message payloads contain a list of attributes, and have the following format: MSb LSb 31 0 +----------------------------------------+ | Source Attribute (Query Only) | +----------------------------------------+ | Key Attribute[1] (if present) | +----------------------------------------+ | Key Attribute[2] (if present) | +----------------------------------------+ | 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. 7.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. Gibbons, Tseng, Monia Standards Track 48 iSNS June 2001 Valid Source Attributes ----------------------- iSCSI Name (iSCSI only) iFCP Node Port WWN (iFCP only) Delimiter Field (If Administratively Allowed) For a query operation, the source attribute is used to bind the scope into the Discovery Domains of which the source is a member. The iSNS may validate that the Source Attribute matches client certificate information. If the iSNS is validating Source Attribute information, and the Source Attribute does not match the client certificate, then the request will be rejected with an authentication error code. The Source Field MAY administratively be allowed to contain the Delimiter Field (Tag of 0, Length of 0). If the Source Attribute is the Delimiter Field, then the operation SHALL be performed on all objects in the iSNS database without scoping to a Discovery Domain. 7.6.2 Key Attributes Key attributes are used to identify the object (or objects) in the iSNS server that the registration or query operation will be performed on. The number of Key Attributes depends on the specific iSNSP request or query operation being performed. 7.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. 7.6.4 Operating Attributes The Operating Attributes are a list of one or more attributes related to the actual iSNS registration or query operation being performed. In a registration, operating attributes represent values to be registered by the iSNS client performing the registration. In a query, operating attributes represent values being requested by the iSNS client. The number of possible Operating Attributes depends on the specific iSNSP request or query. For example, the Operating Attributes in a Device Attribute Query message are the set of attributes to be returned in the associated Device Attribute Query Response message that match the Key Attributes of the query. Some iSNSP messages do not require any Operating Attributes. 7.6.4.1 Operating Attributes for Query and Get Next Requests Gibbons, Tseng, Monia Standards Track 49 iSNS June 2001 In Query and Get Next request messages, TLV attributes with length value of 0 are used to indicate what operating attributes are to be returned in the corresponding response. Operating Attribute values which match the TLV attributes in the original message are returned in the response message. 7.6.5 Registration and Query Message Types The following describes each query and message type. 7.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 network entities. The iSNS client formulates a RegDevAttr by specifying Key Attribute(s) and list of Operating Attributes to register. All values are in Tag Length Value (TLV) format. Attributes following the Delimiter Attribute are Operating Attributes. Depending on the setting of the Update bit in the FLAGS field, the Operating attribute values in the RegDevAttr message will either replace existing attributes(s), or be added to existing attributes(s). See section 7.6.5.1.1 below for a complete description of the Update Flag. The operating attributes are the elements that will be registered. Multiple attributes can be registered in one RegDevAttr. The ordering of the operating attributes indicates the associations to be created in the iSNS. For example, Portal attributes following Entity attributes SHALL create a link between the registered entity and portal. Similarly, node attributes following entity attributes will create an association. A RegDevAttr message with no key attribute results in creation of a new entity (EID) (in addition, the update flag MUST NOT be set). If the EID attribute (with non-zero length) is included among the operating attributes in the RegDevAttr message, then the new 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 SHALL assign the EID value that is returned in the RegDevAttr Response message. Gibbons, Tseng, Monia Standards Track 50 iSNS June 2001 One RegDevAttr message can contain attributes for Entity, Portal, and Node objects if each of these attributes are contained in the same Entity. When the registration contains attributes for the Entity, Portal, and Node objects together in the same message, then the appropriate Portal, and Node key attributes must be registered as part of the operating attributes. Ordering of the attributes is important in multi-object registrations. For example, Node Attributes follow a valid Node key. 7.6.5.1.1 Update Flag The Update Flag, contained in the message header FLAGS field, indicates whether the registration message is an update to an existing entry. If the Update bit in the FLAGS field is enabled in any iSNSP message, then a new object entry SHALL NOT be created by the message. If the key attributes match an existing object in the iSNS directory database, and the Update bit in the flags field is not enabled, then the registration will replace the existing registration. 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 Node object may be de- registered and reregistered with a different Entity object as part of a registration. If the key attributes match an existing entry in the iSNS database and the Update bit in the FLAGS field is enabled, then the new attribute value(s) in the registration request SHALL update existing values and may add new, additional attributes for the key entry. Only non-key attributes can be updated. Existing associations between objects will be maintained. If the update would cause a change in associations, then the error ôInvalid Registration Updateô SHALL be returned. For example, if a RegDevAttr message with an Entity Identifier key for one entity contains a Node attribute associated with another entity, then an error shall be returned. 7.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 network entity attributes. The Source attribute of the DevAttrQry message is as defined in Section 7.6.1. The source is used to scope the query to the Discovery Domains that the source attribute is a member of. The Key Attribute(s) follow the source attribute in the message payload. The attributes returned by the query will be from objects Gibbons, Tseng, Monia Standards Track 51 iSNS June 2001 WHERE the Key Attribute(s) match the object. The Key Attributes map to a type of object. The DevAttrQry message shall support the following minimum set of Key Attributes: Valid Key Attributes for Queries -------------------------------- Entity Identifier Entity Protocol Portal IP-Address Portal IP-Address, Portal TCP/UDP Port iSCSI Node Type iSCSI Identifier iFCP Node Port WWN iFCP Node Port Type iFCP Node Port FC-4 Type If the network entities matching key attributes are not in the same Discovery Domain as the Source Attribute, then the results for the network entity will not be included in the response message. The Operating Attributes are the attributes whose values are being queried. 7.6.5.3 Device Get Next Request (DevGetNext) The DevGetNext message type is 0x0003. This message provides the iSNS client with the means to sequentially retrieve Entity, Portal, iSCSI Node, iFCP Node, or FC Node attributes from DD's to which the client has access. The Source attribute of the DevGetNext message is as defined in Section 7.6.1. The source is used to scope the Get Next process to the Discovery Domains that the source attribute is a member of. The Key Attribute follows the source attribute in the message payload. The Key Attribute may be an Entity Identifier, iSCSI Name, Portal IP Address and TCP/UDP Port, FC Device WWNN, or iFCP Node 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 Device, or iFCP Node instance shall be returned to the client. DevGetNext SHALL return the object that is stored sequentially after the object matching the key provided. If the key provided matches the last object instance, then the Error Code of "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. 7.6.5.4 Deregister Device Request (DeregDev) Gibbons, Tseng, Monia Standards Track 52 iSNS June 2001 The DeregDev message type is 0x0004. An iSNS client port or device is removed from the iSNS directory database by using DeregDev. Upon receiving the DeregDev, the iSNS server removes all object registrations associated with the Key Attribute in the payload. The DeregDev request message payload contains a Source Attribute and Key Attribute(s). The Source attribute of the DeregDev message is as defined in Section 7.6.1. Valid Key Attributes are shown below: Valid Key Attributes for DeregDev --------------------------------- Entity Identifier Portal IP-Address Portal IP-Address, Portal TCP/UDP Port iSCSI Name iFCP Node Port WWN iFCP Device Node WWN 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 SHALL be removed from the iSNS database. 7.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 allow an iSNS client to be notified of changes within the DD or network (if administratively allowed) that the device is a member of. The SCNReg request message payload contains a Source Attribute, a Key Attribute(s), and an Operating Attribute. The Source attribute of the SCNReg message is as defined in Section 7.6.1. Valid Key Attributes for an SCNReg are shown below: Valid Key Attributes for SCNReg -------------------------------- iSCSI Name (iSCSI Only) Port WWN (iFCP Only) The iSCSI nodes or iFCP nodes matching the Key Attributes are registered to receive SCNs. Gibbons, Tseng, Monia Standards Track 53 iSNS June 2001 The Operating Attribute is the SCN Bitmap attribute for the protocol type. The bitmap indicates those INTERESTED EVENT TYPES the node or entity is registering for. 7.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 Key Attribute(s). The Source attribute of the SCNDereg message is as defined in Section 7.6.1. Valid Key Attributes for an SCNDereg are shown below: Valid Key Attributes for SCNDereg --------------------------------- iSCSI Name (iSCSI only) Port WWN (iFCP only) The network entities matching the Key Attributes are deregistered for SCNs. There are no Delimiter or Operating Attributes in the SCNDereg message. 7.6.5.7 SCN Event (SCNEvent) The SCNEvent message type is 0x0007. The SCNEvent is a message generated by an iSNS client. The SCNEvent allows the client to request generation of a State Change Notification (SCN) message by the iSNS server. The SCN, sent by the iSNS server, then notifies other registered network nodes or entities within a DD or network (if administratively allowed) of the change indicated in the SCNEvent. Most SCNs are automatically generated by the iSNS when network nodes or entities are registered or deregistered from the directory database. SCNs are also be generated when a network management application makes changes to the DD membership in the iSNS. However, a network entity can trigger a SCN by using SCNEvent. The SCNEvent message payload contains a Source Attribute, Key Attribute, and Operating Attribute. The Source attribute of the SCNEvent message is as defined in Section 7.6.1. Valid Key Attributes for an SCNEvent are shown below: Valid Key Attributes for SCNEvent --------------------------------- iSCSI Name (iSCSI Only) Port WWN (iFCP Only) The Operating Attributes section SHALL contain the SCN Event Bitmap attribute. The bitmap indicates the event that caused the SCNEvent to be generated. Gibbons, Tseng, Monia Standards Track 54 iSNS June 2001 7.6.5.8 State Change Notification (SCN) The SCN message type is 0x0008. The SCN is a message generated by the iSNS server which allows a registered network node or entity to be notified of changes within a DD, network (if administratively allowed), or about device registration parameter updates in the iSNS directory database. The types of events that a network node or entity will be notified about are based on the value of the SCN Event Bitmap for the node or entity. The format of the SCN payload is shown below: +----------------------------------------+ | Destination Attribute | +----------------------------------------+ | Timestamp | +----------------------------------------+ | Source Attribute[1] | +----------------------------------------+ | Source SCN Bitmap[1] | +----------------------------------------+ | Source Attribute [2](if present) | +----------------------------------------+ | Source SCN Bitmap [2](if present) | +----------------------------------------+ | Source Attribute [3](if present) | +----------------------------------------+ | Source SCN Bitmap [3](if present) | +----------------------------------------+ | . . . | +----------------------------------------+ All payload attributes are in TLV format. The Destination Attribute is the node or entity identifier that is receiving the SCN. The Destination Attribute can be an Entity Identifier, iSCSI Name, or iFCP Port Name. The Timestamp field, using the Timestamp TLV format, indicates the time the SCN was generated. The Source Attribute is the object that caused the SCN to be generated. The Source Attribute can be an Entity Identifier, iSCSI Name, or iFCP Port Name. The Source SCN Bitmap indicates the event that caused the SCN to be generated. The SCN Bitmap is a 32 bit field, with the following definitions: Gibbons, Tseng, Monia Standards Track 55 iSNS June 2001 Bit Field Flag Description --------- ---------------- 0 CHANGE IN DD MEMBERSHIP 1 CHANGE IN NETWORK 2 CHANGE IN CLIENT REGISTRATION PARAMETERS 3 CLIENT ADDED 4 CLIENT REMOVED All Others Reserved 7.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 6.8. The DDReg message payload contains the Source Attribute, and optionally Key and Operating Attributes. The Source attribute of the DDReg message is as defined in Section 7.7.1. A DDReg message with no key attribute results in creation of a new Discovery Domain (DD) (in addition, the update flag MUST NOT be set). 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 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 as the DD_Symbolic_Name for the specified Discovery Domain. 7.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 6.8. The DDDereg message payload contains a Source Attribute, Key Attribute, and Operating Attributes. The Source attribute of the DDDereg message is as defined in Section 7.6.1. Gibbons, Tseng, Monia Standards Track 56 iSNS June 2001 The 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 error code returned. If the key attribute does not match an existing DD then the error code ô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 success error code returned. If any of the operating attributes do not match existing DD members, then the error code ôNo Such Entryö will be returned, and no DD members shall be removed. 7.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 6.8. The DDSReg message payload contains the Source Attribute, and optionally Key and Operating Attributes. The Source attribute of the DDSReg message is as defined in Section 7.6.1. A DDSReg message with no key attribute results in creation of a new Discovery Domain Set (DDS) (in addition, the update flag MUST NOT be set). 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 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 key attribute. In addition, if the DDS_Symbolic_Name is an operating attribute, then it will be stored in the iSNS as the DDS_Symbolic_Name for the specified Discovery Domain Set. 7.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. Gibbons, Tseng, Monia Standards Track 57 iSNS June 2001 DDSs are uniquely defined using DDS_IDs. DDS registration attributes are described in section 6.8. The DDSDereg message payload contains a Source Attribute, Key Attribute, and Operating Attributes. The Source attribute of the DDSDereg message is as defined in Section 7.6.1. The 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 error code returned. If the key attribute does not match an existing DDS then the error code ô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 removed from the DDS and a success error code returned. If any of the operating attributes do not match existing DDS members, then the error code ôNo Such Entryö will be returned and no DDS members shall be removed. 7.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 three consecutive ESI messages, then the iSNS 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. 7.6.5.14 Name Service Heartbeat (Heartbeat) This optional message can be regularly issued by the iSNS server to a broadcast or multicast address at an administratively-configured time interval. The payload of this message is shown below: Gibbons, Tseng, Monia Standards Track 58 iSNS June 2001 MSb LSb 31 0 +----------------------------------------+ | | | IP-Address | | | | | +----------------------------------------+ | iSNS TCP Port | iSNS UDP Port | +----------------------------------------+ | Interval | +----------------------------------------+ | Counter | +----------------------------------------+ The heartbeat payload contains: IP-Address : the IP_Address of the server in IPv6 format TCP Port : the TCP Port of the server currently in use 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 This information is NOT in TLV format. The content of the remainder of this message is vendor-specific. Vendors may use additional fields to coordinate between multiple iSNS servers to identify vendor specific features. This message allows iSNS clients listening to the broadcast or multicast address to discover the IP address of the iSNS server. It may also be used by backup iSNS servers to monitor the health and status of the primary iSNS server. There is no response message to the Name Service Heartbeat. 7.6.5.15 Request Switch ID (RqstSwId) The RqstSwId message type is 0x0011. This optional message is used for iFCP Transparent Mode to allocate non-overlapping SWITCH_ID values 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. The RqstSwId payload contains three TLV attributes in the following order: the requesting entity EID as the source attribute, the Space Identifier as the 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 Gibbons, Tseng, Monia Standards Track 59 iSNS June 2001 shall return the requested Preferred_ID value as the Assigned_ID to the requesting client. The RqstSwId response contains an Error 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 error 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 the ESI message detects that the iSNS client no longer exists on the network. The iSNS server and client SHALL use TCP to transmit and receive RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages. 7.6.5.16 Release Switch ID (RlseSwId) The RlseSwId message type is 0x0012. This optional 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 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. 7.6.5.17 Get Switch IDs (GetSwIds) The GetSwIds message type is 0x0013. This optional 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 Key Attribute. The Source attribute of the GetSwIds message is as defined in Section 7.6.1. The 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. 7.7 Response Messages The iSNSP response message payloads contain an Error Code, followed by a list of attributes, and have the following format: Gibbons, Tseng, Monia Standards Track 60 iSNS June 2001 MSb LSb 31 0 +----------------------------------------+ | 4-byte ERROR CODE | +----------------------------------------+ | Key Attribute[1] (if present) | +----------------------------------------+ | Key Attribute[2] (if present) | +----------------------------------------+ | 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. 7.7.1 Error Code The first field in an iSNSP response message payload is the Error Code for the operation that was performed. The Error Code format is defined in section 7.4. 7.7.2 Key Attributes in Response Depending on the specific iSNSP request, the response message will contain Key Attributes. For example, a Register Device Attribute Response message will contain the Key Attributes used in the Device Attribute Registration with the assigned values, if they were assigned by the iSNS. 7.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. 7.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. Gibbons, Tseng, Monia Standards Track 61 iSNS June 2001 The number of Operating Attributes in the response depends on the specific iSNSP request or query response. For example, the Operating Attributes in a Device Attribute Query Response message are the set of Operating Attributes from network entity entries that matched the Key Attributes in the associated Device Attribute Query message. 7.7.5 Registration and Query Message Types The following describes each query and message type. 7.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 Error Code contains the operation results. If the registration completed successfully the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. The Key Attributes contain the set of keys for the objects registered by the Register Device Attribute message. If the iSNS assigned a unique Entity Identifier for a network entity, then the key attribute field shall contain the assigned Entity Identifier. There are no Operating Attributes in the RegDevRsp message. 7.7.5.2 Device Attribute Query Response (DevAttrQryRsp) The DevAttrQryRsp message type is 0x8002. The DevAttrQryRsp message contains the results for the DevAttrQry message with the same TRANSACTION ID. The Error Code contains the operation results. If the query completed successfully the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. For a successful query result, the DevAttrQryRsp Operating Attributes will contain the results of the original DevAttrQry message. 7.7.5.3 Device Get Next Response (DevGetNextRsp) The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message contains the results for the DevGetNext message with the same TRANSACTION ID. The Error Code contains the operation results. If the operation completed successfully the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. Gibbons, Tseng, Monia Standards Track 62 iSNS June 2001 The Key Attribute field contains the next key, in sequential order, after the Key Attribute used in the DevGetNext message. The Operating Attribute field contains the same attributes as in the DevGetNext message. The values of the Operating Attributes are the attribute values associated with the key returned. 7.7.5.4 Deregister Device Response (DeregDevRsp) The DeregDevRsp message type is 0x8004. If the DeregDev operation completed successfully then the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. The DeregDevRsp message does not contain any key or operating attributes. 7.7.5.5 SCN Register Response (SCNRegRsp) The SCNRegRsp message type is 0x8005. If the SCNReg operation completed successfully then the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. The SCNRegRsp message does not contain any key or operating attributes. 7.7.5.6 SCN Deregister Response (SCNDeregRsp) The SCNDeregRsp message type is 0x8006. If the SCNDereg operation completed successfully then the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. The SCNDeregRsp message does not contain any key or operating attributes. 7.7.5.7 SCN Event Response (SCNEventRsp) The SCNEventRsp message type is 0x8007. If the SCNEvent operation completed successfully then the Error Code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. The SCNEventRsp message does not contain any key or operating attributes. 7.7.5.8 SCN Response (SCNRsp) The SCNRsp message type is 0x8008. This message is sent by an iSNS client, and provides confirmation that the SCN message was received and processed. If the SCN operation completed successfully, then the Error Code of ôNo Errorö is returned by the iSNS client. If an error occurred then the appropriate code will be returned. Gibbons, Tseng, Monia Standards Track 63 iSNS June 2001 The SCNRsp response message payload also contains the SCN Destination Attribute representing the node or entity identifier that received the SCN. 7.7.5.9 DD Register Response (DDRegRsp) The DDRegRsp message type is 0x8009. If the DDReg operation completed successfully then the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. If successful, the DD ID of the DD created or updated during the DDReg operation will be returned as an operating attribute of the message. 7.7.5.10 DD Deregister Response (DDDeregRsp) The DDDeregRsp message type is 0x800A. If the DDDereg operation completed successfully then the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. The DDDeregRsp message does not contain any key or operating attributes. 7.7.5.11 DDS Register Response (DDSRegRsp) The DDSRegRsp message type is 0x800B. If the DDSRegRsp operation completed successfully then the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. If successful, the DDS ID of the DDS created or updated during the DDSReg operation will be returned as an operating attribute of the message. 7.7.5.12 DDS Deregister Response (DDSDeregRsp) The DDSDeregRsp message type is 0x800C. If the DDSDeregRsp operation completed successfully then the code of ôNo Errorö is returned. If an error occurred then the appropriate code will be returned. The DDSDeregRsp message does not contain any key or operating attributes. 7.7.5.13 Entity Status Inquiry Response (ESIRsp) The ESIRsp message type is 0x800D. This message is sent by an iSNS client, and provides confirmation that the ESI message was received and processed. The ESIRsp response message payload contains the attributes from the original ESI message. These attributes represent the iSNS client portal that is responding to the ESI. The ESIRsp Attributes are in the order they were provided in the original ESI message. An error code of "No Error" is returned. Gibbons, Tseng, Monia Standards Track 64 iSNS June 2001 Upon receiving the ESIRsp from the iSNS client, the iSNS server SHALL update the timestamp attribute for that client entity and portal. 7.7.5.14 Request Switch ID Response (RqstSwIdRsp) The RqstSwIdRsp message type is 0x8011. This message provides the response for RqstSwId. The RqstSwId response contains an Error 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 error code 19 "SWITCH_ID not available". Once a SWITCH_ID value is allocated by the iSNS server, it shall not be reused until it has been deallocated by the iSNS client to which the value was assigned, or the ESI message detects that the iSNS client no longer exists on the network. The iSNS server and client SHALL use TCP to transmit and receive RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages. 7.7.5.15 Release Switch ID Response (RlseSwIdRsp) The RlseSwIdRsp message type is 0x8012. This message provides the response for RlseSwId. The response contains an Error indicating if the request was successful or not. If the Assigned_ID value in the original RlseSwId message is not allocated, then the iSNS server SHALL respond with this message using the error code 20 ôSWITCH_ID not allocatedö. The iSNS server and client SHALL use TCP to transmit and receive RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages. 7.7.5.16 Get Switch IDs Response (GetSwIdRsp) The GetSwIdsResp message type is 0x8013. This optional message is used determine which SWITCH_ID values have been allocated for the Space_Identifier specified in the original GetSwId request message. The GetSwIds response message payload contains an error code indicating if the request was successful, and a list of the Assigned IDs from the space requested. The Assigned_ID attributes are listed in TLV format. 7.8 Vendor Specific Messages Vendor-specific iSNSP messages have a functional ID of between 0x0100 and 0x01FF, while vendor-specific responses have a functional ID of between 0x8100 and 0x81FF. The first key attribute in a vendor-specific message SHALL be the company OUI (tag=256) identifying original creator of the proprietary iSNSP message. The contents of the remainder of the message is vendor-specific. Gibbons, Tseng, Monia Standards Track 65 iSNS June 2001 8. Security Considerations 8.1 Data Integrity and Authentication Data integrity and authentication requirements for communication between iSNS clients and server can be achieved through use of the authentication block described in section 7.5. This data integrity and authentication mechanism is compatible with that used by Service Location Protocol [RFC2608]. 8.2 Confidentiality If the operational evironment requires confidentiality in iSNSP queries and responses, then the iSNSP shall be used with Transport Layer Security (TLS). None of the information stored in the iSNS database is inherently confidential. This includes X.509 certificates, which should contain only public keys. In these cases where confidentiality is not required, the iSNS can be used only with the message authentication block described in section 7.5. 8.3 Security Model The iSNS server will leverage existing security mechanisms currently used to secure resources such as DNS servers, e-mail relays servers, and other sensitive and otherwise vulnerable network resources. Existing firewalls technology can protect against active attacks from the Public Internet. 9. References [RFC1035] Domain Implementation and Specification [RFC1305] Network Time Protocol (Version 3) [STD0035] Domain Name System [RFC2065] Domain Name System Security Extensions [RFC2608] Service Location Protocol, Version 2 [FC-GS-2] Fibre Channel Generic Services-2, ANSI NCITS 288 [FC-GS-3] Fibre Channel Generic Services-3, NCITS Working Draft Rev 7.01, November 28, 2000 [RFC2609] Service Templates and Service [IEEE802.1Q] Standard for Virtual Bridged Local Area Networks [RFC1510] The Kerberos Network Authentication Service [DSS] FIPS PUB 186-2, National Institute of Standards and Technology, Digital Signature Standard(DSS), Technical Report [802-1990] ANSI/IEEE Std 802-1990, Name: IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture [SPC] SCSI-3 Primary Commands, ANSI NCITS 995D, Revision 11a [iSCSI-SLP] Finding iSCSI Targets and Name Servers Using SLP, draft-bakke-iscsi-slp-00.txt [iSCSI-NDR] iSCSI Naming and Discovery Requirements, draft-ietf-ips-iscsi-name-disc-00.txt Gibbons, Tseng, Monia Standards Track 66 iSNS June 2001 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 10. Author's Addresses Josh Tseng Kevin Gibbons Charles Monia Nishan Systems 3850 North First Street San Jose, CA 95134-1702 Phone: (408) 519-3749 Email: jtseng@nishansystems.com Franco Travostino Nortel Networks 3 Federal Street Billerica, MA 01821 Phone: 978-288-7708 Email: travos@nortelnetworks.com Kenneth Hirata Vixel Corporation Irvine, CA 92618 Phone: (949) 450-6100 Email: khirata@vixel.com Mark Bakke Cisco Systems 6450 Wedgewood Road Maple Grove, MN 55311 Phone: 763-398-1054 Email: mbakke@cisco.com John Dowdy IBM 4205 South Miami Blvd Research Triangle Park, NC 27709 Email: jdowdy@us.ibm.com Phone: (919)254-5632 Howard Hall Pirus Networks 43 Nagog Park Acton, MA 01720 Email: howard@pirus.com Phone: 978-206-9103 Gibbons, Tseng, Monia Standards Track 67 iSNS June 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Gibbons, Tseng, Monia Standards Track 68 iSNS June 2001 Appendix A - iSNS Examples A.1 iSCSI Initialization Example This example assumes an SLP Service Agent (SA) has been implemented on the iSNS host, and an SLP User Agent (UA) has been implemented on the iSNS initiator. See [RFC2608] for further details on SA's and UA's. This example also assumes the target is configured to use the iSNS, and have its access control policy subordinated to the iSNS. Gibbons, Tseng, Monia Standards Track 69 iSNS June 2001 A.1.1 Simple iSCSI Target Registration In this example, a simple target with a single iSCSI name registers with the iSNS. The target has not been assigned a Fully Qualified Domain Name (FQDN) by the administrator. +--------------------------+------------------+-------------------+ | iSCSI Target Device | iSNS |Management Station | +--------------------------+------------------+-------------------+ |Discover iSNS--SLP------->| |/*mgmt station is | | |<--SLP--iSNS Here:| administratively | | | 192.36.53.1 | authorized to view| | | | all DD's. Device | | | | NAMEabcd has been | | RegDevAttr--------->| | previously placed | |Oper Attrs: | | into DDabcd******/| |tag=1: NULL | | | |tag=2: "iSCSI" | | | |tag=16: "192.36.4.5" | | | |tag=17: "5001" | | | |tag=19: 0 | | | |tag=32: "NAMEabcd" | | | |tag=33: "target" | | | |tag=34: "disk 1" | | | | |<---RegDevAttrRsp | | | |SUCCESS | | | |tag=1: "iSNS:0001"| | | |tag=16: "192.36.4.5" | | |tag=17: "5001" | | | |tag=32: "NAMEabcd"| | | | | | | DevAttrQry--------->| SCN-------->| | |Src:(tag=32) "NAMEabcd" |(or SNMP trap) | | |Key:(tag=2) "iSCSI" |tag=1: "iSNS:0001" | |Key:(tag=33) "initiator" |dest: "mgmt.foo.com" | |Oper Attrs: |CHANGE IN NETWORK | | |tag=16: NULL | | | |tag=17: NULL | |<-------SCNRsp | |tag=32: NULL | | | |/*Query asks for all iSCSI| | | |devices' IP address, port |<---DevAttrQryRsp | | |number, and Name*/ |SUCCESS | | | |tag=16:"192.36.4.1" | | |tag=17:"50000" | | | |tag=32:"devpdq" | | | |tag=16:"192.1.3.2"|<-----DevAttrQry | | |tag=17:"50000" |src: ôMGMTname1ö | | |tag=32:"devrst" |key:(tag=1)iSNS:0001 | | |Op Attrs: | |/*************************| |tag=16: NULL | |Our target "iSNS:0001" | |tag=17: NULL | |discovers two initiators | |tag=32: NULL | |in the same DD. It will | | | Gibbons, Tseng, Monia Standards Track 70 iSNS June 2001 |accept iSCSI logins from | | | |these two identified | | | |initiators presented by | | | |iSNS*********************/| DevAttrQryRsp--->| | | |SUCCESS | | | |tag=16: 192.36.4.5| | | |tag=17: 5001 | | | |tag=32: NAMEabcd | | +--------------------------+------------------+-------------------+ A.1.2 Target Registration and DD Configuration In this example, a more complex target registers with the iSNS. This target has been configured with a Fully Qualified Domain Name (FQDN) in the DNS servers, and the user wishes to use this identifier for the device. Also, the user wishes to use public key certificates in the iSCSI login authentication. +--------------------------+------------------+-------------------+ | iSCSI Target Device | iSNS |Management Station | +--------------------------+------------------+-------------------+ |Discover iSNS--SLP--> | |/*mgmt station is | | |<--SLP--iSNS Here:| administratively | | | 192.36.53.1 | authorized to view| | RegDevAttr--> | | all DD's ********/| |Oper Attrs: | | | |tag=1: "jbod1.foo.com" | | | |tag=2: "iSCSI" | | | |tag=16: "192.36.34.4" | | | |tag=17: "5001" | | | |tag=19: "5 seconds" | | | |tag=16: "192.36.53.5" | | | |tag=17: "5001" | | | |tag=32: "NAMEabcd" | | | |tag=33: "Target" |/*****************| | |tag=34: "Volume 1" |jbod1.foo.com is | | |tag=40: X.509 cert blob 1 |now registered in | | |tag=32: "NAMEefgh" |iSNS, but is not | | |tag=33: "Target" |in any DD. Therefore, | |tag=34: "Volume 2" |no other devices | | |tag=40: X.509 cert blob 2 |can "see" it. | | | |*****************/| | | |<--RegDevAttrRsp | | | |SUCCESS | | | |tag=1: "jbod1.foo.com" | | |tag=16: "192.36.34.4" | | |tag=17: "5001" | | | |tag=16: "192.36.53.5" | | |tag=17: "5001" | | | |tag=32: "NAMEabcd"| | | |tag=32: "NAMEefgh"| | | | | | | | SCN------> | | | | (or SNMP trap) | | Gibbons, Tseng, Monia Standards Track 71 iSNS June 2001 | |tag=1: jbod1.foo.com | | |dest: mgmt.foo.com| | | |CHANGE IN NETWORK | | | | | | | | |<--SCNRsp | | | |<--DevAttrQry | | | |src: mgmt.foo.com | | | |key: (tag=1) | | | | jbod1.foo.com | | | |Op Attr: (tag=2) | | | |Op Attr: (tag=16) | | | |Op Attr: (tag=17) | | | |Op Attr: (tag=32) | | | | | | | DevAttrQryRsp--> | | | |SUCCESS | | | |tag=2: "iSCSI" | | | |tag=16: 192.36.34.4 | | |tag=17: 5001 | | | |tag=16: 192.36.53.5 | | |tag=17: 5001 |/**Mgmt Station ***| | |tag=32:"NAMEabcd" |displays device, | | |tag=32:"NAMEefgh" |the operator decides | | |to place "NAMEabcd"| | | |into Domain "DDxyz"| |/*************************| |******************/| |Target is now registered | | | |in iSNS. It has been placed |<--DDReg | |in DDxyz by management | |src: "mgmt.foo.com"| |station. | |key: "DDxyz ID" | |*************************/| |Op Attr: | | | |tag=32: "NAMEabcd" | | | DDRegRsp----->| | | | SUCCESS | | +--------------------------+------------------+-------------------+ A.1.3 Initiator Registration and Target Discovery The following example illustrates a new initiator registering with the iSNS, and discovering the target NAMEabcd from the example in A.1.2. +--------------------------+------------------+-------------------+ | iSCSI Initiator | iSNS |Management Station | +--------------------------+------------------+-------------------+ |Discover iSNS--SLP--> | |/*mgmt station is | | |<--SLP--iSNS Here:| administratively | | | 192.36.53.1 | authorized to view| |RegDevAttr--> | | all DD's ********/| |Oper Attrs: | | | |tag=1: "svr1.foo.com" | | | |tag=2: "iSCSI" | | | |tag=16: "192.20.3.1" |/*****************| | |tag=17: "5001" |Device not in any | | Gibbons, Tseng, Monia Standards Track 72 iSNS June 2001 |tag=19: 5 seconds |DD, so it is | | |tag=32: "NAMEijkl" |inaccessible by | | |tag=33: "Initiator" |other devices | | |tag=34: "Server1" |*****************/| | |tag=39: X.509 cert blob 3 | | | | |<--RegDevAttrRsp | | | |SUCCESS | | | |tag=1: "svr1.foo.com" | | |tag=16: "192.20.3.1" | | |tag=17: "5001" | | | |tag=32: "NAMEijkl"| | | | | | | | SCN------> | | | | (or SNMP trap) | | | |tag=1: svr1.foo.com | | |dest: mgmt.foo.com| | | |CHANGE IN NETWORK | | | | | | | | |<------SCNRsp | | | |<----DevAttrQry | | | |src: mgmt.foo.com | | | |key: (tag=1) | | | | svr1.foo.com | | | |Op Attr: (tag=2) | | | |Op Attr: (tag=16) | | | |Op Attr: (tag=17) | | | |Op Attr: (tag=32) | | | DevAttrQryRsp--> | | | |SUCCESS | | | |tag=2: "iSCSI" | | | |tag=16:192.20.3.1 | | | |tag=17: "5001" | | | |tag=32:"NAMEijkl" | | | | |/**Mgmt Station ***| | | |displays device, | | | |the operator decides | | |to place "NAMEijkl"| | | |into Domain "DDxyz"| | | |with device NAMEabcd | | |******************/| | | |<--DDReg | | | |src: (tag=1) | | | | "mgmt.foo.com" | | | |key: "DDxyz ID" | | | |tag=32: "NAMEijkl | | | | | | | DDRegRsp---->|/******************| | | SUCCESS |"NAMEijkl" has been| | | |moved to "DDxyz" | | | |******************/| | |<-----SCN | | | |tag=32: "NAMEijkl"| | | |CHANGE IN DD MEMBERSHIP | | DevAttrQry----------->| | | Gibbons, Tseng, Monia Standards Track 73 iSNS June 2001 |src: "NAMEabcd" |/*****************| | |key:(tag=2) "iSCSI" |Note that NAMEabcd| | |key:(tag=33) "Target" |also receives an | | |Op Attr: (tag=16) |SCN that NAMEijkl | | |Op Attr: (tag=17) |is in the same DD | | |Op Attr: (tag=32) |*****************/| | |Op Attr: (tag=34) | | | |Op Attr: (tag=40) |<-----AttrQryRsp | | | |SUCCESS | | | |tag=16: 192.36.34.4 | | |tag=17: 5001 | | | |tag=16: 192.36.53.5 | | |tag=17: 5001 | | | |tag=32: NAMEabcd | | | |tag=34: Volume 1 | | | |tag=40: X.509 cert blob 2 | | | | | |/***The initiator has discovered | | |the target, and has everything | | |needed to complete iSCSI login | | |The same process occurs on the | | |target side; the SCN prompts the | | |target to download the list of | | |authorized initiators from the | | |iSNS (i.e., those initiators in the | | |same DD as the target.************/ | | +--------------------------+------------------+-------------------+ Gibbons, Tseng, Monia Standards Track 74
Datatracker
Report a datatracker bug
draft-ietf-ips-isns-04
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4171.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |