[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-tseng-ips-isns) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 RFC 4171

   Internet Draft                                      Kevin Gibbons
   <draft-ietf-ips-isns-02.txt>                           Josh Tseng
   Expires October 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

                                                          April 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                          April 2001

   Klein (Sanrad), Larry Lamers (SAN Valley), Jack Harwood (EMC), David
   Black (EMC), David Robinson (Sun), and Marjorie Krueger (HP).

Comments

Comments should be sent to the IPS mailing list (ips@ece.cmu.edu) or to
the authors.

                          Table of Contents

Status of this Memo...................................................1
Acknowledgements......................................................1
Comments..............................................................2
1.       Abstract.....................................................6
2.       Conventions used in this document............................6
3.       iSNS Overview................................................6
3.1      iSNS Architectural Components................................6
3.1.1    iSNS Protocol (iSNSP)........................................6
3.1.2    iSNS Client..................................................6
3.1.3    iSNS Server..................................................7
3.1.4    iSNS Database................................................7
3.2      iSNS Functional Components...................................7
3.2.1    Name Registration Service....................................7
3.2.2    Discovery Domain and Login Control Service...................7
3.2.3    State Change Notification Service............................8
3.3      iSNS and Domain Name System (DNS)............................9
3.4      iSNS and LDAP................................................9
3.5      iSNS Server Discovery.......................................10
3.6      iSNS and NAT................................................10
3.7      Interactions Between iSNS Infrastructures...................11
3.8      Deployment Architecture Diagram.............................13
4.       iSNS Object Model...........................................13
4.1      NETWORK ENTITY Object.......................................14
4.2      PORTAL Object...............................................14
4.3      STORAGE NODE Object (iFCP and iSCSI Only)...................14
4.4      FC DEVICE Object (iFCP Only)................................14
4.5      DISCOVERY DOMAIN Object.....................................14
4.6      DISCOVERY DOMAIN SET Object.................................14
4.7      iSNS Database Model.........................................14
5.       iSNS Implementation Requirements............................15
5.1      iSCSI Requirements..........................................15
5.1.1    Required Attributes for Support of iSCSI....................15
5.1.2    Attribute Descriptions for iSCSI Storage Systems............16
5.1.3    Example iSCSI Object Model Diagrams.........................17
5.1.4    Required Commands and Response Messages for Support of iSCSI19
5.2      iFCP Requirements...........................................20
5.2.1    Required Attributes for Support of iFCP.....................20
5.2.2    Attribute Descriptions for iFCP Gateways and FC devices.....21


Gibbons, Tseng, Monia      Standards Track                          2

iSNS                          April 2001

5.2.3    iFCP Attribute Requirements.................................22
5.2.3.1  Port_ID.....................................................23
5.2.4    Example iFCP Object Model Diagram...........................23
5.2.5    Required Commands and Response Messages for Support of iFCP.24
5.3      FCIP Requirements...........................................25
5.3.1    Required Attributes for Support of FCIP.....................25
5.3.2    Attribute Descriptions for FCIP Gateways....................25
5.3.3    Example FCIP Object Model Diagram...........................26
5.3.4    Required Commands and Response Messages for Support of FCIP.27
5.4      Attribute Descriptions for Discovery Domain Registration....28
6.       iSNS Message Attributes.....................................28
6.1      iSNS Attribute Summary......................................29
6.2      Entity Identifier-Keyed Attributes..........................31
6.2.1.   Entity Identifier (EID).....................................32
6.2.2    Entity Type.................................................32
6.2.3    Management IP Address.......................................32
6.2.4    Entity Registration Timestamp...............................32
6.2.5    Entity Certificate..........................................32
6.3      Portal-Keyed Attributes.....................................33
6.3.1    Portal IP-Address...........................................33
6.3.2    Portal TCP/UDP Port.........................................33
6.3.3    Portal Symbolic Name........................................33
6.3.4    Entity Status Inquiry Interval..............................33
6.3.5    Portal Certificate..........................................34
6.4      iSCSI Node-Keyed Attributes.................................34
6.4.1    iSCSI Name..................................................34
6.4.2    iSCSI Node Type.............................................34
6.4.3    iSCSI Node Alias............................................34
6.4.4    iSCSI Node SCN Bitmap.......................................35
6.4.5    iSCSI Node Certificate......................................35
6.5      iFCP Node-Keyed Attributes..................................35
6.5.1    iFCP Node Port Name (WWPN)..................................35
6.5.2    Port ID.....................................................35
6.5.3    Port Type...................................................35
6.5.4    iFCP Node Port Symbolic Name................................36
6.5.5    iFCP Node Fabric Port Name (FWWN)...........................36
6.5.6    FC Hard Address.............................................36
6.5.7    FC Port IP Address..........................................36
6.5.8    FC Class of Service (COS)...................................37
6.5.9    FC FC-4 Types...............................................37
6.5.10   FC FC-4 Descriptor..........................................37
6.5.11   FC FC-4 Features............................................37
6.5.12   iFCP Node SCN Bitmap........................................37
6.5.13   iFCP Node Certificate.......................................38
6.6      iFCP FC Device Node-Keyed Attributes........................38
6.6.1    iFCP FC Device Node Name (WWNN).............................38
6.6.2    iFCP FC Device Symbolic Name................................38


Gibbons, Tseng, Monia      Standards Track                          3

iSNS                          April 2001

6.6.3    FC Device IP Address........................................38
6.6.4    FC Device IPA...............................................38
6.6.5    FC Device Certificate.......................................39
6.7      Other Attributes............................................39
6.7.1    FC-4 Type Code..............................................39
6.7.2    Preferred ID................................................39
6.7.3    Assigned ID.................................................39
6.7.4    Space_Identifier............................................39
6.8      Discovery Domain Registration Attributes....................39
6.8.1    iSNS Discovery Domain Attribute Summary.....................40
6.8.2    DD Set ID Keyed Attributes..................................40
6.8.2.1  Discovery Domain Set ID (DDS ID)............................40
6.8.2.2  Discovery Domain Set Symbolic Name..........................40
6.8.2.3  Discovery Domain Set Member.................................40
6.8.3    DD ID Keyed Attributes......................................41
6.8.3.1  Discovery Domain ID (DD ID).................................41
6.8.3.2  Discovery Domain Symbolic Name..............................41
6.8.3.3  Discovery Domain FCIP Member................................41
6.8.3.4  Discovery Domain iSCSI Node Member..........................41
6.8.2.5  Discovery Domain iFCP Node Member...........................41
6.9      Vendor-Specific and User-Specific Attributes................41
7.       iSNSP Message Format........................................42
7.1      iSNS PDU Header.............................................42
7.1.1    iSNSP Version...............................................42
7.1.2    iSNSP Function ID...........................................42
7.1.3    iSNSP PDU Length............................................42
7.1.4    iSNSP Flags.................................................42
7.1.5    iSNSP Transaction ID........................................43
7.1.6    iSNSP Sequence ID...........................................43
7.2      iSNS Message Segmentation and Reassembly....................43
7.3      iSNS Message Payload........................................43
7.3.1    Attribute Value 4-Byte Alignment............................44
7.4      iSNSP Response Error Codes..................................44
7.5      Message Authentication......................................45
7.7      Registration and Query Messages.............................46
7.7.1    Source Attribute (Query Only)...............................47
7.7.2    Key Attributes..............................................47
7.7.3    Delimiter Attribute.........................................48
7.7.4    Operating Attributes........................................48
7.7.4.1  Operating Attributes for Query and Get Next Requests........48
7.7.5    Registration and Query Message Types........................48
7.7.5.1  Register Device Attribute Request (RegDevAttr)..............48
7.7.5.1.1 Update Flag................................................49
7.7.5.2  Device Attribute Query Request (DevAttrQry).................50
7.7.5.3  Device Get Next Request (DevGetNext)........................50
7.7.5.4  Deregister Device Request (DeregDev)........................51
7.7.5.5  SCN Register Request (SCNReg)...............................51


Gibbons, Tseng, Monia      Standards Track                          4

iSNS                          April 2001

7.7.5.6  SCN Deregister Request (SCNDereg)...........................52
7.7.5.7  SCN Event (SCNEvent)........................................52
7.7.5.8  State Change Notification (SCN).............................53
7.7.5.9  DD Register (DDReg).........................................54
7.7.5.10 DD Deregister (DDDereg).....................................55
7.7.5.11 DDS Register (DDSReg).......................................55
7.7.5.12 DDS Deregister (DDSDereg)...................................56
7.7.5.13 Entity Status Inquiry (ESI).................................56
7.7.5.14 Name Service Heartbeat (Heartbeat)..........................57
7.7.5.15 Request Network Time (RqstTime).............................57
7.7.5.16 Request Switch ID (RqstSwId)................................57
7.7.5.17 Release Switch ID (RlseSwId)................................58
7.7.5.18 Get Switch IDs (GetSwIds)...................................58
7.8      Response Messages...........................................58
7.8.1    Error Code..................................................59
7.8.2    Key Attributes in Response..................................60
7.8.3    Delimiter Attribute in Response.............................60
7.8.4    Operating Attributes in Response............................60
7.8.5    Registration and Query Message Types........................60
7.8.5.1  Register Device Attribute Rsp (RegDevRsp)...................61
7.8.5.2  Device Attribute Query Response (DevAttrQryRsp).............61
7.8.5.3  Device Get Next Response (DevGetNextRsp)....................61
7.8.5.4  Deregister Device Response (DeregDevRsp)....................61
7.8.5.5  SCN Register Response (SCNRegRsp)...........................62
7.8.5.6  SCN Deregister Response (SCNDeregRsp).......................62
7.8.5.7  SCN Event Response (SCNEventRsp)............................62
7.8.5.8  SCN Response (SCNRsp).......................................62
7.8.5.9  DD Register Response (DDRegRsp).............................62
7.8.5.10 DD Deregister Response (DDDeregRsp).........................62
7.8.5.11 DDS Register Response (DDSRegRsp)...........................63
7.8.5.12 DDS Deregister Response (DDSDeregRsp).......................63
7.8.5.13 Entity Status Inquiry Response (ESIRsp).....................63
7.8.5.14 Request Network Time Response (RqstTimeRsp).................63
7.8.5.15 Request Switch ID Response (RqstSwIdRsp)....................64
7.8.5.16 Release Switch ID Response (RlseSwIdRsp)....................64
7.8.5.17 Get Switch IDs Response (GetSwIdRsp)........................64
8.       Security Considerations.....................................65
8.1      Data Integrity and Authentication...........................65
8.2      Confidentiality.............................................65
8.3      Security Model..............................................65
9.       References..................................................65
10.      Author's Addresses..........................................67
Full Copyright Statement.............................................68
A.1      iSCSI Initialization Example................................69
A.1.1    Simple iSCSI Target Registration............................70
A.1.2    Target Registration and DD Configuration....................71
A.1.3    Initiator Registration and Target Discovery.................72


Gibbons, Tseng, Monia      Standards Track                          5

iSNS                          April 2001


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 objective of iSNS is to facilitate scalable configuration and
   management of IP-based storage networks.  iSNS allows the
   administrator to go beyond a simple device-by-device management
   model, where each storage device is manually and individually
   configured with its own list of known initiators and targets.  Using
   the iSNS, each storage device “slaves” its discovery and management
   responsibilities to the iSNS server.  The iSNS server thereby serves
   as the consolidated management contact through which administrator
   workstations can configure and manage the entire storage network.

   iSNS can be implemented to support iSCSI, 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 Protocol (iSNSP)

   The iSNS Protocol (iSNSP) is a flexible and lightweight protocol
   that specifies how iSNS clients and servers communicate.  It is
   suitable for various platforms, including switches and targets as
   well as server hosts.

3.1.2    iSNS Client


Gibbons, Tseng, Monia      Standards Track                          6

iSNS                          April 2001

   iSNS clients initiate transactions with the iSNS server using the
   iSNSP.  iSNS clients are applications that are co-resident in the
   storage device, and can register device’s attribute information,
   download information about other registered clients in a common DD,
   and receive asynchronous notification of topology events that occur
   in their DD(s). Management stations are a special type of iSNS
   client that have access to all DDs stored in the iSNS.

3.1.3    iSNS Server

   The iSNS server responds to iSNS protocol queries and requests, and
   initiates iSNS protocol State Change Notifications.  Properly
   authenticated information submitted by a registration request is
   stored in an internal or external iSNS database.

3.1.4    iSNS Database

   The iSNS database is the information repository for the iSNS
   server(s).  It maintains information about iSNS client attributes.
   A directory-enabled implementation of iSNS may store client
   attributes in an LDAP directory infrastructure.

3.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 mappings which may exist
   in DNS servers, a common backend database storing such mappings may
   be implemented to support both DNS and iSNS.  This backend database
   can be based upon a standard network directory service such as LDAP.

   The naming registration service also provides the ability to obtain
   a network unique Domain ID for iFCP gateways and Fibre Channel
   Autonomous Regions (AR's), when required.

3.2.2    Discovery Domain and Login Control Service



Gibbons, Tseng, Monia      Standards Track                          7

iSNS                          April 2001

   The Discovery Domain (DD) Service facilitates the partitioning of
   iSNS client devices into more manageable groupings for
   administrative and login control purposes. This allows the
   administrator to limit the login process to the more appropriate
   subset of targets registered in the iSNS.  iSNS clients must be in
   at least one common DD in order to obtain information about each
   other.  iSNS clients can be a member of multiple DD's
   simultaneously.

   The DD information stored in the iSNS can be used by various
   enforcement points in the network to 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 policy
   to the iSNS.  The target node or device downloads the list of
   authorized initiator nodes or devices from the iSNS.  Each node or
   device is uniquely identified by an iSCSI Name, Port Name (iFCP), or
   Fully Qualified Domain Name (FCIP).  Only initiator nodes or devices
   that match the required identification and authenticating
   information provided by the iSNS will be allowed access by that
   target node or device during session establishment.  If spoofing of
   initiator identities is a concern, the target may use the public key
   certificate of the authorized initiator, obtained from the iSNS
   server, to authenticate the initiator.

   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 iSCSI
   Name 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
   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 clients. The iSNS client has the ability to register for

Gibbons, Tseng, Monia      Standards Track                          8

iSNS                          April 2001

   these notifications of events detected by the iSNS.  The types of
   events for which SCNs can be sent include change in Discovery Domain
   (DD) membership and device registration updates.

   The State Change Notification service utilizes the Discovery Domain
   Service to control the distribution of notification messages.
   Notifications about changes within a DD are limited to members of
   that DD.

   If the iSNS is unable to service an SCN registration it SHALL reject
   the SCN registration request, returning a SCN Registration Rejected
   error code.  The rejection might occur in situations where the
   network size, or current level of SCN registrations, has passed an
   implementation-specific threshold.  A client not allowed to register
   for SCNs SHOULD monitor its sessions with other storage devices
   directly.

   The specific notification mechanism by which the iSNS learns of the
   events is implementation-specific, but can include examples such as
   explicit notification messages from an iSNS client to the iSNS
   server, or a hardware interrupt to a switch-hosted iSNS as a result
   of link failure.  The iSNS is equivalent to the Fibre Channel State
   Change Notification service, with extensions, operating within the
   context of an IP network.

3.3      iSNS and Domain Name System (DNS)

   A directory-enabled iSNS implementation may use LDAP to store iSNS
   client attributes.  If this is the case, then LDAP can be used to
   support both the iSNS and DNS server infrastructures, maintaining
   consistency in Domain Name-to-IP address mappings used by DNS and
   iSNS.

   A detailed description of the Domain Name System (DNS) protocol is
   found in [RFC 1035], and is beyond the scope of this document. If a
   common LDAP information base is used to support both DNS and iSNS
   servers, then Domain-Name-to-IP address mappings for storage devices
   can be obtained from either DNS servers or the iSNS.

3.4      iSNS and LDAP

   LDAP is a generic protocol to access directory services through the
   network.  It is a passive service designed to deliver scalable
   directory services using a get/set model.  Applications designed and
   tailored to specific user requirements interact with LDAP for their
   generic directory service needs.  On the other hand, iSNS is an
   application that goes beyond the simple get/set model, and provides
   specific capabilities needed to monitor and manage an enterprise-
   scale storage network.  iSNS is one example of an application that
   can leverage the services of LDAP.  By layering iSNS on top of LDAP,
   the capabilities of both iSNS and LDAP can be leveraged to manage
   and scale the enterprise IP storage network.



Gibbons, Tseng, Monia      Standards Track                          9

iSNS                          April 2001

   The iSNS application provides capabilities that LDAP alone is not
   designed to achieve.  This includes the following:

   1)  Client Attribute Awareness - The iSNS server application
   interprets attribute values submitted by clients in registration
   messages, and can take appropriate action based upon specific
   registered attribute values.  The iSNS server is conscious of the
   state of each client.

   2)  State Change Notification - An iSNS server may initiate
   notification messages to clients in the event of a change in the
   network, such as the non-availability or reachability of a storage
   device, or a specific change in the value of a client attribute.

   3)  Monitoring of Clients - iSNS provides a Entity Status Inquiry
   message to verify the availability and reachability of storage
   devices.

   4)  Lightweight - iSNSP is a simple and lightweight protocol
   suitable for implementation on embedded devices such as switches and
   targets.  There are no unused or "wasted" features that may bog down
   the performance of the host device.

3.5      iSNS Server Discovery

   The Service Location Protocol (SLP) provides a flexible and scalable
   framework for providing hosts with access to information about the
   existence, location, and configuration of networked services,
   including the iSNS server.  SLP MAY be used by iSNS clients to
   discover the IP address of the iSNS server.  To implement discovery
   through SLP, a Service Agent (SA) should be cohosted in the iSNS
   server, and a User Agent (UA) should be in each iSNS client. Each
   client multicasts a discovery message requesting the IP address of
   the iSNS server(s).  The SA responds to this request.  Optionally,
   the location of the iSNS can be stored in the SLP Directory Agent
   (DA).

   Note that a complete description and specification of SLP can be
   found in [RFC2608], and is beyond the scope of this document.
   Additional details on use of SLP to discover iSNS can be found in
   the document draft-bakke-iscsi-slp-00.txt.

   If SLP is not used, then the IP address of the iSNS server can be
   stored in a DHCP server to be downloaded using a DHCP option, such
   as any of the reserved site-specific option codes (from 128 to 255).
   Another approach is to configure each iSNS client to listen to the
   iSNS Name Service Heartbeat message (see section 7.7.5.14).  A final
   approach would be to manually configure the IP address of the iSNS
   server in each iSNS client.

3.6      iSNS and NAT

   The existence of NAT will have an impact upon information retrieved
   from the iSNS.  If the iSNS client exists in a different addressing

Gibbons, Tseng, Monia      Standards Track                         10

iSNS                          April 2001

   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
   information from one iSNS server to another.  Once the record
   transfer of the remote device is completed, it becomes visible and
   accessible to local devices on the local iSNS server.  This allows
   local devices to establish sessions with remote devices (provided
   firewall boundaries can be negotiated).


Gibbons, Tseng, Monia      Standards Track                         11

iSNS                          April 2001

   +-------------------------+           +-------------------------+
   |+------+ iSNSP           |           |           iSNSP +-----+ |
   ||dev A |<----->+------+  |           |  +------+<----->|dev C| |
   |+------+       |      |  |           |  |      |       +-----+ |
   |+------+ iSNSP |local |  |           |  |remote| iSNSP +-----+ |
   ||dev B |<----->| iSNS |  |           |  | iSNS |<----->|dev D| |
   |+------+       |      |  |           |  |      |       +-----+ |
   |........       +--+---+  |   WAN     |  +---+--+               |
   |.dev C'.          |      |   Link    |      |                  |
   |........          |      =============      |                  |
   |                  |      |           |      |                  |
   |               +--+---+  |           |  +---+--+               |
   |               | local|<--- <--- <--- <-|remote|               |
   |               | LDAP |  |  LDAP:    |  | LDAP |               |
   |               +------+  Xfer "dev C"|  +------+               |
   +-------------------------+           +-------------------------+

          Enterprise                           Enterprise
          Network A                            Network B

   In the above diagram, two business partners wish to share storage
   "dev C". Using LDAP, the record for "dev C" can be transfered from
   Network B to Network A.  Once accessible to the local iSNS in
   Network A, local devices A and B can now discover and connect to
   "dev C".

   +-------------------------+           +-------------------------+
   |+------+ iSNSP           |           |           iSNSP +-----+ |
   ||dev A |<----->+------+  |           |  +------+<----->|dev C| |
   |+------+       |      |  |           |  |      |       +-----+ |
   |+------+ iSNSP |local |  |           |  |remote| iSNSP +-----+ |
   ||dev B |<----->| iSNS |  |           |  | iSNS |<----->|dev D| |
   |+------+       |      |  |           |  |      |       +-----+ |
   |........       +------+  |   WAN     |  +---+--+               |
   |.dev C'.          ^      |   Link    |      |                  |
   |........          |      =============      v                  |
   |                  |      |           |      |SNMP              |
   |                  |      |           |      |                  |
   |               +--+----+ |           |      v                  |
   |               | SNMP  |<--- <--- <--- <----                   |
   |               | Mgmt  | |  SNMP: Xfer "dev C"                 |
   |               |Station| |           |                         |
   |               +-------+ |           |                         |
   +-------------------------+           +-------------------------+

          Enterprise                           Enterprise
          Network A                            Network B

   The above diagram illustrates a second example of how iSNS records
   can be shared.  In this case, the iSNS servers are not using LDAP to
   store records.  This method uses an SNMP-based management station to
   manually download the desired record for "dev C", and then directly
   upload it to the local iSNS. Once the record is transfered to the
   local iSNS in Network A, "dev C" becomes visible and accessible

Gibbons, Tseng, Monia      Standards Track                         12

iSNS                          April 2001

   (provided firewall boundaries can be negotiated) to other devices in
   Network A.

   Other methods, including proprietary protocols, can be used to
   transfer device records between independently-administered iSNS
   servers.  Further discussion and explanation of these methodologies
   is beyond the scope of this document.

3.8      Deployment Architecture Diagram

   The following diagram displays examples of where and how iSNS can be
   deployed, and of the various IP-based storage entities that it can
   support.

    +------------+          +-----------+          +-----------+
    |            |   LDAP   | Directory |   LDAP   |   iSNS    |
    | DNS Server |<-------->|  Database |<-------->|  Server   |
    |            |          |           |          |           |
    +------+-----+          +-----+-----+          +-----+-----+
           |                      |                      |
           | DNS                  | LDAP           iSNSP |
           |Queries               |                      |
    +------+----------------------+----------------------+---------+
    |                                                              |
    |                         IP Network                           |
    |                                                              |
    +----+-----------+----------+---------------+-------------+----+
         |           |          |               |             |
         |           |    +-----+-----+  +------+-----+  +----+----+
         |           |    |iSCSI-/    |  |iFCP   /    |  |  FCIP   |
         |           |    | FC  /iSNS |  |Switch/iSNS |  | Gateway |
         |           |    |Gtwy/Server|  |     /Server|  |         |
         |           |    +----+------+  +-+-------+--+  +----+----+
         |           |         |           |       |          |
    +----+----+ +----+---+ +---+----+ +----+-+ +---+----+ +---+----+
    |  iSCSI  | |  iSCSI | | Fibre  | |  FC  | | Fibre  | | Fibre  |
    |Initiator| | Target | |Channel | |Device| |Channel | |Channel |
    +---------+ +--------+ |Network | +------+ |Network | |Network |
                           +--------+          +--------+ +--------+

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.

   This architecture framework provides elements needed to describe
   various storage device objects and attributes that may exist on an
   IP storage network.  Objects defined in this architecture framework
   include SAN, NETWORK ENTITY, PORTAL, STORAGE NODE, STORAGE DEVICE
   DISCOVERY DOMAIN, and DISCOVERY DOMAIN SET.  Each of these objects
   are described in greater detail in the following sections.

Gibbons, Tseng, Monia      Standards Track                         13

iSNS                          April 2001


4.1      NETWORK ENTITY Object

   The NETWORK ENTITY object is a container of STORAGE NODE objects and
   PORTAL objects.  It represents a device or gateway that is
   accessible from the IP network.  All STORAGE NODEs and PORTALs
   contained in a NETWORK ENTITY object operate in a coordinated
   manner.

4.2      PORTAL Object

   The PORTAL object is an IP interface through which access to any
   STORAGE NODE within the NETWORK ENTITY can be obtained.  A NETWORK
   ENTITY must have one or more PORTALs, each of which is usable by
   STORAGE NODEs contained in that NETWORK ENTITY to gain access to, or
   be accessible from, the IP network.

4.3      STORAGE NODE Object (iFCP and iSCSI Only)

   The STORAGE NODE object is the logical endpoint of an iSCSI or iFCP
   connection session. In iFCP, the session endpoint is represented by
   the World Wide Port Name (WWPN).  In iSCSI, the session endpoint is
   represented by the iSCSI Name of the device.

4.4      FC DEVICE Object (iFCP Only)

   The FC DEVICE represents the Fibre Channel end node.  Although
   mostly unused in support of the iFCP storage connection, this object
   contains information that may be useful in the management of the
   Fibre Channel device.

4.5      DISCOVERY DOMAIN Object

   DISCOVERY DOMAINS (DD) are a security and management mechanism used
   to partition storage resources.  Discovery Domains limit the
   discovery process to the administrator-configured subset of relevant
   storage devices, preventing initiators from inappropriately
   attempting login to devices that they shouldn’t have access to.
   When queried, the iSNS server will provide information only for
   storage entities that share at least one common DD.  Initiators will
   not be able to "see" devices with which they do not have at least
   one common DD.

4.6      DISCOVERY DOMAIN SET Object

   The DISCOVERY DOMAIN SET (DDS) is a container object for DD’s.
   DDS’s may contain one or more DD’s.  Similarly, each DD can be a
   member of one or more DDS’s.  DDS’s are a mechanism to store
   coordinated sets of DD mappings in the iSNS.

4.7      iSNS Database Model

   The following shows the the various objects described above and
   their relationship to each other.

Gibbons, Tseng, Monia      Standards Track                         14

iSNS                          April 2001



                    +--------------+    +-----------+
                    |    NETWORK   |1  *|           |
                    |    ENTITY    |----|  PORTAL   |
                    |              |    |           |
                    +--------------+    +-----------+
                            | 1    *\
                            |        \<==For FCIP Only
                            |         \
                            | *       *\
   +-----------+    +--------------+    +-----------+    +-----------+
   |    FC     |1  *|   STORAGE    |*  *| DISCOVERY |*  *| DISCOVERY |
   |  DEVICE   |----|    NODE      |----|  DOMAIN   |----|  DOMAIN   |
   |(iFCP Only)|    |(iFCP & iSCSI)|    |           |    |    SET    |
   +-----------+    +--------------+    +-----------+    +-----------+

                * represents 0 to many possible relationships

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 iSCSI Name and IP address of peer
   devices, without the aid or intervention of iSNS.  iSCSI devices
   also MAY use SLP [RFC 2608] to discover peer iSCSI devices.
   However, for scaling a storage network to a larger number of iSCSI
   devices, use of iSNS is RECOMMENDED.

5.1.1    Required Attributes for Support of iSCSI

   The following attributes are available to support iSCSI.  Attributes
   indicated in the REQUIRED TO IMPLEMENT column MUST be supported by
   an iSNS server used to support iSCSI.  Attributes indicated in the
   REQUIRED TO USE column MUST be supported by an iSCSI device that
   elects to use the iSNS.










Gibbons, Tseng, Monia      Standards Track                         15

iSNS                          April 2001

                                               REQUIRED     REQUIRED
   Object                Attribute           to Implement   to Use
   ------                ---------           ------------   --------
   NETWORK ENTITY     Entity Identifier            *           *
                      Entity Type                  *           *
                      Management IP Address
                      Timestamp                    *
                      Entity Certificate           *

   PORTAL             IP Address                   *           *
                      TCP/UDP Port                 *           *
                      Portal Symbolic Name         *
                      ESI Interval                 *

   STORAGE NODE       iSCSI Name                   *           *
                      Node Type                    *           *
                      Alias/Symbolic Node Name     *
                      Node Certificate             *
                      SCN Event Bitmap             *

   DISCOVERY DOMAIN   DD_ID                        *           *
                      DD_Symbolic Name             *

   DISCOVERY DOMAIN   DDS Identifier               *
   SET                DDS Symbolic Name            *
                      Status                       *

   All iSCSI user-specified and vendor-specified attributes are
   optional to implement and use.

5.1.2    Attribute Descriptions for iSCSI Storage Systems

   The iSNS attributes used to represent iSCSI Storage Systems are
   shown and described in the following diagram:





















Gibbons, Tseng, Monia      Standards Track                         16

iSNS                          April 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.
       - Timestamp
       |    Timestamp of last registration update
       - Entity Certificate
       |    X.509 certificate bound to the Entity (FQDN)
       - PORTAL (1 - n per ENTITY)
       |   |
       |   - IP-Address
       |   - TCP/UDP Port
       |   |    The IP-Addr and Port together uniquely
       |   |    define a portal.
       |   - Entity Status Inquiry interval
       |   |    If 0, no ESI is used to this Portal
       |   - Portal Symbolic Name
       |
       - STORAGE NODE (1 - m per ENTITY)
           |
           - iSCSI Name
           - Node Type (initiator / target / ...)
           - Alias/Symbolic Node Name
           - Node Certificate
           - SCN Event Bitmap
                Indicates current SCN state

5.1.3    Example iSCSI Object Model Diagrams

   The following diagram models how a simple iSCSI-based initiator and
   target is represented using database objects stored in the iSNS.  In
   this implementation, each target and initiator is attached to a
   single PORTAL.  Since the devices shown are iSCSI, the FC DEVICE
   object does not apply.  All required attributes are also shown in
   this diagram:












Gibbons, Tseng, Monia      Standards Track                         17

iSNS                          April 2001

   +----------------------------------------------------------------+
   |                         IP Network                             |
   +------------+--------------------------------------+------------+
                |                                      |
                |                                      |
   +-----+------+------+-----+            +-----+------+------+-----+
   |     | PORTAL      |     |            |     | PORTAL      |     |
   |     | -IP Addr 1  |     |            |     | -IP Addr 2  |     |
   |     | -TCP Port 1 |     |            |     | -TCP Port 2 |     |
   |     +-----+ +-----+     |            |     +-----+ +-----+     |
   |           | |           |            |           | |           |
   |           | |           |            |           | |           |
   |  +--------+ +--------+  |            |   +-------+ +--------+  |
   |  |                   |  |            |   |                  |  |
   |  |  STORAGE NODE     |  |            |   |  STORAGE NODE    |  |
   |  |  -iSCSI Name      |  |            |   |   -iSCSI Name    |  |
   |  |  -Alias: "server1"|  |            |   |   -Alias: "disk1"|  |
   |  |  -Type: initiator |  |            |   |   -Type: target  |  |
   |  |                   |  |            |   |                  |  |
   |  +-------------------+  |            |   +------------------+  |
   |                         |            |                         |
   |    NETWORK ENTITY       |            |    NETWORK ENTITY       |
   |   -Entity ID (FQDN):    |            |   -Entity ID (FQDN):    |
   |    "strg1.foo.com"      |            |    "strg2.bar.com"      |
   |   -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 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                         18

iSNS                          April 2001

   +---------------------------------------------------------------+
   |                         IP Network                            |
   +-------------------+-----------------------+-------------------+
                       |                       |
                       |                       |
   +------------+------+------+---------+------+------+------------+
   |            | PORTAL      |         | PORTAL      |            |
   |            | -IP Addr 1  |         | -IP Addr 2  |            |
   |            | -TCP Port 1 |         | -TCP Port 2 |            |
   |            +-----+ +-----+         +-----+ +-----+            |
   |                  | |                     | |                  |
   |  +---------------+ +---------------------+ +---------------+  |
   |  +-------+ +----------------+ +-------------------+ +------+  |
   |          | |                | |                   | |         |
   |  +-------+ +-------+ +------+ +--------+ +--------+ +------+  |
   |  |                 | |                 | |                 |  |
   |  | STORAGE NODE    | | STORAGE NODE    | | STORAGE NODE    |  |
   |  |  -iSCSI Name 1  | |  -iSCSI Name 2  | |  -iSCSI Name 3  |  |
   |  |  -Alias: "disk1"| |  -Alias: "disk2"| |  -Alias: "disk3"|  |
   |  |  -Type: target  | |  -Type: target  | |  -Type: target  |  |
   |  |                 | |                 | |                 |  |
   |  +-----------------+ +-----------------+ +-----------------+  |
   |                                                               |
   |                         NETWORK ENTITY                        |
   |                    -Entity ID (FQDN): "dev1.foo.com"          |
   |                    -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                         19

iSNS                          April 2001

                                                     REQUIRED TO:
      Message Description    Abbreviation  Func ID  Implement  Use
      -------------------    ------------  -------  ---------  ---
   Register Dev Attr Req     RegDevAttr    0x0001       *       *
   Dev Attr Query Request    DevAttrQry    0x0002       *       *
   Dev Get Next Request      DevGetNext    0x0003       *
   Deregister Dev Request    DeregDev      0x0004       *       *
   SCN Register Request      SCNReg        0x0005       *
   SCN Deregister Request    SCNDereg      0x0006       *
   SCN Event                 SCNEvent      0x0007       *
   State Change Notification SCN           0x0008       *
   DD Register               DDReg         0x0009       *       *
   DD Deregister             DDDereg       0x000A       *       *
   DDS Register              DDSReg        0x000B       *       *
   DDS Deregister            DDSDereg      0x000C       *       *
   Entity Status Inquiry     ESI           0x000D       *
   Name Service Heartbeat    Heartbeat     0x000E
   NOT USED                                0x000F
   Request Network Time      RqstTime      0x0010
   NOT USED                                0x0011-0x0013
   RESERVED                                0x0014-0x8000

   The following are iSNSP response messages used in support of iSCSI:

                                                     REQUIRED TO:
   Response Message Desc     Abbreviation  Func_ID  Implement  Use
   ---------------------     ------------  -------  ---------  ---
   Register Dev Attr Rsp     RegDevRsp     0x8001       *       *
   Dev Attr Query Rsp        DevAttrQryRsp 0x8002       *       *
   Dev Get Next Rsp          DevGetNextRsp 0x8003       *
   Deregister Dev Rsp        DeregDevRsp   0x8004       *       *
   SCN Register Rsp          SCNRegRsp     0x8005       *
   SCN Deregister Rsp        SCNDeregRsp   0x8006       *
   SCN Event Rsp             SCNEventRsp   0x8007       *
   SCN Response              SCNRsp        0x8008       *
   DD Register Rsp           DDRegRsp      0x8009       *       *
   DD Deregister Rsp         DDDeregRsp    0x800A       *       *
   DDS Register Rsp          DDSRegRsp     0x800B       *       *
   DDS Deregister Rsp        DDSDeregRsp   0x800C       *       *
   Entity Stat Inquiry Rsp   ESIRsp        0x800D       *
   NOT USED                                0x800E-0x800F
   Request Net Time Rsp      RqstTimeRsp   0x8010
   NOT USED                                0x8011-0x8013
   RESERVED                                0x8014-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                         20

iSNS                          April 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
                      Timestamp                    *
                      Entity Certificate           *

   PORTAL             IP Address                   *           *
                      TCP/UDP Port                 *           *
                      Portal Symbolic Name         *
                      ESI Interval                 *

   STORAGE NODE       Port Name (WWPN)             *           *
                      Port_ID                      *           *
                      Port Type                    *           *
                      Port Symbolic Name           *
                      FC Fabric Port Name (FWWN)   *
                      FC Hard Address              *
                      FC Port IP Address           *
                      FC Class of Service          *
                      FC FC-4 Types                *
                      FC FC-4 Descriptors          *
                      FC FC-4 Features             *
                      Node Certificate             *
                      SCN Event Bitmap             *

   FC DEVICE          Port Name (WWPN)             *           *
                      Node Type                    *           *
                      Alias/Node Symbolic Name     *
                      FC Node IP Address           *
                      FC Node IPA                  *

   DISCOVERY DOMAIN   DD_ID                        *           *
                      DD_Symbolic Name             *

   DISCOVERY DOMAIN   DDS Identifier               *
   SET                DDS Symbolic Name            *
                      Status                       *

5.2.2    Attribute Descriptions for iFCP Gateways and FC devices

   The iSNS attributes used to represent iFCP Storage Systems are shown
   and described in the following figure:

   - iFCP NETWORK ENTITY
       |

Gibbons, Tseng, Monia      Standards Track                         21

iSNS                          April 2001

       - 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.
       - Timestamp
       |    Last registration update.  Maintained by the iSNS.
       - Entity Certificate
       |    X.509 certificate bound to the Entity (FQDN)
       |
       - PORTAL (1 - n per ENTITY)
       |   |
       |   - IP-Address
       |   - TCP/UDP Port
       |   |    The IP-Address and Port combined uniquely
       |   |    define a portal.
       |   - Portal Symbolic Name
       |   - Entity Status Inquiry Interval
       |        0 if no status inquiry is used
       |
       - STORAGE NODE (1 - k per ENTITY)
           |
           - Port Name (WWPN)
           - Port ID
           - Port Type
           - Port Symbolic Name
           - FC Fabric Port Name (FWWN)
           - FC Hard Address
           - FC Port IP Address
           - FC Class of Service
           - FC FC-4 Types
           - FC FC-4 Descriptor
           - FC FC-4 Features
           - Node Certificate
           - SCN Bitmap
           - SCN Event Bitmap
                Indicates current SCN state

      - FC DEVICE (1 - m per ENTITY)
          |
          - Node Name (WWNN)
          - Node Type (initiator / target / ...)
          - Alias/Node Symbolic Name
          - FC Node IP-Address
          - FC Node IPA

5.2.3    iFCP Attribute Requirements



Gibbons, Tseng, Monia      Standards Track                         22

iSNS                          April 2001

5.2.3.1  Port_ID

   Port_ID assignments for each STORAGE NODE object within a single
   NETWORK ENTITY SHALL be unique.  For each NETWORK ENTITY (i.e., iFCP
   gateway), no more than one STORAGE NODE can be assigned a given
   PORT_ID value.

5.2.4    Example iFCP Object Model Diagram

   The iFCP protocol allows native Fibre Channel devices, or Fibre
   Channel fabrics connected to an iFCP gateway, to be directly
   internetworked using IP.

   When supporting iFCP, the iSNS stores Fibre Channel device
   attributes, iFCP gateway attributes, and Fibre Channel fabric switch
   attributes that might also be stored in an FC name server.

   The following diagram shows a representation of a gateway supporting
   multiple Fibre Channel devices behind it.  The two PORTAL objects
   represent IP interfaces on the iFCP gateway that can be used to
   access any of the three STORAGE NODE objects behind it.  Note that
   the FC DEVICE object is not contained in the NETWORK ENTITY object.
   However, each FC DEVICE has a relationship to one or more STORAGE
   NODE objects.

   +--------------------------------------------------------+
   |                         IP Network                     |
   +--------+-----------------+-----------------------------+
            |                 |
   +-+------+------+---+------+------+----------------------+
   | | PORTAL      |   | PORTAL      |    NETWORK ENTITY    |
   | | -IP Addr 1  |   | -IP Addr 2  |   -Entity ID (FQDN): |
   | | -TCP Port 1 |   | -TCP Port 2 |    “gtwy1.foo.com”   |
   | +-----+ +-----+   +-----+ +-----+   -Type: iFCP        |
   |       | |               | |                            |
   | +-----+ +---------------+ +----------------------+     |
   | +-----+ +---------------+ +-------------+ +------+     |
   |       | |               | |             | |            |
   | +-----+ +-----+    +----+ +------+ +----+ +------+     |
   | |STORAGE NODE |    |STORAGE NODE | |STORAGE NODE |     |
   | | -WWPN 1     |    | -WWPN 2     | | -WWPN 3     |     |
   | | -Port ID 1  |    | -Port ID 2  | | -Port ID 3  |     |
   | | -FWWN 1     |    | -FWWN 2     | | -FWWN 3     |     |
   | | -FC COS     |    | -FC COS     | | -FC COS     |     |
   | +------+------+    +-------+-----+ +----+--------+     |
   +--------|-------------------|------------|--------------+
            |                   |            |
     +------+------+        +---+------------+---+
     | FC DEVICE   |        |    FC DEVICE       |
     | -WWNN 1     |        |   -WWNN 2          |
     |             |        |                    |
     +-------------+        +--------------------+



Gibbons, Tseng, Monia      Standards Track                         23

iSNS                          April 2001

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.

                                                     REQUIRED TO:
      Message Description    Abbreviation  Func ID  Implement  Use
      -------------------    ------------  -------  ---------  ---
   Register Dev Attr Req     RegDevAttr    0x0001       *       *
   Dev Attr Query Request    DevAttrQry    0x0002       *       *
   Dev Get Next Request      DevGetNext    0x0003       *
   Deregister Dev Request    DeregDev      0x0004       *       *
   SCN Register Request      SCNReg        0x0005       *
   SCN Deregister Request    SCNDereg      0x0006       *
   SCN Event                 SCNEvent      0x0007       *
   State Change Notification SCN           0x0008       *
   DD Register               DDReg         0x0009       *       *
   DD Deregister             DDDereg       0x000A       *       *
   DDS Register              DDSReg        0x000B       *       *
   DDS Deregister            DDSDereg      0x000C       *       *
   Entity Status Inquiry     ESI           0x000D       *
   Name Service Heartbeat    Heartbeat     0x000E       *
   Reserved                  Reserved      0x000F
   Request Network Time      RqstTime      0x0010
   Request Switch ID         RqstSwId      0x0011
   Release Switch ID         RlseSwId      0x0012
   Get Switch IDs            GetSwIds      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       *
   DD Register Rsp           DDRegRsp      0x8009       *       *
   DD Deregister Rsp         DDDeregRsp    0x800A       *       *
   DDS Register Rsp          DDSRegRsp     0x800B       *       *
   DDS Deregister Rsp        DDSDeregRsp   0x800C       *       *
   Entity Stat Inquiry Resp  ESIRsp        0x800D       *
   NOT USED                                0x800E-0x800F




Gibbons, Tseng, Monia      Standards Track                         24

iSNS                          April 2001

   Request Net Time Resp     RqstTimeRsp   0x8010
   Request Switch ID Resp    RqstSwIdRsp   0x8011
   Release Switch ID Resp    RlseSwIdRsp   0x8012
   Get Switch IDs            GetSwIdRsp    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 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
                      Timestamp                    *
                      Entity Certificate           *
                      SCN Event Bitmap             *

   PORTAL             IP Address                   *           *
                      TCP/UDP Port                 *           *
                      Portal Symbolic Name         *
                      ESI Interval                 *

5.3.2    Attribute Descriptions for FCIP Gateways

   The iSNS attributes used to represent FCIP gateways are shown and
   described in the following figure:















Gibbons, Tseng, Monia      Standards Track                         25

iSNS                          April 2001

   - 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.
       - Timestamp
       |    Last registration update / status inquiry received
       - Entity Certificate
       |    X.509 certificate bound to the Entity (FQDN)
       - SCN Event Bitmap
       |    Indicates current SCN state
       - PORTAL (1 - n per ENTITY)
           |
           - Index
           - IP-Address
           - TCP/UDP Port
           |    The IP-Addr and Port combined uniquely
           |    define a portal.
           - Portal Symbolic Name
           - Entity Status Inquiry Interval
                0 if no status inquiry is used

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 NODE and FC DEVICE 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                 |
   +-------------------------+    +---------------------------------+



Gibbons, Tseng, Monia      Standards Track                         26

iSNS                          April 2001

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.

                                                     REQUIRED TO:
      Message Description    Abbreviation  Func ID  Implement  Use
      -------------------    ------------  -------  ---------  ---
   Register Dev Attr Req     RegDevAttr    0x0001       *       *
   Dev Attr Query Request    DevAttrQry    0x0002       *       *
   Dev Get Next Request      DevGetNext    0x0003       *
   Deregister Dev Request    DeregDev      0x0004       *       *
   SCN Register Request      SCNReg        0x0005       *
   SCN Deregister Request    SCNDereg      0x0006       *
   SCN Event                 SCNEvent      0x0007       *
   State Change Notification SCN           0x0008       *
   DD Register               DDReg         0x0009       *       *
   DD Deregister             DDDereg       0x000A       *       *
   DDS Register              DDSReg        0x000B       *       *
   DDS Deregister            DDSDereg      0x000C       *       *
   Entity Status Inquiry     ESI           0x000D       *
   Name Service Heartbeat    Heartbeat     0x000E       *
   Reserved                  Reserved      0x000F
   Request Network Time      RqstTime      0x0010
   Request Switch ID         RqstSwId      0x0011
   Release Switch ID         RlseSwId      0x0012
   Get Switch IDs            GetSwIds      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       *
   DD Register Rsp           DDRegRsp      0x8009       *       *
   DD Deregister Rsp         DDDeregRsp    0x800A       *       *
   DDS Register Rsp          DDSRegRsp     0x800B       *       *
   DDS Deregister Rsp        DDSDeregRsp   0x800C       *       *
   Entity Stat Inquiry Resp  ESIRsp        0x800D       *
   NOT USED                                0x800E-0x800F




Gibbons, Tseng, Monia      Standards Track                         27

iSNS                          April 2001

   Request Net Time Resp     RqstTimeRsp   0x8010
   Request Switch ID Resp    RqstSwIdRsp   0x8011
   Release Switch ID Resp    RlseSwIdRsp   0x8012
   Get Switch IDs Resp       GetSwIdsRsp   0x8013
   RESERVED                                0x8014-0xFFFF

5.4      Attribute Descriptions for Discovery Domain Registration

   Support for Discovery Domains is required for all protocols.  The
   iSNS attributes for Discovery Domain, and Discovery Domain Set,
   registration are shown in the following figure:

   DISCOVERY DOMAIN SET
      |
      - DD Set_ID
      - DD Set_Symbolic Name
      - DD Set Enabled/Disabled

   DD SET_MEMBER
      |
      - DD Set_ID
      - DD_ID

   DISCOVERY DOMAIN
      |
      - DD_ID
      - DD_Symbolic Name

   DD_MEMBER
      |
      - DD_ID
      - Entity Identifier, iSCSI Name, or WWPN

   Members of a Discovery Domain can be defined by registering one of
   the following storage entity attributes in a Discovery Domain:

        - Entity Identifier: this places the FCIP gateway in the
                             Discovery Domain
        - iSCSI Name       : this places the individual iSCSI
                             storage node in the Discovery Domain
        - WWPN             : this places the iFCP Storage Node in the
                             Discovery Domain

   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.2.2.

6.       iSNS Message Attributes

   When an iSNS client registers with the iSNS server, it provides
   attribute values to describe the entity characteristics and
   capabilities.  The iSNS server also returns the attributes in
   response to queries.

Gibbons, Tseng, Monia      Standards Track                         28

iSNS                          April 2001


6.1      iSNS Attribute Summary

   The following table lists all iSNSP message attributes for device
   registration and queries:


















































Gibbons, Tseng, Monia      Standards Track                         29

iSNS                          April 2001

   T Entity Attributes       Length  Tag  Reg Key Query Key
   - ----------------------- ------  ---  ------- -----------
     Delimiter               0-256   0    N/A     N/A
   ^ Entity Identifier (EID) 0-256   1    1|@     @|1|2|16,17|32|64
   & Entity Type             4       2    1       @|1|2|16,17|32|64
     Mgt IP Address          16      3    1       @|1|2|16,17|32|64
     Timestamp               8       4    1       @|1|2|16,17|32|64
   * Entity Certificate      var     5    1       @|1|2|16,17|32|64
   # Portal IP-Address       16      16   1       @|1|16,17|32|64
   $ Portal TCP/UDP Port     4       17   1       @|1|16,17|32|64
     Portal Symbolic Name    0-256   18   16,17   @|1|16,17|32|64
     ESI interval            4       19   16,17   @|1|16,17|32|64
   * Portal Certificate      var     20   16,17   @|1|16,17|32|64
   # iSCSI Name              4-256   32   1%      @|1|16,17|32|33
   & Node Type               4       33   32      @|1|16,17|32
     Alias                   0-256   34   32      @|1|16,17|32
     iSCSI SCN bitmap        4       35   32      @|1|16,17|32
   * iSCSI Node Certificate  var     40   32      @|1|16,17|32
   # iFCP Node WWPN          8       64   1%    @|1|16,17|64|66|96|128
     Port_ID                 4       65   64      @|1|16,17|64
     Port_Type               4       66   64      @|1|16,17|64
     Port_Symbolic Name      0-256   67   64      @|1|16,17|64
     FC Fabric Port Name     8       68   64      @|1|16,17|64
     FC Hard Address         4       69   64      @|1|16,17|64
     FC Port IP-Address      16      70   64      @|1|16,17|64
     FC Class of Service     4       71   64      @|1|16,17|64
     FC FC-4 Types           32      72   64      @|1|16,17|64
     FC FC-4 Descriptors     0-256   73   64      @|1|16,17|64
     FC FC-4 Features        128     74   64      @|1|16,17|64
     iFCP Node SCN bitmap    4       75   32      @|1|16,17|64
   * iFCP Node Certificate   var     80   64      @|1|16,17|64
   # FC Device WWNN          8       96   @       @|64|96
     FC Device Sym Node Name 0-256   97   96      @|64|96
     FC Device IP-Address    16      98   96      @|64|96
     FC Device IPA           8       99   96      @|64|96
   * FC Device Certificate   var    100   96      @|64|96
     FC-4 Type Code          4      128   Query Key only
     Preferred ID            4      130   Switch ID msgs only
     Assigned ID             4      131   Switch ID msgs only
     Space_Identifier        0-256  132   Switch ID msgs only
   * User Specific iSNS Srvr var     -    tags in range 256-383
   * User Specific Entity    var     -    tags in range 384-511
   * User Specific Portal    var     -    tags in range 512-639
   * User Spec iSCSI Node    var     -    tags in range 640-767
   * User Spec iFCP Node     var     -    tags in range 768-895
   * User Spec iFCP FC Node  var     -    tags in range 896-1023
   * User Specific FCIP      var     -    tags in range 1024-1151
   * User Specific DD        var     -    tags in range 1152-1279
   * Vendor Spec iSCSI Node  var     -    tags in range 1280-1407
   * Vendor Spec iFCP Node   var     -    tags in range 1408-1535
   * Vendor Spec FCIP        var     -    tags in range 1536-1163
   * Vendor-Specific         var     -    -vendor defined-
     RESERVED                       2048-65535


Gibbons, Tseng, Monia      Standards Track                         30

iSNS                          April 2001

   The following is a description of the columns used in the above
   table:

   Attribute Type (T)
   --------------------------------------------------------------
   # : Required key for object registration.
   ^ : Required key for object registration, unique value is
       assigned by the iSNS if value not provided during initial
       registration.
   $ : Required as part of the key, and the canonical value is
       used if one is not registered.
   & : Attribute required during initial registration that is
       not a key.
   * : Optional to implement in the iSNS.
   @ : if no key is present then a new entry is created, or all
       entries of the operating attributes are returned.
   | : used to separate the different sets of possible keys in the
       table.
   % : If an iSCSI Name or iFCP Node WWPN is registered
       without an EID key, then an Entity will be created and an EID
       assigned.  The assigned EID will be returned in the response
       as an Operating attribute.

   Length - indicates the attribute length.  Variable-length
   identifiers are NULL character terminated, which is included in the
   length.

   Tag - the integer tag value used to identify the attribute.  All
   undefined tag values are reserved.

   Value – a description of the data.

   Implementation Notes:
   --------------------------------------------------------------
   A well-formed registration contains the key of the object to
   register, or no key if it can be generated by the iSNS.  If an
   attribute is present as a key, then it cannot be an operating
   attribute.

   The registration response will contain the key for each object
   registered, including any key values that were assigned by the iSNS
   as part of the registration.  For example, if an entity, two
   portals, and one iFCP node was registered, then the response message
   key attributes section would contain the keys for each.  The key
   attributes, returned in the response, may be in a different order
   they appeared in the registration.

   iSNS client attributes are defined below.

6.2      Entity Identifier-Keyed Attributes

   The following attributes are registered in the iSNS using the Entity
   Identifier attribute as the key.


Gibbons, Tseng, Monia      Standards Track                         31

iSNS                          April 2001

6.2.1.   Entity Identifier (EID)

   The Entity Identifier is a variable length identifier that uniquely
   identifies each entity registered in the iSNS.  The attribute length
   varies from 4 to 256 bytes, and is a unique value within the iSNS.

   If the iSNS client does not provide an EID during registration the
   iSNS shall generate one that is unique within the iSNS.  If an EID
   is to be generated, then the EID attribute value in the registration
   message shall be empty (0 length).  The generated EID shall be
   returned in the registration response.

   By convention, iSNS generated EIDs begin with the string “iSNS:”.

6.2.2    Entity Type

   Entity Type is a required 4-byte attribute 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.2.3    Management IP Address

   This optional field is provided by the iSNS client.  It contains the
   IP Address used to manage the entity.  The Management IP Address is
   a 16-byte field that may contain either a 32-bit IPv4 or 128-bit
   IPv6 address.  When this field contains an IPv4 value, the most
   significant 12 bytes are set to 0x00.  If the network entity is
   capable of being managed and this field is not set, then in-band
   management is assumed.

6.2.4    Entity Registration Timestamp

   This field is updated by the iSNS, and indicates the time the client
   registration occurred, or the time of the most recent response to an
   Entity Status Inquiry message, whichever is later.  The time format
   is, in seconds, the update period since the standard base time of
   00:00:00 GMT on January 1, 1970.

6.2.5    Entity Certificate

   This attribute contains an X.509 certificate that is bound to the
   NETWORK ENTITY of the iSNS client, and is optional to implement.
   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

Gibbons, Tseng, Monia      Standards Track                         32

iSNS                          April 2001

   to set up the TLS association between the iSNS client and server, as
   well as to key the authentication block in the iSNSP.

6.3      Portal-Keyed Attributes

   The following portal attributes are registered in the iSNS using the
   combined Portal IP-Address and Portal TCP/UDP Port as the key.  Each
   portal is associated with one Entity Identifier object key.

6.3.1    Portal IP-Address

   The IP address of the PORTAL through which a STORAGE NODE can
   transmit and receive storage data.  This required field is provided
   by the iSNS client. When an IPv4 value is contained in this field,
   the most significant 12 bytes are set to 0x00.  The Portal IP
   Address along with the Portal TCP/UDP Port number uniquely
   identifies a Portal.

6.3.2    Portal TCP/UDP Port

   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.  Byte 0 and 1 represent the port number.  Bit 0
   of byte 2 (bit 17) represents the port type.  If bit 17 is set then
   the port type is UDP, otherwise it is TCP.  All other bits in byte 2
   and 3 are reserved.  If the value is 0, then the port number is the
   implied canonical port number and type of the protocol indicated by
   the associated Entity Type.

   The Portal IP-Address along with the Portal TCP/UDP Port number
   uniquely identifies a Portal.

6.3.3    Portal Symbolic Name

   This is an optional, variable-length text-based value from 0 to 256
   bytes.  The text field contains user-readable UTF-8 text, and is
   terminated with at least one NULL character. The Portal Symbolic
   Name is a user-readable description of the Portal entry in the iSNS.

6.3.4    Entity Status Inquiry Interval

   This optional field is provided by the iSNS client.  It indicates
   the minimum time, in seconds, between Entity Status Inquiry (ESI)
   messages sent from the iSNS to this entity portal.  ESI messages can
   be used to verify that an entity registration continues to be valid.
   To request monitoring by the iSNS, an iSNS client registers a non-
   zero value for this portal attribute using a RegDevAttr message.

   If the iSNS does not receive an ESI response message after having
   sent an implementation dependent number of ESI messages, then the
   entity shall be deregistered.

   If the iSNS is unable to support ESI messages, it SHALL reject the
   ESI request by returning a "ESI Not Available" error code.  The

Gibbons, Tseng, Monia      Standards Track                         33

iSNS                          April 2001

   rejection might occur in situations where the resulting frequency of
   ESI messages being issued to clients would pass an implementation-
   specific threshold.

6.3.5    Portal Certificate

   This attribute contains an X.509 certificate that is bound to the
   PORTAL of the iSNS client, and is optional to implement.  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 PORTAL.  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.4      iSCSI Node-Keyed Attributes

   The following attributes are registered in the iSNS using the iSCSI
   Name attribute as the key.  Each set of Node-Keyed attributes is
   associated with one Entity Identifier object key.

   Although the iSCSI Name key is associated with one Entity
   Identifier, it is unique across the entire iSNS.

6.4.1    iSCSI Name

   This identifier uniquely defines an iSCSI STORAGE NODE, and is a
   variable-length text-based value from 0 to 256 bytes.  This field is
   required for iSCSI STORAGE NODEs, and is provided by the iSNS
   client.

   If an iSCSI Name is registered without an EID key, then an Entity
   will be created and an EID assigned.  The assigned EID will be
   returned in the registration response as an operating attribute.

6.4.2    iSCSI Node Type

   This required 16-bit field is a bitmap indicating the type of iSCSI
   STORAGE NODE.  The bit fields are defined below.  An enabled bit
   indicates the node has the corresponding characteristics.

       Bit Field       Node Type
       ---------       ---------
          0 (Lsb)      Target
          1            Initiator
       All Others      RESERVED

6.4.3    iSCSI Node Alias

   This is an optional, variable-length text-based value from 0 to 256
   bytes.  The text field contains user-readable UTF-8 text, and is
   terminated with at least one NULL character. The Alias is a user-
   readable description of the node entry in the iSNS.



Gibbons, Tseng, Monia      Standards Track                         34

iSNS                          April 2001

6.4.4    iSCSI Node SCN Bitmap

   This optional field is provided by the iSNS client.  It indicates
   the events that the iSCSI Node is interested in.  These events can
   cause a State Change Notification (SCN) to be generated.

   Bit Field          Flag Description
   ---------          ----------------
       0              CHANGE IN DD MEMBERSHIP
       1              CHANGE IN NETWORK
       2              CHANGE IN DEVICE REGISTRATION PARAMETERS
       3              DEVICE ADDED
       4              DEVICE REMOVED
   All others reserved.

6.4.5    iSCSI Node Certificate

   This optional attribute contains an X.509 certificate that is bound
   to the iSCSI STORAGE NODE of the iSNS client.  For example, this
   X.509 certificate may have the Node Identifier of the target device.
   This certificate is uploaded and registered to the iSNS by clients
   wishing to allow other clients to authenticate themselves and access
   the STORAGE NODE.  This certificate SHOULD NOT be used to set up the
   authenticating SA supporting the iSNSP authentication block.

6.5      iFCP Node-Keyed Attributes

   The following attributes are registered in the iSNS using the iFCP
   Node World Wide Port Name (WWPN) attribute as the key.  Each set of
   iFCP Node-Keyed attributes is associated with one Entity Identifier
   object key.

   Although the iFCP Node WWPN is associated with one Entity
   Identifier, it is globally unique.

6.5.1    iFCP Node Port Name (WWPN)

   This 64-bit identifier uniquely defines the iFCP Node, and is the
   World Wide Port Name (WWPN) of the corresponding Fibre Channel
   device.  This globally unique identifier is used during the device
   registration process, and uses a value conforming to IEEE Naming
   Assignment Authority (NAA) type 1, 2, 5, or 6.  This format is found
   in ANSI/IEEE Std 802-1990 [802-1990].

6.5.2    Port ID

   Along with the IP Address, this field uniquely identifies a native
   Fibre Channel device port in the network, and maps one-to-one to a
   specific Port Name (WWPN) entry.  The Port ID is used for iFCP based
   storage devices.

6.5.3    Port Type



Gibbons, Tseng, Monia      Standards Track                         35

iSNS                          April 2001

   Indicates the type of iFCP node port.  This is provided by the iSNS
   client.  Encoded values for this field are listed in the following
   table:

   Type              Description
   ----              -----------
   0x0000           Unidentified/Null Entry
   0x0001           Fibre Channel N_Port
   0x0002           Fibre Channel NL_Port
   0x0003           Fibre Channel F/NL_Port
   0x0004-0080      RESERVED
   0x0081           Fibre Channel F_Port
   0x0082           Fibre Channel FL_Port
   0x0083           RESERVED
   0x0084           Fibre Channel E_Port
   0x0085-00FF      RESERVED
   0xFF11           mFCP Port
   0xFF12           iFCP Port
   0xFF13-FFFF      RESERVED

6.5.4    iFCP Node Port Symbolic Name

   A variable-length text-based description of up to 256 bytes, that is
   associated with the iSNS-registered iFCP Node in the network.  The
   text field contains user-readable UTF-8 text and is terminated with
   at least one NULL character.  This optional field is normally
   provided by the iSNS client during registration.  However, network
   management application can update this field as required.

6.5.5    iFCP Node Fabric Port Name (FWWN)

   This 64-bit identifier uniquely defines the fabric port.  If the
   iSNS client is attached to a Fibre Channel fabric port with a
   registered Port Name, then that fabric Port Name shall be indicated
   in this field.  This field is included in the iSNSP for
   compatibility with Fibre Channel fabric devices and topologies.

   The Fabric Port may itself be registered as a port in the iSNS.  In
   that case, the Fabric Port Name (FWWN) attribute of fabric attached
   ports will match the Port Name (WWPN) of the Fabric Port
   registration.

6.5.6    FC Hard Address

   This optional field is the requested hard address 24-bit NL Port
   Identifier, included in the iSNSP for compatibility with Fibre
   Channel Arbitrated Loop devices and topologies.

6.5.7    FC Port IP Address

   The Fibre Channel IP address associated with the iFCP Node.  This
   optional field is included for compatibility with Fibre Channel.
   When an IPv4 value is contained in this field, the most significant


Gibbons, Tseng, Monia      Standards Track                         36

iSNS                          April 2001

   12 bytes are set to 0x00.  This value is provided by the iSNS
   client.

6.5.8    FC Class of Service (COS)

   This 32-bit bit-map field indicates the Fibre Channel COS types that
   are supported by the registered port.  This field is provided by a
   Fibre Channel-based iSNS client.  The COS values are equivalent to
   Fibre Channel COS values.  The valid COS types, and associated bit-
   map, are listed in the following table:

   Class of Service   Description                         Bit-Map
   ----------------   -----------                         ---------
         2            Delivery Confirmation Provided      bit 2 set
         3            Delivery Confirmation Not Provided  bit 3 set
                      RESERVED                            other

6.5.9    FC FC-4 Types

   This 32-byte field indicates the FC-4 protocol types supported by
   the associated port.  This field for iFCP Node is provided by the
   iSNS client.  This field can be used to support Fibre Channel
   devices and is consistent with FC-GS-4.

6.5.10   FC FC-4 Descriptor

   A variable-length text-based description of up to 256 bytes, that is
   associated with the iSNS-registered device port in the network.
   This optional field for iFCP ports is provided by the iSNS client.
   This field can be used to support Fibre Channel devices.  This field
   can be used to support Fibre Channel devices and is consistent with
   FC-GS-4.

6.5.11   FC FC-4 Features

   This is a 128-byte array, 4 bits per type, for the FC-4 protocol
   types supported by the associated port.  This optional field for
   iFCP ports is provided by the iSNS client.  This field can be used
   to support Fibre Channel devices and is consistent with FC-GS-4.

6.5.12   iFCP Node SCN Bitmap

   This optional field is provided by the iSNS client.  It indicates
   the events that the iFCP Node is interested in.  These events can
   cause SCN to be generated.

   Bit Field          Flag Description
   ---------          ----------------
       0              CHANGE IN DD MEMBERSHIP
       1              CHANGE IN NETWORK
       2              CHANGE IN DEVICE REGISTRATION PARAMETERS
       3              DEVICE ADDED
       4              DEVICE REMOVED
   All others reserved.

Gibbons, Tseng, Monia      Standards Track                         37

iSNS                          April 2001


6.5.13   iFCP Node Certificate

   This optional attribute contains an X.509 certificate that is bound
   to the iFCP STORAGE NODE of the iSNS client.  For example, this
   X.509 certificate may have the Node Identifier of the target device.
   This certificate is uploaded and registered to the iSNS by clients
   wishing to allow other clients to authenticate themselves and access
   the STORAGE NODE.  This certificate SHOULD NOT be used to set up the
   authenticating SA supporting the iSNSP authentication block.

6.6      iFCP FC Device Node-Keyed Attributes

   The following attributes are registered in the iSNS using the iFCP
   FC Node World Wide Node Name (WWNN) attribute as the key.  Each set
   of iFCP FC Node-Keyed attributes represents a single device, and can
   be associated with many iFCP Node Ports.

   The iFCP Node WWNN is unique across the entire iSNS.

6.6.1    iFCP FC Device Node Name (WWNN)

   Node Name is a 64-bit identifier that uniquely identifies the iFCP
   FC device node in the network, and is the World Wide Node Name
   (WWNN) of the corresponding Fibre Channel device. This globally
   unique identifier is used during the device registration process,
   and uses a value conforming to IEEE Naming Assignment Authority
   (NAA) type 1, 2, 5, or 6.  This format is found in ANSI/IEEE Std
   802-1990 [802-1990].

6.6.2    iFCP FC Device Symbolic Name

   A variable-length text-based description of up to 256 bytes, that is
   associated with the iSNS-registered FC Device in the network.  The
   text field contains user-readable UTF-8 text and is terminated with
   at least one NULL character.  This optional field is normally
   provided by the iSNS client during registration.  However, network
   management application can update this field as required.

6.6.3    FC Device IP Address

   This optional IP address is associated with the device node in the
   network.  This field is included for compatibility with Fibre
   Channel.  When an IPv4 value is contained in this field, the most
   significant 12 bytes are set to 0x00.  This value is provided by the
   iSNS client.

6.6.4    FC Device IPA

   This optional 8 byte Fibre Channel Initial Process Associator (IPA)
   is associated with the device node in the network.  This field is
   included for compatibility with Fibre Channel, and is provided by a
   Fibre Channel-based iSNS client entity.  The initial process


Gibbons, Tseng, Monia      Standards Track                         38

iSNS                          April 2001

   associator can be used for communication between Fibre Channel
   devices.

6.6.5    FC Device Certificate

   This optional attribute contains an X.509 certificate that is bound
   to the FC DEVICE of the iSNS client.

6.7      Other Attributes

   The following are not attributes of the previously-defined objects.

6.7.1    FC-4 Type Code

   This is a 4-byte field, and is used to provide a FC-4 type during a
   FC-4 Type query.  The FC-4 types are consistent with the FC-4 Types
   as defined in FC-PH.  Byte 0 contains the FC-4 type.  All other
   bytes are reserved.

6.7.2    Preferred ID

   This is a 4-byte unsigned integer field, and is the requested value
   that the iSNS client wishes to use for the SWITCH_ID.  The iSNS
   server SHALL grant the iSNS client the use of the requested value as
   the SWITCH_ID, if the requested value has not been already
   allocated.  If the requested value is not available, the iSNS server
   SHALL return a different value that has not been allocated.

6.7.3    Assigned ID

   This is a 4-byte unsigned integer field that is used to support iFCP
   Transparent Mode and possibly FCIP.  When operating in iFCP
   Transparent Mode, the RqstSwId message SHALL be used by each iFCP
   gateway to reserve its own unique SWITCH_ID value from the range 1
   to 239.  When a Switch ID is no longer required, it SHALL be
   released by the iFCP gateway using the RlseSwId message.  The iSNS
   MAY use the Entity Status Inquiry message to determine if an iFCP
   gateway is still present on the network.

6.7.4    Space_Identifier

   This is a UTF-8 encoded string.  The Space_Identifier string is used
   as a key attribute to identify a range of non-overlapping SWITCH_ID
   values to be allocated using RqstSwId.  Each Space_Identifier string
   submitted by iSNS clients shall have its own range of non-
   overlapping SWITCH_ID values to be allocated to iSNS clients.

6.8      Discovery Domain Registration Attributes

   iSNS clients can be placed into Discovery Domains, which are areas
   of control.  Only objects that share the same enabled Discovery
   Domain can query for information about each other.  Discovery
   Domains can overlap, so an iSCSI node may be a member of many DD’s.


Gibbons, Tseng, Monia      Standards Track                         39

iSNS                          April 2001

   Additionally, Discovery Domains can be a member of one or more
   Discovery Domain Sets (DDS).  Discovery Domain Sets can be
   administratively enabled or disabled.  Only Discovery Domains in an
   enabled Discovery Domain Set are active / enforced by the iSNS.

6.8.1    iSNS Discovery Domain Attribute Summary

   The following table lists the iSNSP DD attributes:

   Attribute Name     Size(bytes)    ID      Reg Key     Query Key
   --------------     -----------    --      -------     ---------
   DD_Set ID               4        101         @      32,64,101,104
   DD_Set Sym Name        4-256     102        101          101
   DD_Set Status           4        103        101          101
   DD_ID                   4        104       @|101*   32,64,101,104
   DD_Symbolic Name       4-256     105        104          104
   DD FCIP Member         0-256     106        104          104
   DD_iSCSI Node Member   0-256     107        104          104
   DD_iFCP Member (WWPN)   8        108        104          104

   @ = no key required during registration
   | = either key can be used during registration
   * = When a DD ID is placed into a DD Set by using the DDS ID
       as a key

6.8.2    DD Set ID Keyed Attributes

6.8.2.1  Discovery Domain Set ID (DDS ID)

   The DDS ID is a unique integer identifier used in the iSNS directory
   database to indicate a Discovery Domain Set.  A DDS is a collection
   of Discovery Domains that can be enabled or disabled by a management
   station.  This value is used as a key for DDS attribute queries.
   When a Discovery Domain is registered it is initially placed into
   DDS 0.

6.8.2.2  Discovery Domain Set Symbolic Name

   The DDS_Symbolic Name is a UTF-8, variable-length, NULL-terminated
   string.  This is an user-readable field used to assist a network
   administrator in tracking the DDS function.  When registered by a
   client, the DDS symbolic name SHALL be verified unique by the iSNS.
   If the DDS symbolic name is not unique, then the DDS registration
   SHALL be rejected with an “Invalid Registration” error code.  The
   invalid attribute(s), in this case the DDS symbolic name, SHALL be
   included in the response.

6.8.2.3  Discovery Domain Set Member

   The Discovery Domain Set Member is a DD ID for a previously
   registered Discovery Domain.  The DD ID tag value is used to
   represents membership.



Gibbons, Tseng, Monia      Standards Track                         40

iSNS                          April 2001

6.8.3    DD ID Keyed Attributes

6.8.3.1  Discovery Domain ID (DD ID)

   The DD ID is a unique identifier used in the iSNS directory database
   to indicate the DD.  This value is used as the key for any DD
   attribute query. If the iSNS client does not provide a DD_ID in a DD
   registration request message, the iSNS shall generate a DD_ID value
   that is unique within the iSNS database for that new DD (i.e., the
   iSNS client will be registered in a new DD).  The created DD ID
   shall be returned in the response message.  The DD ID value of 0 is
   reserved.

6.8.3.2  Discovery Domain Symbolic Name

   The DD_Symbolic Name is a UTF-8 encoded, variable-length, NULL-
   terminated string.  When registered by a client, the DD symbolic
   name SHALL be verified unique by the iSNS.  If the DD symbolic name
   is not unique, then the DD registration SHALL be rejected with an
   “Invalid Registration” error code.  The invalid attribute(s), in
   this case the DD symbolic name, SHALL be included in the response.

6.8.3.3  Discovery Domain FCIP Member

   The Entity Identifier of an FCIP iSNS client that is a member of the
   DD.  The DD may have a list of 0 to n members.  Registering the
   Entity Identifier of the iSNS client represents DD membership.

6.8.3.4  Discovery Domain iSCSI Node Member

   The iSCSI Name of an iSNS client that is a member of the DD.  The DD
   may have a list of 0 to n members.  The iSCSI Name of the iSNS
   client represents membership.

6.8.2.5  Discovery Domain iFCP Node Member

   The iFCP Node Port Name of an iSNS client that is a member of the
   DD.  The DD may have a list of 0 to n members.  Membership is
   represented by the iFCP Node Port Name (WWPN) of the iSNS client
   being listed.

6.9      Vendor-Specific 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.1.  To avoid
   misinterpreting proprietary attributes, it is RECOMMENDED that the
   vendor's own OUI (Organizationally Unique Identifier) be placed in
   the upper three bytes of the attribute field itself.  If the OUI is
   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


Gibbons, Tseng, Monia      Standards Track                         41

iSNS                          April 2001

   the OUI in the vendor-specific or user-specific attribute field, and
   be able to execute vendor-specific handling of the attribute.

7.       iSNSP Message Format

   The iSNSP message format is similar to the format of other common
   protocols such as DHCP, DNS and BOOTP.  An iSNSP message may be sent
   in one or more iSNS Protocol Data Units (PDU).  Each PDU is 4 byte
   aligned.  The following describes the format of the iSNSP PDU:

   Byte   MSb                                        LSb
   Offset 31                                           0
          +---------------------+----------------------+
        0 |   iSNSP VERSION     |    FUNCTION ID       | 4 Bytes
          +---------------------+----------------------+
        4 |     PDU LENGTH      |       FLAGS          | 4 Bytes
          +---------------------+----------------------+
        8 |   TRANSACTION ID    |    SEQUENCE ID       | 4 Bytes
          +---------------------+----------------------+
       12 |                                            |
          |                PDU PAYLOAD                 | N Bytes
          |                    ...                     |
          +--------------------------------------------+
    12 + N |    AUTHENTICATION BLOCK (if present)       | L Bytes
          +--------------------------------------------+
                     Total Length = 12 + N

7.1      iSNS PDU Header

   The iSNSP header contains the iSNSP VERSION, FUNCTION ID, PDU
   LENGTH, FLAGS, TRANSACTIONID, and SEQUENCE ID fields as defined
   below.

7.1.1    iSNSP Version

   The iSNSP version is currently 0x0001.

7.1.2    iSNSP Function ID

   The FUNCTION ID defines the type of iSNS message and the function
   the message is supporting.  See section 5 under the appropriate
   protocol (i.e., iSCSI, 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.

7.1.3    iSNSP PDU Length

   The iSNS PDU LENGTH specifies the length of the PDU PAYLOAD field in
   bytes.The payload contains the data/attribute values for the
   operation.

7.1.4    iSNSP Flags


Gibbons, Tseng, Monia      Standards Track                         42

iSNS                          April 2001

   The FLAGS field indicates additional information about the message
   and the type of iSNS entity that generated the message.  The
   following table displays the valid flags:

   Bit Field            Enabled Means:
   ---------            -------------
     0-9                RESERVED
      10                First PDU of the iSNS message
      11                Last PDU of the iSNS message
      12                Update Flag (used only for RegDevAttr)
      13                Authentication Block Present
      14                Sender is the iSNS server
      15                Sender is the iSNS client

7.1.5    iSNSP Transaction ID

   The TRANSACTION ID is set to a unique random value for each request
   message.  Replies MUST use the same TRANSACTION ID value as the
   associated iSNS request message.  If a message is retransmitted, the
   same TRANSACTION ID value MUST be used.

7.1.6    iSNSP Sequence ID

   The SEQUENCE ID is set to a unique value for each PDU within a
   single transaction.  Each SEQUENCE_ID value in each PDU SHALL be
   numbered sequentially in the order that the PDU's are transmitted.
   If a message is retransmitted, then the same SEQUENCE_ID value MUST
   be used for all PDU's in the message.

7.2      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 authentication operation described in section 7.5 SHALL be
   performed on a per-PDU basis.

7.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

Gibbons, Tseng, Monia      Standards Track                         43

iSNS                          April 2001

   Offset 31                                           0
          +--------------------------------------------+
        0 |               Attribute Tag                | 4 Bytes
          +--------------------------------------------+
        4 |            Attribute Length (N)            | 4 Bytes
          +--------------------------------------------+
        8 |                                            |
          |              Attribute Value               | N Bytes
          |                                            |
          +--------------------------------------------+
                      Total Length = 8 + N

   Attribute Tag - a 4-byte tag field that identifies the attribute as
   defined in section 6.1.  This field contains the ID of the indicated
   attribute.

   Attribute Length - a 4-byte field that indicates the length, in
   bytes, of the attribute value to follow.

   Attribute Value - a variable-length field containing the attribute
   value.

   The above format is used to identify each attribute in the iSNS
   message payload.  Each iSNSP request message contains several
   attributes in the above format to identify the requesting iSNS
   client and register or query for attribute values in the iSNS
   server.

7.3.1    Attribute Value 4-Byte Alignment

   All attribute values are aligned at 4 byte boundaries.  For variable
   length attributes, the value length is increased to the next 4-byte
   boundary and the value is NULL padded.

7.4      iSNSP Response Error Codes

   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
           5             Invalid Query
           6             Authentication Unknown
           7             Authentication Absent
           8             Authentication Failed
           9             No Such Entry
          10             Version Not Supported

Gibbons, Tseng, Monia      Standards Track                         44

iSNS                          April 2001

          11             Internal Bus Error
          12             Busy Now
          13             Option Not Understood
          14             Invalid Update
          15             Message Not Supported
          16             SCN Event Rejected
          17             SCN Registration Rejected
          18             Entity Status Inquiry (ESI) Not Available
          19             SWITCH_ID not available
          20             SWITCH_ID not allocated
          21             Attribute not Implemented

   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.

7.5      Message Authentication

   iSNSP provides an optional PDU authentication capability. Network
   interactions using iSNSP occur in short transactions, and are
   generally not session based.  The iSNS client connects to the iSNS
   server only when information needs to be registered or queried.  The
   authentication mechanism described here is compatible with that used
   in Service Location Protocol version 2 [RFC2608].

   Public Key Encryption MAY be used for message authentication.  If a
   public key infrastructure is not available, a shared secret
   algorithm MAY alternatively be used.  A shared secret mechanism may
   leverage a Kerberos server, or may involve manual distribution of a
   private key to the iSNS server and each iSNS client.

   If a PKI is available with an X.509 certificate authority, then
   public key authentication of clients is possible.  The
   authentication block leverages the DSA with SHA-1 algorithm, which
   can easily integrate into a public key infrastructure.

   The SNSP optional authentication block is a digital signature for
   the iSNSP PDU.  The digital signature is calculated on a per-PDU
   basis.  The authentication block contains the following information:

   1.  A time stamp, to prevent replay attacks
   2.  A structured authenticator containing a signature calculated
       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:





Gibbons, Tseng, Monia      Standards Track                         45

iSNS                          April 2001

      Byte   MSb                              LSb
      Offset 7    6    5    4    3    2    1    0
             +----------------------------------+
         0   |    BLOCK STRUCTURE DESCRIPTOR    |     2 Bytes
             +----------------------------------+
         2   |   AUTHENTICATION BLOCK LENGTH    |     2 Bytes
             +----------------------------------+
         4   |           TIMESTAMP              |     4 Bytes
             +----------------------------------+
         8   |       SPI STRING LENGTH          |     1 Byte
             +----------------------------------+
         9   |           SPI STRING             |     N Bytes
             +----------------------------------+
     9 + N   |     STRUCTURED AUTHENTICATOR     |     M Bytes
             +----------------------------------+
                Total Length = 9 + N + M

   BLOCK STRUCTURE DESCRIPTOR (BSD) - Defines the structure and
   algorithm to use for the STRUCTURED AUTHENTICATOR.  Currently, the
   only defined value for BSD is 0x0002, which represents DSA with SHA-
   1. Details on DSA can be found in [DSS].  BSD values from 0x0000 to
   0x7FFF are assigned by IANA, while 0x8000 to 0x8FFF are for private
   use. The BSD value 0x0002 is compatible with the X.509 PKI
   specification, allowing easy integration of the STRUCTURED
   AUTHENTICATOR format with an existing PKI infrastructure.

   AUTHENTICATION BLOCK LENGTH - Defines the length of the
   authentication block, beginning with the BSD field and running
   through the last byte of the STRUCTURED AUTHENTICATOR.

   TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving
   the number of seconds since 00:00:00 GMT on January 1, 1970.

   SPI STRING LENGTH - The length of the SPI STRING field.

   SPI STRING (Security Parameters Index) - Index to the key and
   algorithm used by the message recipient to decode the STRUCTURED
   AUTHENTICATOR field.

   STRUCTURED AUTHENTICATOR - Contains the digital signature.  For the
   default BSD value of 0x0002, this field contains the binary ASN.1
   encoding of output values from the DSA with SHA-1 signature
   calculation.

7.7      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                         46

iSNS                          April 2001

             MSb                                    LSb
             31                                       0
             +----------------------------------------+
             |         Source Attribute (Query Only)  |
             +----------------------------------------+
             |         Key Attribute[1] (if present)  |
             +----------------------------------------+
             |         Key Attribute[2] (if present)  |
             +----------------------------------------+
             |         Key Attribute[3] (if present)  |
             +----------------------------------------+
             |                 . . .                  |
             +----------------------------------------+
             |       - Delimiter Attribute -          |
             +----------------------------------------+
             |   Operating Attribute[1]               |
             +----------------------------------------+
             |   Operating Attribute[2] (if present)  |
             +----------------------------------------+
             |   Operating Attribute[3] (if present)  |
             +----------------------------------------+
             |                 . . .                  |
             +----------------------------------------+

   iSNS Registration and Query messages, sent by iSNS Clients, are sent
   to the iSNS IP-Address and TCP/UDP Port.  The iSNS Responses will be
   sent to the iSNS Client IP-Address and the originating TCP/UDP Port
   used for the associated registration and query message.

7.7.1    Source Attribute (Query Only)

   The source attribute is used to identify the iSNS client to the iSNS
   server for query messages.  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 (FCIP Only)
           iSCSI Name (iSCSI only)
           iFCP Node 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.

7.7.2    Key Attributes



Gibbons, Tseng, Monia      Standards Track                         47

iSNS                          April 2001

   Key attributes are used to identify the object (or objects) in the
   iSNS server that the registration or query operation will be
   performed on.  The number of Key Attributes depends on the specific
   iSNSP request or query operation being performed.

7.7.3    Delimiter Attribute

   The Delimiter Attribute separates the key attributes from the
   operating attributes in a message payload.  The Delimiter Attribute
   has a tag value of 0 and a length value of 0.  The Delimiter
   Attribute is effectively 8 Bytes long, a 4 Byte tag containing
   0x00000000, and a 4 Byte length field containing 0x00000000.

7.7.4    Operating Attributes

   The Operating Attributes are a list of one or more attributes
   related to the actual iSNS registration or query operation being
   performed.  In a registration, operating attributes represent values
   to be registered by the iSNS client performing the registration.  In
   a query, operating attributes represent values being requested by
   the iSNS client.

   The number of possible Operating Attributes depends on the specific
   iSNSP request or query.  For example, the Operating Attributes in a
   Device Attribute Query message are the set of attributes to be
   returned in the associated Device Attribute Query Response message
   that match the Key Attributes of the query.

   Some iSNSP messages do not require any Operating Attributes.

7.7.4.1  Operating Attributes for Query and Get Next Requests

   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.7.5    Registration and Query Message Types

   The following describes each query and message type.

7.7.5.1  Register Device Attribute Request (RegDevAttr)

   The RegDevAttr message type is 0x0001. The RegDevAttr message
   provides an iSNS client with the means to register network entities.
   The iSNS client formulates a RegDevAttr by specifying Key
   Attribute(s) and list of Operating Attributes to register.  All
   values are in Tag Length Value (TLV) format.




Gibbons, Tseng, Monia      Standards Track                         48

iSNS                          April 2001

   For the initial network entity registration a Key Attribute is not
   required, but is required for update registrations to existing
   objects.

   The operating attributes are elements that will be registered.
   Multiple attributes can be registered in one RegDevAttr.  The
   ordering of the operating attributes indicates the associations to
   be created in the iSNS.  For example, Portal attributes following
   Entity attributes SHALL create a link between the registered entity
   and portal.  Similarly, node attributes following entity attributes
   will create an association.

   One RegDevAttr message can contain attributes for Entity, Portal,
   and Node objects if they are contained in the same Entity.  When the
   registration contains attributes for the Entity, Portal, and Node
   objects together, then the appropriate Portal, and Node key
   attributes must be registered as part of the operating attributes.

   Ordering of the attributes is important in multi-object
   registrations.  For example, Node Attributes follow a valid Node
   key.

   When a registration of a Portal, Node or Port is performed, the
   appropriate associations between objects will be created in the
   iSNS.

   A operating attribute TLV with a length value of 0 is valid for
   initial client registration when the iSNS is being used to assign a
   unique identifier to the client.

   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.

7.7.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

Gibbons, Tseng, Monia      Standards Track                         49

iSNS                          April 2001

   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 attribute associated with another entity,
   then an error shall be returned.

7.7.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.7.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 minimum set of
   Key Attributes:

          Valid Key Attributes for Queries
          --------------------------------
           Entity Identifier
           Entity Type
           Portal IP-Address
           Portal IP-Address, Portal TCP/UDP Port
           iSCSI Node Type
           iSCSI Identifier
           iFCP Node Port WWN
           iFCP Node Port Type
           iFCP Node Port FC-4 Type

   If the network entities matching key attributes are not in the same
   Discovery Domain as the Source Attribute, then the results for the
   network entity will not be included in the response message.

   The Operating Attributes are the attributes whose values are being
   queried.

7.7.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, iSCSI Names, 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.7.1.  The source is used to scope the Get Next process to

Gibbons, Tseng, Monia      Standards Track                         50

iSNS                          April 2001

   the Discovery Domains that the source attribute is a member of.  It
   is the Entity Identifier, iSCSI Name, 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 an Entity Identifier, iSCSI Name, 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, iSCSI Name, 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.7.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.7.1.  Valid Key Attributes are shown below:

          Valid Key Attributes for DeregDev
          ---------------------------------
           Entity Identifier
           Portal IP-Address
           Portal IP-Address, Portal TCP/UDP Port
           iSCSI Name
           iFCP Node Port WWN
           iFCP Device Node WWN

   The removal of the object will initiate an SCN message to registered
   iSNS clients that are in the same DD as the removed device or port.
   After removing the port or device, the iSNS server sends back an
   acknowledgement to the iSNS client.

7.7.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.7.1.  Valid Key Attributes
   for an SCNReg are shown below:



Gibbons, Tseng, Monia      Standards Track                         51

iSNS                          April 2001

          Valid Key Attributes for SCNReg
          --------------------------------
           iSCSI Name
           Port WWN (iFCP Only)
           Entity Identifier (FCIP Only)

   The network entity nodes 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.5.12 describes each flag used in the EVENT TYPE FLAGS
   field.

7.7.5.6  SCN Deregister Request (SCNDereg)

   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.7.1.  Valid Key Attributes for an SCNDereg
   are shown below:

          Valid Key Attributes for SCNDereg
          --------------------------------
           Entity Identifier (FCIP only)
           iSCSI Name (iSCSI only)
           Port WWN (iFCP only)

   The network entities matching the Key Attributes are deregistered
   for SCNs.

   There are no Delimiter or Operating Attributes in the SCNDereg
   message.

7.7.5.7  SCN Event (SCNEvent)

   The SCNEvent message type is 0x0007. The SCNEvent is a special
   message generated by an iSNS client.  The SCNEvent allows the client
   to request generation of a State Change Notification (SCN) message
   by the iSNS server.  The SCN, sent by the iSNS server, then notifies
   other registered network 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.


Gibbons, Tseng, Monia      Standards Track                         52

iSNS                          April 2001

   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, iSCSI
   Name, 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
   All Others        Reserved

7.7.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:















Gibbons, Tseng, Monia      Standards Track                         53

iSNS                          April 2001

             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)  |
             +----------------------------------------+
             |                 . . .                  |
             +----------------------------------------+

   The Destination Attribute is the object that is receiving the SCN.
   The Destination Attribute can be an Entity Identifier, iSCSI Name,
   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, iSCSI
   Name, 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
   All Others        Reserved

7.7.5.9  DD Register (DDReg)

   The DDReg message type is 0x0009.  This message allows an iSNS
   client to create a new Discovery Domain (DD), update an existing DD
   Symbolic Name, or add DD members.



Gibbons, Tseng, Monia      Standards Track                         54

iSNS                          April 2001

   DDs are uniquely defined using DD_IDs.  DD registration attributes
   are described in section 6.8.

   The DDReg message payload contains the Source Attribute, Key
   Attributes and Operating Attributes. The Source attribute of the
   DDReg message is as defined in Section 7.7.1.

   For the initial DD registration a Key Attribute is not required, but
   is required for update registrations to existing DDs.  The Key
   Attribute for a DDReg message is the DD ID for the domain being
   updated.  If the key attribute matches an existing DD, then the DD
   will be updated with the Operating Attributes.

   The operating attributes can contain the DD ID and DD Symbolic Name
   for a new registration.  If the DD ID is to be assigned by the iSNS
   then the DD ID will be of length 0 and the assigned value shall be
   returned in the response.

   The Operating Attributes also contain the iSCSI Node Identifier,
   iFCP WWPN, or FCIP Entity_ID of iSNS clients to be added to the DD.

7.7.5.10 DD Deregister (DDDereg)

   The DDDereg message type is 0x000A.  This message allows an iSNS
   client to deregister an existing Discovery Domain (DD) or remove
   members from an existing DD.

   DDs are uniquely defined using DD_IDs.  DD registration attributes
   are described in section 6.8.

   The DDDereg message payload contains a Source Attribute, Key
   Attribute, and Operating Attributes.  The Source attribute of the
   DDDereg message is as defined in Section 7.7.1.

   The Key Attribute for a DDDereg message is the DD ID for the domain
   being removed, or having members removed.  If the DD ID matches an
   existing DD, and there are no operating attributes, then the DD will
   be removed and a success error code returned.  If the key attribute
   does not match an existing DD then the error code “No Such Entry”
   will be returned.

   If the DD ID matches an existing DD, and there are operating
   attributes matching DD members, then the DD members identified by
   the operating attributes SHALL be removed from the DD and a success
   error code returned.  If the operating attributes do not match DD
   members, then the error code “No Such Entry” will be returned, and
   no DD members shall be removed.

7.7.5.11 DDS Register (DDSReg)

   The DDSReg message type is 0x000B.  This message allows an iSNS
   client to create a new Discovery Domain Set (DDS), update an
   existing DDS Symbolic Name, or add DDS members.


Gibbons, Tseng, Monia      Standards Track                         55

iSNS                          April 2001

   DDS’s are uniquely defined using DDS_ID’s.  DDS registration
   attributes are described in section 6.8.

   The DDSReg message payload contains the Source Attribute, Key
   Attributes and Operating Attributes. The Source attribute of the
   DDSReg message is as defined in Section 7.7.1.

   For the initial DDS registration a Key Attribute is not required,
   but is required for update registrations to existing DDS’s.  The Key
   Attribute for a DDSReg message is the DDS ID for the set being
   updated.  If the key attribute matches an existing DDS, then the DDS
   will be updated with the Operating Attributes.

   The operating attributes can contain the DDS ID, DDS Symbolic Name,
   and DDS Status for a new registration.  If the DDS ID is to be
   assigned by the iSNS then the DDS ID will be of length 0 and the
   assigned value shall be returned in the response.

   The Operating Attributes also contain the DD_ID’s of Discovery
   Domains to be added to the DDS.

7.7.5.12 DDS Deregister (DDSDereg)

   The DDSDereg message type is 0x000C. This message allows an iSNS
   client to deregister an existing Discovery Domain Set (DDS) or
   remove some DD’s from an existing DDS.

   DDSs are uniquely defined using DDS_IDs.  DDS registration
   attributes are described in section 6.8.

   The DDSDereg message payload contains a Source Attribute, Key
   Attribute, and Operating Attributes.  The Source attribute of the
   DDSDereg message is as defined in Section 7.7.1.

   The Key Attribute for a DDSDereg message is the DDS ID for the set
   being removed, or having members removed.  If the DDS ID matches an
   existing DDS, and there are no operating attributes, then the DDS
   will be removed and a success error code returned.  If the key
   attribute does not match an existing DDS then the error code “No
   Such Entry” will be returned.

   If the DDS ID matches an existing DDS, and there are operating
   attributes matching DDS members, then the DDS members will be
   removed from the DDS and a success error code returned.  If the
   operating attributes do not match DDS members, then the error code
   “No Such Entry” will be returned.

7.7.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.

Gibbons, Tseng, Monia      Standards Track                         56

iSNS                          April 2001


   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.7.5.14 Name Service Heartbeat (Heartbeat)

   This optional message is regularly issued by the iSNS server to a
   broadcast or multicast address at an administratively-configured
   time interval.  The payload of this message contains a single 4-byte
   unsigned integer field containing the heartbeat period, the number
   of seconds between each successive heartbeat message.  This
   information is NOT in TLV format.  The contents of the remainder of
   this message are vendor-specific.

   This message allows iSNS clients listening to the broadcast or
   multicast address to discover the IP address of the iSNS server by
   examining the source IP address of the message.  It may also be used
   by backup iSNS servers to monitor the health and status of the
   primary iSNS server.

   There is no response message to the Name Service Heartbeat.

7.7.5.15 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.7.5.16 Request Switch ID (RqstSwId)

   The RqstSwId message type is 0x0011. This optional message is used
   for FCIP and iFCP Transparent Mode to allocate non-overlapping
   SWITCH_ID values between 1 and 239. 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.  To obtain multiple SWITCH_ID values, this request must be
   repeated multiple times to the iSNS server.

   The RqstSwId payload contains three TLV attributes in the following
   order: the requesting entity EID as the source attribute, the Space
   Identifier as the key attribute, and Preferred ID as the operating
   attribute. The Space Identifier is a string identifying the domain
   space for which the iSNS server shall allocate non-overlapping
   integer SWITCH_ID values between 1 and 239.  The Preferred_ID is the
   nominal SWITCH_ID value requested by the iSNS client.  If the
   Preferred_ID value is available and has not been already allocated
   for the Space_Identifier specified in the message, the iSNS server


Gibbons, Tseng, Monia      Standards Track                         57

iSNS                          April 2001

   shall return the requested Preferred_ID value as the Assigned_ID to
   the requesting client.

   The RqstSwId response contains an Error Code, and the TLV attribute
   Assigned ID, which contains the integer value in the space
   requested. If no further unallocated values are available from this
   space, the iSNS server SHALL respond with the error code 18
   "SWITCH_ID not available".

   Once an SWITCH_ID value has been allocated by the iSNS server for a
   give Space_Identifier, that SWITCH_ID value shall not be reused
   until it has been deallocated by the iSNS client to which the value
   was assigned, or the ESI message detects that the iSNS client no
   longer exists on the network.

   The iSNS server and client SHALL use TCP to transmit and receive
   RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages.

7.7.5.17 Release Switch ID (RlseSwId)

   The RlseSwId message type is 0x0012. This optional message may be
   used by FCIP and iFCP Transparent Mode to release integer identifier
   values used to assign 3-byte Fibre Channel PORT_ID values.

   The RlseSwId message contains three TLV attributes in the following
   order:  the requesting entity EID as the source attribute, the
   Space_Identifier as the key attribute, and Assigned_ID as the
   operating attribute.  Upon receiving the RlseSwId message, the iSNS
   server shall deallocate the SWITCH_ID value contained in the
   Assigned_ID attribute for the Space_Identifier attribute specified.
   Upon deallocation, that SWITCH_ID value can now be requested by, and
   assigned to, a different iSNS client.

   The iSNS server and client SHALL use TCP to transmit and receive
   RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages.

7.7.5.18 Get Switch IDs (GetSwIds)

   The GetSwIds message type is 0x0013. This optional message is used
   to learn the currently-used SWITCH_ID values allocated for a given
   Space_Identifier.

   The GetSwIds message payload contains a Source Attribute and Key
   Attribute.  The Source attribute of the GetSwIds message is as
   defined in Section 7.7.1.

   The Key Attribute for the GetSwIds message is the Space_Identifier.
   The response to this message returns all of the SWITCH_ID values
   that have been allocated for the Space_Identifier specified.

7.8      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                         58

iSNS                          April 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.8.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                         59

iSNS                          April 2001

   Error Code       Error Description
   ----------       -----------------
      0             No Error
      1             Unknown Error
      2             Message Format Error
      3             Invalid Registration
      4             Invalid Registration Update
      5             Invalid Query
      6             Authentication Unknown
      7             Authentication Absent
      8             Authentication Failed
      9             No Such Entry
     10             Version Not Supported
     11             Internal Bus Error
     12             Busy Now
     13             Option Not Understood
     14             Invalid Update
     15             Message Not Supported
     16             SCN Event Rejected
     17             SCN Registration Rejected
     18             Client Status Inquiry Not Available
     19             DOMAIN_ID not available

7.8.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.8.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.8.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.8.5    Registration and Query Message Types

   The following describes each query and message type.

Gibbons, Tseng, Monia      Standards Track                         60

iSNS                          April 2001


7.8.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 Attributes contain the set of keys for the objects
   registered by the Register Device Attribute message.  If the iSNS
   assigned a unique Entity Identifier for a network entity, then the
   key attribute field shall contain the assigned Entity Identifier.

   There are no Operating Attributes in the RegDevRsp message.

7.8.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.8.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.8.5.4  Deregister Device Response (DeregDevRsp)

   The DeregDevRsp message type is 0x8004. If the DeregDev operation
   completed successfully then the code of “No Error” is returned.  If
   an error occurred then the appropriate code will be returned.

Gibbons, Tseng, Monia      Standards Track                         61

iSNS                          April 2001


   The DeregDevRsp message does not contain any key or operating
   attributes.

7.8.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.8.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.8.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.8.5.8  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.8.5.9  DD Register Response (DDRegRsp)

   The DDRegRsp message type is 0x8009. If the DDReg operation
   completed successfully then the code of “No Error” is returned.  If
   an error occurred then the appropriate code will be returned.

   If successful, the DD ID of the DD created or updated during the
   DDReg operation will be returned as an operating attribute of the
   message.

7.8.5.10 DD Deregister Response (DDDeregRsp)

   The DDDeregRsp message type is 0x800A.  If the DDDereg operation
   completed successfully then the code of “No Error” is returned.  If
   an error occurred then the appropriate code will be returned.

Gibbons, Tseng, Monia      Standards Track                         62

iSNS                          April 2001


   If successful, the DD ID of the DD removed or updated during the
   DDDereg operation will be returned as an operating attribute of the
   message.

7.8.5.11 DDS Register Response (DDSRegRsp)

   The DDSRegRsp message type is 0x800B. If the DDSRegRsp operation
   completed successfully then the code of “No Error” is returned.  If
   an error occurred then the appropriate code will be returned.

   If successful, the DDS ID of the DDS created or updated during the
   DDSReg operation will be returned as an operating attribute of the
   message.

7.8.5.12 DDS Deregister Response (DDSDeregRsp)

   The DDSDeregRsp message type is 0x800C. If the DDSDeregRsp operation
   completed successfully then the code of “No Error” is returned.  If
   an error occurred then the appropriate code will be returned.

   If successful, the DDS ID of the DDS removed or updated during the
   DDSDereg operation will be returned as an operating attribute of the
   message.

7.8.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.8.5.14 Request Network Time Response (RqstTimeRsp)

   The RqstTimeRsp message type is 0x8010.  The format of the
   RqstTimeRsp payload is different than other response message
   payloads, and is shown below:







Gibbons, Tseng, Monia      Standards Track                         63

iSNS                          April 2001

             MSb                                    LSb
             31                                       0
             +----------------------------------------+
             |          4-byte ERROR CODE             |
             +----------------------------------------+
             |          8-byte TIMESTAMP              |
             +----------------------------------------+

   The TIMESTAMP is a 8-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.8.5.15 Request Switch ID Response (RqstSwIdRsp)

   The RqstSwIdRsp message type is 0x8011.  This message provides the
   response for RqstSwId.

   The RqstSwId response contains an Error Code and the TLV attribute
   Assigned ID, which contains the integer value in the space
   requested. If no further unallocated values are available from this
   space, the iSNS server SHALL respond with the error code 19
   "SWITCH_ID not available".

   Once a SWITCH_ID value is allocated by the iSNS server, it shall not
   be reused until it has been deallocated by the iSNS client to which
   the value was assigned, or the ESI message detects that the iSNS
   client no longer exists on the network.

   The iSNS server and client SHALL use TCP to transmit and receive
   RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages.

7.8.5.16 Release Switch ID Response (RlseSwIdRsp)

   The RlseSwIdRsp message type is 0x8012. This message provides the
   response for RlseSwId.  The response contains an Error indicating if
   the request was successful or not.  If the Assigned_ID value in the
   original RlseSwId message is not allocated, then the iSNS server
   SHALL respond with this message using the error code 20 “SWITCH_ID
   not allocated”.

   The iSNS server and client SHALL use TCP to transmit and receive
   RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages.

7.8.5.17 Get Switch IDs Response (GetSwIdRsp)

   The GetSwIdsResp message type is 0x8013. This optional message is
   used determine which SWITCH_ID values have been allocated for the
   Space_Identifier specified in the original GetSwId request message.

   The GetSwIds response message payload contains an error code
   indicating if the request was successful, and a list of the Assigned


Gibbons, Tseng, Monia      Standards Track                         64

iSNS                          April 2001

   IDs from the space requested.  The Assigned_ID attributes are listed
   in TLV format.

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.  This data integrity
   and authentication mechanism is compatible with that used by Service
   Location Protocol [RFC2608].

8.2      Confidentiality

   If the operational evironment requires confidentiality in iSNSP
   queries and responses, then the iSNSP shall be used with Transport
   Layer Security (TLS).  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

   [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,

Gibbons, Tseng, Monia      Standards Track                         65

iSNS                          April 2001

                  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                         66

iSNS                          April 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                         67

iSNS                          April 2001


Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."




























Gibbons, Tseng, Monia      Standards Track                         68

iSNS                          April 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                         69

iSNS                          April 2001


A.1.1    Simple iSCSI Target Registration

   In this example, a simple target with a single iSCSI name registers
   with the iSNS.  The target has not been assigned a Fully Qualified
   Domain Name (FQDN) by the administrator.

   +--------------------------+------------------+-------------------+
   |    iSCSI Target Device   |    iSNS          |Management Station |
   +--------------------------+------------------+-------------------+
   |Discover iSNS--SLP------->|                  |/*mgmt station is  |
   |                          |<--SLP--iSNS Here:| administratively  |
   |                          |      192.36.53.1 | authorized to view|
   |                          |                  | all DD's.  Device |
   |                          |                  | NAMEabcd has been |
   |      RegDevAttr--------->|                  | previously placed |
   |Oper Attrs:               |                  | into DDabcd******/|
   |tag=1: NULL               |                  |                   |
   |tag=2: "iSCSI"            |                  |                   |
   |tag=16: "192.36.4.5"      |                  |                   |
   |tag=17: "5001"            |                  |                   |
   |tag=19: 0                 |                  |                   |
   |tag=32: "NAMEabcd"        |                  |                   |
   |tag=33: "target"          |                  |                   |
   |tag=34: "disk 1"          |                  |                   |
   |                          |<---RegDevAttrRsp |                   |
   |                          |SUCCESS           |                   |
   |                          |tag=1: "iSNS:0001"|                   |
   |                          |tag=16: "192.36.4.5"                  |
   |                          |tag=17: "5001"    |                   |
   |                          |tag=32: "NAMEabcd"|                   |
   |                          |                  |                   |
   |      DevAttrQry--------->|      SCN-------->|                   |
   |Src:(tag=32) "NAMEabcd"   |(or SNMP trap)    |                   |
   |Key:(tag=2) "iSCSI"       |tag=1: "iSNS:0001"                    |
   |Key:(tag=33) "initiator"  |dest: "mgmt.foo.com"                  |
   |Oper Attrs:               |CHANGE IN NETWORK |                   |
   |tag=16:  NULL             |                  |                   |
   |tag=17:  NULL             |                  |<-------SCNRsp     |
   |tag=32:  NULL             |                  |                   |
   |/*Query asks for all iSCSI|                  |                   |
   |devices' IP address, port |<---DevAttrQryRsp |                   |
   |number, and Name*/        |SUCCESS           |                   |
   |                          |tag=16:"192.36.4.1"                   |
   |                          |tag=17:"50000"    |                   |
   |                          |tag=32:"devpdq"   |                   |
   |                          |tag=16:"192.1.3.2"|<-----DevAttrQry   |
   |                          |tag=17:"50000"    |src: “MGMTname1”   |
   |                          |tag=32:"devrst"   |key:(tag=1)iSNS:0001
   |                          |                  |Op Attrs:          |
   |/*************************|                  |tag=16:  NULL      |
   |Our target "iSNS:0001"    |                  |tag=17:  NULL      |
   |discovers two initiators  |                  |tag=32:  NULL      |
   |in the same DD.  It will  |                  |                   |

Gibbons, Tseng, Monia      Standards Track                         70

iSNS                          April 2001

   |accept iSCSI logins from  |                  |                   |
   |these two identified      |                  |                   |
   |initiators presented by   |                  |                   |
   |iSNS*********************/| DevAttrQryRsp--->|                   |
   |                          |SUCCESS           |                   |
   |                          |tag=16: 192.36.4.5|                   |
   |                          |tag=17: 5001      |                   |
   |                          |tag=32: NAMEabcd  |                   |
   +--------------------------+------------------+-------------------+

A.1.2    Target Registration and DD Configuration

   In this example, a more complex target registers with the iSNS.
   This target has been configured with a Fully Qualified Domain Name
   (FQDN) in the DNS servers, and the user wishes to use this
   identifier for the device.  Also, the user wishes to use public key
   certificates in the iSCSI login authentication.

   +--------------------------+------------------+-------------------+
   |    iSCSI Target Device   |    iSNS          |Management Station |
   +--------------------------+------------------+-------------------+
   |Discover iSNS--SLP-->     |                  |/*mgmt station is  |
   |                          |<--SLP--iSNS Here:| administratively  |
   |                          |      192.36.53.1 | authorized to view|
   |      RegDevAttr-->       |                  | all DD's ********/|
   |Oper Attrs:               |                  |                   |
   |tag=1: "jbod1.foo.com"    |                  |                   |
   |tag=2: "iSCSI"            |                  |                   |
   |tag=16: "192.36.34.4"     |                  |                   |
   |tag=17: "5001"            |                  |                   |
   |tag=19: "5 seconds"       |                  |                   |
   |tag=16: "192.36.53.5"     |                  |                   |
   |tag=17: "5001"            |                  |                   |
   |tag=32: "NAMEabcd"        |                  |                   |
   |tag=33: "Target"          |/*****************|                   |
   |tag=34: "Volume 1"        |jbod1.foo.com is  |                   |
   |tag=40: X.509 cert blob 1 |now registered in |                   |
   |tag=32: "NAMEefgh"        |iSNS, but is not  |                   |
   |tag=33: "Target"          |in any DD. Therefore,                 |
   |tag=34: "Volume 2"        |no other devices  |                   |
   |tag=40: X.509 cert blob 2 |can "see" it.     |                   |
   |                          |*****************/|                   |
   |                          |<--RegDevAttrRsp  |                   |
   |                          |SUCCESS           |                   |
   |                          |tag=1: "jbod1.foo.com"                |
   |                          |tag=16: "192.36.34.4"                 |
   |                          |tag=17: "5001"    |                   |
   |                          |tag=16: "192.36.53.5"                 |
   |                          |tag=17: "5001"    |                   |
   |                          |tag=32: "NAMEabcd"|                   |
   |                          |tag=32: "NAMEefgh"|                   |
   |                          |                  |                   |
   |                          |       SCN------> |                   |
   |                          |  (or SNMP trap)  |                   |

Gibbons, Tseng, Monia      Standards Track                         71

iSNS                          April 2001

   |                          |tag=1: jbod1.foo.com                  |
   |                          |dest: mgmt.foo.com|                   |
   |                          |CHANGE IN NETWORK |                   |
   |                          |                  |                   |
   |                          |                  |<--SCNRsp          |
   |                          |                  |<--DevAttrQry      |
   |                          |                  |src: mgmt.foo.com  |
   |                          |                  |key:  (tag=1)      |
   |                          |                  |  jbod1.foo.com    |
   |                          |                  |Op Attr: (tag=2)   |
   |                          |                  |Op Attr: (tag=16)  |
   |                          |                  |Op Attr: (tag=17)  |
   |                          |                  |Op Attr: (tag=32)  |
   |                          |                  |                   |
   |                          | DevAttrQryRsp--> |                   |
   |                          |SUCCESS           |                   |
   |                          |tag=2:  "iSCSI"   |                   |
   |                          |tag=16: 192.36.34.4                   |
   |                          |tag=17: 5001      |                   |
   |                          |tag=16: 192.36.53.5                   |
   |                          |tag=17: 5001      |/**Mgmt Station ***|
   |                          |tag=32:"NAMEabcd" |displays device,   |
   |                          |tag=32:"NAMEefgh" |the operator decides
   |                          |                  |to place "NAMEabcd"|
   |                          |                  |into Domain "DDxyz"|
   |/*************************|                  |******************/|
   |Target is now registered  |                  |                   |
   |in iSNS.  It has been placed                 |<--RegDevDD        |
   |in DDxyz by management    |                  |src: "mgmt.foo.com"|
   |station.                  |                  |key: "DDxyz ID"    |
   |*************************/|                  |Op Attr:           |
   |                          |                  |tag=32: "NAMEabcd" |
   |                          |  RegDevDDRsp---->|                   |
   |                          |    SUCCESS       |                   |
   +--------------------------+------------------+-------------------+

A.1.3    Initiator Registration and Target Discovery

   The following example illustrates a new initiator registering with
   the iSNS, and discovering the target NAMEabcd from the example in
   A.1.2.

   +--------------------------+------------------+-------------------+
   |    iSCSI Initiator       |    iSNS          |Management Station |
   +--------------------------+------------------+-------------------+
   |Discover iSNS--SLP-->     |                  |/*mgmt station is  |
   |                          |<--SLP--iSNS Here:| administratively  |
   |                          |      192.36.53.1 | authorized to view|
   |RegDevAttr-->             |                  | all DD's ********/|
   |Oper Attrs:               |                  |                   |
   |tag=1: "svr1.foo.com"     |                  |                   |
   |tag=2: "iSCSI"            |                  |                   |
   |tag=16: "192.20.3.1"      |/*****************|                   |
   |tag=17: "5001"            |Device not in any |                   |

Gibbons, Tseng, Monia      Standards Track                         72

iSNS                          April 2001

   |tag=19: 5 seconds         |DD, so it is      |                   |
   |tag=32: "NAMEijkl"        |inaccessible by   |                   |
   |tag=33: "Initiator"       |other devices     |                   |
   |tag=34: "Server1"         |*****************/|                   |
   |tag=39: X.509 cert blob 3 |                  |                   |
   |                          |<--RegDevAttrRsp  |                   |
   |                          |SUCCESS           |                   |
   |                          |tag=1: "svr1.foo.com"                 |
   |                          |tag=16: "192.20.3.1"                  |
   |                          |tag=17: "5001"    |                   |
   |                          |tag=32: "NAMEijkl"|                   |
   |                          |                  |                   |
   |                          |       SCN------> |                   |
   |                          |  (or SNMP trap)  |                   |
   |                          |tag=1: svr1.foo.com                   |
   |                          |dest: mgmt.foo.com|                   |
   |                          |CHANGE IN NETWORK |                   |
   |                          |                  |                   |
   |                          |                  |<------SCNRsp      |
   |                          |                  |<----DevAttrQry    |
   |                          |                  |src: mgmt.foo.com  |
   |                          |                  |key:  (tag=1)      |
   |                          |                  |  svr1.foo.com     |
   |                          |                  |Op Attr: (tag=2)   |
   |                          |                  |Op Attr: (tag=16)  |
   |                          |                  |Op Attr: (tag=17)  |
   |                          |                  |Op Attr: (tag=32)  |
   |                          | DevAttrQryRsp--> |                   |
   |                          |SUCCESS           |                   |
   |                          |tag=2:  "iSCSI"   |                   |
   |                          |tag=16:192.20.3.1 |                   |
   |                          |tag=17: "5001"    |                   |
   |                          |tag=32:"NAMEijkl" |                   |
   |                          |                  |/**Mgmt Station ***|
   |                          |                  |displays device,   |
   |                          |                  |the operator decides
   |                          |                  |to place "NAMEijkl"|
   |                          |                  |into Domain "DDxyz"|
   |                          |                  |with device NAMEabcd
   |                          |                  |******************/|
   |                          |                  |<--RegDevDD        |
   |                          |                  |src: (tag=1)       |
   |                          |                  |  "mgmt.foo.com"   |
   |                          |                  |key: "DDxyz ID"    |
   |                          |                  |tag=32: "NAMEijkl  |
   |                          |                  |                   |
   |                          |   RegDevDDRsp--->|/******************|
   |                          |     SUCCESS      |"NAMEijkl" has been|
   |                          |                  |moved to "DDxyz"   |
   |                          |                  |******************/|
   |                          |<-----SCN         |                   |
   |                          |tag=32: "NAMEijkl"|                   |
   |                          |CHANGE IN DD MEMBERSHIP               |
   |    DevAttrQry----------->|                  |                   |

Gibbons, Tseng, Monia      Standards Track                         73

iSNS                          April 2001

   |src: "NAMEabcd"           |/*****************|                   |
   |key:(tag=2) "iSCSI"       |Note that NAMEabcd|                   |
   |key:(tag=33) "Target"     |also receives an  |                   |
   |Op Attr: (tag=16)         |SCN that NAMEijkl |                   |
   |Op Attr: (tag=17)         |is in the same DD |                   |
   |Op Attr: (tag=32)         |*****************/|                   |
   |Op Attr: (tag=34)         |                  |                   |
   |Op Attr: (tag=40)         |<-----AttrQryRsp  |                   |
   |                          |SUCCESS           |                   |
   |                          |tag=16: 192.36.34.4                   |
   |                          |tag=17: 5001      |                   |
   |                          |tag=16: 192.36.53.5                   |
   |                          |tag=17: 5001      |                   |
   |                          |tag=32: NAMEabcd  |                   |
   |                          |tag=34: Volume 1  |                   |
   |                          |tag=40: X.509 cert blob 2             |
   |                          |                  |                   |
   |/***The initiator has discovered             |                   |
   |the target, and has everything               |                   |
   |needed to complete iSCSI login               |                   |
   |The same process occurs on the               |                   |
   |target side; the SCN prompts the             |                   |
   |target to download the list of               |                   |
   |authorized initiators from the               |                   |
   |iSNS (i.e., those initiators in the          |                   |
   |same DD as the target.************/          |                   |
   +--------------------------+------------------+-------------------+




























Gibbons, Tseng, Monia      Standards Track                         74


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/