Internet Draft Kevin Gibbons Josh Tseng Expires September 2001 Charles Monia Nishan Systems Franco Travostino Nortel Networks Ken Hirata Vixel Corporation Mark Bakke Cisco Systems Jim Hafner IBM Research Howard Hall Pirus Networks March 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), Yaron Gibbons, Tseng, Monia Standards Track iSNS March 2001 Klein (Sanrad), Larry Lamers (SAN Valley), Jack Harwood (EMC), David Black (EMC), and David Robinson (Sun). Comments Comments should be sent to the IPS mailing list (ips@ece.cmu.edu) or to the authors. 1. Abstract This document provides a generic framework centering around use of the iSNS for discovery and management of storage entities in an enterprise-scale IP storage network. iSNS is an application that stores client attributes and monitors the availability and reachability of storage assets in an integrated IP storage network. Due to its role as a consolidated information repository, iSNS provides for more efficient and scalable management of IP storage assets. 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 iSNS provides a common framework used to provide naming, discovery, and resource management services for enterprise-scale IP storage networks. iSNS can be implemented to support iSCSI, iFCP, and/or FCIP protocols as needed; an iSNS implementation MAY provide support for any one, two, or all three of these protocols as desired by the implementer. Implementation requirements within each of these protocols is further discussed in section 5. Although use of iSNS is optional for iSCSI and FCIP, these protocols will benefit from iSNS as the number of devices in the storage network increases. 3.1 iSNS Architectural Components 3.1.1 iSNS Client Entities that initiate transactions using the iSNSP are referred to as iSNS clients. Using the iSNSP, iSNS clients can register their 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 Gibbons, Tseng, Monia Standards Track 2 iSNS March 2001 a special type of iSNS client that have access to all DDs stored in the iSNS. 3.1.2 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 database. The iSNS server MAY be discovered by iSNS clients through a multicast discovery message, although the protocol format for this discovery mechanism is beyond the scope of this document. 3.1.3 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.4 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.2 iSNS Functional Components There are three main functional components of the iSNS: 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 mapping 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. Gibbons, Tseng, Monia Standards Track 3 iSNS March 2001 The naming registration service also provides the ability to obtain a network unique Domain ID for iFCP gateways and Fibre Channel Autonomous Regions (AR's), 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. With DD's, an administrator can partition groups of initiators and targets into more manageable groups in order 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 from the iSNS. 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 provide enhanced security. 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 "slave" their access control mechanism to the iSNS. The target downloads the list of authorized initiators from the iSNS. Each initiator is uniquely identified by an iSCSI WWUI, iFCP Port Name, or FCIP IP Address. Only initiators that match the required identification and authenticating information provided by the iSNS will be allowed access by that target during the initiator's session login (e.g., the iSCSI login process). If spoofing of initiator identities is a concern, the target MAY use the public key certificate of the authorized initiator, obtained from the iSNS server, to authenticate the initiator. DD's can be managed offline 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 authorized, a target can upload its own Login Control list. This is accomplished using the RegDevDD message and listing the WWUI of each initiator to be registered in the Target's DD. Devices that do not belong to any Discovery Domain SHALL NOT be accessible to any other device (except the management station). 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 Gibbons, Tseng, Monia Standards Track 4 iSNS March 2001 devices in that DD. Other implementations MAY decide that they are registered with no DD, making them inaccessible to any other devices in the iSNS database. 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 client entities. 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, as described in section 3.1.2, 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. 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 Gibbons, Tseng, Monia Standards Track 5 iSNS March 2001 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. 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. 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 Discovery and SLP The Service Location Protocol (SLP) provides a flexible and scalable framework for providing hosts with access to information about the existence, location, and configuration of networked services. 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). If iSNS is not used, then the IP address of the iSNS server should be manually configured in each iSNS client. 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. Gibbons, Tseng, Monia Standards Track 6 iSNS March 2001 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 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 Gibbons, Tseng, Monia Standards Track 7 iSNS March 2001 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). +-------------------------+ +-------------------------+ |+------+ 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". Gibbons, Tseng, Monia Standards Track 8 iSNS March 2001 +-------------------------+ +-------------------------+ |+------+ 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 (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. Gibbons, Tseng, Monia Standards Track 9 iSNS March 2001 +------------+ +-----------+ +-----------+ | | LDAP | Directory | LDAP | iSNS | | DNS Server |<-------->| Database |<-------->| Server | | | | | | | +------+-----+ +-----+-----+ +-----+-----+ | | | | DNS | LDAP iSNSP | |Queries | | +------+----------------------+----------------------+---------+ | | | IP Network | | | +----+-----------+----------+---------------+-------------+----+ | | | | | | | +-----+-----+ +------+-----+ +----+----+ | | |iSCSI-/ | |iFCP / | | FCIP | | | | FC /iSNS | |Switch/iSNS | | Gateway | | | |Gtwy/Server| | /Server| | | | | +----+------+ +-+-------+--+ +----+----+ | | | | | | +----+----+ +----+---+ +---+----+ +----+-+ +---+----+ +---+----+ | iSCSI | | iSCSI | | Fibre | | FC | | Fibre | | Fibre | |Initiator| | Target | |Channel | |Device| |Channel | |Channel | +---------+ +--------+ |Network | +------+ |Network | |Network | +--------+ +--------+ +--------+ iSNS Client Entities 4. iSNS Object Model iSNS provides the framework for the registration and discovery of iSCSI devices, Fibre Channel-based devices using iFCP, and FCIP tunnel endpoint gateways. This architecture defines common objects that can be used to represent components referenced by each of these three protocols. In iSCSI, the IP-based storage end devices (NICs, controllers, etc...) are registered in the iSNS. In iFCP, the iFCP gateway and its supported Fibre Channel-based storage end devices (HBA's, controllers, etc...) have their attributes registered in the iSNS by the iFCP gateway. Finally, for FCIP, only the FCIP gateway and its supported tunnel endpoints are registered in the iSNS by the FCIP gateway. The following architecture framework provides elements needed to describe various storage device objects and attributes that may exist on an IP storage network. Five object entities are defined in this architecture framework. They are PORTAL, NETWORK ENTITY, STORAGE NODE, STORAGE PORT, and DISCOVERY DOMAIN. Each of these objects are described in greater detail in sections 4.1 to 4.5. The object containment hierarchy starts with the DISCOVERY DOMAIN. The DISCOVERY DOMAIN contains a set of NETWORK ENTITY objects, STORAGE NODE objects, and/or PORTAL objects. Conversely, an individual NETWORK ENTITY, STORAGE NODE, or PORTAL can be contained Gibbons, Tseng, Monia Standards Track 10 iSNS March 2001 in one or more DISCOVERY DOMAIN objects. The NETWORK ENTITY object describes a device or gateway visible to the IP network. It can contain one or more STORAGE NODE objects, and one or more PORTAL objects. STORAGE NODE objects are used to represent an initiator or target storage controller, while a PORTAL represents an IP Address and Port Number which can be used to access any of the STORAGE NODE objects within that NETWORK ENTITY object. Within the STORAGE NODE are one or more STORAGE PORTS. Each object has a set of attributes described in section 5. Not all objects are applicable to each protocol (i.e., iSCSI, iFCP, and FCIP) supported by iSNS. For example, the STORAGE PORT object is not used in iSCSI. In the diagrams below, objects are denoted in all CAPITAL letters. 4.1 NETWORK ENTITY Object The NETWORK ENTITY object represents a device or gateway that is accessible from the IP network. This device or gateway may support one or more initiators or target controllers that are either internal to the storage device, or accessible through a network behind the gateway. Each individual initiator or target controller is represented by subordinate STORAGE NODE objects. Applicability Primary Attribute iSCSI iFCP FCIP Key Attribute --------- ----- ---- ---- ------------- Entity Identifier * * * * Entity Type * * * Management IP Address * * * ESI Interval * * * Timestamp * * * Entity Certificate * * * SCN Event Bitmap * * * ESI TCP/UDP Port * * * 4.2 PORTAL Object The PORTAL object is a port 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 the IP network. Applicability Primary Attribute iSCSI iFCP FCIP Key Attribute --------- ----- ---- ---- ------------- IP Address * * * * TCP/UDP Port * * * * Portal Symbolic Name * * * 4.3 STORAGE NODE Object Gibbons, Tseng, Monia Standards Track 11 iSNS March 2001 The STORAGE NODE object defines an individual storage initiator or target. This entity may be a RAID controller, a Fibre Channel HBA, or other individual storage controller. The STORAGE NODE may have one or more STORAGE PORT objects. There may be one or more STORAGE NODE objects within the NETWORK ENTITY. Applicability Primary Attribute iSCSI iFCP FCIP Key Attribute --------- ----- ---- ---- ------------- WWUI * * Node Name (WWNN) * * Node Type * * Alias/Node Symbolic Name * * FC Node IP-Address * FC Node IPA * Node Certificate * * The primary key used to uniquely identify an iSCSI-based STORAGE ENTITY is WWUI, while the key for an iFCP/Fibre Channel-based STORAGE ENTITY is WWNN. iFCP/Fibre Channel-based Nodes contain 1 or more STORAGE PORT objects, which are keyed with a WWPN. 4.4 DISCOVERY DOMAIN Object DISCOVERY DOMAINS are a security and management mechanism used to partition storage resources. Zoning prevents initiators from potentially logging in to every possible target during device discovery. When queried, the iSNS server will only provide information on storage entities in a common DD. Initiators will thus not be able to "see" devices that are not in a common DD. Applicability Primary Attribute iSCSI iFCP FCIP Key Attribute --------- ----- ---- ---- ------------- DD_ID * * * * DD_Symbolic Name * * * * DD_Member (WWUI) * * DD_Member (WWPN) * * DD_Member (WWNN) * * DD_Member (IP Address) * * * 4.5 STORAGE PORT Object The STORAGE PORT object defines an individual service delivery port that services a STORAGE ENTITY. An iSCSI device does not have a STORAGE PORT, and this object is therefore unused for an iSCSI device. For a Fibre Channel device, the STORAGE PORT describes an N_PORT interface. Gibbons, Tseng, Monia Standards Track 12 iSNS March 2001 Applicability Primary Attribute iSCSI iFCP FCIP Key Attribute --------- ----- ---- ---- ------------- 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 * 4.6 Diagram Examples In each of the following subsections, the attributes described for each object are covered in more detail in section 5.4. The Key Attribute column indicates that the attribute is a search key which can be used to query for that object. 4.6.1 iSCSI 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 STORAGE PORT object does not apply. All required attributes are also shown in this diagram: Gibbons, Tseng, Monia Standards Track 13 iSNS March 2001 +----------------------------------------------------------------+ | IP Network | +------------+--------------------------------------+------------+ | | | | +-----+------+------+-----+ +-----+------+------+-----+ | | PORTAL | | | | PORTAL | | | | -IP Addr 1 | | | | -IP Addr 2 | | | | -TCP Port 1 | | | | -TCP Port 2 | | | +-----+ +-----+ | | +-----+ +-----+ | | | | | | | | | | | | | | | | | | +--------+ +--------+ | | +-------+ +--------+ | | | | | | | | | | | STORAGE NODE | | | | STORAGE NODE | | | | -WWUI | | | | -WWUI | | | | -Alias: "server1"| | | | -Alias: "disk1"| | | | -Type: initiator | | | | -Type: target | | | | | | | | | | | +-------------------+ | | +------------------+ | | | | | | NETWORK ENTITY | | NETWORK ENTITY | | -Entity ID (FQDN): | | -Entity ID (FQDN): | | "strg1.foo.com" | | "strg2.bar.com" | | -Type: iSCSI | | -Type: 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 highly-available 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 14 iSNS March 2001 +---------------------------------------------------------------+ | IP Network | +-------------------+-----------------------+-------------------+ | | | | +------------+------+------+---------+------+------+------------+ | | PORTAL | | PORTAL | | | | -IP Addr 1 | | -IP Addr 2 | | | | -TCP Port 1 | | -TCP Port 2 | | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | +---------------+ +---------------------+ +---------------+ | | +-------+ +----------------+ +-------------------+ +------+ | | | | | | | | | | +-------+ +-------+ +------+ +--------+ +--------+ +------+ | | | | | | | | | | | STORAGE NODE | | STORAGE NODE | | STORAGE NODE | | | | -WWUI 1 | | -WWUI 2 | | -WWUI 3 | | | | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| | | | -Type: target | | -Type: target | | -Type: target | | | | | | | | | | | +-----------------+ +-----------------+ +-----------------+ | | | | NETWORK ENTITY | | -Entity ID (FQDN): "dev1.foo.com" | | -Type: iSCSI | | | +---------------------------------------------------------------+ 4.6.2 iFCP 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 the attributes of the Fibre Channel devices themselves, attributes of the iFCP gateway, as well as 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 the two Fibre Channel devices behind it. The NETWORK ENTITY object represents the iFCP gateway itself, while each of the STORAGE NODE objects represents an actual Fibre Channel device. One of the target devices has two ports, each represented by a STORAGE PORT object. Gibbons, Tseng, Monia Standards Track 15 iSNS March 2001 +---------------------------------------------------------------+ | IP Network | +-------------------+-----------------------+-------------------+ | | | | +------------+------+------+---------+------+------+------------+ | | PORTAL | | PORTAL | | | | -IP Addr 1 | | -IP Addr 2 | | | | -TCP Port 1 | | -TCP Port 2 | | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | +---------------+ +---------------------+ +---------------+ | | | Fibre Channel Loop or Fabric | | | +-------+ +-----------------+ +----------------+ +--------+ | | | | | | | | | | +-+-----+ +-----+-+ +--+----+ +------+---+-----+ +-----+--+ | | | |STORAGE PORT | | | |STORAGE PORT | |STORAGE PORT | | | | | | -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 | | | | | +-------------+ | | +-------------+ +-------------+ | | | | | | | | | | STORAGE NODE | | STORAGE NODE | | | | -WWNN 1 | | -WWNN 2 | | | | -Symbolic Name| | -Symbolic Name | | | | -FC Node IPA | | -FC Node IPA | | | | -Type: target | | -Type: target | | | | | | | | | +-----------------+ +-------------------------------------+ | | | | NETWORK ENTITY | | -Entity ID (FQDN): "gtwy1.foo.com" | | -Type: iFCP | | | +---------------------------------------------------------------+ 4.6.3 FCIP Gibbons, Tseng, Monia Standards Track 16 iSNS March 2001 The following diagram depicts FCIP gateways stored in the iSNS. In FCIP, the iSNS is only used for tunnel endpoint discovery. Therefore, no information about the storage end nodes are registered in the iSNS, and the STORAGE PORT and STORAGE NODE objects are not applicable. +----------------------------------------------------------------+ | IP Network | +-------------+-------------------------+----------------+-------+ | | | | | | +-----+-------+------+----+ +-+------+------+--+------+-----+-+ | | PORTAL | | | | PORTAL | | PORTAL | | | | -IP Addr 1 | | | | -IP Addr 2 | | -IP Addr 3 | | | | -TCP Port 1 | | | | -TCP Port 2 | | -TCP Port 3| | | +--------------+ | | +-------------+ +------------+ | | | | | | NETWORK ENTITY | | NETWORK ENTITY | | -Entity ID (FQDN): | | -Entity ID (FQDN): | | "Tunnelgtwy1.foo.com" | | "Tunnelgtwy2.bar.com" | | -Type: FCIP | | -Type: FCIP | +-------------------------+ +---------------------------------+ 5. iSNS Implementation Requirements iSNS can be implemented with features to support any combination of the following protocols: iSCSI, iFCP, and FCIP. Implementation of support for any or all 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 WWUI 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 17 iSNS March 2001 REQUIRED REQUIRED Object Attribute to Implement to Use ------ --------- ------------ -------- NETWORK ENTITY Entity Identifier * * Entity Type * * Management IP Address ESI Interval * Timestamp * Entity Certificate * SCN Event Bitmap * ESI TCP/UDP Port * * PORTAL IP Address * * TCP/UDP Port * * Portal Symbolic Name * STORAGE NODE WWUI * * Node Type * * Alias/Symbolic Node Name * Node Certificate * DISCOVERY DOMAIN DD_ID * * DD_Symbolic Name * DD Member (Entity ID) * DD_Member (WWUI) * * DD_Member (IP Address) * 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 18 iSNS March 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 Type | Indicates this is an iSCSI registration - Mgt IP-Address | If it is not registered then in-band management | is assumed. - Entity Status Inquiry Interval | If 0 no status inquiry is used - Timestamp | Timestamp of last registration update - Entity Certificate | X.509 certificate bound to the Entity (FQDN) - SCN Event Bitmap | Indicates current SCN state - ESI TCP/UDP Port Destination port number for ESI messages - PORTAL (1 - n per ENTITY) | | | - IP-Address | - TCP/UDP Port | | The IP-Addr and Port together uniquely | | define a portal. | - Portal Symbolic Name | - STORAGE NODE (1 - m per ENTITY) | - WWUI (World-Wide Unique Identifier) - Node Type (initiator / target / ...) - Alias/Symbolic Node Name - 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 STORAGE PORT object does not apply. All required attributes are also shown in this diagram: Gibbons, Tseng, Monia Standards Track 19 iSNS March 2001 +----------------------------------------------------------------+ | IP Network | +------------+--------------------------------------+------------+ | | | | +-----+------+------+-----+ +-----+------+------+-----+ | | PORTAL | | | | PORTAL | | | | -IP Addr 1 | | | | -IP Addr 2 | | | | -TCP Port 1 | | | | -TCP Port 2 | | | +-----+ +-----+ | | +-----+ +-----+ | | | | | | | | | | | | | | | | | | +--------+ +--------+ | | +-------+ +--------+ | | | | | | | | | | | STORAGE NODE | | | | STORAGE NODE | | | | -WWUI | | | | -WWUI | | | | -Alias: "server1"| | | | -Alias: "disk1"| | | | -Type: initiator | | | | -Type: target | | | | | | | | | | | +-------------------+ | | +------------------+ | | | | | | NETWORK ENTITY | | NETWORK ENTITY | | -Entity ID (FQDN): | | -Entity ID (FQDN): | | "strg1.foo.com" | | "strg2.bar.com" | | -Type: iSCSI | | -Type: 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 highly-available 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 20 iSNS March 2001 +---------------------------------------------------------------+ | IP Network | +-------------------+-----------------------+-------------------+ | | | | +------------+------+------+---------+------+------+------------+ | | PORTAL | | PORTAL | | | | -IP Addr 1 | | -IP Addr 2 | | | | -TCP Port 1 | | -TCP Port 2 | | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | +---------------+ +---------------------+ +---------------+ | | +-------+ +----------------+ +-------------------+ +------+ | | | | | | | | | | +-------+ +-------+ +------+ +--------+ +--------+ +------+ | | | | | | | | | | | STORAGE NODE | | STORAGE NODE | | STORAGE NODE | | | | -WWUI 1 | | -WWUI 2 | | -WWUI 3 | | | | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| | | | -Type: target | | -Type: target | | -Type: target | | | | | | | | | | | +-----------------+ +-----------------+ +-----------------+ | | | | NETWORK ENTITY | | -Entity ID (FQDN): "dev1.foo.com" | | -Type: 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 21 iSNS March 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 * Register DD RegDD 0x0009 * * Deregister DD DeregDD 0x000A * * Register Dev in DD RegDevDD 0x000B * * Deregister Dev in DD DeregDevDD 0x000C * * Entity Status Inquiry ESI 0x000D * Name Service Heartbeat Heartbeat 0x000E NOT USED 0x000F Request Network Time RqstTime 0x0010 NOT USED 0x0011-0x0012 RESERVED 0x0013-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 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 * Register DD Resp RegDDRsp 0x8009 * * Deregister DD Resp DeregDDRsp 0x800A * * Register Dev in DD Resp RegDevDDRsp 0x800B * * Deregister Dev in DD Resp DeregDevDDRsp 0x800C * * Entity Stat Inquiry Resp ESIRsp 0x800D * NOT USED 0x800E-0x800F Request Net Time Resp RqstTimeRsp 0x8010 NOT USED 0x8011-0x8012 RESERVED 0x8013-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 22 iSNS March 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 Type * * Management IP Address ESI Interval * * Timestamp * Entity Certificate * SCN Event Bitmap * ESI TCP/UDP Port * * PORTAL IP Address * * TCP/UDP Port * * Portal Symbolic Name * STORAGE NODE Node Name * * Node Type * * Alias/Node Symbolic Name * FC Node IP Address * FC Node IPA * Node Certificate * DISCOVERY DOMAIN DD_ID * * DD_Symbolic Name * DD Member (Entity ID) * DD_Member (IP Address) * DD Member (WWPN) * * DD Member (WWNN) * STORAGE PORT 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 * 5.2.2 Attribute Descriptions for iFCP Gateways and FC devices The iSNS attributes used to represent iFCP Storage Systems are shown and described in the following figure: Gibbons, Tseng, Monia Standards Track 23 iSNS March 2001 - 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 Type | Indicates this is an iFCP registration - Management IP-Address | If it is not registered then in-band management | is assumed. - Entity Status Inquiry Interval | 0 if no status inquiry is used - Timestamp | Last registration update. Maintained by the iSNS. - Entity Certificate | X.509 certificate bound to the Entity (FQDN) - SCN Event Bitmap | Indicates current SCN state - ESI TCP/UDP Port | Destination port number for ESI messages | - PORTAL (1 - n per ENTITY) | | | - IP-Address | - TCP/UDP Port | | The IP-Address and Port combined uniquely | | define a portal. | - Portal Symbolic Name | - NODE (1 - m per ENTITY) | - Node Name (WWNN) - Node Type (initiator / target / ...) - Alias/Node Symbolic Name - FC Node IP-Address - FC Node IPA - Node Certificate | - PORT (1 - k per 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 Descriptor Gibbons, Tseng, Monia Standards Track 24 iSNS March 2001 - FC FC-4 Features 5.2.3 iFCP Attribute Requirements 5.2.3.1 Port_ID Port_ID assignments for each STORAGE PORT object within a single NETWORK ENTITY SHALL be unique. For each NETWORK ENTITY (i.e., iFCP gateway), no more than one STORAGE PORT 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 the attributes of the Fibre Channel devices themselves, attributes of the iFCP gateway, as well as 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 the two Fibre Channel devices behind it. The NETWORK ENTITY object represents the iFCP gateway itself, while each of the STORAGE NODE objects represents an actual Fibre Channel device. One of the target devices has two ports, each represented by a STORAGE PORT object. Gibbons, Tseng, Monia Standards Track 25 iSNS March 2001 +---------------------------------------------------------------+ | IP Network | +-------------------+-----------------------+-------------------+ | | | | +------------+------+------+---------+------+------+------------+ | | PORTAL | | PORTAL | | | | -IP Addr 1 | | -IP Addr 2 | | | | -TCP Port 1 | | -TCP Port 2 | | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | +---------------+ +---------------------+ +---------------+ | | | Fibre Channel Loop or Fabric | | | +-------+ +-----------------+ +----------------+ +--------+ | | | | | | | | | | +-+-----+ +-----+-+ +--+----+ +------+---+-----+ +-----+--+ | | | |STORAGE PORT | | | |STORAGE PORT | |STORAGE PORT | | | | | | -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 | | | | | +-------------+ | | +-------------+ +-------------+ | | | | | | | | | | STORAGE NODE | | STORAGE NODE | | | | -WWNN 1 | | -WWNN 2 | | | | -Symbolic Name| | -Symbolic Name | | | | -FC Node IPA | | -FC Node IPA | | | | -Type: target | | -Type: target | | | | | | | | | +-----------------+ +-------------------------------------+ | | | | NETWORK ENTITY | | -Entity ID (FQDN): "gtwy1.foo.com" | | -Type: iFCP | | | +---------------------------------------------------------------+ 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 26 iSNS March 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 * Register DD RegDD 0x0009 * * Deregister DD DeregDD 0x000A * * Register Dev in DD RegDevDD 0x000B * * Deregister Dev in DD DeregDevDD 0x000C * * Entity Status Inquiry ESI 0x000D * Name Service Heartbeat Heartbeat 0x000E * Reserved Reserved 0x000F Request Network Time RqstTime 0x0010 Request Domain ID RqstDmnId 0x0011 Release Domain ID RlseDmnId 0x0012 Get Domain IDs GetDmnIds 0x0013 RESERVED 0x0014-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 * Register DD Resp RegDDRsp 0x8009 * * Deregister DD Resp DeregDDRsp 0x800A * * Register Dev in DD Resp RegDevDDRsp 0x800B * * Deregister Dev in DD Resp DeregDevDDRsp 0x800C * * Entity Stat Inquiry Resp ESIRsp 0x800D * NOT USED 0x800E-0x800F Request Net Time Resp RqstTimeRsp 0x8010 Request Domain ID Resp RqstDmnIdRsp 0x8011 Release Domain ID Resp RlseDmnIdRsp 0x8012 Get Domain IDs GetDmnIds 0x0013 RESERVED 0x8014-0xFFFF 5.3 FCIP Requirements Use of iSNS in support of FCIP is OPTIONAL. iSNS MAY be used to provide dynamic tunnel endpoint discovery. iSNS MAY also be used Gibbons, Tseng, Monia Standards Track 27 iSNS March 2001 to allocate DOMAIN_ID addresses, in an FCIP/Fibre Channel fabric implementation with multiple Autonomous Regions. 5.3.1 Required Attributes for Support of FCIP The following lists attributes used in support of FCIP. Attributes indicated in the REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server. Attributes indicated in the REQUIRED TO USE column MUST be supported by an FCIP gateway that elects to use the iSNS for dynamic tunnel endpoint discovery. REQUIRED REQUIRED Object Attribute to Implement to Use ------ --------- ------------ -------- NETWORK ENTITY Entity Identifier * * Entity Type * * Management IP Address ESI Interval * * Timestamp * Entity Certificate * SCN Event Bitmap * ESI TCP/UDP Port * PORTAL IP Address * * TCP/UDP Port * * Portal Symbolic Name * 5.3.2 Attribute Descriptions for FCIP Gateways The iSNS attributes used to represent FCIP gateways are shown and described in the following figure: - FCIP 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 Type | Indicates this is an FCIP registration - Mgt IP-Address | If it is not registered then in-band management | is assumed. - Entity Status Inquiry Interval | 0 if no status inquiry is used - Timestamp | Last registration update / status inquiry received - Entity Certificate | X.509 certificate bound to the Entity (FQDN) - SCN Event Bitmap | Indicates current SCN state - ESI TCP/UDP Port Gibbons, Tseng, Monia Standards Track 28 iSNS March 2001 | Destination port number for ESI messages - PORTAL (1 - n per ENTITY) | - Index - IP-Address - TCP/UDP Port | The IP-Addr and Port combined uniquely | define a portal. - Portal Symbolic Name 5.3.3 Example FCIP Object Model Diagram The following diagram depicts FCIP gateways stored in the iSNS. In FCIP, the iSNS is only used for tunnel endpoint discovery. Therefore, no information about the storage end nodes are registered in the iSNS, and the STORAGE PORT and STORAGE NODE objects are not applicable. +----------------------------------------------------------------+ | IP Network | +-------------+-------------------------+----------------+-------+ | | | | | | +-----+-------+------+----+ +-+------+------+--+------+-----+-+ | | PORTAL | | | | PORTAL | | PORTAL | | | | -IP Addr 1 | | | | -IP Addr 2 | | -IP Addr 3 | | | | -TCP Port 1 | | | | -TCP Port 2 | | -TCP Port 3| | | +--------------+ | | +-------------+ +------------+ | | | | | | NETWORK ENTITY | | NETWORK ENTITY | | -Entity ID (FQDN): | | -Entity ID (FQDN): | | "Tunnelgtwy1.foo.com" | | "Tunnelgtwy2.bar.com" | | -Type: FCIP | | -Type: FCIP | +-------------------------+ +---------------------------------+ 5.3.4 Required Commands and Response Messages for Support of FCIP The following tables display iSNS messages and responses that are used to support FCIP. Messages indicated in the REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server used to support FCIP. Messages indicated in the REQUIRED TO USE column MUST be supported by the FCIP gateway that elects to use the iSNS. Gibbons, Tseng, Monia Standards Track 29 iSNS March 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 * Register DD RegDD 0x0009 * * Deregister DD DeregDD 0x000A * * Register Dev in DD RegDevDD 0x000B * * Deregister Dev in DD DeregDevDD 0x000C * * Entity Status Inquiry ESI 0x000D * Name Service Heartbeat Heartbeat 0x000E * Reserved Reserved 0x000F Request Network Time RqstTime 0x0010 Request Domain ID RqstDmnId 0x0011 Release Domain ID RlseDmnId 0x0012 Get Domain IDs GetDmnIds 0x0013 RESERVED 0x0014-0x8000 The following are iSNSP response messages in support of FCIP: 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 * Register DD Resp RegDDRsp 0x8009 * * Deregister DD Resp DeregDDRsp 0x800A * * Register Dev in DD Resp RegDevDDRsp 0x800B * * Deregister Dev in DD Resp DeregDevDDRsp 0x800C * * Entity Stat Inquiry Resp ESIRsp 0x800D * NOT USED 0x800E-0x800F Request Net Time Resp RqstTimeRsp 0x8010 Request Domain ID Resp RqstDmnIdRsp 0x8011 Release Domain ID Resp RlseDmnIdRsp 0x8012 Get Domain IDs Resp GetDmnIdsRsp 0x8013 RESERVED 0x8014-0xFFFF 5.4 Attribute Descriptions for Discovery Domain Registration Gibbons, Tseng, Monia Standards Track 30 iSNS March 2001 Discovery Domains are a required iSNS attribute for all protocols. The iSNS attributes for Discovery Domain registration are shown in the following figure: DISCOVERY DOMAIN | - DD_ID - DD_Symbolic Name DD_MEMBER | - DD_ID - Entity Identifier, WWUI, WWNN, WWPN, IP-Address or FWWN Members of a Discovery Domain can be defined by registering one of the following storage entity attributes in a Discovery Domain: - Entity Identifier: this places all contained iSCSI or iFCP storage nodes, or FCIP gateways, in the Discovery Domain - WWUI : this places the individual iSCSI storage node in the Discovery Domain - WWNN : this places all associated iFCP ports in the Discovery Domain - WWPN : this places the associated iFCP port in the Discovery Domain - FWWN : this places all iFCP ports attached to the Fabric Port in the Discovery Domain - IP-Address : this places all associated iSCSI storage nodes or FCIP storage entities in the Discovery Domain 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. Discovery Domains are described in Section 3.1.2. 6. iSNS Message Protocol 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). The following describes the format of the iSNSP PDU: Gibbons, Tseng, Monia Standards Track 31 iSNS March 2001 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 6.1 iSNS PDU Header The iSNSP header contains the iSNSP VERSION, FUNCTION ID, PDU LENGTH, FLAGS, TRANSACTIONID, and SEQUENCE ID fields as defined below: iSNSP VERSION - Currently 0x0001 FUNCTION ID defines the type of iSNS message. It indicates the function the message is supporting. See section 5 under the appropriate protocol (i.e., iSCSI, iFCP, and/or FCIP) for a mapping of the FUNCTION_ID value to the iSNSP Command or Response message. All PDU's comprising an iSNSP message must have the same FUNCTION_IDand TRANSACTION ID value. iSNS PDU LENGTH - Specifies the length of the PDU PAYLOAD field in bytes.The payload contains the data/attribute values for the operation. FLAGS - 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 RegDevAttr) 13 Authentication Block Present 14 Sender is the iSNS server 15 Sender is the iSNS client TRANSACTION ID - Is set to a unique random value for each request message. Replies MUST use the same TRANSACTION ID value as the Gibbons, Tseng, Monia Standards Track 32 iSNS March 2001 associated iSNS request message. If a message is retransmitted, the same TRANSACTION ID value MUST be used. 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. 6.2 iSNS 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. The recipient of the iSNSP message SHALL NOT process the message until it receives The authentication operation described in section 6.4 SHALL be performed on a per-PDU basis. 6.3 iSNS 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 5.5. This field contains the ID of the indicated attribute. Gibbons, Tseng, Monia Standards Track 33 iSNS March 2001 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. For iSNS response messages sent by the iSNS server to the client, a 4-byte ERROR CODE field is included as the first field in the iSNSP PAYLOAD. This field contains 0x00000000 (NO ERROR) if the original iSNSP request message was processed normally by the iSNS server. Error Code Error Description ---------- ----------------- 0 No Error 1 Unknown Error 2 Message Format Error 3 Invalid Registration 4 Invalid Registration Update 4 Invalid Query 5 Authentication Unknown 6 Authentication Absent 7 Authentication Failed 8 No Such Entry 9 Version Not Supported 10 Internal Bus Error 11 Busy Now 12 Option Not Understood 13 Invalid Update 14 Message Not Supported 15 SCN Event Rejected 16 SCN Registration Rejected 17 Entity Status Inquiry (ESI) Not Available 18 DOMAIN_ID not available For iSNS State Change Notification message and Request Network Time Response messages, a 4-byte TIMESTAMP field is included. The TIMESTAMP is a 4-byte unsigned, fixed-point integer giving the number of seconds since 00:00:00 GMT on January 1, 1970. 6.4 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. Gibbons, Tseng, Monia Standards Track 34 iSNS March 2001 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 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 | AUTHENTICATION BLOCK LENGTH | 2 Bytes +----------------------------------+ 2 | BLOCK STRUCTURE DESCRIPTOR | 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 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. 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 Gibbons, Tseng, Monia Standards Track 35 iSNS March 2001 PKI specification, allowing easy integration of the STRUCTURED AUTHENTICATOR format with an existing PKI infrastructure. TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving the number of seconds since 00:00:00 GMT on January 1, 1970. SPI STRING LENGTH - The length of the SPI STRING field. SPI STRING (Security Parameters Index) - Index to the key and algorithm used by the message recipient to decode the STRUCTURED AUTHENTICATOR field. STRUCTURED AUTHENTICATOR - Contains the digital signature. For the default BSD value of 0x0002, this field contains the binary ASN.1 encoding of output values from the DSA with SHA-1 signature calculation. 6.5 iSNS Client Registration Attributes When an iSNS client registers with the iSNS server, it provides attribute values to describe the entity characteristics and capabilities. The attributes are also returned by the iSNS server in response to queries. The following table lists all iSNSP message attributes for device registration and queries: Gibbons, Tseng, Monia Standards Track 36 iSNS March 2001 Attribute Name Length(bytes) Tag Reg Key Query Keys -------------- ------------- --- ------- ---------- Delimiter 0 0 N/A N/A Entity Identifier 0-255 1 N/A 1,3,17,32,34,64 Entity Type 4 2 1 1,3,17,32,34,64 Management IP Address 16 3 1 1,3,17,32,34,64 ESI Interval 4 4 1 1,3,17,32,34,64 ESI TCP/UDP Port 4 5 1 32,1&33,34,64 Timestamp 8 6 1 1,3,17,32,34,64 Entity Event Bitmap 4 7 1 32,1&33,34,64 Entity Certificate variable 8 1 32,1&33,34,64 Portal IP Address 16 16 1 1,32,64 Portal TCP/UDP Port 4 17 1 1,32,64 Portal Symbolic Name 0-255 18 16&17 1,32,64 WWUI 4-255 32 1 1,32,1&33 Node Name (WWNN) 8 33 1 1,34,64 Node Type 4 34 32 or 33 32,1&33,34,64 Alias/Symbolic Node Name 0-255 35 32 or 33 32,1&33,34,64 FC Node IP Address 16 36 33 34,64 FC Node IPA 8 37 33 34,64 Node Certificate variable 38 32 or 33 32,1&33,34,64 Port Name (WWPN) 8 64 33 1,34,66,68,71,72 Port ID 4 65 64 64,17,65 Port Type 4 66 64 64,17&65 Port Symbolic Name 0-255 67 64 64,17&65 Fabric Port Name (FWWN) 8 68 64 64,17&65 FC Hard Address 4 69 64 64,17&65 FC Port IP Address 16 70 64 64,17&65 FC Class of Service 4 71 64 64,17&65 FC FC-4 Types 32 72 64 64,17&65 FC FC-4 Descriptor 0-255 73 64 64,17&65 FC FC-4 Features 128 74 64 64,17&65 User-Specific-Entity 0-65536 128-255 1 --user defined-- User-Specific-Portal 0-65536 256-383 16&17 --user defined-- User-Spec-iSCSI-Node 0-65536 384-511 32 --user defined-- User-Spec-iFCP-Node 0-65536 512-639 33 --user defined-- User-Spec-iFCP-Port 0-65536 640-767 64 --user defined-- RESERVED 768-895 Vendor-Specific-DD 0-65536 896-1023 101 --vendor defined-- Vendor-Specific-DD 0-65536 896-1023 101 --vendor defined-- Vendor-Specific 0-65536 1024-2047 --vendor defined-- RESERVED 2048-65535 The following is a description of the columns used in the above table: Size - indicates the attribute length. Variable-length identifiers are NULL character terminated, which is included in the length. Tag - the value used to identify the attribute. All undefined tag values are reserved. Gibbons, Tseng, Monia Standards Track 37 iSNS March 2001 Reg Key - indicates the attribute ID(s) that is (are) the unique key used for attribute registration. This attribute is also known as the primary key for the iSNS directory database entry. Query Keys - indicates the attribute IDs that can be used to query the iSNS directory database. iSNS client attributes are defined below. 6.5.1 Entity Identifier-Keyed Attributes The following attributes are registered in the iSNS using the Entity Identifier attribute as the key. 6.5.1.1 Entity Identifier (DNS Name) The Entity Identifier is a variable length identifier that uniquely identifies an entity registered in the iSNS. The attribute length varies from 1 to 255 bytes, and is a unique value within the iSNS. By convention the Entity Identifier is the DNS Name used by the entity. The Entity Identifier along with the Alias can be used to uniquely identify and address any associated STORAGE NODE. If the iSNS client does not provide an Entity Identifier during registration, the iSNS shall generate one that is unique within the iSNS. 6.5.1.2 Entity Type Entity Type is a 2-byte field that indicates the type 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 3 FCIP All Others RESERVED 6.5.1.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.5.1.4 Entity Status Inquiry Interval Gibbons, Tseng, Monia Standards Track 38 iSNS March 2001 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 a client. ESI messages can be used to verify that a client registration continues to be valid. To request monitoring by the iSNS, an iSNS client registers a non-zero value for this attribute using a RegDevAttr message. If the value is 0 then entity status messages SHALL not be sent. If the iSNS is unable to issue ESI messages, it SHALL reject the ESI request by returning a "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. If the registration is part of a multi-attribute RegDevAttr message and the registration is rejected with _ESI Not Available_, then the multi-attribute registration SHALL be resent with a ESI value of 0. 6.5.1.5 ESI TCP/UDP Port This is the TCP or UDP Port Number of the iSNS client entity uses to receive ESI messages from the iSNS server and transmit ESI responses. 6.5.1.6 Entity Registration Timestamp Indicates the time the client registration occurred, or the most recent response from the iSNS client to the Client Status Inquiry message, whichever is later. It is the time, in milliseconds, after the standard base time of 00:00:00 GMT on January 1, 1970, that the update occurred. The timestamp can be used to ensure the SNS directory does not contain entries for non-existent devices. An implementation may decide to remove stale registrations of iSNS clients that exceed an implementation-specific threshhold age limit. 6.5.1.7 Entity Event Bitmap This optional field is provided by the iSNS client. It indicates the events that the client 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 DEVICE REGISTRATION PARAMETERS 3 DEVICE ADDED 4 DEVICE REMOVED 5 CLIENT STATUS UPDATE REQUESTED (for CSI message) 6.5.1.8 Entity Certificate Gibbons, Tseng, Monia Standards Track 39 iSNS March 2001 This optional attribute contains an X.509 certificate that is bound to the NETWORK ENTITY of the iSNS client. For example, in FCIP this X.509 certificate may have the Fully Qualified Domain Name of the FCIP gateway device. 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. 6.5.2 Portal-Keyed Attributes The following attributes are registered in the iSNS using the combined Portal IP-Address and Portal TCP/UDP Port as the key. Each set of Portal-Keyed attributes is also associated with one Entity Identifier object key. Although the combined Portal IP-Address and Portal TCP/UDP Port key is associated with one Entity Identifier, it is unique across the entire iSNS. 6.5.2.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 Network Entity Portal. 6.5.2.2 Portal TCP/UDP Port The TCP/UDP port of the PORTAL through which a STORAGE NODE can transmit and receive storage data. This required field is provided by the iSNS client. If the value is 0, then the port number is the implied canonical port number of the protocol being used. The Portal IP Address along with the Portal TCP/UDP Port number uniquely identifies a Network Entity Portal. 6.5.2.3 Portal Symbolic Name This is an optional, variable-length text-based value from 0 to 255 bytes. The text field contains user-readable ASCII 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.5.3 Node-Keyed Attributes The following attributes are registered in the iSNS using the WWUI (for iSCSI) or WWNN (for iFCP) attribute as the key. Each set of Node-Keyed attributes is also associated with one Entity Identifier object key. Gibbons, Tseng, Monia Standards Track 40 iSNS March 2001 Although the WWUI (for iSCSI) or WWNN (for iFCP) key is associated with one Entity Identifier, it is unique across the entire iSNS. 6.5.3.1 World Wide Unique Identifier (WWUI) This identifier uniquely defines an iSCSI STORAGE NODE. This field is required for iSCSI STORAGE NODEs, and is provided by the iSNS client. 6.5.3.2 Alias/Symbolic Node Name This is an optional, variable-length text-based value from 0 to 255 bytes. The text field contains user-readable ASCII text, and is terminated with at least one NULL character. The Alias is a user- readable description of the node entry in the iSNS. The Node Symbolic Name is available for use by both Fibre Channel and iSCSI clients. 6.4.3.3 Node Name (WWNN) Node Name is a 64-bit identifier that uniquely identifies the iFCP device node in the network, and is provided by a Fibre Channel- based iSNS client entity. 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.3.4 Node Type This 16-bit field is a bitmap indicating the type of STORAGE NODE. The fields are defined as below. An enabled bit indicates the node has the corresponding characteristics. Bit Field Node Type --------- --------- 0 (Lsb) Target 1 Initiator All Others RESERVED This field will be consistent with the FC-4 Feature bits described in [FC-GS-3] if the node represents a Fibre Channel device. The default value for this field is 0x0000, which is "unknown". 6.5.3.5 FC Node 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.5.3.5 FC Node IPA Gibbons, Tseng, Monia Standards Track 41 iSNS March 2001 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.5.3.6 Node Certificate This optional attribute contains an X.509 certificate that is bound to the STORAGE NODE of the iSNS client. For example, in iSCSI this X.509 certificate may have the WWUI 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.4 Storage Port-Keyed Attributes The following attributes are registered in the iSNS using the Port Name (WWPN) attribute as the key. Each set of Port-Keyed attributes is also associated with one Node-Keyed object. Although the Port Name (WWPN) key is associated with one Node-Keyed object, it is unique across the entire iSNS. 6.5.4.1 Port Name (WWPN) This 64-bit identifier uniquely defines the iFCP device port, and is provided by a Fibre Channel-based iSNS client entity. 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.4.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.4.3 Port Type Indicates the type of iFCP device port. This is provided by the iSNS client entity. Encoded values for this field are listed in the following table: Gibbons, Tseng, Monia Standards Track 42 iSNS March 2001 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.4 Port Symbolic Name A variable-length text-based description of up to 255 bytes, that is associated with the iSNS-registered device port in the network. The text field contains user-readable ASCII 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.5.4.5 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.4.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.4.7 FC Port IP Address The IP address associated with the device port in the network. 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.4.8 FC Class of Service (COS) Gibbons, Tseng, Monia Standards Track 43 iSNS March 2001 This 32-bit bit-map field indicates the FC COS types that are supported by the registered port. This field is provided by the 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.4.9 FC FC-4 Types This 32-byte field indicates the FC-4 protocol types supported by the associated port. This required field for iFCP ports is provided by the iSNS client. This field can be used to support Fibre Channel devices. 6.5.4.10 FC FC-4 Descriptor A variable-length text-based description of up to 255 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. 6.5.4.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. 6.5.5 Domain ID This is a 4-byte field, with a valid value range of 1 _ 239. This optional field is for iFCP Transparent Mode. When in iFCP Transparent Mode, the Request Domain ID message SHALL be used by an iFCP gateway to reserve an available Domain ID for use. When a Domain ID is no longer required, it SHALL be released by the iFCP gateway using the Release Domain ID message. The iSNS MAY use the Client Status Inquiry message to determine if an iFCP gateway is still present on the network. 6.6 Discovery Domain Registration Attributes iSNS clients can be placed into areas of control belonging to one or more Discovery Domains. When an iSNS client or Network Management System registers a DD, it provides attribute values to describe the DD characteristics and capabilities. The following table lists the iSNSP DD attributes: Gibbons, Tseng, Monia Standards Track 44 iSNS March 2001 Attribute Name Size(bytes) ID Reg Key Query Key -------------- ----------- -- ------- --------- DD_ID 4 101 101 DD_Symbolic Name 1-64 102 101 101 DD Member (Ent Ident) 0-255 103 101 101 DD_Member (WWUI) 4-255 104 101 101 DD_Member (WWPN) 8 105 101 101 DD_Member (WWNN) 8 106 101 101 DD_Member (FWWN) 8 107 101 101 DD_Member (IP Addr) 16 108 101 101 Vendor-Specific 0-65535 640-767 101 101 DD_ID - 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 DD ID value of 0 is reserved. DD_Symbolic Name - an ASCII, variable-length string that is NULL- terminated. This is an optional user-readable field used to assist a network administrator in tracking the DD function. 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. DD_Member (WWUI) - the Entity Identifier 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 Entity Identifier of the iSNS client being listed. DD_Member (WWUI) - the World Wide Unique Identifier 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 WWUI of the iSNS client being listed. DD_Member (WWPN) - the 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 Port Name (WWPN) of the iSNS client being listed. DD_Member (WWNN) - the Node 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 Node Name (WWNN) of the iSNS client being listed. DD_Member (FWWN) - the Fabric World Wide 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 FWWN of the iSNS client being listed. Gibbons, Tseng, Monia Standards Track 45 iSNS March 2001 DD_Member (IP Addr) - the IP address of an iSNS client that is a member of the DD. The DD may have a list of 0 to n members. This IP address indicates that all storage entities using this IP address are members of the DD. 6.7 Vendor-Specific and User-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.5 and 6.6. 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 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.8 State Change Notification and Client Status Inquiry Flags A State Change Notification (SCN) allows an iSNS client to be notified of changes within a DD, network, or existing device attribute values in the iSNS directory database. An iSNS client registers for SCN's using the SCN Registration Request command. The SCN message is sent to the iSNS client by the iSNS server. The types of changes for which SCNs are sent is based on flags set in the EVENT TYPE FLAGS field. The EVENT TYPE FLAGS field is a 16- bit mask containing flags for different event types. Client Status Inquiry (CSI) allows an iSNS server to verify that an iSNS client entity is still connected to the network. The CSI message is sent to the iSNS client by the server to verify client status. If enabled, the iSNS server will send a CSI to request a Client Status Inquiry Update message from the SCE. The following table displays the flags in the EVENT TYPE FLAGS field used in SCNReg, SCN and CSI messages: Bit Field Flag Description --------- ---------------- 0 CHANGE IN DD MEMBERSHIP 1 CHANGE IN NETWORK 2 CHANGE IN DEVICE REGISTRATION PARAMETERS 3 DEVICE ADDED 4 DEVICE REMOVED 5 CLIENT STATUS UPDATE REQUESTED (for CSI message) Gibbons, Tseng, Monia Standards Track 46 iSNS March 2001 CHANGE IN DD MEMBERSHIP - indicates a change has occurred in a DD that the iSNS client is a member of. A client can be a member of multiple DDs. This flag indicates that a change in registration parameters or membership has occured, either an addition or deletion, to a DD that the client is a member of. CHANGE IN NETWORK - indicates a change in the network has occurred. The change may be anywhere in the network of devices. This flag is administratively controlled, and may not be allowed by the iSNS server except for use by an IP address associated with a Network Management Station. CHANGE TO DEVICE REGISTRATION PARAMETERS - indicates a change in a device registration in the network or DDs that the client is a member of. This flag is used in conjunction with CHANGE IN DD MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the change in device registration occurred in a DD or the network. This flag may be administratively enabled/disabled. DEVICE ADDED - indicates a device addition has occurred in the network or DD. This flag is used in conjunction with CHANGE IN DD MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the addition occurred in a DD or the network. DEVICE REMOVED - indicates a device removal has occurred in the network or DD. This flag is used in conjunction with CHANGE IN DD MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the removal occurred in a DD or the network. 7. iSNSP Message Descriptions The iSNSP PDU payload follows the iSNSP PDU header described in section 6.1. The message payload contains a list of attributes, each in TLV format described in section 6.3. 7.1 Registration and Query Messages The iSNSP registration and query message payloads contain a list of attributes, and have the following format: Gibbons, Tseng, Monia Standards Track 47 iSNS March 2001 MSb LSb 31 0 +----------------------------------------+ | Source Attribute | +----------------------------------------+ | Key Attribute[1] | +----------------------------------------+ | 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.1.1 Source Attribute The source attribute is used to identify the iSNS client to the iSNS server. The source attribute is an attribute that uniquely identifies the source of the message. Valid source attribute types are shown below. Valid Source Attributes ----------------------- Entity Identifier WWUI (iSCSI only) Node WWN (iFCP only) Port WWN (iFCP only) The source attribute is used to bind the scope of a query 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. Gibbons, Tseng, Monia Standards Track 48 iSNS March 2001 7.1.1.1 Source Attribute for Initial Registration A length value of 0 in the source attribute TLV is valid for initial client registration when the iSNS is being used to assign a unique Entity Identifier to the client. In this case, since the Entity Identifier will not yet have been assigned, the source attribute field will contain a 0 length Entity Identifier. The response message to the registration will contain the assigned identifier. 7.1.2 Key Attribute 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. Following the set of Key Attributes is a Delimiter Attribute, whose tag value is 0. 7.1.2.1 Key Attribute for Initial Registration A length value of 0 in the key attribute TLV is valid for initial client registration when the iSNS is being used to assign a unique Entity Identifier to the client. In this case, the Entity Identifier will not yet have been assigned. The key attribute field will contain a 0 length Entity Identifier. The response message to the registration will contain the assigned identifier. 7.1.3 Delimiter Attribute The Delimiter Attribute separates the key and operating attributes in a message. 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.1.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. The number of 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.1.4.1 Operating Attributes for Query and Get Next Requests Gibbons, Tseng, Monia Standards Track 49 iSNS March 2001 A length value of 0 in an Operating Attribute TLV is valid for query request and get next messages, where the iSNS will be returning matching attribute values in the response message. In this case the Operating Attributes indicate the desired attributes to be returned in the response and therefore do not require values. The response message will contain valid values for the Operating Attributes if the Key Attributes in the query or get next are matched. 7.1.5 Registration and Query Message Types The following describes each query and message type. 7.1.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 a Source, Key Attribute(s), and list of Operating Attributes to register. All values are in Tag Length Value (TLV) format. The Source attribute of the RegDevAttr message is as defined in Section 7.1.1. For the initial network entity registration the Key Attribute SHALL be the Entity Identifier. A length value of 0 in the key attribute TLV is valid for initial client registration when the iSNS is being used to assign a unique Entity Identifier to the client. The operating attributes are the elements that will be registered and associated with the key attributes. Multiple attributes associated with the one key attribute can be registered in one RegDevAttr. One RegDevAttr message can contain attributes for Entity, Portal, Node, and Port objects if they are contained in the same Entity. When the registration contains attributes for the Entity, Portal, Node or Port objects together, then the appropriate Portal, Node and Port 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. When a registration of a Portal, Node or Port is performed, the appropriate associations between objects will be created in the iSNS. 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 value(s), or be added to existing value(s) of the specified operating attribute. Gibbons, Tseng, Monia Standards Track 50 iSNS March 2001 7.1.5.1.1 Update Flag The Update Flag, contained in the message header FLAGS field, indicates the RegDevAttr message is an update to an existing entry. If the key attributes match an existing object in the iSNS directory database, and the Update bit in the flags field is not set, then the registration will replace the existing registration. The existing object shall be de-registered. A new registration will 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 or add additional attributes in the key entry. Existing associations between objects will be maintained. If the Update bit is set and the registration 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 WWUI attribute associated with another entity, then an error shall be returned. 7.1.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.1.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 WHERE the Key Attribute(s) match the object. The Key Attributes map to a type of object. The DevAttrQry message shall support the following Key Attributes: Gibbons, Tseng, Monia Standards Track 51 iSNS March 2001 Valid Key Attributes for Queries -------------------------------- Entity Identifier Entity Type Node Type Portal IP-Address Portal IP-Address, Portal TCP/UDP Port WWUI (iSCSI only) Node WWN (iFCP only) Port WWN (iFCP only) 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.1.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 Identifiers, IP Addresses, WWUI's, Node Names and Port Names from devices in DDs to which the client has access. The Source attribute of the DevGetNext message is as defined in Section 7.1.1. The source is used to scope the Get Next process to the Discovery Domains that the source attribute is a member of. It is the Entity Identifier, WWUI, Node Name, Port Name, or the IP- Address of the client performing the query. The Key Attribute follows the source attribute in the message payload. The Key Attribute is a Entity Identifier, WWUI, IP Address, Node Name, or Port Name. If the key length value entered is zero, signifying an empty key value field, the first accessible a Entity Identifier, WWUI, IP Address, Node Name, or Port Name instance shall be returned to the client. There are no Delimiter or Operating Attributes in the DevGetNext request message. 7.1.5.4 Deregister Device Request (DeregDev) 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.1.1. Valid Key Attributes are shown below: Gibbons, Tseng, Monia Standards Track 52 iSNS March 2001 Valid Key Attributes for DeregDev --------------------------------- Entity Identifier Portal IP-Address Portal IP-Address, Portal TCP/UDP Port WWUI (iSCSI only) Node WWN (iFCP only) Port WWN (iFCP only) 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. 7.1.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 network entity 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 port is a member of. The SCNReg request message payload contains a Source Attribute, Key Attribute(s), and Operating Attributes. The Source attribute of the SCNReg message is as defined in Section 7.1.1. Valid Key Attributes for an SCNReg are shown below: Valid Key Attributes for SCNReg -------------------------------- Entity Identifier Portal IP-Address Portal IP-Address, Portal TCP/UDP Port WWUI (iSCSI only) Node WWN (iFCP only) Port WWN (iFCP only) The network entities matching the Key Attributes are registered to receive SCNs. The Operating Attributes section contains the Entity Event Bitmap attribute. The bitmap indicates the INTERESTED EVENT TYPE FLAGS that the network entity is registering for. Section 6.8 describes each flag used in the EVENT TYPE FLAGS field. 7.1.5.6 SCN Deregister Request (SCNDereg) Gibbons, Tseng, Monia Standards Track 53 iSNS March 2001 The SCNDereg message type is 0x0006. The SCNDereg message allows an iSNS client to deregister a network entity to receive 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.1.1. Valid Key Attributes for an SCNDereg are shown below: Valid Key Attributes for SCNDereg -------------------------------- Entity Identifier Portal IP-Address Portal IP-Address, Portal TCP/UDP Port WWUI (iSCSI only) Node WWN (iFCP 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.1.5.7 SCN Event (SCNEvent) The SCNEvent message type is 0x0007. The SCNEvent is a special message generated by a network entity for the iSNS. The SCNEvent allows a network entity to request generation of a State Change Notification (SCN) message by the iSNS. The SCN, sent by the iSNS, then notifies other registered network 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 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 the SCNEvent. The format of the SCNEvent message is shown below: MSb LSb 31 0 +----------------------------------------+ | Source Attribute | +----------------------------------------+ | Source Event Bitmap | +----------------------------------------+ The Source Attribute is the object that caused the SCN to be generated. The Source Attribute can be an Entity Identifier, WWUI, Node Name or Port Name. Gibbons, Tseng, Monia Standards Track 54 iSNS March 2001 The Source Event Bitmap indicates the event that caused the SCN to be generated. The Event Bitmap is a 32 bit field, with the following definitions: Bit Field Flag Description --------- ---------------- 0 CHANGE IN DD MEMBERSHIP 1 CHANGE IN NETWORK 2 CHANGE IN DEVICE REGISTRATION PARAMETERS 3 DEVICE ADDED 4 DEVICE REMOVED 5 CLIENT STATUS UPDATE REQUESTED (for CSI message) All Others Reserved 7.1.5.8 State Change Notification (SCN) The SCN message type is 0x0008. The SCN is a special message generated by the iSNS which allows a registered network 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 entity will be notified about are based on the value of the Entity Event Bitmap, as described in Section 6.8. The format of the SCN message is shown below: MSb LSb 31 0 +----------------------------------------+ | Destination Attribute | +----------------------------------------+ | Timestamp | +----------------------------------------+ | Source Attribute[1] | +----------------------------------------+ | Source Event Bitmap[1] | +----------------------------------------+ | Source Attribute [2](if present) | +----------------------------------------+ | Source Event Bitmap [2](if present) | +----------------------------------------+ | Source Attribute [3](if present) | +----------------------------------------+ | Source Event Bitmap [3](if present) | +----------------------------------------+ | . . . | +----------------------------------------+ Gibbons, Tseng, Monia Standards Track 55 iSNS March 2001 The Destination Attribute is the object that is receiving the SCN. The Destination Attribute can be an Entity Identifier, WWUI, Node Name or Port Name. The Timestamp field indicates the time the SCN Event was generated. The timestamp is a 4-byte unsigned, fixed-point integer giving the number of seconds since 00:00:00 GMT on January 1, 1970. The Source Attribute is the object that caused the SCN to be generated. The Source Attribute can be an Entity Identifier, WWUI, Node Name or Port Name. The Source Event Bitmap indicates the event that caused the SCN to be generated. The Event Bitmap is a 32 bit field, with the following definitions: Bit Field Flag Description --------- ---------------- 0 CHANGE IN DD MEMBERSHIP 1 CHANGE IN NETWORK 2 CHANGE IN DEVICE REGISTRATION PARAMETERS 3 DEVICE ADDED 4 DEVICE REMOVED 5 CLIENT STATUS UPDATE REQUESTED (for CSI message) All Others Reserved 7.1.5.9 Register DD (RegDD) The RegDD message type is 0x0009. This message allows an iSNS client to create a new Discovery Domain (DD) or update an existing DD Symbolic Name. Once created, network identities can be added and deleted from the DD. DDs are uniquely defined using DD_IDs. DD registration attributes are described in section 5.5. The RegDD message payload contains the Source Attribute, Key Attributes and Operating Attributes. The Source attribute of the RegDD message is as defined in Section 7.1.1. The Key Attribute for a RegDD message is the DD ID for the domain being added or updated. If the DD ID matches an existing DD, then the DD Symbolic Name will be updated with the value contained in the Operating Attribute payload. If the DD ID does not match an existing DD, then a new DD is registered with the DD ID. The new DD Symbolic Name will be the value contained in the Operating Attribute payload. The Operating Attribute for a RegDD message is the DD_Symbolic Name for the DD. 7.1.5.10 Deregister DD (DeregDD) Gibbons, Tseng, Monia Standards Track 56 iSNS March 2001 The DeregDD message type is 0x000A. This message allows an iSNS client to deregister an existing Discovery Domain (DD). DDs are uniquely defined using DD_IDs. DD registration attributes are described in section 5.5. The DeregDD message payload contains Source Attribute and Key Attributes. The Source attribute of the DeregDD message is as defined in Section 7.1.1. The Key Attribute for a DeregDD message is the DD ID for the domain being removed. If the DD ID matches an existing DD, then the DD will be removed and a success error code returned. If the DD ID does not match an existing DD then the error code _No Such Entry_ will be returned. 7.1.5.11 Register Device in DD (RegDevDD) The RegDevDD message type is 0x000B. This message allows an iSNS client to add network identities to the DD. DD registration attributes are described in section 5.5. The RegDevDD message payload contains the Source Attribute, Key Attribute and Operating Attributes. The Source attribute of the RegDevDD message is as defined in Section 7.1.1. The Key Attribute for a RegDevDD message is the DD ID for the Discovery Domain (DD) to which the network entity will be added. If the DD ID matches an existing DD, then the network entity will be added to the DD. If the DD ID does not match an existing DD then the error code _No Such Entry_ will be returned. The Operating Attribute for a RegDevDD message is the member to be added to the DD. Valid members for a DD are shown in section 4.4. The network identities matching the Key Attributes will be added to the DD. 7.1.5.12 Deregister Device in DD (DeregDevDD) The DeregDevDD message type is 0x000C. This message allows an iSNS client to remove network identities from a DD. DD attributes are described in section 5.5. The DeregDevDD message payload contains the Source Attribute, Key Attribute and Operating Attributes. The Source attribute of the DeregDevDD message is as defined in Section 7.1.1. The Key Attribute for a DeregDevDD message is the DD ID for the Discovery Domain (DD) from which the network entity will be deregistered. If the DD ID matches an existing DD, then the network entity will be removed to the DD. If the DD ID does not match an existing DD then the error code _No Such Entry_ will be returned. The Operating Attributes for a DeregDevDD message are the members to be deregistered from the DD. Valid members for a DD are shown Gibbons, Tseng, Monia Standards Track 57 iSNS March 2001 in section 4.4. The network identities matching the Operating Attributes will be deregistered from the DD indicated in the Key Attribute. If any of the Operating Attributes do not match a network entity in the DD then the error code _No Such Entry_ will be returned. All other matching network entities will be removed. 7.1.5.13 Entity Status Inquiry (ESI) The ESI message type is 0x000D. This message is used to verify that an individual iSNS client is reachable and available. The ESI response message payload contains the destination attribute specifying the Entity Identifier of the iSNS client. If the iSNS client fails to respond to three consecutive ESI messages, then the iSNS shall remove that client from the iSNS database and trigger the appropriate State Change Notifications, if any. 7.1.5.14 Request Network Time (RqstTime) The RqstTime message type is 0x0010. This is a special message that returns the network time as stored in the iSNS. The iSNS uses NTP to obtain and maintain the network time provided in the RqstTime message. There are no Key or Operating attributes in this message. 7.1.5.15 Request Domain ID (RqstDmnId) The RqstDmnId message type is 0x0011. This optional message is used for FCIP and iFCP Transparent Mode to allocate DOMAIN_ID values used to assign 3-byte Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client may be an address assignment authority for an Autonomous Region of a Fibre Channel fabric. In the case of iFCP, the iSNS server becomes the address assignment authority for the entire iFCP fabric. The iSNS server responds to RqstDmnID with the DOMAIN_ID values from the range 1 to 239 that have not been previously allocated to other iSNS clients. If no further unallocated DOMAIN_ID values are available from this range, the iSNS server SHALL respond with the error code 18 "DOMAIN_ID not available". Once a DOMAIN_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 CSI message detects that the iSNS client no longer exists on the network. The iSNS server and client SHALL use TCP to transmit and receive RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages. Gibbons, Tseng, Monia Standards Track 58 iSNS March 2001 7.1.5.16 Release Domain ID (RlseDmnId) The RlseDmnId message type is 0x0012. This optional message is used for FCIP and iFCP Transparent Mode to release DOMAIN_ID values used to assign 3-byte Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client may be an address assignment authority for an Autonomous Region of a Fibre Channel fabric. In the case of iFCP, the iSNS server becomes the address assignment authority for the entire iFCP fabric. Once a DOMAIN_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 CSI message detects that the iSNS client no longer exists on the network. The iSNS server and client SHALL use TCP to transmit and receive RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages. 7.1.5.17 Get Domain IDs (GetDmnIds) The GetDmnIds message type is 0x0013. This optional message is used for FCIP and iFCP Transparent Mode to query for the currently used DOMAIN_ID values used to assign 3-byte Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client may be an address assignment authority for an Autonomous Region of a Fibre Channel fabric. In the case of iFCP, the iSNS server becomes the address assignment authority for the entire iFCP fabric. The GetDmnIds message payload contains Source Attribute and Key Attributes. The Source attribute of the GetDmnIds message is as defined in Section 7.1.1. The Key Attribute for a GetDmnIds message is the Domain, used as a Scope, for the query. The Operating Attribute is the Domain attribute. If the Domain Scope matches a domain, then the utilized Area Codes will be returned in the Operating Attribute. If the Domain used as a key is 0, then all currently used Domain IDs will be returned. If the Domain Scope is non-zero and does not match an existing Domain then the error code _No Such Entry_ will be returned. 7.2 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 59 iSNS March 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.2.1 Error Code The iSNSP response message payloads contain a 4-byte ERROR CODE field. If the operation completed successfully the Error Code field will contain No Error, represented by 0x00000000. The list of valid Error Codes are shown below: Gibbons, Tseng, Monia Standards Track 60 iSNS March 2001 Error Code Error Description ---------- ----------------- 0 No Error 1 Unknown Error 2 Message Format Error 3 Invalid Registration 4 Invalid Registration Update 4 Invalid Query 5 Authentication Unknown 6 Authentication Absent 7 Authentication Failed 8 No Such Entry 9 Version Not Supported 10 Internal Bus Error 11 Busy Now 12 Option Not Understood 13 Invalid Update 14 Message Not Supported 15 SCN Event Rejected 16 SCN Registration Rejected 17 Client Status Inquiry Not Available 18 DOMAIN_ID not available 7.2.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.2.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.2.4 Operating Attributes in Response The Operating Attributes in a response are the results related to the iSNS registration or query operation being performed. 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.2.5 Registration and Query Message Types Gibbons, Tseng, Monia Standards Track 61 iSNS March 2001 The following describes each query and message type. 7.2.5.1 Register Device Attribute Rsp (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 Attribute contains the key used for the Register Device Attribute message. If the RegDevAttr registration message was used to assign a unique Entity Identifier to the network entity, then the key attribute field contains the assigned Entity Identifier. There are no Operating Attributes in the RegDevRsp message. 7.2.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 Attribute field will contain the set of results that match the original DevAttrQry Key Attributes. 7.2.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. The Key Attribute field contains the next key, in lexicographical order, after the Key Attribute used in the DevGetNext message. The Operating Attribute field contains the same attributes as were in the DevGetNext message. The values of the Operating Attributes are the attribute values associated with the key returned. 7.2.5.4 Deregister Device Response (DeregDevRsp) Gibbons, Tseng, Monia Standards Track 62 iSNS March 2001 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.2.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.2.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.2.5.7 SCN Event Response (SCNEventRsp) The SCNEventRsp message type is 0x8007. If the SCNEvent operation completed successfully then the 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.2.5.5 SCN Response (SCNRsp) The SCNRsp message type is 0x8008. If the SCN operation completed successfully then the code of _No Error_ is returned. If an error occurred then the appropriate code will be returned. The SCNRsp message does not contain any key or operating attributes. 7.2.5.9 Register DD Response (RegDDRsp) The RegDDRsp message type is 0x8009. If the RegDD operation completed successfully then the code of _No Error_ is returned. If an error occurred then the appropriate code will be returned. The RegDDRsp message does not contain any key or operating attributes. 7.2.5.10 Deregister DD Response (DeregDDRsp) Gibbons, Tseng, Monia Standards Track 63 iSNS March 2001 The DeregDDRsp message type is 0x800A. If the DeregDD operation completed successfully then the code of _No Error_ is returned. If an error occurred then the appropriate code will be returned. The DeregDDRsp message does not contain any key or operating attributes. 7.2.5.11 Register Device in DD Response (RegDevDDRsp) The RegDevDDRsp message type is 0x800B. If the RegDevDD operation completed successfully then the code of _No Error_ is returned. If an error occurred then the appropriate code will be returned. The DeregDDRsp message does not contain any key or operating attributes. 7.2.5.12 Deregister Device in DD Response (DeregDevDDRsp) The DeregDevDDRsp message type is 0x800C. If the DeregDevDD operation completed successfully then the code of _No Error_ is returned. If an error occurred then the appropriate code will be returned. The DeregDevDDRsp message does not contain any key or operating attributes. 7.2.5.13 Entity Status Inquiry Response (ESIRsp) The ESIRsp message type is 0x800D. This message provides confirmation that the ESI message was received and processed by the iSNS client. The ESIRsp response message payload contains the source attribute of the iSNS client network entity. Upon receiving the ESIRsp from the iSNS client, the iSNS server SHALL update the timestamp attribute for that client. If the ESI operation completed successfully on the iSNS client then the code of _No Error_ is returned. If an error occurred then the appropriate code will be returned. The ESIRsp message does not contain any key or operating attributes. 7.2.5.14 Request Network Time Response (RqstTimeRsp) The RqstTimeRsp message type is 0x8010. The format of the RqstTimeRsp payload is different then other response message payloads, and is shown below: Gibbons, Tseng, Monia Standards Track 64 iSNS March 2001 MSb LSb 31 0 +----------------------------------------+ | 4-byte ERROR CODE | +----------------------------------------+ | 4-byte TIMESTAMP | +----------------------------------------+ The TIMESTAMP is a 4-byte unsigned, fixed-point integer giving the number of seconds since 00:00:00 GMT on January 1, 1970. The Network Time Protocol can be used by the iSNS to generate the timestamp provided. The iSNS TIMESTAMP shall only be considered to be locally significant. 7.2.5.15 Request Domain ID Response (RqstDmnIdRsp) The RqstDmnIdRsp message type is 0x8011. This optional message provides the response for RqstDmnID, and is used for FCIP and iFCP Transparent Mode to allocate DOMAIN_ID values used to assign 3-byte Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client may be an address assignment authority for an Autonomous Region of a Fibre Channel fabric. In the case of iFCP, the iSNS server becomes the address assignment authority for the entire iFCP fabric. The iSNS server responds to RqstDmnID with the DOMAIN_ID values from the range 1 to 239 that have not been previously allocated to other iSNS clients. If no further unallocated DOMAIN_ID values are available from this range, the iSNS server SHALL respond with the error code 18 "DOMAIN_ID not available". Once a DOMAIN_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 CSI message detects that the iSNS client no longer exists on the network. The iSNS server and client SHALL use TCP to transmit and receive RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages. 7.2.5.16 Release Domain ID Response (RlseDmnIdRsp) The RlseDmnIdRsp message type is 0x8012. This optional message provides the response for RlseDmnId, and is used for FCIP and iFCP Transparent Mode to release DOMAIN_ID values used to assign 3-byte Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client may be an address assignment authority for an Autonomous Region of a Fibre Channel fabric. In the case of iFCP, the iSNS server becomes the address assignment authority for the entire iFCP fabric. Once a DOMAIN_ID value is allocated by the iSNS server, it shall not be reused until it has been deallocated by the iSNS client to Gibbons, Tseng, Monia Standards Track 65 iSNS March 2001 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 RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages. 7.2.5.17 Get Domain IDs Response (GetDmnIdsResp) The GetDmnIdsResp message type is 0x8013. This optional message is used for FCIP and iFCP Transparent Mode to return the results of a query for the currently-allocated DOMAIN_ID values used to assign 3-byte Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client may be an address assignment authority for an Autonomous Region of a Fibre Channel fabric. In the case of iFCP, the iSNS server becomes the address assignment authority for the entire iFCP fabric. If the Domain Scope matches a domain, then the utilized Area Codes will be returned in the Operating Attribute. If the Domain used as a key is 0, then all currently used Domain IDs will be returned. If the Domain Scope is non-zero and does not match an existing Domain then the error code _No Such Entry_ will be returned. 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 6.4. 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). However, there will be many instances where confidentiality will not be a requirement. 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 6.4. 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 Gibbons, Tseng, Monia Standards Track 66 iSNS March 2001 [RFC1035] Domain Implementation and Specification [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 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 Gibbons, Tseng, Monia Standards Track 67 iSNS March 2001 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 Jim Hafner IBM Research Almaden Research Center K53-B2 650 Harry Road San Jose, CA 95120-6099 Email: hafner@almaden.ibm.com Phone: 408-927-1892 Howard Hall Pirus Networks 43 Nagog Park Acton, MA 01720 Email: howard@pirus.com Phone: 978-206-9103 Gibbons, Tseng, Monia Standards Track 68 iSNS March 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 69 iSNS March 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 "slaved" to the iSNS. Gibbons, Tseng, Monia Standards Track 70 iSNS March 2001 A.1.1 Simple iSCSI Target Registration In this example, a simple target with a single WWUI 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 | | | | WWUIabcd has been | | RegDevAttr--------->| | previously placed | |Src:(tag=1) NULL | | into DDabcd******/| |Key:(tag=1) NULL | | | |tag=2: "iSCSI" | | | |tag=4: 0 | | | |tag=16: "192.36.4.5" | | | |tag=17: "5001" | | | |tag=32: "WWUIabcd" | | | |tag=34: "target" | | | |tag=35: "disk 1" | | | | |<---RegDevAttrRsp | | | |tag=1: "iSNS:0001"| | | | | | | DevAttrQry--------->| SCN-------->| | |Src:(tag=32) "WWUIabcd" |(or SNMP trap) | | |Key:(tag=2) "iSCSI" |src: "iSNS:0001" | | |Key:(tag=34) "initiator" |dest: "mgmt.foo.com" | |tag=16: NULL |CHANGE IN NETWORK | | |tag=32: NULL | |<-------SCNRsp | |/*Query asks for all iSCSI| | | |devices' IP address, port |<---DevAttrQryRsp | | |number, and WWUI*/ |tag=16:"192.36.4.1" | | |tag=32:"WWUIpdq" |<-----DevAttrQry | | |tag=16:"192.1.3.2"|src: mgmt.foo.com | | |tag=32:"WWUIrst" |key:(tag=1)iSNS:0001 |/*************************| |Op Attr: (tag=16) | |Our target "iSNS:0001" | |Op Attr: (tag=17) | |discovers two initiators | |Op Attr: (tag=32) | |in the same DD. It will | | | |accept iSCSI logins from | | | |these two identified | | | |initiators presented by | | | |iSNS*********************/| DevAttrQryRsp--->| | | |tag=16: 192.36.4.5| | | |tag=17: 5001 | | | |tag=32: WWUIabcd | | +--------------------------+------------------+-------------------+ Gibbons, Tseng, Monia Standards Track 71 iSNS March 2001 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 ********/| |Src:(tag=1)"jbod1.foo.com"| | | |Key:(tag=1)"jbod1.foo.com"| | | |tag=1: "jbod1.foo.com" | | | |tag=2: "iSCSI" | | | |tag=4: 5 seconds | | | |tag=16: "192.36.34.4" | | | |tag=17: "5001" | | | |tag=16: "192.36.53.5" | | | |tag=17: "5001" | | | |tag=32: "WWUIabcd" | | | |tag=35: "Target" |/*****************| | |tag=36: "Volume 1" |jbod1.foo.com is | | |tag=39: X.509 cert blob 1 |now registered in | | |tag=32: "WWUIefgh" |iSNS, but is not | | |tag=35: "Target" |in any DD. Therefore, | |tag=36: "Volume 2" |no other devices | | |tag=39: X.509 cert blob 2 |can "see" it. | | | |*****************/| | | |<--DevAttrRsp | | | | | | | | SCN------> | | | | (or SNMP trap) | | | |src: 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--> | | Gibbons, Tseng, Monia Standards Track 72 iSNS March 2001 | |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:"WWUIabcd" |displays device, | | |tag=32:"WWUIefgh" |the operator decides | | |to place "WWUIabcd"| | | |into Domain "DDxyz"| |/*************************| |******************/| |Target is now registered | | | |in iSNS. It has been placed |<--RegDevDD | |in DDxyz by management | |src:(tag=1) |station. | | "mgmt.foo.com" | |*************************/| |key: "DDxyz" | | | |tag=32: "WWUIabcd" | | | | | | | RegDevRsp---->| | +--------------------------+------------------+-------------------+ Gibbons, Tseng, Monia Standards Track 73 iSNS March 2001 A.1.3 Initiator Registration and Target Discovery The following example illustrates a new initiator registering with the iSNS, and discovering the target WWUIabcd from the example in A.1.1. +--------------------------+------------------+-------------------+ | 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 ********/| |Src:(tag=1)"svr1.foo.com" | | | |Key:(tag=1)"svr1.foo.com" | | | |tag=1: "svr1.foo.com" | | | |tag=2: "iSCSI" | | | |tag=4: 5 seconds |/*****************| | |tag=16: "192.20.3.1" |Device not in any | | |tag=17: "5001" |DD, so it is | | |tag=32: "WWUIijkl" |inaccessible by | | |tag=35: "Initiator" |other devices | | |tag=36: "Server1" |*****************/| | |tag=39: X.509 cert blob 3 | | | | |<--DevAttrRsp | | | | | | | | SCN------> | | | | (or SNMP trap) | | | |src: 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--> | | | |tag=2: "iSCSI" | | | |tag=17:192.20.3.1 | | | |tag=32:"WWUIijkl" | | | | |/**Mgmt Station ***| | | |displays device, | | | |the operator decides | | |to place "WWUIijkl"| | | |into Domain "DDxyz"| | | |with device WWUIabcd | | |******************/| Gibbons, Tseng, Monia Standards Track 74 iSNS March 2001 | | |<--RegDevDD | | | |src: (tag=1) | | | | "mgmt.foo.com" | | | |key: "DDxyz" | | | |tag=32: "WWUIijkl | | | | | | | RegDevRsp--->|/******************| | | |"WWUIijkl" has been| | | |moved to "DDxyz" | | | |******************/| | |<-----SCN | | | |src: "WWUIijkl" | | | |dest: "WWUIijkl" | | | |CHANGE IN DD MEMBERSHIP | | DevAttrQry----------->| | | |src: "WWUIabcd" |/*****************| | |key:(tag=2) "iSCSI" |Note that WWUIabcd| | |key:(tag=35) "Target" |also receives an | | |Op Attr: (tag=16) |SCN that WWUIijkl | | |Op Attr: (tag=17) |is in the same DD | | |Op Attr: (tag=32) |*****************/| | |Op Attr: (tag=36) | | | |Op Attr: (tag=39) |<-----AttrQryRsp | | | |tag=16: 192.36.34.4 | | |tag=17: 5001 | | | |tag=16: 192.36.53.5 | | |tag=17: 5001 | | | |tag=32: WWUIabcd | | | |tag=36: Volume 1 | | | |tag=39: 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 75 iSNS March 2001 Appendix B _ SNMP Management MIB The following SNMP MIB is for iSNS network management. The definition is based on SNMPv2c. This is the first general release of the MIB. iSNS DEFINITIONS ::= BEGIN -- -- iSNS.mib: IETF IPS Internet Storage Name Service (iSNS) management -- v1.0 -- IMPORTS enterprises, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, IpAddress, Counter32 FROM SNMPv2-SMI Gauge FROM RFC1155-SMI OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, DisplayString, DateAndTime, RowStatus, PhysAddress, TimeStamp FROM SNMPv2-TC; FCIDtype ::= OCTET STRING (SIZE (3)) WWNtype ::= OCTET STRING (SIZE (8)) EntIdx ::= INTEGER PortalIdx ::= INTEGER NodeIdx ::= INTEGER EIDtype ::= OCTET STRING NodeType ::= OCTET STRING (SIZE (2)) EntType ::= INTEGER {iSCSI(1), FCIP(2), iFCP(3)} WWUItype ::= OCTET STRING DDIDtype ::= INTEGER TFtype ::= INTEGER {true(1), false(2)} iSNS MODULE-IDENTITY LAST-UPDATED "200103010000Z" ORGANIZATION "IETF IPS iSNS Working Group" CONTACT-INFO " Gibbons, Tseng, Monia Standards Track 76 iSNS March 2001 Attn: Kevin Gibbons / Josh Tseng Nishan Systems 3850 North First Street San Jose, CA 95134 USA Tel : +1 408 519-3700 email : snmp@nishansystems.com " DESCRIPTION "The MIB for internet Storage Name Service (iSNS) Management." ::= {experimental 1} -- -- Internet Storage Name Service Management -- iSnsVersion OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of this iSNS instance. The header of each iSNSP message contains iSNS version information." ::= {iSNS 1} -- -- Discovery Domain Membership Information -------------------- -- iSnsDdMmbrs OBJECT IDENTIFIER ::= {iSNS 2} -- -- Naming Service's Discovery Domain Information -------------- -- iSnsNumDomains OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of Discovery Domain entries in the iSNS." ::= {iSnsDdMmbrs 1} iSnsNewDomainMemberStatus OBJECT-TYPE SYNTAX INTEGER {inNoDomain(0), inDefaultDomain(1)} MAX-ACCESS read-write STATUS current DESCRIPTION "The Domain Status for a new device when added to the network. Either the new device will not be in a domain, or go into a default domain. The default domain is by convention DD ID 1." Gibbons, Tseng, Monia Standards Track 77 iSNS March 2001 ::= {iSnsDdMmbrs 2} iSnsDDTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsDDtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing configuration information for each Discovery Domain (DD) configured in the network managed by the iSNS." ::= {iSnsDdMmbrs 3} iSnsDDtInfoEntry OBJECT-TYPE SYNTAX iSnsDDtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration information for each Discovery Domain (DD) configured in the network." INDEX {iSnsDDtId} ::= {iSnsDDTable 1} iSnsDDtInfoEntry ::= SEQUENCE { iSnsDDtId DDIDtype, iSnsDDtSymbolicName OCTET STRING, iSnsDDtRowStatus RowStatus } iSnsDDtId OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-write STATUS current DESCRIPTION "The ID that refers to this Discovery Domain." ::= {iSnsDDtInfoEntry 1} iSnsDDtSymbolicName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 .. 64)) MAX-ACCESS read-write STATUS current DESCRIPTION "The Discovery Domain Symbolic Name field contains a variable length description (from 0 to 64) that is associated with the DD. If the DD Sym Name is not registered, then the length of this field is set to zero bytes." ::= {iSnsDDtInfoEntry 2} iSnsDDtRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current Gibbons, Tseng, Monia Standards Track 78 iSNS March 2001 DESCRIPTION "This object indicates the status of this entry. active (1), read-write notInService (2), read-write notReady (3), read-only createAndGo (4), write-only createAndWait (5), write-only destroy (6), write-only" ::= {iSnsDDtInfoEntry 3} -- -- DD Entity Membership Assignment -- iSnsDDMemberEntityTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsDDEIDtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Entity Identifiers that have been assigned to specific DDs." ::= {iSnsDdMmbrs 4} iSnsDDEIDtInfoEntry OBJECT-TYPE SYNTAX iSnsDDEIDtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "DD membership information for Entity Identifiers." INDEX {iSnsDDEIDtId} ::= {iSnsDDMemberEntityTable 1} iSnsDDEIDtInfoEntry ::= SEQUENCE { iSnsDDEIDtId INTEGER, iSnsDDEIDtEID EIDtype, iSnsDDEIDtRowStatus RowStatus } iSnsDDEIDtId OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-write STATUS current DESCRIPTION "The ID that refers to the Discovery Domain that the entity is a member of." ::= {iSnsDDEIDtInfoEntry 1} iSnsDDEIDtEID OBJECT-TYPE SYNTAX EIDtype MAX-ACCESS read-write STATUS current DESCRIPTION Gibbons, Tseng, Monia Standards Track 79 iSNS March 2001 "The Enity ID of the entity that is a member of the DD." ::= {iSnsDDEIDtInfoEntry 2} iSnsDDEIDtRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the status of this entry. active (1), read-write notInService (2), read-write notReady (3), read-only createAndGo (4), write-only createAndWait (5), write-only destroy (6), write-only" ::= {iSnsDDEIDtInfoEntry 3} -- -- DD Portal Membership Assignment -- iSnsDDMemberPortalIPAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsDDPIPtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Portal IP Addreses that have been assigned to specific DDs." ::= {iSnsDdMmbrs 5} iSnsDDPIPtInfoEntry OBJECT-TYPE SYNTAX iSnsDDPIPtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "DD membership information for Portal IP Addresses." INDEX {iSnsDDPIPtId} ::= {iSnsDDMemberPortalIPAddrTable 1} iSnsDDPIPtInfoEntry ::= SEQUENCE { iSnsDDPIPtId INTEGER, iSnsDDPIPtPIPA IpAddress, iSnsDDPIPtRowStatus RowStatus } iSnsDDPIPtId OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-write STATUS current DESCRIPTION "The ID that refers to the Discovery Domain that the portal is a member of." Gibbons, Tseng, Monia Standards Track 80 iSNS March 2001 ::= {iSnsDDPIPtInfoEntry 1} iSnsDDPIPtPIPA OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The Portal IP Address of the entity that is a member of the DD." ::= {iSnsDDPIPtInfoEntry 2} iSnsDDPIPtRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the status of this entry. active (1), read-write notInService (2), read-write notReady (3), read-only createAndGo (4), write-only createAndWait (5), write-only destroy (6), write-only" ::= {iSnsDDPIPtInfoEntry 3} -- -- DD Node Membership Assignment -- -- By WWUI iSnsDDMemberNodeWWUITable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsDDNWWUItInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Node WWUIs that have been assigned to specific DDs." ::= {iSnsDdMmbrs 6} iSnsDDNWWUItInfoEntry OBJECT-TYPE SYNTAX iSnsDDNWWUItInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "DD membership information for Node WWUIs." INDEX {iSnsDDNWWUItId} ::= {iSnsDDMemberNodeWWUITable 1} iSnsDDNWWUItInfoEntry ::= SEQUENCE { iSnsDDNWWUItId INTEGER, iSnsDDNWWUItWWUI WWUItype, iSnsDDNWWUItRowStatus RowStatus } Gibbons, Tseng, Monia Standards Track 81 iSNS March 2001 iSnsDDNWWUItId OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-write STATUS current DESCRIPTION "The ID that refers to the Discovery Domain that the node is a member of." ::= {iSnsDDNWWUItInfoEntry 1} iSnsDDNWWUItWWUI OBJECT-TYPE SYNTAX WWUItype MAX-ACCESS read-write STATUS current DESCRIPTION "The WWUI the node that is a member of the DD." ::= {iSnsDDNWWUItInfoEntry 2} iSnsDDNWWUItRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the status of this entry. active (1), read-write notInService (2), read-write notReady (3), read-only createAndGo (4), write-only createAndWait (5), write-only destroy (6), write-only" ::= {iSnsDDNWWUItInfoEntry 3} -- DD Node Membership By Node Name WWN iSnsDDMemberNodeWWNTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsDDNWWNtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Node WWNs that have been assigned to specific DDs." ::= {iSnsDdMmbrs 7} iSnsDDNWWNtInfoEntry OBJECT-TYPE SYNTAX iSnsDDNWWNtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "DD membership information for Node WWNs." INDEX {iSNSDDNWWNtId} ::= {iSnsDDMemberNodeWWNTable 1} iSnsDDNWWNtInfoEntry ::= Gibbons, Tseng, Monia Standards Track 82 iSNS March 2001 SEQUENCE { iSnsDDNWWNtId INTEGER, iSnsDDNWWNtNodeWWN WWNtype, iSnsDDNWWNtRowStatus RowStatus } iSnsDDNWWNtId OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-write STATUS current DESCRIPTION "The ID that refers to the Discovery Domain that the node is a member of." ::= {iSnsDDNWWNtInfoEntry 1} iSnsDDNWWNtNodeWWN OBJECT-TYPE SYNTAX WWNtype MAX-ACCESS read-write STATUS current DESCRIPTION "The WWN the node that is a member of the DD." ::= {iSnsDDNWWNtInfoEntry 2} iSnsDDNWWNtRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the status of this entry. active (1), read-write notInService (2), read-write notReady (3), read-only createAndGo (4), write-only createAndWait (5), write-only destroy (6), write-only" ::= {iSnsDDNWWNtInfoEntry 3} -- -- DD Port Membership Assignment -- iSnsDDMemberPortWWNTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsDDPWWNtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Port WWNs that have been assigned to specific DDs." ::= {iSnsDdMmbrs 8} iSnsDDPWWNtInfoEntry OBJECT-TYPE SYNTAX iSnsDDPWWNtInfoEntry MAX-ACCESS not-accessible Gibbons, Tseng, Monia Standards Track 83 iSNS March 2001 STATUS current DESCRIPTION "DD membership information for Port WWNs." INDEX {iSnsDDPWWNtId} ::= {iSnsDDMemberPortWWNTable 1} iSnsDDPWWNtInfoEntry ::= SEQUENCE { iSnsDDPWWNtId INTEGER, iSnsDDPWWNtPortWWN WWNtype, iSnsDDPWWNtRowStatus RowStatus } iSnsDDPWWNtId OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-write STATUS current DESCRIPTION "The ID that refers to the Discovery Domain that the port is a member of." ::= {iSnsDDPWWNtInfoEntry 1} iSnsDDPWWNtPortWWN OBJECT-TYPE SYNTAX WWNtype MAX-ACCESS read-write STATUS current DESCRIPTION "The WWN the port that is a member of the DD." ::= {iSnsDDPWWNtInfoEntry 2} iSnsDDPWWNtRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the status of this entry. active (1), read-write notInService (2), read-write notReady (3), read-only createAndGo (4), write-only createAndWait (5), write-only destroy (6), write-only" ::= {iSnsDDPWWNtInfoEntry 3} -- -- iSNS Registered Objects ---------------------------------------- ---------- -- iSnsRegObj OBJECT IDENTIFIER ::= {iSNS 3} -- Gibbons, Tseng, Monia Standards Track 84 iSNS March 2001 -- iSNS Content Information --------------------------------------- ----------- -- -- -- iSNS Registered Entity Information -- iSnsNumEntities OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of Entity entries in the iSNS." ::= {iSnsRegObj 1} -- -- iSNS Registered Entities Table -- iSnsRegEntityTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsREtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the registered entities in the iSNS." ::= {iSnsRegObj 2} iSnsREtInfoEntry OBJECT-TYPE SYNTAX iSnsREtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on registered entities in the iSNS." INDEX {iSnsREtEIdx} ::= {iSnsRegEntityTable 1} iSnsREtInfoEntry ::= SEQUENCE { iSnsREtEIdx EntIdx, iSnsREtEID EIDtype, iSnsREtType EntType, iSnsREtMgtIpAddr IpAddress, iSnsREtESIintvl INTEGER, iSnsREtESIport INTEGER, iSnsREtTimestamp DateAndTime, iSnsREtESCNmap OCTET STRING } iSnsREtEIdx OBJECT-TYPE SYNTAX EntIdx MAX-ACCESS read-only STATUS current Gibbons, Tseng, Monia Standards Track 85 iSNS March 2001 DESCRIPTION "The Entity Index for this entity. The index is derived for mapping between objects." ::= {iSnsREtInfoEntry 1} iSnsREtEID OBJECT-TYPE SYNTAX EIDtype MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Identifier for this entity as defined in the iSNS Specification." ::= {iSnsREtInfoEntry 2} iSnsREtType OBJECT-TYPE SYNTAX EntType MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Type as defined in the iSNS Specification. Type Value Entity Type ---------- ----------- 1 iSCSI 2 iFCP 3 FCIP All Others Reserved " ::= {iSnsREtInfoEntry 3} iSnsREtMgtIpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Management IP address for this entity as defined in the iSNS Specification." ::= {iSnsREtInfoEntry 4} iSnsREtESIintvl OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "ESI interval as defined in the iSNS Specification." ::= {iSnsREtInfoEntry 5} iSnsREtESIport OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "The TCP/UDP port used for ESI updates as defined in the iSNS Specification." Gibbons, Tseng, Monia Standards Track 86 iSNS March 2001 ::= {iSnsREtInfoEntry 6} iSnsREtTimestamp OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The entity registration timestamp as defined in the iSNS Specification." ::= {iSnsREtInfoEntry 7} iSnsREtESCNmap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) MAX-ACCESS read-only STATUS current DESCRIPTION "The entity SCN notification map as defined in the iSNS Specification." ::= {iSnsREtInfoEntry 8} -- -- iSNS Registered Portal Information -- iSnsNumPortals OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of registered Portals in iSNS." ::= {iSnsRegObj 3} -- -- iSNS Registered Portals Table -- iSnsRegPortalTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsRPRTLtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the registered portals in the iSNS." ::= {iSnsRegObj 4} iSnsRPRTLtInfoEntry OBJECT-TYPE SYNTAX iSnsRPRTLtInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on registered entity portals in the iSNS." INDEX {iSnsRPRTLtEIdx, iSnsRPRTLtPrtlIdx} ::= {iSnsRegPortalTable 1} Gibbons, Tseng, Monia Standards Track 87 iSNS March 2001 iSnsRPRTLtInfoEntry ::= SEQUENCE { iSnsRPRTLtEIdx EntIdx, iSnsRPRTLtPrtlIdx PrtlIdx, iSnsRPRTLtEID EIDtype, iSnsRPRTLtIpAddr IpAddress, iSnsRPRTLtPort INTEGER } iSnsRPRTLtEIdx OBJECT-TYPE SYNTAX EntIdx MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Index of the entity associated with this portal. The index is derived for mapping between objects." ::= {iSnsRPRTLtInfoEntry 1} iSnsRPRTLtPrtlIdx OBJECT-TYPE SYNTAX PortalIdx MAX-ACCESS read-only STATUS current DESCRIPTION "The Portal Index for this node. The index is derived for mapping between objects." ::= {iSnsRPRTLtInfoEntry 2} iSnsRPRTLtEID OBJECT-TYPE SYNTAX EIDtype MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Identifier of the entity associated with this portal." ::= {iSnsRPRTLtInfoEntry 3} iSnsRPRTLtIpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address for this portal as defined in the iSNS Specification." ::= {iSnsRPRTLtInfoEntry 4} iSnsRPRTLtPort OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "The TCP/UDP port for this portal as defined in the iSNS Specification." ::= {iSnsRPRTLtInfoEntry 5} Gibbons, Tseng, Monia Standards Track 88 iSNS March 2001 -- -- iSNS Registered Node Information by WWUI, -- iSnsNumWWUINodes OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of Node entries, by WWUI, in the iSNS." ::= {iSnsRegObj 5} -- -- iSNS Registered Node Table by WWUI -- iSnsRegWWUINodeTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsRegWWUINtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the registered Nodes, by WWUI, in the iSNS." ::= {iSnsRegObj 6} iSnsRegWWUINtEntry OBJECT-TYPE SYNTAX iSnsRegWWUINtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on registered entity nodes, by WWUI, in the iSNS." INDEX {iSnsRegWWUINtEIdx, iSnsRegWWUINtNodeIdx} ::= {iSnsRegWWUINodeTable 1} iSnsRegWWUINtEntry ::= SEQUENCE { iSnsRegWWUINtEIdx EntIdx, iSnsRegWWUINtNodeIdx NodeIdx, iSnsRegWWUINtEID EIDtype, iSnsRegWWUINtNodeWWUI WWUItype, iSnsRegWWUINtNodeType NodeType, iSnsRegWWUINtNodeAliasSymb OCTET STRING } iSnsRegWWUINtEIdx OBJECT-TYPE SYNTAX EntIdx MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Index of the Entity associated with this node. The index is derived for mapping between objects." ::= {iSnsRegWWUINtEntry 1} iSnsRegWWUINtNodeIdx OBJECT-TYPE SYNTAX NodeIdx Gibbons, Tseng, Monia Standards Track 89 iSNS March 2001 MAX-ACCESS read-only STATUS current DESCRIPTION "The Node Index for this node. The index is derived for mapping between objects." ::= {iSnsRegWWUINtEntry 2} iSnsRegWWUINtEID OBJECT-TYPE SYNTAX EIDtype MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Identifier of the Entity associated with this node." ::= {iSnsRegWWUINtEntry 3} iSnsRegWWUINtNodeWWUI OBJECT-TYPE SYNTAX WWUItype MAX-ACCESS read-only STATUS current DESCRIPTION "The WWUI for this node as defined in the iSNS Specification." ::= {iSnsRegWWUINtEntry 4} iSnsRegWWUINtNodeType OBJECT-TYPE SYNTAX NodeType MAX-ACCESS read-only STATUS current DESCRIPTION "The Node Type bit-map as defined in the iSNS Specification. Bit Field Node Type --------- --------- 0 (Lsb) Target 1 Initiator All Others RESERVED " ::= {iSnsRegWWUINtEntry 5} iSnsRegWWUINtNodeAliasSymb OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Alias/Symbolic Name of the node as defined in the iSNS Specification. This is a variable-length text-based description of up to 255 bytes." ::= {iSnsRegWWUINtEntry 6} -- -- iSNS Registered Node, by WWN, Information -- iSnsNumWWNNodes OBJECT-TYPE SYNTAX INTEGER Gibbons, Tseng, Monia Standards Track 90 iSNS March 2001 MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of Node entries, by WWN, in the iSNS." ::= {iSnsRegObj 7} -- -- iSNS Registered Node Table by WWN -- iSnsRegWWNNodeTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsRegWWNNtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the registered Nodes, by WWN, in the iSNS." ::= {iSnsRegObj 8} iSnsRegWWNNtEntry OBJECT-TYPE SYNTAX iSnsRegWWNNtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on registered entity nodes, by WWN, in the iSNS." INDEX {iSnsRegWWNNtNodeWwn} ::= {iSnsRegWWNNodeTable 1} iSnsRegWWNNtEntry ::= SEQUENCE { iSnsRegWWNNtNodeWwn WWNtype, iSnsRegWWNNtEIdx EntIdx, iSnsRegWWNNtEID EIDtype, iSnsRegWWNNtNodeType NodeType, iSnsRegWWNNtNodeAliasSymb OCTET STRING, iSnsRegWWNNtFcNodeIpAddress IpAddress, iSnsRegWWNNtFcNodeIPA OCTET STRING } iSnsRegWWNNtNodeWwn OBJECT-TYPE SYNTAX WWNtype MAX-ACCESS read-only STATUS current DESCRIPTION "The Node WorldWideName as defined in the iSNS Specification." ::= {iSnsRegWWNNtEntry 1} iSnsRegWWNNtEIdx OBJECT-TYPE SYNTAX EntIdx MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Index of the Entity associated with this node. The index is derived for mapping between objects." ::= {iSnsRegWWNNtEntry 2} Gibbons, Tseng, Monia Standards Track 91 iSNS March 2001 iSnsRegWWNNtEID OBJECT-TYPE SYNTAX EIDtype MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Identifier of the Entity associated with this node." ::= {iSnsRegWWNNtEntry 3} iSnsRegWWNNtNodeType OBJECT-TYPE SYNTAX NodeType MAX-ACCESS read-only STATUS current DESCRIPTION "The Node Type bit-map as defined in the iSNS Specification. Bit Field Node Type --------- --------- 0 (Lsb) Target 1 Initiator All Others RESERVED " ::= {iSnsRegWWNNtEntry 4} iSnsRegWWNNtNodeAliasSymb OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Alias/Symbolic Name of the node as defined in the iSNS Specification. This is a variable-length text-based description of up to 255 bytes." ::= {iSnsRegWWNNtEntry 5} iSnsRegWWNNtFcNodeIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Node IP address of the node as defined in the iSNS Specification." ::= {iSnsRegWWNNtEntry 6} iSnsRegWWNNtFcNodeIPA OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The object identifies the FC Initial Process Associator of the node for the entry as defined in the iSNS Specification." ::= {iSnsRegWWNNtEntry 7} -- Gibbons, Tseng, Monia Standards Track 92 iSNS March 2001 -- iSNS Registered Port Information -- iSnsNumPorts OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of Port entries in the iSNS. This is only applicable to iFCP entries." ::= {iSnsRegObj 9} -- -- iSNS Port Table -- iSnsRegWWNPortTable OBJECT-TYPE SYNTAX SEQUENCE OF iSnsRegWWNPtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on registered entity ports, by WWN, in the iSNS." ::= {iSnsRegObj 10} iSnsRegWWNPtEntry OBJECT-TYPE SYNTAX iSnsRegWWNPtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on registered entity ports, by WWN, in the iSNS." INDEX {iSnsRegWWNPtPortWwn} ::= {iSnsRegWWNPortTable 1} iSnsRegWWNPtEntry ::= SEQUENCE { iSnsRegWWNPtPortWwn WWNtype, iSnsRegWWNPtPortID FCIDtype, iSnsRegWWNPtPortType INTEGER, iSnsRegWWNPtPortSymb OCTET STRING, iSnsRegWWNPtNodeWwn WWNtype, iSnsRegWWNPtFabricPortWwn WWNtype, iSnsRegWWNPtFcHA FCIDtype, iSnsRegWWNPtFcPortIpAddress IpAddress, iSnsRegWWNPtFcCos INTEGER, iSnsRegWWNPtFcFc4Types OCTET STRING, iSnsRegWWNPtFcFc4Descr OCTET STRING, iSnsRegWWNPtFcFc4Features OCTET STRING } iSnsRegWWNPtPortWwn OBJECT-TYPE SYNTAX WWNtype MAX-ACCESS read-only STATUS current DESCRIPTION Gibbons, Tseng, Monia Standards Track 93 iSNS March 2001 "The Port WWN as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 1} iSnsRegWWNPtPortID OBJECT-TYPE SYNTAX FCIDtype MAX-ACCESS read-only STATUS current DESCRIPTION "The Port ID as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 2} iSnsRegWWNPtPortType OBJECT-TYPE SYNTAX INTEGER { unknown (0), n-port (1), nl-port (2), f-nl-port (3), f-port (129), -- x'81' fl-port (130), -- x'82' e-port (132), -- x'84' b-port (133), -- x'85' mFCP-port (65297), -- x'FF11' iFCP-port (65298), -- x'FF12' unknown-end (65535) } MAX-ACCESS read-only STATUS current DESCRIPTION "The Port Type as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 3} iSnsRegWWNPtPortSymb OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Port Symbolic Name as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 4} iSnsRegWWNPtNodeWwn OBJECT-TYPE SYNTAX WWNtype MAX-ACCESS read-only STATUS current DESCRIPTION "The Node WWN associated with this Port as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 5} iSnsRegWWNPtFabricPortWwn OBJECT-TYPE SYNTAX WWNtype MAX-ACCESS read-only STATUS current DESCRIPTION Gibbons, Tseng, Monia Standards Track 94 iSNS March 2001 "The Fabric Port WWN associated with this Port as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 6} iSnsRegWWNPtFcHA OBJECT-TYPE SYNTAX FCIDtype MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Hard Address as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 7} iSnsRegWWNPtFcPortIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port IP Address as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 8} iSnsRegWWNPtFcCos OBJECT-TYPE SYNTAX INTEGER { -- class-unknown (0), class-F (1), class-1 (2), class-F-1 (3), class-2 (4), class-F-2 (5), class-1-2 (6), class-F-1-2 (7), class-3 (8), class-F-3 (9), class-1-3 (10), class-F-1-3 (11), class-2-3 (12), class-F-2-3 (13), class-1-2-3 (14), class-F-1-2-3 (15) } MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Class of Service as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 9} iSnsRegWWNPtFcFc4Types OBJECT-TYPE SYNTAX OCTET STRING (SIZE (32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC FC-4 Types as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 10} Gibbons, Tseng, Monia Standards Track 95 iSNS March 2001 iSnsRegWWNPtFcFc4Descr OBJECT-TYPE SYNTAX OCTET STRING (SIZE (32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC FC-4 Descriptors as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 11} iSnsRegWWNPtFcFc4Features OBJECT-TYPE SYNTAX OCTET STRING (SIZE (32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC FC-4 Features as defined in the iSNS Specification." ::= {iSnsRegWWNPtEntry 12} END Gibbons, Tseng, Monia Standards Track 96