IPS                                                    Josh Tseng
   Internet Draft                                      Kevin Gibbons
   <draft-ietf-ips-isns-12.txt>                       Nishan Systems
   Standards Track
   Expires February 2003                           Franco Travostino
                                                     Nortel Networks

                                                       Curt Du Laney
                                                                 IBM

                                                           Joe Souza
                                                           Microsoft

                                                         August 2002


                    Internet Storage Name Service (iSNS)

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Acknowledgements

   Numerous individuals contributed to the creation of this draft
   through their careful review and submissions of comments and
   recommendations.  We acknowledge the following persons for their
   technical contributions to this document:  Mark Bakke (Cisco), John
   Hufferd (IBM), Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe
   Czap (IBM), John Dowdy (IBM), Tom McSweeney (IBM), Jim Hafner (IBM),
   Chad Gregory (Intel), Yaron Klein (Sanrad), Larry Lamers (SAN
   Valley), Jack Harwood (EMC), David Black (EMC), David Robinson
   (Sun), Alan Warwick (Microsoft), Bob Snead (Microsoft), Fa Yoeu
   (Nishan), Charles Monia (Nishan), Ken Hirata (Vixel), Howard Hall
   (Pirus), Malikarjun Chadalapaka (HP), Marjorie Krueger (HP), and
   Vinai Singh (American Megatrends).


Gibbons, Tseng, Monia      Standards Track                   [Page 1]


                 Internet Storage Name Service (iSNS)      August 2002

Comments

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

                             Table of Contents

Status of this Memo..................................................1
Acknowledgements.....................................................1
Comments.............................................................2
1.    Abstract.......................................................6
2.    About this Document............................................6
2.1   Conventions Used in this Document..............................6
2.2   Purpose of this Document.......................................6
3.    iSNS Overview..................................................6
3.1   iSNS Architectural Components..................................7
3.1.1 iSNS Protocol (iSNSP)..........................................7
3.1.2 iSNS Client....................................................7
3.1.3 iSNS Server....................................................7
3.1.4 iSNS Database..................................................7
3.1.5 iSCSI..........................................................7
3.1.6 iFCP...........................................................8
3.2   iSNS Functional Overview.......................................8
3.2.1 Name Registration Service......................................8
3.2.2 Discovery Domain and Login Control Service (Zoning)............8
3.2.3 State Change Notification Service.............................10
3.2.4 Open Mapping Between Fibre Channel and iSCSI Devices..........10
3.3   iSNS Usage Model..............................................11
3.3.1 iSCSI Initiator...............................................11
3.3.2 iSCSI Target..................................................11
3.3.3 iSCSI-FC Gateway..............................................12
3.3.4 iFCP Gateway..................................................12
3.3.5 Management Station............................................12
3.4   Administratively Controlled iSNS Settings.....................12
3.5   iSNS Server Discovery.........................................13
3.5.1 Service Location Protocol (SLP)...............................13
3.5.2 Dynamic Host Configuration Protocol (DHCP)....................14
3.5.3 iSNS Heartbeat Message........................................14
3.6   iSNS and NAT..................................................14
3.7   Transfer of iSNS Database Records between iSNS Servers........14
3.8   Backup iSNS Servers...........................................16
4.    iSNS Object Model.............................................18
4.1   NETWORK ENTITY Object.........................................18
4.2   PORTAL Object.................................................18
4.3   STORAGE NODE Object...........................................18
4.4   FC DEVICE Object..............................................19
4.5   DISCOVERY DOMAIN Object.......................................19
4.6   DISCOVERY DOMAIN SET Object...................................19
4.7   iSNS Database Model...........................................19
5.    iSNS Implementation Requirements..............................20
5.1   iSCSI Requirements............................................20
5.1.1 Required Attributes for Support of iSCSI......................20
5.1.2 Example iSCSI Object Model Diagrams...........................21
5.1.3 Required Commands and Response Messages for Support of iSCSI..23

Tseng, Gibbons, et al.     Standards Track                   [Page 2]


                 Internet Storage Name Service (iSNS)      August 2002

5.2   iFCP Requirements.............................................24
5.2.1 Required Attributes for Support of iFCP.......................24
5.2.2 Example iFCP Object Model Diagram.............................26
5.2.3 Required Commands and Response Messages for Support of iFCP...26
5.3   Use of TCP For iSNS Communication.............................28
5.4   Use of UDP For iSNS Communication.............................28
6.    iSNSP Message Format..........................................29
6.1   iSNSP PDU Header..............................................29
6.1.1 iSNSP Version.................................................29
6.1.2 iSNSP Function ID.............................................30
6.1.3 iSNSP PDU Length..............................................30
6.1.4 iSNSP Flags...................................................30
6.1.5 iSNSP Transaction ID..........................................30
6.1.6 iSNSP Sequence ID.............................................30
6.2   iSNSP Message Segmentation and Reassembly.....................31
6.3   iSNSP Message Payload.........................................31
6.3.1 Attribute Value 4-Byte Alignment..............................32
6.4   iSNSP Response Status Codes...................................32
6.5   iSNS Multicast Message Authentication.........................32
6.6   Registration and Query Messages...............................34
6.6.1 Source Attribute..............................................34
6.6.2 Message Key Attributes........................................35
6.6.3 Delimiter Attribute...........................................35
6.6.4 Operating Attributes..........................................35
6.6.5 Registration and Query Request Message Types..................36
6.7   Response Messages.............................................49
6.7.1 Status Code...................................................49
6.7.2 Message Key Attributes in Response............................50
6.7.3 Delimiter Attribute in Response...............................50
6.7.4 Operating Attributes in Response..............................50
6.7.5 Registration and Query Response Message Types.................50
6.8   Vendor Specific Messages......................................54
7.    iSNS Message Attributes.......................................54
7.1   iSNS Attribute Summary........................................54
7.2   Entity Identifier-Keyed Attributes............................56
7.2.1 Entity Identifier (EID).......................................56
7.2.2 Entity Protocol...............................................57
7.2.3 Management IP Address.........................................57
7.2.4 Entity Registration Timestamp.................................57
7.2.5 Protocol Version Range........................................58
7.2.6 Registration Period...........................................58
7.2.7 Entity Index..................................................58
7.2.8 Entity ISAKMP Phase-1 Proposals...............................59
7.2.9 Entity Certificate............................................59
7.3   Portal-Keyed Attributes.......................................59
7.3.1 Portal IP-Address.............................................59
7.3.2 Portal TCP/UDP Port...........................................59
7.3.3 Portal Symbolic Name..........................................60
7.3.4 Entity Status Inquiry Interval................................60
7.3.5 ESI Port......................................................60
7.3.6 Portal Group Tag..............................................61
7.3.7 Portal Index..................................................61
7.3.8 SCN Port......................................................61
7.3.9 Portal Security Bitmap........................................62

Tseng, Gibbons, et al.     Standards Track                   [Page 3]


                 Internet Storage Name Service (iSNS)      August 2002

7.3.10Portal ISAKMP Phase-1 Proposals...............................62
7.3.11Portal ISAKMP Phase-2 Proposals...............................63
7.3.12Portal Certificate............................................63
7.4   iSCSI Node-Keyed Attributes...................................63
7.4.1 iSCSI Name....................................................63
7.4.2 iSCSI Node Type...............................................63
7.4.3 iSCSI Node Alias..............................................64
7.4.4 iSCSI Node SCN Bitmap.........................................64
7.4.5 iSCSI Node Index..............................................65
7.4.6 WWNN Token....................................................66
7.4.7 iSCSI AuthMethod..............................................67
7.4.8 iSCSI Node Certificate........................................67
7.5   FC Port Name-Keyed Attributes.................................67
7.5.1 FC Port Name (WWPN)...........................................67
7.5.2 Port ID (FC_ID)...............................................68
7.5.3 FC Port Type..................................................68
7.5.4 Symbolic Port Name............................................68
7.5.5 Fabric Port Name (FWWN).......................................68
7.5.6 Hard Address..................................................68
7.5.7 Port IP Address...............................................68
7.5.8 Class of Service (COS)........................................69
7.5.9 FC-4 Types....................................................69
7.5.10FC-4 Descriptor...............................................69
7.5.11FC-4 Features.................................................69
7.5.12iFCP SCN Bitmap...............................................69
7.5.13Port Role.....................................................70
7.5.14Port Certificate..............................................71
7.6   Node-Keyed Attributes.........................................71
7.6.1 FC Node Name (WWNN)...........................................71
7.6.2 Symbolic Node Name............................................71
7.6.3 Node IP Address...............................................71
7.6.4 Node IPA......................................................71
7.6.5 Node Certificate..............................................71
7.6.6 Proxy iSCSI Name..............................................71
7.7   Other Attributes..............................................72
7.7.1 FC-4 Type Code................................................72
7.7.2 iFCP Switch Name..............................................72
7.7.3 iFCP Transparent Mode Commands................................72
7.8   iSNS Server-Specific Attributes...............................73
7.8.1 iSNS Server Vendor OUI........................................73
7.9   Discovery Domain Registration Attributes......................73
7.9.1 DD Set ID Keyed Attributes....................................73
7.9.2 DD ID Keyed Attributes........................................74
7.10  Vendor-Specific Attributes....................................75
7.10.1Vendor-Specific Server Attributes.............................75
7.10.2Vendor-Specific Entity Attributes.............................76
7.10.3Vendor-Specific Portal Attributes.............................76
7.10.4Vendor-Specific iSCSI Node Attributes.........................76
7.10.5Vendor-Specific FC Port Name Attributes.......................76
7.10.6Vendor-Specific FC Node Name Attributes.......................76
7.10.7Vendor-Specific Discovery Domain Attributes...................76
7.10.8Vendor-Specific Discovery Domain Set Attributes...............76
7.10.9Other Vendor-Specific Attributes..............................76
7.11  Standards-Based Extensions....................................77

Tseng, Gibbons, et al.     Standards Track                   [Page 4]


                 Internet Storage Name Service (iSNS)      August 2002

8.    Security Considerations.......................................77
8.1   iSNS Security Threat Analysis.................................77
8.2   iSNS Security Implementation and Usage Requirements...........77
8.3   Discovering Security Requirements of Peer Devices.............79
8.4   Configuring Security Policies of iFCP/iSCSI Devices...........79
8.5   Resource Issues...............................................80
8.6   iSNS Interaction with IKE and IPSec...........................80
9.    Normative References..........................................81
10.   Informative References........................................82
11.   Author's Addresses............................................83
Full Copyright Statement.............................................84
Appendix A -- iSNS Examples..........................................85
A.1   iSCSI Initialization Example..................................85
A.1.1 Simple iSCSI Target Registration..............................85
A.1.2 Target Registration and DD Configuration......................86
A.1.3 Initiator Registration and Target Discovery...................87







































Tseng, Gibbons, et al.     Standards Track                   [Page 5]


                 Internet Storage Name Service (iSNS)      August 2002


1.       Abstract

   This document specifies the iSNS protocol, which is used for
   interaction between iSNS servers and iSNS clients in order to
   facilitate automated discovery, management, and configuration of
   iSCSI and Fibre Channel (FCP) devices on a TCP/IP network.  iSNS
   provides intelligent storage discovery and management services
   comparable to those found in Fibre Channel networks, allowing a
   commodity IP network to function in a similar capacity as a storage
   area network.  iSNS also facilitates a seamless integration of IP
   and Fibre Channel networks, due to its ability to emulate Fibre
   Channel fabric services, and manage both iSCSI and Fibre Channel
   devices.  iSNS thereby provides value in any storage network
   comprised of iSCSI devices, Fibre Channel devices, or any
   combination thereof.

2.       About this Document

2.1      Conventions Used in this Document

   iSNS refers to the framework consisting of the storage network model
   and associated services.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119].

   All frame formats are in big endian network byte order.

   All unused fields and bitmaps, including those that are RESERVED,
   SHOULD be set to zero.

2.2      Purpose of this Document

   This is a standards track document containing normative text
   specifying the iSNS Protocol, used by iSCSI and iFCP devices to
   communicate with the iSNS server.  This document focuses on the
   interaction between iSNS servers and iSNS clients; interactions
   among multiple authoritative primary iSNS servers are a potential
   topic for future work.

3.       iSNS Overview

   iSNS facilitates scalable configuration and management of iSCSI and
   Fibre Channel (FCP) storage devices in an IP network, by providing a
   set of services comparable to that available in Fibre Channel
   networks.  iSNS thus allows a commodity IP network to function at
   comparable level of intelligence to a Fibre Channel fabric.  iSNS
   allows the administrator to go beyond a simple device-by-device
   management model, where each storage device is manually and
   individually configured with its own list of known initiators and
   targets.  Using the iSNS, each storage device subordinates its
   discovery and management responsibilities to the iSNS server.  The

Tseng, Gibbons, et al.     Standards Track                   [Page 6]


                 Internet Storage Name Service (iSNS)      August 2002

   iSNS server thereby serves as the consolidated configuration point
   through which management stations can configure and manage the
   entire storage network, including both iSCSI and Fibre Channel
   devices.

   iSNS can be implemented to support iSCSI and/or iFCP protocols as
   needed; an iSNS implementation MAY provide support for one or both
   of these protocols as desired by the implementor.  Implementation
   requirements within each of these protocols is further discussed in
   section 5.  Use of iSNS is OPTIONAL for iSCSI, and REQUIRED for
   iFCP.

3.1      iSNS Architectural Components

3.1.1   iSNS Protocol (iSNSP)

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

3.1.2   iSNS Client

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

3.1.3   iSNS Server

   iSNS servers respond to iSNS protocol queries and requests, and
   initiate iSNS protocol State Change Notifications.  Properly
   authenticated information submitted by a registration request is
   stored in an iSNS database.

3.1.4   iSNS Database

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

3.1.5   iSCSI

   iSCSI (Internet SCSI) is an encapsulation of SCSI for a new
   generation of storage devices interconnected with TCP/IP.





Tseng, Gibbons, et al.     Standards Track                   [Page 7]


                 Internet Storage Name Service (iSNS)      August 2002

3.1.6   iFCP

   iFCP (Internet FCP) is a gateway-to-gateway protocol designed to
   interconnect existing Fibre Channel and SCSI devices using TCP/IP.
   iFCP maps the existing FCP standard and associated Fibre Channel
   services to TCP/IP.

3.2      iSNS Functional Overview

   iSNS Protocol registration and query messages are sent by iSNS
   clients to servers, while notification messages are sent by iSNS
   servers to iSNS clients.  Messages originating at the client are
   sent to the iSNS server at the well-known iSNS TCP or UDP port
   number.

   There are four main functions of the iSNS:

   1)  A Name Service Providing Storage Resource Discovery

   2)  Discovery Domain (DD) and Login Control Service

   3)  State Change Notification Service

   4)  Open Mapping of Fibre Channel and iSCSI Devices

3.2.1   Name Registration Service

   The iSNS provides a registration function to allow all entities in a
   storage network to register and query the iSNS database.  Both
   targets and initiators can register in the iSNS database, as well as
   query for information about other initiators and targets.  This
   allows, for example, a client initiator to obtain information about
   target devices from the iSNS server. This service is modeled on the
   Fibre Channel Generic Services Name Server described in FC-GS-3,
   with extensions, operating within the context of an IP network.

   The naming registration service also provides the ability to obtain
   a network unique Domain ID for iFCP gateways when required.

3.2.2   Discovery Domain and Login Control Service (Zoning)

   Zoning is an important function in existing Storage Area Networks
   that allows storage administrators to partition storage assets into
   more manageable groups for administrative and management purposes.
   It also provides important storage network isolation capabilities to
   prevent interaction among incompatible storage and file systems.
   iSNS provides zoning capability through the Discovery Domain (DD)
   Service.

   The Discovery Domain (DD) Service facilitates the partitioning of
   iSNS client devices into more manageable groupings for
   administrative and login control purposes. This allows the
   administrator to limit the login process to the more appropriate
   subset of targets registered in the iSNS.  iSNS clients must be in

Tseng, Gibbons, et al.     Standards Track                   [Page 8]


                 Internet Storage Name Service (iSNS)      August 2002

   at least one common DD in order to obtain information about each
   other.  iSNS clients can be a member of multiple DD's
   simultaneously.

   The DD information stored in the iSNS can be used by various
   enforcement points in the network to configure security and access
   control policy.  For example, a DD-aware switch can block storage
   initiators from accessing targets that are not in the same DD, even
   if the initiator somehow obtained address information for a target
   outside of its DD.

   Login Control allows targets to subordinate their access
   control/authorization policy to the iSNS server.  The target node or
   device downloads the list of authorized initiators from the iSNS.
   Each node or device is uniquely identified by an iSCSI Name or FC
   Port Name.  Only initiators that match the required identification
   and authentication information provided by the iSNS will be allowed
   access by that target node or device during session establishment.
   If spoofing of initiator identities is a concern, the target may use
   the public key certificate of the authorized initiator, obtained
   from the iSNS server, to authenticate the initiator.

   DD's can be managed offline through a separate management
   workstation using the iSNSP or SNMP.  If the target opts to use the
   Login Control feature of the iSNS, the target subordinates
   management of access control policy (i.e., the list of initiators
   allowed to login to that target) to the management workstations that
   are manipulating information in the iSNS database.

   If administratively authorized, a target can upload its own Login
   Control list.  This is accomplished using the DDReg message and
   listing the iSCSI Name of each initiator to be registered in the
   Target's DD.

   An implementation MAY decide that newly registered devices that have
   not explicitly been placed into a DD by the management station are
   be placed into a "default DD" contained in a "default DDS" whose
   initial DD Set Status value is "enabled".  This makes them visible
   to other devices in the default DD.  Other implementations MAY
   decide that they are registered with no DD, making them inaccessible
   to source-scoped iSNSP messages.  If used, the DD_ID of the "default
   DD" is 1, and the DDS_ID of the "default DDS" is 1.

   The iSNS server uses the SOURCE field of each iSNSP message to
   determine the source of the request and scope the operation to the
   set of Discovery Domains that the iSNS client is a member of. In
   addition, the Node Type (specified in the iFCP or iSCSI Node Type
   bitmap field) may also be used to determine authorization for the
   specified iSNS operation.  For example, only control nodes are
   authorized to create or delete discovery domains.

   Valid and active Discovery Domains (DD's) belong to at least one
   active Discovery Domain Sets (DDS's).  Discovery Domains that do not
   belong to an activated DDS are not enabled.

Tseng, Gibbons, et al.     Standards Track                   [Page 9]


                 Internet Storage Name Service (iSNS)      August 2002

3.2.3   State Change Notification Service

   The State Change Notification (SCN) service allows the iSNS Server
   to issue notifications about network events that affect the
   operational state of iSNS clients. The iSNS client has the ability
   to register for these notifications of events detected by the iSNS
   Server.

   There are two types of SCN registrations: Regular registrations and
   management registrations; management registrations result in
   management SCN's, while regular registrations result in regular
   SCN's. The type of registration and SCN message is indicated in the
   SCN bitmap (see sections 7.4.4 and 7.5.12).

   A regular SCN registration indicates that the Discovery Domain
   Service shall be used to control the distribution of SCN messages.
   Receipt of regular SCN's is limited to the discovery domains in
   which the SCN-triggering event takes place.  Regular SCN's do not
   contain information about discovery domains.

   A management SCN registration can only by conducted by control
   nodes.  Management SCN's resulting from management registrations are
   not bound by the Discovery Domain service.  Authorization to conduct
   management SCN registrations may be administratively controlled.

   The iSNS server may refuse SCN service by returning a SCN
   Registration Rejected (Status Code 17).  The rejection might occur
   in situations where the network size or current number of SCN
   registrations, has passed an implementation-specific threshold.  A
   client not allowed to register for SCNs may decide to monitor its
   sessions with other storage devices directly.

   The specific notification mechanism by which the iSNS server learns
   of the events that trigger SCN's is implementation-specific, but can
   include examples such as explicit notification messages from an iSNS
   client to the iSNS server, or a hardware interrupt to a switch-
   hosted iSNS server as a result of link failure.

3.2.4   Open Mapping Between Fibre Channel and iSCSI Devices

   The iSNS database stores naming and discovery information about both
   Fibre Channel and iSCSI devices.  This allows the iSNS server to
   store mappings of a Fibre Channel device to a proxy iSCSI device
   "image" in the IP network.  Similarly, mappings of an iSCSI device
   to a "proxy WWN" can be stored under the WWNN Token field for that
   that iSCSI device.

   Furthermore, through use of iSCSI-FC gateways, Fibre Channel-aware
   management stations can interact with the iSNS server to retrieve
   information about Fibre Channel devices, and use this information to
   manage Fibre Channel devices as well as iSCSI devices.  This allows
   management functions such as Discovery Domains and State Change
   Notifications to be seamlessly applied for both iSCSI and Fibre


Tseng, Gibbons, et al.     Standards Track                  [Page 10]


                 Internet Storage Name Service (iSNS)      August 2002

   Channel devices, facilitating integration of IP networks with Fibre
   Channel devices and fabrics.

   Note that Fibre Channel attributes are stored as iFCP attributes,
   and the ability to store this information in the iSNS server is
   useful even if the iFCP protocol is not implemented.  In particular,
   tag 101 can be used to store a "Proxy iSCSI Name" for Fibre Channel
   devices registered in the iSNS server.  This field is used to
   associate the FC device with an iSCSI registration entry that is
   used for the Fibre Channel device to communicate with iSCSI devices
   in the IP network.  Conversely, tag 37 (see section 7.1) contains an
   WWNN Token field, which can be used to store an FC Node Name (WWNN)
   value used by iSCSI-FC gateways to represent an iSCSI device in the
   Fibre Channel domain.

   By storing the mapping between Fibre Channel and iSCSI devices in
   the iSNS server, this information becomes open to any authorized
   iSNS client wishing to retrieve and use this information.  In many
   cases, this provides advantages over storing this information
   internally within an iSCSI-FC gateway, where the mapping is
   inaccessible to other devices except by proprietary mechanisms.

3.3      iSNS Usage Model

   The following is a high-level description of how each type of device
   in a storage network can utilize iSNS.  Each type of device
   interacts with the iSNS server as an iSNS client, and must register
   itself in the iSNS database in order to access services provided by
   the iSNS.

3.3.1   iSCSI Initiator

   An iSCSI initiator will query the iSNS server to discover the
   presence and location of iSCSI target devices.  It may also request
   state change notifications (SCN's) so that it can be notified of new
   targets that appear on the network after the initial bootup and
   discovery.  SCN's can also inform the iSCSI initiator of targets
   that are removed or no longer available in the storage network, so
   that incomplete storage sessions can be gracefully terminated and
   resources for non-existent targets can be reallocated.

3.3.2   iSCSI Target

   An iSCSI target allows itself to be discovered by iSCSI initiators
   by registering its presence in the iSNS server.  It may also
   register for SCN's in order to detect the addition or removal of
   initiators for resource allocation purposes.  The iSCSI target
   device may also register for Entity Status Enquiry (ESI) messages,
   which allow the iSNS to monitor the target device's availability in
   the storage network.





Tseng, Gibbons, et al.     Standards Track                  [Page 11]


                 Internet Storage Name Service (iSNS)      August 2002

3.3.3   iSCSI-FC Gateway

   An iSCSI-FC Gateway bridges devices in a Fibre Channel network to an
   iSCSI/IP network.  It may use the iSNS store FC device attributes
   discovered in the FC name server, as well as mappings of FC device
   identifiers to iSCSI device identifiers.  iSNS has the capability to
   store all attributes of both iSCSI and Fibre Channel devices; iSCSI
   devices are managed through direct interaction using iSNS, while FC
   devices can be indirectly managed through iSNS interactions with the
   iSCSI-FC gateway.  This allows both iSCSI and Fibre Channel devices
   to be managed in a seamless management framework.

3.3.4   iFCP Gateway

   An iFCP Gateway uses iSNS to emulate the services provided by a
   Fibre Channel name server for FC devices in its gateway region.
   iSNS provides basic discovery and zoning configuration information
   to be enforced by the iFCP gateway.  When queried, iSNS returns
   information on the N_Port network address used to establish iFCP
   sessions between FC devices supported by iFCP gateways.

3.3.5   Management Station

   A Management Station uses iSNS to monitor storage devices and enable
   or disable storage sessions by configuring discovery domains.  A
   Management Station usually interacts with the iSNS server as a
   control node endowed with access to all iSNS database records and
   special privileges to configure discovery domains.  Through
   manipulation of discovery domains, the Management Station controls
   the establishment and termination of storage sessions in the storage
   network.

3.4      Administratively Controlled iSNS Settings

   Some important operational settings for the iSNS server are
   configured using administrative means, such as through a
   configuration file, console port, SNMP, or other implementation-
   specific method.  These administratively controlled settings cannot
   be configured using the iSNS Protocol.

   The following is a list of parameters that are administratively
   controlled for the iSNS server.













Tseng, Gibbons, et al.     Standards Track                  [Page 12]


                 Internet Storage Name Service (iSNS)      August 2002

         Setting                                Default Setting
         -------                                ---------------
   ESI Non-Response Threshold                         3
   Management SCNs (Control Nodes only)            enabled
   Default DD/DDS                                 disabled
   DD/DDS Modification
      - Control Node                               enabled
      - iSCSI Target Node Type                    disabled
      - iSCSI Initiator Node Type                 disabled
      - iFCP Target Port Role                     disabled
      - iFCP Initiator Port Role                  disabled
   Authorized Control Nodes                          N/A

   ESI Non-Response Threshold - determines the number of ESI messages
   sent without receiving a response before the entity is deregistered
   from the iSNS database.

   Management SCN for Control Node - determines whether a registered
   control node is permitted to register to receive Management SCN's.

   Default DD/DDS - determines whether a newly registered device not
   explicitly placed into a discovery domain (DD) and discovery domain
   set (DDS) is placed into a default DD/DDS.

   DD/DDS Modification - determines whether the specified type of node
   is allowed to add, delete or update DD's and DDS's.

   Authorized Control Nodes - a list of nodes identified by iSCSI Name
   or FC Port Name WWPN that are authorized to register as control
   nodes.

3.5      iSNS Server Discovery

3.5.1   Service Location Protocol (SLP)

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

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




Tseng, Gibbons, et al.     Standards Track                  [Page 13]


                 Internet Storage Name Service (iSNS)      August 2002

3.5.2   Dynamic Host Configuration Protocol (DHCP)

   The IP address of the iSNS server can be stored in a DHCP server to
   be downloaded by iSNS clients using a DHCP option.  The DHCP option
   number to be used for distributing the iSNS server location is
   <<TBD>>.

3.5.3   iSNS Heartbeat Message

   The iSNS heartbeat message is described in section 6.6.5.14.  It
   allows iSNS clients within the broadcast or multicast domain of the
   iSNS server to discover the location of the active iSNS server and
   any backup servers.

3.6      iSNS and NAT

   The existence of NAT will have an impact upon information retrieved
   from the iSNS server.  If the iSNS client exists in a different
   addressing domain than the iSNS server, then IP address information
   stored in the iSNS server may not be correct when interpreted in the
   domain of the iSNS client.

   There are several possible approaches to allow operation of iSNS
   within a NAT network.  The first approach is to require use of the
   canonical TCP port number by both targets and initiators when
   addressing targets across a NAT boundary, and for the iSNS client to
   not query for nominal IP addresses.  Rather, the iSNS client
   initiator queries for the DNS Fully Qualified Domain Name stored in
   the Entity Identifier field, when seeking addressing information.
   Once retrieved, the DNS name can be interpreted in each address
   domain and mapped to the appropriate IP address by local DNS
   servers.

   A second approach is to deploy a distributed network of iSNS
   servers.  Local iSNS servers are deployed inside and outside NAT
   boundaries, with each local server storing relevant IP addresses for
   their respective NAT domains.  Updates among the network of
   decentralized, local iSNS servers are handled using LDAP and using
   appropriate NAT translation rules implemented within the update
   mechanism in each server.

   The final alternative is to simply disallow use of NAT in
   communication between the iSNS server and any iSNS client.

3.7      Transfer of iSNS Database Records between iSNS Servers

   Transfer of iSNS database records between iSNS servers has important
   applications, including the following:

   1)  An independent organization needs to transfer storage
   information to a different organization.  Each organization
   independently maintains its own iSNS infrastructure.  To facilitate
   discovery of storage assets of the peer organization using IP, iSNS
   database records can be transferred between authoritative iSNS

Tseng, Gibbons, et al.     Standards Track                  [Page 14]


                 Internet Storage Name Service (iSNS)      August 2002

   servers from each organization.  This allows storage sessions to be
   established directly between devices residing in each organization's
   storage network infrastructure over a common IP network.

   2)  Multiple iSNS servers are desired for redundancy.  Backup
   servers need to maintain copies of the primary server's dynamically
   changing database.

   To support the above applications, information in an iSNS server can
   be distributed to other iSNS servers either using the iSNS protocol,
   or through out-of-band mechanisms using non-iSNS protocols. The
   following examples illustrate possible methods to transfer data
   records between iSNS servers.  In the first example, a back-end LDAP
   information base is used to support the iSNS server, and the data is
   transferred using the LDAP protocol.  Once the record transfer of
   the remote device is completed, it becomes visible and accessible to
   local devices using the local iSNS server.  This allows local
   devices to establish sessions with remote devices (provided firewall
   boundaries can be negotiated).

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

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











Tseng, Gibbons, et al.     Standards Track                  [Page 15]


                 Internet Storage Name Service (iSNS)      August 2002

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


   The above diagram illustrates a second example of how iSNS records
   can be shared. This method uses an SNMP-based management station to
   manually download the desired record for "dev C", and then directly
   upload it to the local iSNS server. Once the record is transferred
   to the local iSNS server in Network A, "dev C" becomes visible and
   accessible (provided firewall boundaries can be negotiated) to other
   devices in Network A.

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

3.8      Backup iSNS Servers

   This section offers a broad framework for implementation and
   deployment of iSNS backup servers.  Server failover and recovery are
   topics of continuing research and adequate resolution of issues such
   as split brain and primary server selection is dependent on the
   specific implementation requirements and deployment needs.
   Therefore, it is beyond the scope of this specification to
   facilitate more than a basic interoperability among failover
   mechanisms.  Further development of redundant iSNS server mechanisms
   are left to the individual implementation.

   Multiple iSNS servers can be used to provide redundancy in the event
   that the active iSNS server fails or is removed from the network.
   The methods described in section 3.7 above can be used to transfer
   name server records to backup iSNS servers.  Each backup server
   maintains a redundant copy of the name server database found in the
   primary iSNS server, and can respond to iSNS protocol messages in
   the same way as the active server.  Each backup server SHOULD

Tseng, Gibbons, et al.     Standards Track                  [Page 16]


                 Internet Storage Name Service (iSNS)      August 2002

   monitor the health and status of the active iSNS server, including
   checking to make sure its own database is synchronized with the
   active server's database.  How each backup server accomplishes this
   is implementation-dependent, and may (or may not) include using the
   iSNS protocol.  If the iSNS protocol is used, then the backup server
   MAY register itself in the active server's iSNS database as a
   control node, allowing it to receive state change notifications.

   Generally, the administrator or some automated election process is
   responsible for initial and subsequent designation of the primary
   server and each backup server.

   A maximum of one backup iSNS server SHALL exist at any individual IP
   address.

   In addition to proprietary vendor-specific ways of deploying
   multiple redundant iSNS servers, the iSNS heartbeat can also be used
   to coordinate designation and selection of primary and backup iSNS
   servers.

   Each backup server should note its relative precedence in the active
   server's list of backup servers.  If not already known, each backup
   server MAY learn its precedence from the iSNS heartbeat message, by
   noting the position of its IP address in the ordered list of backup
   server IP addresses.  For example, if it is the first backup listed
   in the heartbeat message, then its backup precedence is 1.  If it is
   the third backup server listed, then its backup precedence is 3.

   If a backup server establishes that it has lost connectivity to the
   active server and other backup servers of higher precedence, then it
   shall assume that it is the active server.  The method of
   determining whether connectivity has been lost is implementation-
   specific.  One possible approach is to assume that if the backup
   server does not receive iSNS hearbeat messages for a period of time,
   then connectivity to the active server has been lost.   Alternately,
   the backup server may establish TCP connections to the active server
   and other backup servers, and loss of connectivity determined
   through non-response to periodic echo messages (using iSNSP, SNMP,
   or other protocols).

   When a backup server becomes the active server, it shall assume all
   active server responsibilities, including (if used) transmission of
   the iSNS heartbeat message.  If transmitting the iSNS heartbeat, the
   backup server replaces the active Server IP Address and TCP/UDP Port
   entries with its own IP address and TCP/UDP Port, and begins
   incrementing the counter field from the last known value from the
   previously-active iSNS server.  However, it MUST NOT change the
   original ordered list of backup server IP Address and TCP/UDP Port
   entries.  If the primary backup server or other higher-precedence
   backup server returns, then the existing active server is
   responsible for ensuring that the new active server's database is
   up-to-date before demoting itself to its original status as backup.



Tseng, Gibbons, et al.     Standards Track                  [Page 17]


                 Internet Storage Name Service (iSNS)      August 2002


4.       iSNS Object Model

   iSNS provides the framework for the registration, discovery, and
   management of iSCSI devices and Fibre Channel-based devices (using
   iFCP).  This architecture framework provides elements needed to
   describe various storage device objects and attributes that may
   exist on an IP storage network.  Objects defined in this
   architecture framework include NETWORK ENTITY, PORTAL, STORAGE NODE,
   FC DEVICE, DEVICE DISCOVERY DOMAIN, and DISCOVERY DOMAIN SET.  Each
   of these objects is described in greater detail in the following
   sections.

4.1      NETWORK ENTITY Object

   The NETWORK ENTITY object is a container of STORAGE NODE objects and
   PORTAL objects.  It represents the infrastructure supporting access
   to a unique set of one or more STORAGE NODEs.  All STORAGE NODEs and
   PORTALs contained within a single NETWORK ENTITY object operate as a
   cohesive unit.

   Note that it is possible for a single physical device or gateway to
   be represented by more than one logical Network Entity in the iSNS
   database.  For example, one of the storage nodes on a physical
   device may be accessible from only a subset of the network
   interfaces (i.e., portals) available on that device.  In this case,
   a logical network entity (i.e., a "shadow entity") is created and
   used to contain the portals and storage nodes that can operate
   cooperatively.  No object (PORTALs, STORAGE NODEs, etc...) can be
   contained by more than one logical Network Entity.

   Similarly, it is possible for a logical Network Entity to be
   supported by more than one physical device or gateway.  For example,
   multiple FC-iSCSI gateways may be used to bridge FC devices in a
   single Fibre Channel network.  The multiple gateways collectively
   can be used to support a single logical NETWORK ENTITY that is used
   to contain all of the devices in that Fibre Channel network.

4.2      PORTAL Object

   The PORTAL object is an interface through which access to any
   STORAGE NODE within the NETWORK ENTITY can be obtained.  An IP
   address and TCP/UDP Port number uniquely distinguish a PORTAL
   object.  A NETWORK ENTITY should have one or more PORTALs, each of
   which is usable by STORAGE NODEs contained in that NETWORK ENTITY to
   gain access to, or be accessible from, the IP network.

4.3      STORAGE NODE Object

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


Tseng, Gibbons, et al.     Standards Track                  [Page 18]


                 Internet Storage Name Service (iSNS)      August 2002

4.4      FC DEVICE Object

   The FC DEVICE represents the Fibre Channel node.  This object
   contains information that may be useful in the management of the
   Fibre Channel device.

4.5      DISCOVERY DOMAIN Object

   DISCOVERY DOMAINS (DD) are a security and management mechanism used
   to administer access and connectivity to storage devices.  Discovery
   Domains limit the discovery process to the administrator-configured
   subset of relevant storage devices, preventing initiators from
   inappropriately attempting login to devices that they shouldnÆt have
   access to.  A query by an iSNS client SHOULD only return information
   about objects with which it shares at least one active DD.  A DD is
   considered active if it is a member of at least one active DD Set.
   DD's that are not members of at least one enabled DDS are considered
   disabled.  A STORAGE NODE can be a member of one or more DD's.

4.6      DISCOVERY DOMAIN SET Object

   The DISCOVERY DOMAIN SET (DDS) is a container object for DDÆs.
   DDSÆs may contain one or more DDÆs.  Similarly, each DD can be a
   member of one or more DDSÆs.  DDSÆs are a mechanism to store
   coordinated sets of DD mappings in the iSNS server.  Active DD's are
   members of at least one active DD Set.  DDS's are enabled by setting
   bit 0 in the DDS Status Field.

4.7      iSNS Database Model

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

                    +--------------+    +-----------+
                    |    NETWORK   |1  *|           |
                    |    ENTITY    |----|  PORTAL   |
                    |              |    |           |
                    +--------------+    +-----------+
                            | 1
                            |
                            |
                            | *
   +-----------+    +--------------+    +-----------+    +-----------+
   |    FC     |1  *|   STORAGE    |*  *| DISCOVERY |*  *| DISCOVERY |
   |  DEVICE   |----|    NODE      |----|  DOMAIN   |----|  DOMAIN   |
   |           |    |              |    |           |    |    SET    |
   +-----------+    +--------------+    +-----------+    +-----------+

                * represents 0 to many possible relationships






Tseng, Gibbons, et al.     Standards Track                  [Page 19]


                 Internet Storage Name Service (iSNS)      August 2002

5.       iSNS Implementation Requirements

   This section details specific requirements for support of each of
   these IP storage protocols. Implementation requirements for security
   are described in section 8.

5.1      iSCSI Requirements

   Use of iSNS in support of iSCSI is OPTIONAL.  iSCSI devices MAY be
   manually configured with the iSCSI Name and IP address of peer
   devices, without the aid or intervention of iSNS.  iSCSI devices
   also may use SLP [RFC 2608] to discover peer iSCSI devices.
   However, iSNS is useful for scaling a storage network to a larger
   number of iSCSI devices.

5.1.1   Required Attributes for Support of iSCSI

   The following attributes are available to support iSCSI.  Attributes
   indicated in the REQUIRED TO IMPLEMENT column MUST be supported by
   an iSNS server used to support iSCSI.  Attributes indicated in the
   REQUIRED TO USE column MUST be supported by an iSCSI device that
   elects to use the iSNS.  A more detailed description of each
   attribute is found in section 7.
































Tseng, Gibbons, et al.     Standards Track                  [Page 20]


                 Internet Storage Name Service (iSNS)      August 2002

                                               REQUIRED     REQUIRED
   Object                Attribute           to Implement   to Use
   ------                ---------           ------------   --------
   NETWORK ENTITY     Entity Identifier            *           *
                      Entity Protocol              *           *
                      Management IP Address
                      Timestamp                    *
                      Protocol Version Range       *
                      Registration Period          *
                      Entity Index                 *
                      Entity IKE Phase-1 Proposal
                      Entity Certificate

   PORTAL             IP Address                   *           *
                      TCP/UDP Port                 *           *
                      Portal Symbolic Name         *
                      ESI Interval                 *
                      ESI Port                     *
                      Portal Group Tag             *
                      Portal Index                 *
                      SCN Port                     *
                      Portal Security Bitmap       *
                      Portal IKE Phase-1 Proposal
                      Portal IKE Phase-2 Proposal
                      Portal Certificate

   STORAGE NODE       iSCSI Name                   *           *
                      iSCSI Node Type              *           *
                      Alias                        *
                      iSCSI SCN Bitmap             *
                      iSCSI Node Index             *
                      WWNN Token
                      iSCSI AuthMethod
                      iSCSI Node Certificate

   DISCOVERY DOMAIN   DD ID                        *           *
                      DD Symbolic Name             *
                      DD iSCSI Node Index          *
                      DD iSCSI Node Member         *
                      DD Features                  *

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


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

5.1.2   Example iSCSI Object Model Diagrams

   The following diagram models how a simple iSCSI-based initiator and
   target is represented using database objects stored in the iSNS

Tseng, Gibbons, et al.     Standards Track                  [Page 21]


                 Internet Storage Name Service (iSNS)      August 2002

   server.  In this implementation, each target and initiator is
   attached to a single PORTAL.

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

   The object model can be expanded to describe more complex devices,
   such as an iSCSI device with more than one storage controller, each
   controller accessible through any of multiple PORTAL interfaces.
   The storage controllers on this device can be accessed through
   alternate PORTAL interfaces, if any original interface should fail.
   The following diagram describes such a device:


















Tseng, Gibbons, et al.     Standards Track                  [Page 22]


                 Internet Storage Name Service (iSNS)      August 2002

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


5.1.3   Required Commands and Response Messages for Support of iSCSI

   The following iSNSP messages and responses are available in support
   of iSCSI.  Messages indicated in the REQUIRED TO IMPLEMENT column
   MUST be implemented in iSNS servers used for iSCSI devices.
   Messages indicated in the REQUIRED TO USE column must be implemented
   in iSCSI devices that elect to use the iSNS server.

                                                     REQUIRED TO:
      Message Description    Abbreviation  Func_ID  Implement  Use
      -------------------    ------------  -------  ---------  ---
   Device Attr Reg Request   DevAttrReg    0x0001       *       *
   Dev Attr Query Request    DevAttrQry    0x0002       *       *
   Dev Get Next Request      DevGetNext    0x0003       *
   Deregister Dev Request    DevDereg      0x0004       *       *
   SCN Register Request      SCNReg        0x0005       *
   SCN Deregister Request    SCNDereg      0x0006       *
   SCN Event                 SCNEvent      0x0007       *
   State Change Notification SCN           0x0008       *
   DD Register               DDReg         0x0009       *       *
   DD Deregister             DDDereg       0x000A       *       *
   DDS Register              DDSReg        0x000B       *       *
   DDS Deregister            DDSDereg      0x000C       *       *
   Entity Status Inquiry     ESI           0x000D       *

Tseng, Gibbons, et al.     Standards Track                  [Page 23]


                 Internet Storage Name Service (iSNS)      August 2002

   Name Service Heartbeat    Heartbeat     0x000E
   NOT USED                                0x000F-0x0013
   RESERVED                                0x0014-0x00FF
   Vendor Specific                         0x0100-0x01FF
   RESERVED                                0x0200-0x8000


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

                                                     REQUIRED TO:
   Response Message Desc     Abbreviation  Func_ID  Implement  Use
   ---------------------     ------------  -------  ---------  ---
   Device Attr Register Rsp  DevAttrRegRsp     0x8001       *       *
   Device Attr Query Rsp     DevAttrQryRsp 0x8002       *       *
   Device Get Next Rsp       DevGetNextRsp 0x8003       *
   Device Dereg Rsp          DevDeregRsp   0x8004       *       *
   SCN Register Rsp          SCNRegRsp     0x8005       *
   SCN Deregister Rsp        SCNDeregRsp   0x8006       *
   SCN Event Rsp             SCNEventRsp   0x8007       *
   SCN Response              SCNRsp        0x8008       *
   DD Register Rsp           DDRegRsp      0x8009       *       *
   DD Deregister Rsp         DDDeregRsp    0x800A       *       *
   DDS Register Rsp          DDSRegRsp     0x800B       *       *
   DDS Deregister Rsp        DDSDeregRsp   0x800C       *       *
   Entity Stat Inquiry Rsp   ESIRsp        0x800D       *
   NOT USED                                0x800E-0x8013
   RESERVED                                0x8014-0x80FF
   Vendor Specific                         0x8100-0x81FF
   RESERVED                                0x8200-0xFFFF


5.2      iFCP Requirements

   In iFCP, use of iSNS is REQUIRED.  No alternatives exist for support
   of iFCP Naming & Discovery functions.

5.2.1   Required Attributes for Support of iFCP

   The following table displays attributes that are used by iSNS to
   support iFCP.  Attributes indicated in the REQUIRED TO IMPLEMENT
   column MUST be supported by the iSNS server that supports iFCP.
   Attributes indicated in the REQUIRED TO USE column MUST be supported
   by iFCP gateways. A more detailed description of each attribute is
   found in section 7.

                                               REQUIRED     REQUIRED
   Object                Attribute           to Implement    to Use
   ------                ---------           ------------   --------
   NETWORK ENTITY     Entity Identifier            *           *
                      Entity Protocol              *           *
                      Management IP Address
                      Timestamp                    *
                      Protocol Version Range       *
                      Registration period

Tseng, Gibbons, et al.     Standards Track                  [Page 24]


                 Internet Storage Name Service (iSNS)      August 2002

                      Entity Index
                      Entity IKE Phase-1 Proposal
                      Entity Certificate

   PORTAL             IP Address                   *           *
                      TCP/UDP Port                 *           *
                      Symbolic Name                *
                      ESI Interval                 *
                      ESI Port                     *
                      SCN Port                     *
                      Portal IKE Phase-1 Proposal
                      Portal IKE Phase-2 Proposal
                      Portal Certificate
                      Security Bitmap              *

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

   FC DEVICE          FC Node Name (WWNN)          *           *
   (FC Node)          Node Symbolic Name           *
                      Node IP Address              *
                      Node IPA                     *
                      Node Certificate
                      Proxy iSCSI Name

   DISCOVERY DOMAIN   DD_ID                        *           *
                      DD_Symbolic Name             *
                      DD iFCP Member (WWPN)        *

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

   OTHER              Switch Name
                      Preferred_ID
                      Assigned_ID
                      Space Identifier





Tseng, Gibbons, et al.     Standards Track                  [Page 25]


                 Internet Storage Name Service (iSNS)      August 2002

5.2.2   Example iFCP Object Model Diagram

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

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

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

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


5.2.3   Required Commands and Response Messages for Support of iFCP

   The iSNSP messages and responses displayed in the following tables
   are available to support iFCP gateways.  Messages indicated in the
   REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server
   used by iFCP gateways.  Messages indicated in the REQUIRED TO USE
   column MUST be supported by the iFCP gateways themselves.

Tseng, Gibbons, et al.     Standards Track                  [Page 26]


                 Internet Storage Name Service (iSNS)      August 2002

                                                     REQUIRED TO:
      Message Description    Abbreviation  Func ID  Implement  Use
      -------------------    ------------  -------  ---------  ---
   Device Attr Reg Request   DevAttrReg    0x0001       *       *
   Device Attr Query Request DevAttrQry    0x0002       *       *
   Device Get Next Request   DevGetNext    0x0003       *
   Device Dereg Request      DevDereg      0x0004       *       *
   SCN Register Request      SCNReg        0x0005       *
   SCN Deregister Request    SCNDereg      0x0006       *
   SCN Event                 SCNEvent      0x0007       *
   State Change Notification SCN           0x0008       *
   DD Register               DDReg         0x0009       *       *
   DD Deregister             DDDereg       0x000A       *       *
   DDS Register              DDSReg        0x000B       *       *
   DDS Deregister            DDSDereg      0x000C       *       *
   Entity Status Inquiry     ESI           0x000D       *
   Name Service Heartbeat    Heartbeat     0x000E       *
   Reserved                  Reserved      0x000F-0x0010
   Request Switch ID         RqstSwId      0x0011
   Release Switch ID         RlseSwId      0x0012
   Get Switch IDs            GetSwIds      0x0013
   RESERVED                                0x0014-0x00FF
   Vendor Specific                         0x0100-0x01FF
   RESERVED                                0x0200-0x8000


   The following are iSNSP response messages in support of iFCP:




























Tseng, Gibbons, et al.     Standards Track                  [Page 27]


                 Internet Storage Name Service (iSNS)      August 2002

                                                     REQUIRED TO:
   Response Message Desc     Abbreviation  Func_ID  Implement  Use
   ---------------------     ------------  -------  ---------  ---
   Device Attr Reg Rsp       DevAttrRegRsp 0x8001       *       *
   Device Attr Query Rsp     DevAttrQryRsp 0x8002       *       *
   Device Get Next Rsp       DevGetNextRsp 0x8003       *
   Device Deregister Rsp     DevDeregRsp   0x8004       *       *
   SCN Register Rsp          SCNRegRsp     0x8005       *
   SCN Deregister Rsp        SCNDeregRsp   0x8006       *
   SCN Event Rsp             SCNEventRsp   0x8007       *
   SCN Rsp                   SCNRsp        0x8008       *
   DD Register Rsp           DDRegRsp      0x8009       *       *
   DD Deregister Rsp         DDDeregRsp    0x800A       *       *
   DDS Register Rsp          DDSRegRsp     0x800B       *       *
   DDS Deregister Rsp        DDSDeregRsp   0x800C       *       *
   Entity Status Inquiry Rsp ESIRsp        0x800D       *
   NOT USED                                0x800E
   RESERVED                                0x800F-0x8010
   Request Switch ID Rsp     RqstSwIdRsp   0x8011
   Release Switch ID Rsp     RlseSwIdRsp   0x8012
   Get Switch IDs            GetSwIdRsp    0x0013
   RESERVED                                0x8014-0x80FF
   Vendor Specific                         0x8100-0x81FF
   RESERVED                                0x8200-0xFFFF


5.3      Use of TCP For iSNS Communication

   It MUST be possible to use TCP for iSNS communication.  The iSNS
   server MUST accept TCP connections for client registrations.  The
   well-known TCP port used by the iSNS server to receive TCP messages
   used is 3205.

   To receive ESI monitoring using TCP, the client registers the Portal
   ESI Interval and the port number of the TCP port that will be used
   to receive ESI messages.  The iSNS server initiates the TCP
   connection used to deliver the ESI message.  This TCP connection
   does not need to be continuously open.

   To receive SCN notifications using TCP, the client registers the
   iSCSI or iFCP SCN Bitmap and the port number of the TCP port in the
   Portal used to receive SCN's. The iSNS server initiates the TCP
   connection used to deliver the SCN message.  This TCP connection
   does not need to be continuously open.

   It is possible for an iSNS client to use the same TCP connection for
   SCN, ESI, and iSNS queries.  Alternatively, separate connections may
   be used.

5.4      Use of UDP For iSNS Communication

   The iSNS server MAY accept UDP messages for client registrations.
   The iSNS server MUST accept registrations from clients requesting


Tseng, Gibbons, et al.     Standards Track                  [Page 28]


                 Internet Storage Name Service (iSNS)      August 2002

   UDP-based ESI and SCN messages.  The well-known UDP port used to
   receive UDP messages is 3205.

   To receive UDP-based ESI monitoring messages, the client registers
   the port number of the UDP port in at least one Portal to be used to
   receive and respond to ESI messages from the iSNS server.  If an
   entity has multiple Portals with registered ESI UDP Ports, then ESI
   messages SHALL be delivered to every Portal registered to receive
   such messages.

   To receive UDP-based SCN notification messages, the client registers
   the port number of the UDP port in at least one Portal to be used to
   receive SCN messages from the iSNS server.  If an entity has
   multiple Portals with registered SCN UDP Ports, then SCN messages
   SHALL be delivered to each Portal registered to receive such
   messages.

   When using UDP to transport iSNS messages, each UDP datagram MUST
   contain exactly one iSNS PDU.

6.       iSNSP Message Format

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

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

6.1      iSNSP PDU Header

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

6.1.1   iSNSP Version

   The iSNSP version described in this document is 0x0001.


Tseng, Gibbons, et al.     Standards Track                  [Page 29]


                 Internet Storage Name Service (iSNS)      August 2002

6.1.2   iSNSP Function ID

   The FUNCTION ID defines the type of iSNS message and the operation
   to be executed.  FUNCTION_ID values with the leading bit cleared
   indicate query, registration, and notification messages, while
   FUNCTION_ID values with the leading bit set indicate response
   messages.

   See section 5 under the appropriate protocol (i.e., iSCSI or iFCP)
   for a mapping of the FUNCTION_ID value to the iSNSP Command or
   Response message.  All PDU's comprising an iSNSP message must have
   the same FUNCTION_ID and TRANSACTION ID value.

6.1.3   iSNSP PDU Length

   The iSNS PDU length specifies the length of the PDU PAYLOAD field in
   bytes. The payload contains TLV attributes for the operation.  The
   PDU length MUST be 4-byte aligned.

6.1.4   iSNSP Flags

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

   Bit Field            Enabled Means:
   ---------            -------------
      16                Sender is the iSNS client
      17                Sender is the iSNS server
      18                RESERVED
      19                Replace Flag (valid only for DevAttrReg)
      20                Last PDU of the iSNS message
      21                First PDU of the iSNS message
     22-31              RESERVED

6.1.5   iSNSP Transaction ID

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

6.1.6   iSNSP Sequence ID

   The SEQUENCE ID has a unique value for each PDU within a single
   transaction.  The SEQUENCE_ID value of the first PDU transmitted in
   a given iSNS message MUST be zero (0), and each SEQUENCE_ID value in
   each PDU MUST be numbered sequentially in the order that the PDU's
   are transmitted.  Note that the two-byte SEQUENCE ID allows for up
   to 65536 PDU's per iSNS message.




Tseng, Gibbons, et al.     Standards Track                  [Page 30]


                 Internet Storage Name Service (iSNS)      August 2002

6.2      iSNSP Message Segmentation and Reassembly

   iSNS messages may be carried in one or more iSNS PDU's.  If only one
   iSNS PDU is used to carry the iSNS message, then bit 21 (First PDU)
   and bit 20 in the FLAGS field (Last PDU) SHALL both be set.  If
   multiple PDUs are used to carry the iSNS message, then bit 21 SHALL
   be set in the first PDU of the message, and bit 20 SHALL be set in
   the last PDU.

   All PDU's comprising the same iSNSP message SHALL have the same
   FUNCTION_ID and TRANSACTION_ID values.  Each PDU comprising an iSNSP
   message SHALL have a unique SEQUENCE_ID value.

6.3      iSNSP Message Payload

   The MESSAGE PAYLOAD is variable length and contains attributes used
   for registration and query operations.  The attribute data items use
   a format similar to other protocols, such as DHCP (RFC 2131)
   options.  Each iSNS attribute is specified in the iSNSP message
   payload using Tag-Length-Value (TLV) data format, as shown below:

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

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

   Attribute Length - a 4-byte field that indicates the length, in
   bytes, of the value field to follow in the TLV. For variable-length
   attributes, the value field may contain padding bytes, if necessary,
   in order to achieve 4-byte alignment.

   Attribute Value - a variable-length field containing the attribute
   value and padding bytes (if necessary).

   The above format is used to identify each attribute in the iSNS
   message payload.  Note that TLV boundaries need not be aligned with
   PDU boundaries; PDU's may carry one or more TLV's, or any fraction
   thereof.





Tseng, Gibbons, et al.     Standards Track                  [Page 31]


                 Internet Storage Name Service (iSNS)      August 2002

6.3.1   Attribute Value 4-Byte Alignment

   All attribute values are aligned at 4 byte boundaries.  For variable
   length attributes, if necessary, the TLV length is increased to the
   next 4-byte boundary through padding with bytes containing zero (0).

6.4      iSNSP Response Status Codes

   All iSNSP response messages contain a 4-byte Status Code field as
   the first field in the iSNSP PAYLOAD. If the original iSNSP request
   message was processed normally by the iSNS server, or the iSNS
   client for ESI and SCN messages, this field shall contain a status
   code of 0 (Successful) or 1 (Successful w/Additions or
   Modifications)

        Status Code      Status Description
        -----------      -----------------
           0             Successful
           1             Unknown Error
           2             Message Format Error
           3             Invalid Registration
           4             RESERVED
           5             Invalid Query
           6             Authentication Unknown
           7             Authentication Absent
           8             Authentication Failed
           9             No Such Entry
          10             Version Not Supported
          11             Internal Error
          12             Busy
          13             Option Not Understood
          14             Invalid Update
          15             Message (FUNCTION_ID) Not Supported
          16             SCN Event Rejected
          17             SCN Registration Rejected
          18             Attribute not Implemented
          19             SWITCH_ID not available
          20             SWITCH_ID not allocated
          21             ESI Not Available
          22             Invalid Deregistration
          23 And Above   RESERVED

6.5      iSNS Multicast Message Authentication

   For iSNS multicast messages, the iSNSP provides authentication
   capability. The following section details the iSNS Authentication
   Block, which is identical in format to the SLP authentication block
   [RFC2608]. iSNS unicast messages SHOULD NOT include the
   authentication block, but rather should rely upon IPSec security
   mechanisms.

   If a PKI is available with an X.509 certificate authority, then
   public key authentication of the iSNS server is possible.  The


Tseng, Gibbons, et al.     Standards Track                  [Page 32]


                 Internet Storage Name Service (iSNS)      August 2002

   authentication block leverages the DSA with SHA-1 algorithm, which
   can easily integrate into a public key infrastructure.

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

   1.  A time stamp, to prevent replay attacks
   2.  A structured authenticator containing a signature calculated
       over the time stamp and the message being secured
   3.  An indicator of the cryptographic algorithm that was used to
       calculate the signature.
   4.  An indicator of the keying material and algorithm parameters,
       used to calculate the signature.

   The authentication block is described in the following figure:

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

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

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

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

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




Tseng, Gibbons, et al.     Standards Track                  [Page 33]


                 Internet Storage Name Service (iSNS)      August 2002

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

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

6.6      Registration and Query Messages

   The iSNSP registration and query message payloads contain a list of
   attributes, and have the following format:

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

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

6.6.1   Source Attribute

   The source attribute is used to identify the iSNS client to the iSNS
   server for queries and other messages that require source
   identification.  The source attribute uniquely identifies the source
   of the message.  Valid source attribute types are shown below.






Tseng, Gibbons, et al.     Standards Track                  [Page 34]


                 Internet Storage Name Service (iSNS)      August 2002

           Valid Source Attributes
           -----------------------
           iSCSI Name
           FC Port Name WWPN

   For a query operation, the source attribute is used to limit the
   scope of the specified operation to the Discovery Domains of which
   the source is a member.  Special control nodes, identified by the
   source attribute, may be administratively configured to perform the
   specified operation on all objects in the iSNS database without
   scoping to Discovery Domains.

   For registration, deregistration, and update messages that change
   the contents of the iSNS database, the iSNS server MUST verify that
   the source attribute identifies either a control node, or a STORAGE
   NODE that is a part of the entity containing the added, deleted, or
   modified objects.  The iSNS server SHALL reject invalid
   registration, deregistration, and update messages from non-control
   nodes with a status code of 3 (invalid registration), 14 (invalid
   update), or 22 (invalid deregistration).

6.6.2   Message Key Attributes

   Message Key attributes are used to identify pre-existing objects in
   the iSNS database for iSNS query and registration messages.  If the
   object identified by the Message Key attributes are not found in the
   iSNS database, then an Status Code of 9 (no such entry) shall be
   returned by the iSNS server.  When registering a new NETWORK ENTITY
   object that did not previously exist in the iSNS database, no
   Message Key attribute should be used.  Non-key attributes MUST NOT
   be listed among the Message Key Attributes.

6.6.3   Delimiter Attribute

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

6.6.4   Operating Attributes

   The Operating Attributes are a list of one or more key and non-key
   attributes related to the actual iSNS registration or query
   operation being performed.

   Operating Attributes include object key attributes and non-key
   attributes.  Object key attributes uniquely identify iSNS objects.
   The tag value distinguishes the attribute as an object key attribute
   (i.e., tag=16&17, 32, 64, and 96) or non-key attribute.

   The ordering of operating attributes in the message is important in
   determining the relationships among objects and their ownership of
   non-key attributes.  iSNS protocol messages that violate these

Tseng, Gibbons, et al.     Standards Track                  [Page 35]


                 Internet Storage Name Service (iSNS)      August 2002

   ordering rules SHALL be rejected with the Status Code of 2 (Message
   Format Error).

   Some objects are keyed by more than one object key attribute value.
   For example, the PORTAL object is keyed by attribute tags 16 and 17.
   When describing an object keyed by more than one key attribute, each
   and every object key attribute of that object MUST be listed
   sequentially by tag value in the message before non-key attributes
   of that object, and key attributes of the next object.

   Non-key attributes that immediately follow a set of one or more
   object key attributes MUST be attributes of the object referenced by
   that set of object key attributes.  All non-key attributes of an
   object MUST be listed before the object key attributes introducing
   the next object.

   Objects and their attributes MUST be listed in their order of
   inheritance hierarchy.  STORAGE NODE and PORTAL objects and their
   respective attributes MUST follow the NETWORK ENTITY object to which
   they have a relationship.  Similarly, FC DEVICE objects MUST follow
   the STORAGE NODE object to which they have a relationship.

   Vendor-specific objects defined by tag values in the range 1537-2048
   have the same requirements described above.

6.6.4.1  Operating Attributes for Query and Get Next Requests

   In Query and Get Next request messages, TLV attributes with length
   value of 0 are used to indicate which operating attributes are to be
   returned in the corresponding response. Operating Attribute values
   that match the TLV attributes in the original message are returned
   in the response message.

6.6.5   Registration and Query Request Message Types

   The following describes each query and message type.

6.6.5.1  Device Attribute Registration Request (DevAttrReg)

   The DevAttrReg message type is 0x0001. The DevAttrReg message
   provides allows iSNS clients to register objects and attributes.

   The Source Attribute identifies the node initiating the registration
   request.  If the node identified by the Source Attribute is not a
   control node, then it MUST be from the same entity as the object(s)
   being registered (i.e., those listed in the operating attributes).

   Depending on the setting of the Replace bit in the FLAGS field, the
   Operating attribute values in the DevAttrReg message will either
   replace existing attributes, or be added to existing attributes.
   See section 6.6.5.1.1 below for a complete description of the
   Replace Flag.



Tseng, Gibbons, et al.     Standards Track                  [Page 36]


                 Internet Storage Name Service (iSNS)      August 2002

   The operating attributes represent new objects and attributes that
   are to be registered.  Multiple objects and attributes can be
   registered in one DevAttrReg message.  The ordering of the objects
   in this message indicate the structure of associations among the
   objects to be created in the iSNS server.  To create a relationships
   between a parent ENTITY object and its PORTAL and STORAGE NODE
   objects, the registration message SHALL list the key and operating
   attributes of the ENTITY object, followed by the attributes of each
   PORTAL and STORAGE NODE object to be linked to that ENTITY.
   Similarly, FC DEVICE object attributes that follow a STORAGE NODE
   object are considered to have a subordinate relationship with that
   STORAGE NODE.  A maximum of one new ENTITY object can be created
   with a single DevAttrReg message; there is no limit to the number of
   PORTAL, STORAGE NODE, and FC DEVICE objects that can be created for
   the ENTITY registered by the DevAttrReg message.

   A DevAttrReg message with no Message Key Attribute results in
   creation of a new NETWORK ENTITY object.  If the EID attribute (with
   non-zero length) is included among the operating attributes in the
   DevAttrReg message, then the new NETWORK ENTITY SHALL be assigned
   the value contained in that EID attribute.  Otherwise, if the EID
   attribute is not contained among the operating attributes of the
   DevAttrReg message, or if the EID is an operating attribute with TLV
   length of 0, then the iSNS server SHALL create the EID for the new
   NETWORK ENTITY that is registered in the iSNS database and returned
   in the DevAttrReg Response message.

   A registration message that creates a new NETWORK ENTITY object that
   does not contain at least one PORTAL and one STORAGE NODE shall be
   considered invalid.  Invalid registrations shall return a response
   with Status Code of 3 (Invalid Registration).

   Note that the iSNS server may modify or reject the registration of
   certain attributes, such as ESI Interval.  In addition, the iSNS
   server may assign values for additional operating attributes that
   are not registered in the original DevAttrReg message, such as the
   Portal Group Tag.  The values for such attributes are returned in
   the operating attributes of the corresponding DevAttrRegRsp message.

6.6.5.1.1 Replace Flag

   The Replace Flag, contained in the message header FLAGS field,
   indicates whether the registration is a replacement of, or update
   to, an existing object.

   If the object key attributes of a registration message do not match
   an existing object in the iSNS database, then the Replace flag is
   irrelevant; a new object is created regardless of whether the
   Replace flag is enabled or not.

   If the object key attributes match an existing object in the iSNS
   database, and the Replace flag is enabled, then the registration
   will replace the existing entry in the iSNS database. The existing
   object(s) specified in the DevAttrReg message shall be de-

Tseng, Gibbons, et al.     Standards Track                  [Page 37]


                 Internet Storage Name Service (iSNS)      August 2002

   registered.  A new registration shall be created with the new
   attribute value(s) in the registration request.  Existing
   associations between objects will be updated to reflect the new
   information.  For example, an existing STORAGE NODE object may be
   de-registered and reregistered with a different NETWORK ENTITY
   object with a single registration message.

   If the object key attributes match an existing object in the iSNS
   database, and the Replace flag is not enabled, then the new
   attribute value(s) in the registration request SHALL update existing
   values and may add new, additional attributes for the object key
   entry.  Only non-key attributes can be updated.  Existing
   associations between objects will be maintained and SHALL NOT be
   changed if the Replace flag is not enabled.  If a registration
   update of the existing object would cause a change in associations,
   then the error ôInvalid Updateô SHALL be returned.  For example, if
   a DevAttrReg message with an Entity Identifier key for one NETWORK
   ENTITY object contains a STORAGE NODE object attribute associated
   with different NETWORK ENTITY object, then an error shall be
   returned.

6.6.5.2  Device Attribute Query Request (DevAttrQry)

   The DevAttrQry message type is 0x0002.  The DevAttrQry message
   provides an iSNS client with the means to query the iSNS server for
   objects and attributes.

   The source attribute identifies the node initiating the request, and
   is used to scope the query to the Discovery Domains that the
   initiating node is a member of.

   The Message Key Attribute(s) follow the source attribute in the
   message payload.  The attributes returned by the query will be from
   objects WHERE the Message Key Attribute(s) match the object.

   If no operating attributes are included in the DevAttrQry, then all
   operating attributes of the object and sub-objects identified by the
   message key attribute(s) SHALL be returned in the response message.

   For queries by non-control nodes, any objects matching the Message
   Key Attributes that are not in the same Discovery Domain as the
   Source Attribute SHALL NOT be included in the response message.

   Registration and query messages for iSNS server-specific attributes
   (i.e., tags in the range 132 to 384) shall be formatted using the
   identifying key attribute of the STORAGE NODE originating the query
   (i.e., iSCSI Name or FC Port Name WWPN) for both the source
   attribute and message key attribute.  Operating attributes shall
   include the TLV of the server-specific attribute being requested.

   The DevAttrQry message shall support the following minimum set of
   Message Key Attributes:



Tseng, Gibbons, et al.     Standards Track                  [Page 38]


                 Internet Storage Name Service (iSNS)      August 2002

          Valid Message Key Attributes for Queries
          ----------------------------------------
           Entity Identifier
           Entity Protocol
           Portal IP-Address
           Portal IP-Address, Portal TCP/UDP Port
           iSCSI Node Type
           iSCSI Identifier
           FC Port Name WWPN
           FC Port Type
           FC-4 Type
           Source Attribute (for server-specific attributes)
           Switch Name (FC Device WWNN--for space identifier queries)

6.6.5.3  Device Get Next Request (DevGetNext)

   The DevGetNext message type is 0x0003. This message provides the
   iSNS client with the means to retrieve each and every type of object
   exactly once.

   The source attribute identifies the node initiating the DevGetNext
   request, and is used to scope the retrieval process to the Discovery
   Domains that the initiating node is a member of.

   The Message Key Attribute may be an Entity Identifier (EID), iSCSI
   Name, Portal IP Address and TCP/UDP Port, FC Node Name WWNN, or FC
   Port Name WWPN.  If the TLV length of the Message Key Attribute(s)
   is zero, then the first accessible matching entry (Entity
   Identifier, iSCSI Name, Portal IP Address and TCP/UDP Port, FC Node
   name, or FC Port Name instance) shall be returned to the client.
   The DevGetNext response message SHALL return attributes of the
   object stored after the object identified by the Message Key
   Attribute (i.e., the next object). The Operating Attributes of the
   DevGetNext message specify which operating attributes of the next
   object are to be returned in the DevGetNext response message. If the
   Message Key provided matches the last object instance in the iSNS
   database, then the Status Code of 9 (No Such Entry) SHALL be
   returned in the response.

   Note that there are no specific requirements concerning the order in
   which object entries are retrieved from the iSNS database; the
   retrieval order of object entries using the DevGetNext message is
   implementation specific.

6.6.5.4  Device Deregister Request (DevDereg)

   The DevDereg message type is 0x0004.  This message is used to remove
   object entries from the iSNS database.  Multiple objects may be
   removed through a single DevDereg message only if the objects are of
   the same type.  Removal of different types of objects requires use
   of more than one DevDereg message.  For example, to remove one
   PORTAL object and one STORAGE NODE object, separate DevDereg
   messages are needed for each object.  But to remove two STORAGE NODE
   objects from the same entity, a single DevDereg message may be used

Tseng, Gibbons, et al.     Standards Track                  [Page 39]


                 Internet Storage Name Service (iSNS)      August 2002

   by listing the key attributes identifying each STORAGE NODEs as
   Message Key Attributes.

   Upon receiving the DevDereg, the iSNS server removes all objects
   identified by the Message Key Attribute(s), as well as all
   associated subordinate objects of those identified objects.  For
   example, removal of an ENTITY also results in removal of all
   associated PORTAL, STORAGE NODE, and FC DEVICE objects associated
   with that NETWORK ENTITY.

   The DevDereg request message payload contains a Source Attribute and
   Message Key Attribute(s).  If the node identified by the Source
   Attribute is not a control node, then it MUST be from the same
   entity as the object(s) identified for removal by the Message Key
   Attribute(s). Valid Message Key Attributes are shown below:

          Valid Message Key Attributes for DevDereg
          -----------------------------------------
           Entity Identifier
           Portal IP-Address
           Portal IP-Address, Portal TCP/UDP Port
           iSCSI Name
           FC Port Name WWPN
           FC Node Name WWNN

   The removal of the object may result in an SCN message to registered
   iSNS clients.

   If all nodes associated with an entity are deregistered from that
   entity, then the entity SHALL also be removed unless the entity
   (through one or more Portals) is responding to ESI's.

   If all Portals associated with an entity are deregistered from that
   entity, then that entity and all associated nodes SHALL be removed
   from the iSNS database.

6.6.5.5  SCN Register Request (SCNReg)

   The SCNReg message type is 0x0005.  The State Change Notification
   Registration Request (SCNReg) message allows an iSNS client to
   register a STORAGE NODE to receive State Change Notification (SCN)
   messages.

   SCN messages are sent to each indicated UDP or TCP Port specified in
   the SCN Port field (tag 23) of each PORTAL object associated with
   the STORAGE NODE requesting the SCN notification.  The SCN notifies
   the iSNS client of changes within its DD; if the STORAGE NODE is a
   control node, it will receive SCN notifications for changes in the
   entire network.  Note that while SCNReg sets the SCN Bitmap field,
   the DevAttrReg message registers the UDP or TCP Port used by each
   Portal to receive SCN messages.  If no SCN Port fields of any
   Portals of the iSNS client are registered to receive SCN messages,
   then the SCNReg message SHALL be rejected with Status Code 17 (SCN
   Registration Rejected).

Tseng, Gibbons, et al.     Standards Track                  [Page 40]


                 Internet Storage Name Service (iSNS)      August 2002

   The SCNReg request message payload contains a Source Attribute, a
   Message Key Attribute(s), and an Operating Attribute. Valid Message
   Key Attributes for an SCNReg are shown below:

          Valid Message Key Attributes for SCNReg
          ---------------------------------------
           iSCSI Name
           FC Port Name WWPN

   Nodes with iSCSI Name or FC Port Name WWPN attributes that match the
   Message Key Attributes in the SCNReg message are registered to
   receive SCNs using the specified SCN bitmap.

   The SCN Bitmap is the only operating attribute of this message, and
   it always overwrites the previous contents of this field in the iSNS
   database.  The bitmap indicates those INTERESTED EVENT TYPES the
   node is registering for.

   Note that the settings of this bitmap determine whether the SCN
   registration is for regular SCN's or management SCN's.  Only control
   nodes MAY conduct registrations for management SCN's; iSNS clients
   that are not control nodes MUST NOT conduct management SCN
   registrations.  Note that control nodes that register for management
   SCN's receive a copy of every SCN message generated by the iSNS
   server.  Therefore, management registrations should be used
   sparingly in order to conserve iSNS server resources, and the
   control nodes that conduct such registrations should be prepared to
   receive the anticipated volume of SCN message traffic.

6.6.5.6  SCN Deregister Request (SCNDereg)

   The SCNDereg message type is 0x0006. The SCNDereg message allows an
   iSNS client to disable State Change Notification (SCN) messages.

   The SCNDereg request message payload contains a Source Attribute and
   Message Key Attribute(s). Valid Message Key Attributes for an
   SCNDereg are shown below:

          Valid Message Key Attributes for SCNDereg
          -----------------------------------------
           iSCSI Name
           FC Port Name WWPN

   Nodes with iSCSI Name or FC Port Name WWPN attributes that match the
   Message Key Attributes in the SCNDereg message are deregistered for
   SCNs.  The SCN bitmap field of such nodes are cleared, and no SCN
   messages shall be sent for changes to that node.

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





Tseng, Gibbons, et al.     Standards Track                  [Page 41]


                 Internet Storage Name Service (iSNS)      August 2002

6.6.5.7  SCN Event (SCNEvent)

   The SCNEvent message type is 0x0007. The SCNEvent is a message sent
   by an iSNS client to request generation of a State Change
   Notification (SCN) message by the iSNS server.  The SCN, sent by the
   iSNS server, then notifies iFCP, iSCSI, and control nodes within the
   affected DD of the change indicated in the SCNEvent.

   Most SCNs are automatically generated by the iSNS server when nodes
   are registered or deregistered from the directory database.  SCNs
   are also generated when a network management application makes
   changes to the DD membership in the iSNS server.  However, an iSNS
   client can trigger an SCN by using SCNEvent.

   The SCNEvent message payload contains a Source Attribute, Message
   Key Attribute, and Operating Attribute. Valid Key Attributes for an
   SCNEvent are shown below:

          Valid Message Key Attributes for SCNEvent
          -----------------------------------------
           iSCSI Name
           FC Port Name WWPN

   The Operating Attributes section SHALL contain the SCN Event Bitmap
   attribute.  The bitmap indicates the event that caused the SCNEvent
   to be generated.

6.6.5.8  State Change Notification (SCN)

   The SCN message type is 0x0008. The SCN is a message generated by
   the iSNS server, notifying a registered node of changes. There are
   two types of SCN registrations: regular registrations and management
   registrations.  Regular SCN's notify iSNS clients of events within
   the discovery domain.  Management SCN's notify control nodes that
   register for management SCN's of events occurring anywhere in the
   network.

   The SCN message is sent to each Portal of the registered STORAGE
   NODE that has a registered TCP or UDP Port value in the SCN Port
   field.

   The types of events that can trigger an SCN message, and the amount
   of information contained in the SCN message, depend on the
   registered SCN Event Bitmap for the iSNS client.

   The format of the SCN payload is shown below:









Tseng, Gibbons, et al.     Standards Track                  [Page 42]


                 Internet Storage Name Service (iSNS)      August 2002

             +----------------------------------------+
             |         Destination Attribute          |
             +----------------------------------------+
             |               Timestamp                |
             +----------------------------------------+
             |          Source SCN Bitmap 1           |
             +----------------------------------------+
             |          Source Attribute [1]          |
             +----------------------------------------+
             |    Source Attribute [2](if present)    |
             +----------------------------------------+
             |    Source Attribute [3](if present)    |
             +----------------------------------------+
             |    Source Attribute [n](if present)    |
             +----------------------------------------+
             |    Source SCN Bitmap 2 (if present)    |
             +----------------------------------------+
             |                 . . .                  |
             +----------------------------------------+

   All payload attributes are in TLV format.

   The Destination Attribute is the node identifier that is receiving
   the SCN.  The Destination Attribute can be an iSCSI Name, or FC Port
   Name.

   The Timestamp field, using the Timestamp TLV format, indicates the
   time the SCN was generated.

   The Source Attributes describe the object(s) that are affected by
   the event causing the SCN to be generated.  For regular SCN
   messages, the Source Attributes can be an iSCSI Name or FC Port Name
   WWPN.  For management SCN messages, the Source Attributes can be an
   iSCSI Name, DD ID, DDS ID, or FC Port Name WWPN.  The provided
   source attribute can then be used by the iSNS client in a follow-up
   query to more fully learn of the changes in the iSNS database that
   triggered the SCN.

   For example, a management SCN to notify a control node of a new DD
   within a Discovery Domain Set would contain both the DD_ID and the
   DDS_ID of the affected Discovery Domain and Discovery Domain Set
   among the source attributes.  A regular SCN to notify an iSNS client
   of a new PORTAL available for particular iSCSI target would contain
   the iSCSI Name of the target device among the source attributes.

   The Source SCN Bitmap field indicates the type of SCN notification
   (i.e., regular or management SCN), and the type of event that caused
   the SCN to be generated; it does not necessarily correlate with the
   original SCN bitmap registered in the iSNS server.  This field is
   also used as a delimiter between information about multiple objects,
   if the SCN message is providing multiple SCN notifications.  See
   sections 7.4.4 and 7.5.12 for additional information on the SCN
   Bitmap.


Tseng, Gibbons, et al.     Standards Track                  [Page 43]


                 Internet Storage Name Service (iSNS)      August 2002

6.6.5.9  DD Register (DDReg)

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

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

   The DDReg message payload contains the Source Attribute, and
   optionally Key and Operating Attributes.

   A DDReg message with no Message Key Attribute results in creation of
   a new Discovery Domain (DD).  If the DD_ID attribute (with non-zero
   length) is included among the operating attributes in the DDReg
   message, then the new Discovery Domain SHALL be assigned the value
   contained in that DD_ID attribute.  Otherwise, if the DD_ID
   attribute is not contained among the operating attributes of the
   DDReg message, or if the DD_ID is an operating attribute with TLV
   length of 0, then the iSNS server SHALL assign the DD_ID value that
   is returned in the DDReg Response message.

   The Operating Attributes can contain the iSCSI Node Identifier or FC
   Port Name of iSNS clients to be added to the DD.  It may also
   contain the DD_Symbolic_Name of the DD.

   This message shall add any DD members listed as operating attributes
   to the Discovery Domain specified by the DD_ID.  In addition, if the
   DD_Symbolic_Name is an operating attribute, then it will be stored
   in the iSNS database as the DD_Symbolic_Name for the specified
   Discovery Domain.

6.6.5.10 DD Deregister (DDDereg)

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

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

   The DDDereg message payload contains a Source Attribute, Message Key
   Attribute, and Operating Attributes.

   The Message Key Attribute for a DDDereg message is the DD ID for the
   domain being removed, or having members removed.  If the DD ID
   matches an existing DD, and there are no operating attributes, then
   the DD will be removed and a success Status Code returned.  If the
   Message Key Attribute does not match an existing DD then the Status
   Code 9 (No Such Entry) will be returned.

   If the DD ID matches an existing DD, and there are operating
   attributes matching DD members, then the DD members identified by
   the operating attributes SHALL be removed from the DD and a

Tseng, Gibbons, et al.     Standards Track                  [Page 44]


                 Internet Storage Name Service (iSNS)      August 2002

   successful Status Code (0 or 1) returned.  If any of the operating
   attributes do not match existing DD members, then the Status Code 9
   (No Such Entry) will be returned, and no DD members shall be
   removed.

6.6.5.11 DDS Register (DDSReg)

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

   DDSÆs are uniquely defined using DDS_IDÆs.  DDS registration
   attributes are described in section 7.9.1.

   The DDSReg message payload contains the Source Attribute, and
   optionally, Message Key and Operating Attributes.

   A DDSReg message with no Message Key Attribute results in creation
   of a new Discovery Domain Set (DDS).  If the DDS_ID attribute (with
   non-zero length) is included among the operating attributes in the
   DDSReg message, then the new Discovery Domain Set SHALL be assigned
   the value contained in that DDS_ID attribute.  Otherwise, if the
   DDS_ID attribute is not contained among the operating attributes of
   the DDSReg message, or if the DDS_ID is an operating attribute with
   TLV length of 0, then the iSNS server SHALL assign the DDS_ID value
   that is returned in the DDSReg Response message.

   The Operating Attributes can contain the DDS_Symbolic_Name and the
   DD_IDÆs of Discovery Domains to be added to the DDS.

   This message shall add any DDS members listed as operating
   attributes to the Discovery Domain Set specified by the DDS_ID
   Message Key Attribute.  In addition, if the DDS_Symbolic_Name is an
   operating attribute, then it will be stored in the iSNS database as
   the DDS_Symbolic_Name for the specified Discovery Domain Set.

6.6.5.12 DDS Deregister (DDSDereg)

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

   The DDSDereg message payload contains a Source Attribute, Message
   Key Attribute, and Operating Attributes.

   The Message Key Attribute for a DDSDereg message is the DDS ID for
   the set being removed, or having members removed.  If the DDS ID
   matches an existing DDS, and there are no operating attributes, then
   the DDS will be removed and a success Status Code returned.  If the
   Message Key Attribute does not match an existing DDS then the Status
   Code 9 (No Such Entry) will be returned.

   If the DDS ID matches an existing DDS, and there are operating
   attributes matching DDS members, then the DDS members will be

Tseng, Gibbons, et al.     Standards Track                  [Page 45]


                 Internet Storage Name Service (iSNS)      August 2002

   removed from the DDS and a success Status Code returned.  If any of
   the operating attributes do not match existing DDS members, then the
   Status Code 9 (No Such Entry) will be returned and no DDS members
   shall be removed.

6.6.5.13 Entity Status Inquiry (ESI)

   The ESI message type is 0x000D. This message is sent by the iSNS
   server, and is used to verify that an iSNS client portal is
   reachable and available. The ESI message is sent to the ESI UDP port
   provided during registration, or the TCP connection used for ESI
   registration, depending on which communication type that is being
   used.

   The ESI message payload contains several attributes in TLV format,
   including the current iSNS timestamp, the EID, the Portal IP
   Address, and Portal TCP/UDP Port.

   The ESI response message payload contains the Attributes from the
   original ESI message.

   If the iSNS client portal fails to respond to an administratively-
   determined number of consecutive ESI messages, then the iSNS server
   SHALL remove that client portal from the iSNS database. If there are
   no other remaining ESI monitored portals for the associated entity,
   then the entity SHALL also be removed.  The appropriate State Change
   Notifications, if any, SHALL be triggered.

6.6.5.14 Name Service Heartbeat (Heartbeat)

   This message, if used, is only sent by the active iSNS server.  It
   allows iSNS clients and backup servers listening to a broadcast or
   multicast address to discover the IP address of the primary and
   backup iSNS servers.  It also allows concerned parties to monitor
   the health and status of the primary iSNS server.

   This message is NOT in TLV format.  There is no response message to
   the Name Service Heartbeat.

















Tseng, Gibbons, et al.     Standards Track                  [Page 46]


                 Internet Storage Name Service (iSNS)      August 2002

        MSb                                            LSb
        0                                               31
        +------------------------------------------------+
        |            Active Server IP-Address            |
        +------------------------------------------------+
        |     iSNS TCP Port     |      iSNS UDP Port     |
        +------------------------------------------------+
        |                   Interval                     |
        +------------------------------------------------+
        |                    Counter                     |
        +------------------------------------------------+
        |      RESERVED         |    Backup Servers      |
        +------------------------------------------------+
        |    Primary Backup Server IP Address(if any)    |
        +------------------------------------------------+
        |Backup TCP Port(if any)|Backup UDP Port(if any) |
        +------------------------------------------------+
        |      2nd Backup Server IP Address(if any)      |
        +------------------------------------------------+
        |Backup TCP Port(if any)|Backup UDP Port(if any) |
        +------------------------------------------------+
        |                     . . .                      |
        +------------------------------------------------+
        |                VENDOR SPECIFIC                 |
        +------------------------------------------------+

   The heartbeat payload contains:

   Active Server IP-Address: the IP_Address of the active iSNS server
   in IPv6 format.

   Active TCP Port: the TCP Port of the server currently in use

   Active UDP Port: the UDP Port of the server currently in use,
   otherwise 0

   Interval: the interval, in seconds, of the heartbeat

   Counter: a monotonically incrementing count of heartbeats sent

   Backup Servers: the number of iSNS backup servers.  The IP address,
   TCP Port, and UDP Port of each iSNS backup server follow this field.
   Note that if backup servers are used, then the active iSNS server
   SHOULD list be among the list of backup servers.

   The content of the remainder of this message after the list of
   backup servers is vendor-specific.  Vendors may use additional
   fields to coordinate between multiple iSNS servers, and/or to
   identify vendor specific features.

6.6.5.15 Request Switch ID (RqstSwId)

   The RqstSwId message type is 0x0011. This message is used for iFCP
   Transparent Mode to allocate non-overlapping SWITCH_ID values

Tseng, Gibbons, et al.     Standards Track                  [Page 47]


                 Internet Storage Name Service (iSNS)      August 2002

   between 1 and 239. The iSNS server becomes the address assignment
   authority for the entire iFCP fabric.  To obtain multiple SWITCH_ID
   values, this request must be repeated multiple times to the iSNS
   server.  iSNS clients that acquire SWITCH_ID values from an iSNS
   server MUST register for ESI monitoring from that iSNS server.

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

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

   Once a SWITCH_ID value has been allocated to an iSNS client by the
   iSNS server for a given Space_Identifier, that SWITCH_ID value SHALL
   NOT be reused until it has been deallocated, or until ESI monitoring
   detects that the iSNS client no longer exists on the network and
   objects for that client are removed from the iSNS database.

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

6.6.5.16 Release Switch ID (RlseSwId)

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

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

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





Tseng, Gibbons, et al.     Standards Track                  [Page 48]


                 Internet Storage Name Service (iSNS)      August 2002

6.6.5.17 Get Switch IDs (GetSwIds)

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

   The GetSwIds message payload contains a Source Attribute and Message
   Key Attribute.

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

6.7      Response Messages

   The iSNSP response message payloads contain an Status Code, followed
   by a list of attributes, and have the following format:

             MSb                                    LSb
             0                                       31
             +----------------------------------------+
             |          4-byte STATUS CODE            |
             +----------------------------------------+
             |  Message Key Attribute[1] (if present) |
             +----------------------------------------+
             |  Message Key Attribute[2] (if present) |
             +----------------------------------------+
             |  Message Key Attribute[3] (if present) |
             +----------------------------------------+
             |                 . . .                  |
             +----------------------------------------+
             |  - Delimiter Attribute - (if present)  |
             +----------------------------------------+
             |   Operating Attribute[1] (if present)  |
             +----------------------------------------+
             |   Operating Attribute[2] (if present)  |
             +----------------------------------------+
             |   Operating Attribute[3] (if present)  |
             +----------------------------------------+
             |                 . . .                  |
             +----------------------------------------+

   The iSNS Response messages will be sent to the iSNS Client IP
   Address and the originating TCP/UDP Port that was used for the
   associated registration and query message.

6.7.1   Status Code

   The first field in an iSNSP response message payload is the Status
   Code for the operation that was performed.  The Status Code encoding
   is defined in section 6.4.



Tseng, Gibbons, et al.     Standards Track                  [Page 49]


                 Internet Storage Name Service (iSNS)      August 2002

6.7.2   Message Key Attributes in Response

   Depending on the specific iSNSP request, the response message will
   contain Message Key Attributes.  Message Key Attributes generally
   contain the interesting key attributes that are affected by the
   operation specified in the original iSNS registration or query
   message.  Non-key attributes MUST NOT be listed among the Message
   Key Attributes.

6.7.3   Delimiter Attribute in Response

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

6.7.4   Operating Attributes in Response

   The Operating Attributes in a response are the results related to
   the iSNS registration or query operation being performed.  Some
   response messages will not have operating attributes.

6.7.5   Registration and Query Response Message Types

   The following describes each query and message type.

6.7.5.1  Device Attribute Registration Response (DevAttrRegRsp)

   The DevAttrRegRsp message type is 0x8001.  The DevAttrRegRsp message
   contains the results for the DevAttrReg message with the same
   TRANSACTION ID.

   The Message Key Attributes contain the set of key attributes
   identifying the objects registered by the Register Device Attribute
   message.  These key attributes are listed in their order of
   inheritance hierarchy.  If the iSNS server assigned the Entity
   Identifier for a network entity, then the Message Key Attribute
   field SHALL contain the assigned Entity Identifier.

   The operating attributes of the DevAttrRegRsp message contain the
   affected objects and attributes that have been modified or added by
   the iSNS server. These attributes include key and non-key attributes
   identifying the object and the modified or added attribute.  Note
   that key attributes should also be among listed among the Message
   Key Attributes.  Among the operating attributes, each modified or
   added non-key attribute shall be listed following its key attribute.

   For example, three Portals are registered in the original DevAttrReg
   request message.  Due to lack of resources, the iSNS server needs to
   modify the registered ESI Interval value of one of those Portals.
   To accomplish this, the iSNS server returns the key attributes
   identifying the Portal, followed by the non-key modified ESI
   Interval attribute value, as operating attributes of the

Tseng, Gibbons, et al.     Standards Track                  [Page 50]


                 Internet Storage Name Service (iSNS)      August 2002

   corresponding DevAttrRegRsp message.  In addition, the key
   attributes for each Portal are also listed among the Message Key
   Attributes.

   The iSNS server may also reject a specific attribute registration in
   a multi-attribute registration message.  It accomplishes this by
   returning the rejected attribute's TLV with length set to 0 in the
   operating attributes of the response message.  The key attribute
   identifying the parent object to the rejected attribute value must
   precede the rejected non-key attribute.

6.7.5.2  Device Attribute Query Response (DevAttrQryRsp)

   The DevAttrQryRsp message type is 0x8002.  The DevAttrQryRsp message
   contains the results for the DevAttrQry message with the same
   TRANSACTION ID.

   If no operating attributes are included in the original query, then
   all operating attributes will be returned in the response.

   For a successful query result, the DevAttrQryRsp Operating
   Attributes will contain the results of the original DevAttrQry
   message.

6.7.5.3  Device Get Next Response (DevGetNextRsp)

   The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message
   contains the results for the DevGetNext message with the same
   TRANSACTION ID.

   The Message Key Attribute field returns the object keys for the next
   object after the Message Key Attribute in the original DevGetNext
   message.

   The Operating Attribute field returns the operating attributes of
   the next object as requested in the original DevGetNext message.
   The values of the Operating Attributes are those associated with the
   object identified by the Message Key Attribute field of the
   DevGetNextRsp message.

6.7.5.4  Deregister Device Response (DevDeregRsp)

   The DevDeregRsp message type is 0x8004.  This message is the
   response to the DevDereg request message.

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

6.7.5.5  SCN Register Response (SCNRegRsp)

   The SCNRegRsp message type is 0x8005. This message is the response
   to the SCNReg request message.



Tseng, Gibbons, et al.     Standards Track                  [Page 51]


                 Internet Storage Name Service (iSNS)      August 2002

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

6.7.5.6  SCN Deregister Response (SCNDeregRsp)

   The SCNDeregRsp message type is 0x8006.  This message is the
   response to the SCNDereg request message.

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

6.7.5.7  SCN Event Response (SCNEventRsp)

   The SCNEventRsp message type is 0x8007. This message is the response
   to the SCNEvent request message.

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

6.7.5.8  SCN Response (SCNRsp)

   The SCNRsp message type is 0x8008. This message is sent by an iSNS
   client, and provides confirmation that the SCN message was received
   and processed.

   The SCNRsp response message payload also contains the SCN
   Destination Attribute representing the node identifier that received
   the SCN.

6.7.5.9  DD Register Response (DDRegRsp)

   The DDRegRsp message type is 0x8009. This message is the response to
   the DDReg request message.

   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.

6.7.5.10 DD Deregister Response (DDDeregRsp)

   The DDDeregRsp message type is 0x800A.  This message is the response
   to the DDDereg request message.

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

6.7.5.11 DDS Register Response (DDSRegRsp)

   The DDSRegRsp message type is 0x800B. This message is the response
   to the DDSReg request message.

   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.

Tseng, Gibbons, et al.     Standards Track                  [Page 52]


                 Internet Storage Name Service (iSNS)      August 2002

6.7.5.12 DDS Deregister Response (DDSDeregRsp)

   The DDSDeregRsp message type is 0x800C.  This message is the
   response to the DDSDereg request message.

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

6.7.5.13 Entity Status Inquiry Response (ESIRsp)

   The ESIRsp message type is 0x800D. This message is sent by an iSNS
   client, and provides confirmation that the ESI message was received
   and processed.

   The ESIRsp response message payload contains the attributes from the
   original ESI message.  These attributes represent the iSNS client
   portal that is responding to the ESI. The ESIRsp Attributes are in
   the order they were provided in the original ESI message.

   Upon receiving the ESIRsp from the iSNS client, the iSNS server
   SHALL update the timestamp attribute for that client entity and
   portal.

6.7.5.14 Request Switch ID Response (RqstSwIdRsp)

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

   The RqstSwId response contains a Status Code and the TLV attribute
   Assigned ID, which contains the integer value in the space
   requested. If no further unallocated values are available from this
   space, the iSNS server SHALL respond with the Status Code 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.

6.7.5.15 Release Switch ID Response (RlseSwIdRsp)

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

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


Tseng, Gibbons, et al.     Standards Track                  [Page 53]


                 Internet Storage Name Service (iSNS)      August 2002

6.7.5.16 Get Switch IDs Response (GetSwIdRsp)

   The GetSwIdsResp message type is 0x8013. This 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 Status Code
   indicating if the request was successful, and a list of the Assigned
   IDs from the space requested.  The Assigned_ID attributes are listed
   in TLV format.

6.8      Vendor Specific Messages

   Vendor-specific iSNSP messages have a functional ID of between
   0x0100 and 0x01FF, while vendor-specific responses have a functional
   ID of between 0x8100 and 0x81FF.  The first Message Key Attribute in
   a vendor-specific message SHALL be the company OUI (tag=256)
   identifying original creator of the proprietary iSNSP message.  The
   contents of the remainder of the message are vendor-specific.

7.       iSNS Message Attributes

   The following attributes are stored in the iSNS server.  Attributes
   can be inserted into the iSNS server using iSNSP registration
   messages, and they can be retrieved using iSNSP query messages.
   Unless otherwise indicated, these attributes are supplied by iSNS
   clients using iSNSP registration messages.

7.1      iSNS Attribute Summary

   The following table lists all iSNSP message attributes:

   T Entity Attributes       Length   Tag   Reg Key   Query Key
   - -----------------       ------   ---   -------   ---------
     Delimiter               0        0     N/A       N/A
   ^ Entity Identifier (EID) 0-256    1     1         1|2|16,17|32|64
   & Entity Protocol         4        2     1         1|2|16,17|32|64
     Management IP Address   16       3     1         1|2|16,17|32|64
   = Timestamp               8        4     1         1|2|16,17|32|64
     Protocol Version Range  4        5     1         1|2|16,17|32|64
     Registration Period     4        6     1         1|2|16,17|32|64
     Entity Index            4        7     1         1|2|16,17|32|64
     Entity ISAKMP Phase-1   var      11    1         1|2|16,17|32|64
   * Entity Certificate      var      12    1         1|2|16,17|32|64
   # Portal IP Address       16       16    1         1|16,17|32|64
   $ Portal TCP/UDP Port     4        17    1         1|16,17|32|64
     Portal Symbolic Name    0-256    18    16,17     1|16,17|32|64
     ESI Interval            4        19    16,17     1|16,17|32|64
     ESI Port                4        20    16,17     1|16,17|32|64
     Portal Group Tag        4        21    16,17     1|16,17|32|64
     Portal Index            4        22    16,17     1|16,17|32|64
     SCN Port                4        23    16,17     1|16,17|32|64
     Portal Security Bitmap  4        27    16,17     1|16,17|32|64
   * Portal ISAKMP Phase-1   var      28    16,17     1|16,17|32|64

Tseng, Gibbons, et al.     Standards Track                  [Page 54]


                 Internet Storage Name Service (iSNS)      August 2002

   * Portal ISAKMP Phase-2   var      29    16,17     1|16,17|32|64
   * Portal Certificate      var      31    16,17     1|16,17|32|64
   # iSCSI Name              0-256    32    1%        1|16,17|32|33
   & iSCSI Node Type         4        33    32        1|16,17|32
     iSCSI Alias             0-256    34    32        1|16,17|32
     iSCSI SCN Bitmap        4        35    32        1|16,17|32
     iSCSI Node Index        4        36    32        1|16,17|32
     WWNN Token              8        37    32        1|16,17|32
     iSCSI AuthMethod        var      42    32        1|16,17|32
   * iSCSI Node Certificate  var      43    32        1|16,17|32
   # FC Port Name WWPN       8        64    1%     1|16,17|64|66|96|128
     Port ID                 3        65    64        1|16,17|64
     FC Port Type            4        66    64        1|16,17|64
     Symbolic Port Name      0-256    67    64        1|16,17|64
     Fabric Port Name        8        68    64        1|16,17|64
     Hard Address            3        69    64        1|16,17|64
     Port IP-Address         16       70    64        1|16,17|64
     Class of Service        4        71    64        1|16,17|64
     FC-4 Types              32       72    64        1|16,17|64
     FC-4 Descriptor         0-256    73    64        1|16,17|64
     FC-4 Features           128      74    64        1|16,17|64
     iFCP SCN bitmap         4        75    64        1|16,17|64
     Port Role               4        76    64        1|16,17|64
   * Port Certificate        var      83    64        1|16,17|64
     FC-4 Type Code          4        95    Query Key only
   # FC Node Name WWNN       8        96    64        1|16,17|64|96
     Symbolic Node Name      0-256    97    96        64|96
     Node IP-Address         16       98    96        64|96
     Node IPA                8        99    96        64|96
   * Node Certificate        var     100    96        64|96
     Proxy iSCSI Name        0-256   101    96        64|96
     Switch Name             8       128    128
     Preferred ID            4       129    128       128
     Assigned ID             4       130    128       128
     Space_Identifier        0-256   131    128       128
     RESERVED--server-specific     132-255  SOURCE    SOURCE Attribute
     iSNS Server Vendor OUI  4       256    ------    SOURCE Attribute
   * Vendor-Spec iSNS Srvr   var   257-384  SOURCE    SOURCE Attribute
   * Vendor-Spec Entity      var   385-512  1         1|2|16,17|32|64
   * Vendor-Spec Portal      var   513-640  16,17     1|16,17|32|64
   * Vendor-Spec iSCSI Node  var   641-768  32        16,17|32
   * Vendor-Spec FC Port Name var  769-896  64        1|16,17|64
   * Vendor-Spec FC Node Name var  897-1024 96        64|96
   * Vendor-Specific DDS      var 1025-1280 2049      2049
   * Vendor-Specific DD      var  1281-1536 2065      2065
   * Other Vendor-Specific   var  1537-2048 vendor-defined
     DD_Set ID               4      2049    @         1|32|64|2049|2065
     DD_Set Sym Name         4-256  2050    2049      2049
     DD_Set Status           4      2051    2049      2049
     RESERVED                    2052-2064
   + DD_ID                   4      2065    @|2049    1|32|64|2049|2065
     DD_Symbolic Name        4-256  2066    2065      2065
     DD_iSCSI Node Index     4      2067    2065      2065
     DD_iSCSI Node Member    0-256  2068    2065      2065

Tseng, Gibbons, et al.     Standards Track                  [Page 55]


                 Internet Storage Name Service (iSNS)      August 2002

     DD_iFCP Member (WWPN)   8      2069    2065      2065
     RESERVED                     2070-2077
     DD_Features             4      2078    2065      2065
     RESERVED                     2079-65535

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

   Length - indicates the attribute length in bytes.  Variable-length
   identifiers are NULL-terminated (NULL is included in the length).

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

   Reg Key - indicates the possible tag values for the object key in
   registration messages for storing a new attribute value in the
   database.

   Query Key - indicates the possible tag values for the Message Key
   and object key that used in the query messages for retrieving a
   stored value from the iSNS database.

   Attribute Type (T)
   --------------------------------------------------------------
   # : Required key for object registration
   ^ : Required key for object registration, unique value is
       assigned by the iSNS server 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
   * : Optional to implement.
   = : Cannot be used as a query key or be explicitly registered.  This
       value is provided by the iSNS server.
   | : used to separate the different sets of possible keys in the
       table.
   % : If an iSCSI Name or FC Port Name 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
   + : A DD ID is placed into a DD_Set by using the DD_Set ID
       as the object key attribute

7.2      Entity Identifier-Keyed Attributes

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

7.2.1   Entity Identifier (EID)

   The Entity Identifier (EID) is a variable-length field containing
   user-readable UTF-8 text, and is terminated with at least one NULL
   character. variable length identifier   This field uniquely
   identifies each network entity registered in the iSNS server.  The

Tseng, Gibbons, et al.     Standards Track                  [Page 56]


                 Internet Storage Name Service (iSNS)      August 2002

   attribute length varies from 4 to 256 bytes (including the NULL
   termination), and is a unique value within the iSNS server.

   If the iSNS client does not provide an EID during registration the
   iSNS server shall generate one that is unique within the iSNS
   database.  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.

   In environments where the iSNS server is integrated with a DNS
   infrastructure, the Entity Identifier may be used to store the Fully
   Qualified Domain Name (FQDN) of the iSCSI or iFCP device.  FQDN's of
   greater than 255 bytes MUST NOT be used.

   If FQDN's are not used, the iSNS server can be used to generate
   EIDs.  By convention, EIDs generated by the iSNS server begin with
   the string ôiSNS:ö.  iSNS clients MUST NOT generate and register
   EIDs beginning with the string "iSNS:".

7.2.2   Entity Protocol

   Entity Protocol is a required 4-byte integer attribute that
   indicates the protocol of registered network entity.  The valid
   protocol types are defined as below:

        Value          Entity Protocol Type
        -----          --------------------
          1            Protocol Neutral
          2            iSCSI
          3            iFCP
       All Others      RESERVED

   'Protocol neutral' is used to indicate that the NETWORK ENTITY does
   not support an IP block storage protocol.

7.2.3   Management IP Address

   This field contains the IP Address used to manage the Network Entity
   and all Storage Nodes contained therein.  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.  When this field contains an
   IPv6 value, the entire 16-byte field is used.  If the network entity
   is capable of being managed and this field is not set, then in-band
   management through the IP address of one of the Portals of the
   Network Entity is assumed.

7.2.4   Entity Registration Timestamp

   This field indicates the most recent time that the entity
   registration occurred or an associated object attribute was updated
   or queried by the iSNS client registering the entity. The time
   format is, in seconds, the update period since the standard base


Tseng, Gibbons, et al.     Standards Track                  [Page 57]


                 Internet Storage Name Service (iSNS)      August 2002

   time of 00:00:00 GMT on January 1, 1970.  This field cannot be used
   as a query key or be explicitly registered.

7.2.5   Protocol Version Range

   This field contains the minimum and maximum version of the protocol
   supported by the entity.  The most significant two bytes contain the
   maximum version supported, and the least significant two bytes
   contain the minimum version supported.  If a range is not registered
   then the entity is assumed to support all versions of the protocol.
   The value 0xffff is a wildcard that indicates no minimum or maximum.
   If the entity is protocol neutral, then this field SHALL be set to
   0.

7.2.6   Registration Period

   This field indicates the maximum period, in seconds, that the entity
   registration will be maintained by the server without receipt of an
   iSNS message from the iSNS client that registered the entity.  If
   the Registration Period is set to 0, then the Entity SHALL NOT be
   deregistered due to no contact with the iSNS client.

   If Entity Status Inquiry (ESI) messages are not requested by an
   entity and the Registration Period is not set to 0, then the entity
   registration SHALL be removed if an iSNS Protocol message is not
   received from the iSNS client before the registration period has
   expired.  Receipt of any iSNS Protocol message from the iSNS client
   automatically refreshes the Entity Registration Period and Entity
   Registration Timestamp. To prevent a registration from expiring, the
   iSNS client should send an iSNS Protocol message to the iSNS server
   at intervals shorter than the registration period.  Such a message
   can be as simple as a query for one of its own attributes, using its
   associated iSCSI Name or FC Port Name WWPN as the SOURCE attribute.

   For an iSNS client that is a NETWORK ENTITY with multiple STORAGE
   NODE objects, receipt of an iSNS message from any STORAGE NODE of
   that entity is sufficient to refresh the registration for all
   STORAGE NODE objects of the entity.

   Byte 2 and 3 (the least significant bytes) represents the entity
   registration period, in seconds.  Byte 0 and 1 are reserved.

   If ESI support is requested as part of a portal registration, the
   ESI Response message received from the iSNS client by the iSNS
   server SHALL refresh the entity registration.

7.2.7   Entity Index

   The Entity Index is a 4-byte integer value that uniquely identifies
   each network entity registered in the iSNS server.  The Entity Index
   is assigned by the iSNS server during the initial registration of an
   Entity.  It can be used to represent a registered entity in
   situations where the Entity Identifier is too long to be used.


Tseng, Gibbons, et al.     Standards Track                  [Page 58]


                 Internet Storage Name Service (iSNS)      August 2002

7.2.8   Entity ISAKMP Phase-1 Proposals

   This field contains the IKE Phase-1 proposal listing in decreasing
   order of preference the protection suites acceptable to protect all
   IKE Phase-2 messages sent and received by the Entity.  This includes
   Phase-2 SA's from the iSNS client to the iSNS server as well as to
   peer iFCP and/or iSCSI devices.  This attribute contains the SA
   payload, proposal payload(s), and transform payload(s) in the ISAKMP
   format defined in [RFC2408].

   This field should be used if the implementer wishes to define a
   single phase-1 SA security configuration used to protect all phase-2
   IKE traffic.  If the implementer desires to have a different phase-1
   SA security configuration to protect each Portal interface, then the
   Portal Phase-1 Proposal (section 7.3.10) should be used.

7.2.9   Entity Certificate

   This attribute contains one or more X.509 certificate that are bound
   to the NETWORK ENTITY of the iSNS client. This certificate is
   uploaded and registered to the iSNS server by clients wishing to
   allow other clients to authenticate themselves and access the
   services offered by that NETWORK ENTITY.  The format of the X.509
   certificate is found in [X.509].

7.3      Portal-Keyed Attributes

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

7.3.1   Portal IP-Address

   This attribute is the IP address of the PORTAL through which a
   STORAGE NODE can transmit and receive storage data. When this field
   contains an IPv4 address, the most significant 12 bytes are set to
   0x00.  When this field contains an IPv6 address, the entire 16-byte
   field is used.  The Portal IP Address along with the Portal TCP/UDP
   Port number uniquely identifies a Portal.

7.3.2   Portal TCP/UDP Port

   The TCP/UDP port of the PORTAL through which a STORAGE NODE can
   transmit and receive storage data.  Bits 16 to 31 represents the
   TCP/UDP port number.  Bit 15 represents the port type.  If bit 15 is
   set, then the port type is UDP.  Otherwise it is TCP.  Bits 0 to 14
   are reserved.

   If the field value is 0, then the port number is the implied
   canonical port number and type of the protocol indicated by the
   associated Entity Type.



Tseng, Gibbons, et al.     Standards Track                  [Page 59]


                 Internet Storage Name Service (iSNS)      August 2002

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

7.3.3   Portal Symbolic Name

   This is a variable-length field containing 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 server.

7.3.4   Entity Status Inquiry Interval

   This field indicates the requested time, in seconds, between Entity
   Status Inquiry (ESI) messages sent from the iSNS server to this
   entity portal.  ESI messages can be used to verify that a Portal
   registration continues to be valid.  To request monitoring by the
   iSNS server, an iSNS client registers a non-zero value for this
   portal attribute using a DevAttrReg message.  The client must also
   register an ESI Port on at least one of its Portals to receive the
   ESI monitoring.

   If the iSNS server does not receive an expected response to an ESI
   message, it shall attempt an administratively configured number of
   re-transmissions of the ESI message.  The ESI Interval period begins
   with the iSNS server's receipt of the last ESI Response.  All re-
   transmissions MUST be sent before twice the ESI Interval period has
   passed.  If no response is received from any of the ESI messages,
   then the Portal SHALL be deregistered.  Note that only Portals that
   have registered a value in their ESI Port field can be deregistered
   in this way.

   If all Portals associated with an entity that have registered for
   ESI messages are deregistered due to non-response, and no
   registrations have been received from the client for at least two
   ESI Interval periods, then the entity and all associated objects
   (including storage nodes) SHALL be deregistered.

   If the iSNS server is unable to support ESI messages or the ESI
   Interval requested, it SHALL reject the ESI request by returning an
   "ESI Not Available" Status Code.

   If at any time an iSNS client that is registered for ESI messages
   has not received an ESI message to any of its portals as expected,
   then the client MAY attempt to query the iSNS server using a
   DevAttrQry message using its Entity_ID as the key.  If the query
   result is the error "no such entry", then the client SHALL close all
   remaining TCP connections to the iSNS server and assume that it is
   no longer registered in the iSNS database.  Such a client MAY
   attempt re-registration.

7.3.5   ESI Port

   This field contains the TCP or UDP port of the iSNS client used for
   ESI monitoring by the iSNS server. Bit 16 to 31 represents the port

Tseng, Gibbons, et al.     Standards Track                  [Page 60]


                 Internet Storage Name Service (iSNS)      August 2002

   number. If bit 15 is set, then the port type is UDP.  Otherwise, the
   port is TCP.  Bits 0 to 14 are reserved.

   If the iSNS client registers a valid TCP or UDP port number in this
   field, then the client SHALL allow ESI messages to be received at
   the indicated TCP or UDP port.  If a TCP port is registered and a
   pre-existing TCP connection from that TCP port to the iSNS server
   does not already exist, then the iSNS client SHALL accept new TCP
   connections from the iSNS server at the indicated TCP port.

   The iSNS server SHALL return an error if an Entity is registered for
   ESI monitoring and none of the portals of that Entity has an entry
   for the ESI Port field.  If multiple Portals have a registered ESI
   port, then the ESI message may be delivered to any of the indicated
   portals.

7.3.6   Portal Group Tag

   This field is used to group portals into aggregation groups.  The
   least significant two bytes of this field contain the integer Portal
   Group Tag value for the Portal.  The most significant two bytes are
   reserved.  All Portals MUST be members of a Portal Group.  For
   further details on use of Portal Groups, see [iSCSI].

   If a registration message creating a new Portal entry does not
   contain a Portal Group Tag attribute, or contains the Portal Group
   Tag attribute with TLV length of 0, then the iSNS server SHALL
   assign a 16-bit Portal Group Tag value for that Portal that is
   unique for that Network Entity.  The generated Portal Group Tag
   value shall be returned in the registration response as an operating
   attribute.

7.3.7   Portal Index

   The Portal Index is a 4-byte integer value that uniquely identifies
   each portal registered in the iSNS database.  The Portal Index is
   assigned by iSNS server during the initial registration of a portal.

   The Portal Index can be used to represent a registered portal in
   situations where the Portal IP-Address and Portal TCP/UDP Port is
   unwieldy to use.  An example of this is when SNMP tables are used to
   access the contents of the iSNS server.  In this case, the Portal
   Index may be used as the Registered Portal table index.

7.3.8   SCN Port

   This field contains the TCP or UDP port used by the iSNS client to
   receive SCN messages from the iSNS server.  When a value is
   registered for this attribute, an SCN message may be received on the
   indicated port for any of the STORAGE NODEs supported by the Portal.
   Bits 16 to 31 contain the port number.  If bit 15 is set, then the
   port type is UDP.  Otherwise, the port type is TCP.  Bits 0 to 14
   are reserved.


Tseng, Gibbons, et al.     Standards Track                  [Page 61]


                 Internet Storage Name Service (iSNS)      August 2002

   If the iSNS client registers a valid TCP or UDP port number in this
   field, then the client SHALL allow SCN messages to be received at
   the indicated TCP or UDP port.  If a TCP port is registered and a
   pre-existing TCP connection from that TCP port to the iSNS server
   does not already exist, then the iSNS client SHALL accept new TCP
   connections from the iSNS server at the indicated TCP port.

   The iSNS server SHALL return an error if an SCN registration message
   is received and none of the portals of the iSNS client has an entry
   for the SCN Port.  If multiple Portals have a registered SCN Port,
   then the SCN SHALL be delivered to all of the indicated portals of
   that entity.

7.3.9   Portal Security Bitmap

   This 4-byte field contains flags that indicate security attribute
   settings for the Portal.  Bit 31 (Lsb) of this field must be 1
   (enabled) in order for this field to contain significant
   information.  If Bit 31 is enabled, this signifies the iSNS server
   can be used to store and distribute security policies and settings
   for iSNS clients (i.e., iSCSI devices).  Bit 30 must be 1 in order
   for bits 25-29 to contain significant information.  All other bits
   are reserved for non-IKE/IPSec security mechanisms to be specified
   in the future.

   Bit Field           Flag Description
   ---------           ----------------
      25               1 = Tunnel Mode Preferred; 0 = No Preference
      26               1 = Transport Mode Preferred; 0 = No Preference
      27               1 = PFS Enabled; 0 = PFS Disabled
      28               1 = Aggressive Mode Enabled; 0 = Disabled
      29               1 = Main Mode Enabled; 0 = MM Disabled
      30               1 = IKE/IPSec Enabled; 0 = IKE/IPSec Disabled
      31 (Lsb)         1 = Bitmap VALID; 0 = INVALID
   All others reserved

7.3.10  Portal ISAKMP Phase-1 Proposals

   This field contains the IKE Phase-1 proposal listing in decreasing
   order of preference of the protection suites acceptable to protect
   all IKE Phase-2 messages sent and received by the Portal.  This
   includes Phase-2 SA's from the iSNS client to the iSNS server as
   well as to peer iFCP and/or iSCSI devices.  This attribute contains
   the SA payload, proposal payload(s), and transform payload(s) in the
   ISAKMP format defined in [RFC2408].

   This field should be used if the implementer wishes to define phase-
   1 SA security configuration on a per-PORTAL basis, as opposed to on
   a per-NETWORK ENTITY basis.  If the implementer desires to have a
   single phase-1 SA security configuration to protect all phase-2
   traffic regardless of the interface used, then the Entity Phase-1
   Proposal (section 7.2.8) should be used.



Tseng, Gibbons, et al.     Standards Track                  [Page 62]


                 Internet Storage Name Service (iSNS)      August 2002

7.3.11  Portal ISAKMP Phase-2 Proposals

   This field contains the IKE Phase-2 proposal, in ISAKMP format
   [RFC2408], listing in decreasing order of preference the security
   proposals acceptable to protect traffic sent and received by the
   Portal. This field is used only if bits 31, 30 and 29 of the
   Security Bitmap (see 7.3.9) are enabled.  This attribute contains
   the SA payload, proposal payload(s), and associated transform
   payload(s) in the ISAKMP format defined in [RFC2408].

7.3.12  Portal Certificate

   This attribute contains one or more X.509 certificates that is a
   credential of the PORTAL.  This certificate is used to identify and
   authenticate communications to the IP address supported by the
   Portal.  The format of the X.509 certificate is specified in [X.509]

7.4      iSCSI Node-Keyed Attributes

   The following attributes are stored in the iSNS database 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 database.

7.4.1   iSCSI Name

   This is a variable-length text-based field with length from 0 to 256
   bytes (including NULL termination).  This field is required for
   iSCSI STORAGE NODEs, and is provided by the iSNS client.  The
   registered iSCSI Name MUST be conformant to the format described in
   [iSCSI] for iSCSI Names.

   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.

7.4.2   iSCSI Node Type

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












Tseng, Gibbons, et al.     Standards Track                  [Page 63]


                 Internet Storage Name Service (iSNS)      August 2002

       Bit Field       Node Type
       ---------       ---------
          29            Control
          30            Initiator
          31 (Lsb)      Target
        All Others      RESERVED

   If the Target bit is set, then the node represents an iSCSI target.
   Setting of the Target bit MAY be performed by iSNS clients using the
   iSNSP.

   If the Initiator bit is set, then the node represents an iSCSI
   initiator.  Setting of the Initiator bit MAY be performed by iSNS
   clients using the iSNSP.

   If the control bit is set, then the node represents a gateway,
   management station, backup iSNS server, or other device which is not
   an initiator or target, but requires the ability to send and receive
   iSNSP messages, including state change notifications.  Setting of
   the control bit is an administrative task that MUST be performed on
   the iSNS server; iSNS clients SHALL NOT be allowed to change this
   bit using the iSNSP.

   This field MAY be used by the iSNS server to distinguish among
   permissions by different iSCSI node types for accessing various iSNS
   functions.  More than one Node Type bit may be simultaneously
   enabled.

7.4.3   iSCSI Node Alias

   This is a variable-length text-based field with length 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 database.

7.4.4   iSCSI Node SCN Bitmap

   The iSCSI Node SCN Bitmap indicates those events for which the
   registering iSNS client wishes to receive a notification message.
   The following table displays events that result in notifications,
   and the bit field in the SCN Bitmap that when enabled, results in
   the corresponding notification.













Tseng, Gibbons, et al.     Standards Track                  [Page 64]


                 Internet Storage Name Service (iSNS)      August 2002

   Note that this field is of dual use--it is used in the SCN
   registration process to define interested events that will trigger
   an SCN message, and it is also contained in each SCN message itself,
   to indicate the type of event that triggered the SCN message.

        Bit Field          Flag Description
        ---------          ----------------
           24              INITIATOR AND SELF INFORMATION ONLY
           25              TARGET AND SELF INFORMATION ONLY
           26              MANAGEMENT REGISTRATION/SCN
           27              OBJECT REMOVED
           28              OBJECT ADDED
           29              OBJECT UPDATED
           30              DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
           31 (Lsb)        DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
        All others         RESERVED

   DD/DDS MEMBER REMOVED indicates that an existing member of a
   Discovery Domain and/or Discovery Domain Set has been removed.

   DD/DDS MEMBER ADDED indicates that a new member was added to an
   existing DD and/or DDS.

   OBJECT REMOVED, OBJECT ADDED, and OBJECT UPDATED indicate a NETWORK
   ENTITY, PORTAL, STORAGE NODE, FC DEVICE, DD, and/or DDS object was
   removed, added, or updated in the iSNS database.  These flags are
   not used to indicate a change in the membership of a DD or DDS.

   Regular SCNs provide information about objects that are updated,
   added or removed from Discovery Domains that the iSNS client is a
   member of.  An SCN or SCN registration is considered a regular SCN
   or regular SCN registration if the MANAGEMENT REGISTRATION/SCN flag
   is cleared.  All iSNS clients may register for regular SCN's.

   Management SCNs provide information about all changes to the
   network, regardless of discovery domain membership.  Registration
   for management SCN's is indicated by enabling bit 26.  Only control
   nodes may register for management SCN's.  Bits 30 and 31 may only be
   enabled if bit 26 is enabled.

   TARGET AND SELF INFORMATION ONLY SCN's (bit 25) may be useful for
   iSCSI initiators.  This SCN provides information only about changes
   to target devices, or if the iSCSI Node itself has undergone a
   change.  Similarly, INITIATOR AND SELF INFORMATION ONLY SCN's (bit
   24) may be useful for iSCSI targets, by providing information only
   about changes to initiator nodes, or the target itself.

7.4.5   iSCSI Node Index

   The iSCSI Node Index is a 4-byte integer value that uniquely
   identifies each iSCSI node registered in the iSNS database.  The
   iSCSI Node Index is assigned by the iSNS server during the initial
   registration of the iSCSI node.


Tseng, Gibbons, et al.     Standards Track                  [Page 65]


                 Internet Storage Name Service (iSNS)      August 2002

   The iSCSI Node Index may be used to represent a registered node in
   situations where the iSCSI Name is too long to be used.  An example
   of this is when SNMP tables are used to access the contents of the
   iSNS server.  In this case, the iSCSI Node Index may be used as the
   registered iSCSI Node table index.

7.4.6   WWNN Token

   This field contains a globally unique 64-bit integer value that can
   be used to represent the World Wide Node Name of the iSCSI device in
   a Fibre Channel fabric. This identifier is used during the device
   registration process, and MUST conform to the requirements in [FC-
   FS].

   The FC-iSCSI gateway uses the value found in this field to register
   the iSCSI device in the Fibre Channel name server.  It is stored in
   the iSNS server to prevent conflict when assigning "proxy" WWNN
   values to iSCSI initiators establishing storage sessions to devices
   in the FC fabric.

   If the iSNS client does not assign a value for WWNN Token, then the
   iSNS server SHALL provide a value for this field upon initial
   registration of the iSCSI node.  The process by which the WWNN Token
   is assigned by the iSNS server MUST conform to the following
   requirements:

   1.  The assigned WWNN Token value MUST be unique among all WWN
   entries in the existing iSNS database, as well as among all devices
   that can potentially be registered in the iSNS database.

   2.  Once assigned, the iSNS server MUST persistently save the
   mapping between the WWNN Token value and registered iSCSI Name.
   That is, successive re-registrations of the iSCSI node keyed by the
   same iSCSI Name maintains the original mapping to the associated
   WWNN Token value in the iSNS server.  Similarly, the mapping shall
   be persistent across iSNS server reboots.  Once assigned, the
   mapping can only be changed if a DevAttrReg message from an
   authorized iSNS client explicitly provides a different WWNN Token
   value.

   3.  Once a WWNN Token value has been assigned and mapped to an iSCSI
   name, that WWNN Token value SHALL NOT be reused or mapped to any
   other iSCSI name.

   4.  The assigned WWNN Token value MUST conform to the formatting
   requirements of [FC-FS] for World Wide Names (WWN's).

   An iSNS client, such as an FC-iSCSI gateway or the iSCSI initiator,
   MAY register its own WWNN Token value or overwrite the iSNS Server-
   supplied WWNN Token value, if it wishes to supply its own iSCSI-FC
   name mapping.  This is accomplished using the DevAttrReg message
   with the WWNN Token (tag=37) as an operating attribute.  Once
   overwritten, the new WWNN Token value MUST be stored and saved by
   the iSNS server, and all requirements specified above continue to

Tseng, Gibbons, et al.     Standards Track                  [Page 66]


                 Internet Storage Name Service (iSNS)      August 2002

   apply.  If an iSNS client attempts to register a value for this
   field that is not unique in the iSNS database or is otherwise
   invalid, then the registration SHALL be rejected with an Status Code
   of 3 (Invalid Registration).

   There MAY be a matching records in the iSNS database for the Fibre
   Channel device specified by the WWNN Token.  These records for the
   FC device may contain device attributes for that FC device
   registered in the Fibre Channel fabric name server.

7.4.7   iSCSI AuthMethod

   This attribute contains a null-terminated string containing UTF-8
   text listing the iSCSI authentication methods enabled for this iSCSI
   Node, in order of preference.  The text values used to identify
   iSCSI authentication methods are embedded in this string attribute
   and delineated by a comma.  The text values are identical to those
   found in the main iSCSI draft [iSCSI]; additional vendor-specific
   text values are also possible.

        Text Value       Description                   Reference
        ----------       -----------                   ---------
          KB5            Kerberos V5                   RFC 1510
          SPKM1          Simple Public Key GSS-API     RFC 2025
          SPKM2          Simple Public Key GSS-API     RFC 2025
          SRP            Secure Remote Password        RFC 2945
          CHAP           Challenge Handshake Protocol  RFC 1994
          DH-CHAP        Diffie-Hellman Enhanced CHAP
          none           No iSCSI Authentication

7.4.8   iSCSI Node Certificate

   This attribute contains one or more X.509 certificates that may be a
   credential used to authenticate the iSCSI node during iSCSI
   authentication.  This certificate MAY be used for the SPKM Public
   Key authentication method.  The format of the X.509 certificate is
   specified in [X.509].

7.5      FC Port Name-Keyed Attributes

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

   Although the FC Port World Wide Name is associated with one Entity
   Identifier, it is also globally unique.

7.5.1   FC Port Name (WWPN)

   This 64-bit identifier uniquely defines the FC Port, and is the
   World Wide Port Name (WWPN) of the corresponding Fibre Channel
   device.  This globally unique identifier is used during the device


Tseng, Gibbons, et al.     Standards Track                  [Page 67]


                 Internet Storage Name Service (iSNS)      August 2002

   registration process, and uses a value conforming to IEEE EUI-64
   [EUI-64].

7.5.2   Port ID (FC_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 FC Port Name (WWPN) entry.

7.5.3   FC Port Type

   Indicates the type of FC port. 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

7.5.4   Symbolic Port Name

   A variable-length text-based description of up to 256 bytes, that is
   associated with the iSNS-registered FC Port Name in the network.
   The text field contains user-readable UTF-8 text and is terminated
   with at least one NULL character.

7.5.5   Fabric Port Name (FWWN)

   This 64-bit identifier uniquely defines the fabric port.  If the
   port of the FC Device is attached to a Fibre Channel fabric port
   with a registered Port Name, then that fabric Port Name shall be
   indicated in this field.

7.5.6   Hard Address

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

7.5.7   Port IP Address

   The Fibre Channel IP address associated with the FC Port.  When an
   IPv4 value is contained in this field, then the most significant 12

Tseng, Gibbons, et al.     Standards Track                  [Page 68]


                 Internet Storage Name Service (iSNS)      August 2002

   bytes are set to 0x00.  When an IPv6 value is contained in this
   field, then the entire 16-byte field is used.

7.5.8   Class of Service (COS)

   This 32-bit bit-map field indicates the Fibre Channel COS types that
   are supported by the registered port.  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 29 set
         3            Delivery Confirmation Not Provided  bit 28 set
                      RESERVED                            other

7.5.9   FC-4 Types

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

7.5.10  FC-4 Descriptor

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

7.5.11  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 field can be used to
   support Fibre Channel devices and is consistent with FC-GS-4.

7.5.12  iFCP SCN Bitmap

   This field indicates the events that the iSNS client is interested
   in.  These events can cause SCN to be generated.  SCNs provide
   information about objects that are updated, added or removed from
   Discovery Domains that the source and destination are a member of.
   Management SCNs provide information about all changes to the
   network.












Tseng, Gibbons, et al.     Standards Track                  [Page 69]


                 Internet Storage Name Service (iSNS)      August 2002

       Bit Field          Flag Description
       ---------          ----------------
          24              INITIATOR AND SELF INFORMATION ONLY
          25              TARGET AND SELF INFORMATION ONLY
          26              MANAGEMENT REGISTRATION/SCN
          27              OBJECT REMOVED
          28              OBJECT ADDED
          29              OBJECT UPDATED
          30              DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
          31 (Lsb)        DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
       All others         RESERVED

   Further information on use of the above specified bit fields can be
   found in section 7.4.4.

7.5.13  Port Role

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

       Bit Field          Node Type
       ---------          ---------
          29              Control
          30              Initiator
          31 (Lsb)        Target
      All Others          RESERVED

   If the 'Target' bit is set, then the port represents an FC target.
   Setting of the 'Target' bit MAY be performed by iSNS clients using
   the iSNSP.

   If the 'Initiator' bit is set, then the port represents an FC
   initiator. Setting of the 'Initiator' bit MAY be performed by iSNS
   clients using the iSNSP.

   If the 'Control' bit is set, then the port represents a gateway,
   management station, iSNS backup server, or other device.  This is
   usually a special device that is neither an initiator nor target,
   which requires the ability to send and receive iSNSP messages
   including state change notifications.  Setting of the control bit is
   an administrative task that MUST be administratively configured on
   the iSNS server; iSNS clients SHALL NOT be allowed to change this
   bit using the iSNSP.

   This field MAY be used by the iSNS server to distinguish among
   permissions by different iSNS clients.  For example, an iSNS server
   implementation may be administratively configured to allow only
   targets to receive ESI's, or for only control nodes to have
   permission to add, modify, or delete discovery domains.





Tseng, Gibbons, et al.     Standards Track                  [Page 70]


                 Internet Storage Name Service (iSNS)      August 2002

7.5.14  Port Certificate

   This attribute contains one or more X.509 certificates that is a
   credential of the iFCP STORAGE NODE.  The format of the X.509
   certificate is found in [X.509].

7.6      Node-Keyed Attributes

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

   The FC Node Name is unique across the entire iSNS database.

7.6.1   FC Node Name (WWNN)

   The FC Node Name is a 64-bit identifier that 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 EUI-64 [EUI-64].

7.6.2   Symbolic Node Name

   A variable-length NULL-terminated 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.

7.6.3   Node IP Address

   This 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. When an IPv6 value is contained in this
   field, then the entire 16-byte field is used.

7.6.4   Node IPA

   This field is the 8 byte Fibre Channel Initial Process Associator
   (IPA) associated with the device node in the network. The initial
   process associator is used for communication between Fibre Channel
   devices.

7.6.5   Node Certificate

   This attribute contains an X.509 certificate that is bound to the FC
   Node of the iSNS client.  The format of the X.509 certificate is
   specified in [X.509].

7.6.6   Proxy iSCSI Name

   This is a variable-length NULL-terminated text-based field that
   contains the iSCSI Name used to represent the FC Node in the IP

Tseng, Gibbons, et al.     Standards Track                  [Page 71]


                 Internet Storage Name Service (iSNS)      August 2002

   network.  It is used as a pointer to the matching iSCSI Name entry
   in the iSNS server.  Its value is usually registered by an FC-iSCSI
   gateway connecting the IP network to the fabric containing the FC
   device.

   Note that if this field is used, there SHOULD be a matching entry in
   the iSNS database for the iSCSI device specified by the iSCSI name.
   The database entry should include the full range of iSCSI attributes
   needed for discovery and management of the "iSCSI proxy image" of
   the FC device.

7.7      Other Attributes

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

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

7.7.2   iFCP Switch Name

   The iFCP Switch Name is a 64-bit World Wide Name (WWN) identifier
   that uniquely identifies a distinct iFCP gateway in the network.
   This globally unique identifier is used during the switch
   registration/switch ID assignment process.  The iFCP Switch Name
   value used MUST conform to the requirements stated in [FC-FS] for
   World Wide Names.  The iSNS server SHALL track the state of all
   Switch_ID values that have been allocated to each iFCP Switch Name.
   If a given iFCP Switch Name is deregistered from the iSNS database,
   then all Switch_ID values allocated to that iFCP Switch Name shall
   be returned to the unused pool of values.

7.7.3   iFCP Transparent Mode Commands

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

7.7.3.2  Assigned ID

   This is a 4-byte unsigned integer field that is used by an 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
   server MUST use the Entity Status Inquiry message to determine if an
   iFCP gateway is still present on the network.

Tseng, Gibbons, et al.     Standards Track                  [Page 72]


                 Internet Storage Name Service (iSNS)      August 2002

7.7.3.3  Space Identifier

   This a variable-length NULL-terminated text-based field.  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 an iSNS client
   shall have its own range of non-overlapping SWITCH_ID values to be
   allocated to iSNS clients.

7.8  iSNS Server-Specific Attributes

   Access to the following attributes for through either registration
   or query messages may be administratively controlled.  These
   attributes are specific to the iSNS server instance; the same value
   is returned for all iSNS clients accessing the iSNS server.

   A registration or query for iSNS Server-Specific attribute MUST
   contain the identifying key attribute (i.e., iSCSI Name or FC Port
   Name WWPN) of the node originating the registration or query message
   as the SOURCE and MESSAGE KEY attributes.  The operating attributes
   are the server-specific attributes being registered or queried.

7.8.1   iSNS Server Vendor OUI

   This attribute is the OUI (Organizationally Unique Identifier) [802-
   1990] identifying the specific vendor implementing the iSNS server.
   This attribute can only be queried; iSNS clients SHALL NOT be
   allowed to register a value for the iSNS Server Vendor OUI.

7.9      Discovery Domain Registration Attributes

7.9.1   DD Set ID Keyed Attributes

7.9.1.1  Discovery Domain Set ID (DDS ID)

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

   If the iSNS client does not provide a DDS_ID in a DDS registration
   request message, the iSNS server shall generate a DDS_ID value that
   is unique within the iSNS database for that new DDS.  The created
   DDS ID shall be returned in the response message.  The DDS ID value
   of 0 is reserved.

7.9.1.2  Discovery Domain Set Symbolic Name

   The DDS_Symbolic Name is a UTF-8, variable-length, NULL-terminated
   field.  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

Tseng, Gibbons, et al.     Standards Track                  [Page 73]


                 Internet Storage Name Service (iSNS)      August 2002

   server.  If the DDS symbolic name is not unique, then the DDS
   registration SHALL be rejected with an ôInvalid Registrationö Status
   Code.  The invalid attribute(s), in this case the DDS symbolic name,
   SHALL be included in the response.

7.9.1.3  Discovery Domain Set Status

   The DDS_Status field is a 32-bit bitmap indicating the status of the
   DDS.  Bit 0 of the bitmap indicates whether the DDS is Enabled (1)
   or Disabled (0).  The default value for the DDS Enabled flag is
   Disabled (0).

       Bit Field       DDS Status
       ---------       ---------
          31 (Lsb)      DDS Enabled (1) / DDS Disabled (0)
       All Others      RESERVED

7.9.2    DD ID Keyed Attributes

7.9.2.1  Discovery Domain ID (DD ID)

   The DD ID is a unique unsigned integer 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 server 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.

7.9.2.2  Discovery Domain Symbolic Name

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

7.9.2.3  Discovery Domain iSCSI Node Index

   This is the iSCSI Node Index of an iSNS client that is a member of
   the DD.  The DD may have a list of 0 to n members.  The iSCSI Node
   Index is one alternative representation of membership in a Discovery
   Domain, the other alternative being the iSCSI Name.  The Discovery
   Domain iSCSI Node Index is a 4-byte integer value.

   The iSCSI Node Index can be used to represent a DD member in
   situations where the iSCSI Name is too long to be used.  An example
   of this is when SNMP tables are used to access the contents of the
   iSNS server.




Tseng, Gibbons, et al.     Standards Track                  [Page 74]


                 Internet Storage Name Service (iSNS)      August 2002

   The iSCSI Node Index and iSCSI Name stored as a member in a DD SHALL
   be consistent with the iSCSI Node Index and iSCSI Name attributes
   registered for the STORAGE NODE object in the iSNS server.

7.9.2.4  Discovery Domain Member--iSCSI Name

   This is a variable-length NULL-terminated text-based field.  It
   indicates membership for the specified iSCSI STORAGE NODE in the
   Discovery Domain.  There is no limit to the number of members that
   may be in a DD. Membership is represented by the iSCSI Name of the
   iSCSI STORAGE NODE.

7.9.2.5  Discovery Domain Member--FC Port Name

   This 64-bit identifier attribute indicates membership for an iFCP
   STORAGE NODE (FC Port) in the Discovery Domain .  There is no limit
   to the number of members that may be in a DD.  Membership is
   represented by the FC Port Name (WWPN) of the iFCP STORAGE NODE.

7.9.2.6  Discovery Domain Features

   The Discovery Domain Features is a bitmap indicating the features of
   this DD.  The bit fields are defined below.  An enabled bit
   indicates the DD has the corresponding characteristics.

       Bit Field       DD Feature
       ---------       ----------
          31 (Lsb)      Boot List
        All Others      RESERVED

   Boot List: this feature indicates that the targets in this DD
   provide boot capabilities for the member initiators, as described in
   [iSCSI-boot].

7.10     Vendor-Specific Attributes

   Specific iSNS server implementations MAY define vendor-specific
   attributes for private use.  The tag values reserved for vendor-
   specific and user-specific use are defined in section 7.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
   the OUI in the vendor-specific or user-specific attribute field, and
   be able to execute vendor-specific handling of the attribute.

7.10.1  Vendor-Specific Server Attributes

   Attributes with tags in the range 257 to 384 are vendor-specific or
   site-specific attributes of the iSNS server.  Registration and/or
   query access to these attribute may be administratively controlled.

Tseng, Gibbons, et al.     Standards Track                  [Page 75]


                 Internet Storage Name Service (iSNS)      August 2002

   These attributes are unique for each logical iSNS server instance.
   Query and registration messages for these attributes SHALL use the
   key identifier (i.e., iSCSI Name or FC Port Name WWPN) for both the
   SOURCE attribute and MESSAGE KEY attribute.

7.10.2  Vendor-Specific Entity Attributes

   Attributes in the range 385 to 512 are vendor-specific or site-
   specific attributes used to describe the Entity object.  These
   attributes are keyed by the Entity Identifier attribute (tag=1).

7.10.3  Vendor-Specific Portal Attributes

   Attributes in the range 513 to 640 are vendor-specific or site-
   specific attributes used to describe the Portal object.  These
   attributes are keyed by the Portal IP-Address (tag=16) and Portal
   TCP/UDP Port (tag=17).

7.10.4  Vendor-Specific iSCSI Node Attributes

   Attributes in the range 641 to 768 are vendor-specific or site-
   specific attributes used to describe the iSCSI Node object.  These
   attributes are keyed by the iSCSI Name (tag=32).

7.10.5  Vendor-Specific FC Port Name Attributes

   Attributes in the range 769 to 896 are vendor-specific or site-
   specific attributes used to describe the N_Port Port Name object.
   These attributes are keyed by the FC Port Name WWPN (tag=64).

7.10.6  Vendor-Specific FC Node Name Attributes

   Attributes in the range 897 to 1024 are vendor-specific or site-
   specific attributes used to describe the FC Node Name object.  These
   attributes are keyed by the FC Node Name WWNN (tag=96).

7.10.7  Vendor-Specific Discovery Domain Attributes

   Attributes in the range 1025 to 1280 are vendor-specific or site-
   specific attributes used to describe the Discovery Domain object.
   These attributes are keyed by the DD_ID (tag=104).

7.10.8  Vendor-Specific Discovery Domain Set Attributes

   Attributes in the range 1281 to 1536 are vendor-specific or site-
   specific attributes used to describe the Discovery Domain Set
   object.  These attributes are keyed by the DD Set ID (tag=101)

7.10.9  Other Vendor-Specific Attributes

   Attributes in the range 1537 to 2048 can be used for key and non-key
   attributes that describe new vendor-specific objects specific to the
   vendor's iSNS server implementation.


Tseng, Gibbons, et al.     Standards Track                  [Page 76]


                 Internet Storage Name Service (iSNS)      August 2002

7.11     Standards-Based Extensions

   These attributes are reserved for future work by other standards
   bodies.

8.       Security Considerations

8.1      iSNS Security Threat Analysis

   When the iSNS protocol is deployed, the interaction between iSNS
   server and iSNS clients are subject to the following security
   threats:

   [1]  An attacker could alter iSNS protocol messages, such as to
   direct iSCSI and iFCP devices to establish connections with rogue
   peer devices, or to weaken/eliminate IPSec protection for iSCSI or
   iFCP traffic.

   [2]  An attacker could masquerade as the real iSNS server using
   false iSNS heartbeat messages.  This could cause iSCSI and iFCP
   devices to use rogue iSNS servers.

   [3]  An attacker could gain knowledge about iSCSI and iFCP devices
   by snooping iSNS protocol messages.  Such information could aid an
   attacker in mounting a direct attack on iSCSI and iFCP devices, such
   as a denial-of-service attack or outright physical theft.

   To address these threats, the following capabilities are needed:

   [a]  Unicast iSNS protocol messages may need to be authenticated.
   In addition, to protect against threat [3] above, confidentiality
   support is desirable, and REQUIRED when certain functions of iSNS
   server are utilized.

   [b]  Multicast iSNS protocol messages such as the iSNS heartbeat
   message may need to be authenticated. These messages need not be
   confidential since they do not leak critical information.

8.2      iSNS Security Implementation and Usage Requirements

   If the iSNS server is used to distribute authorizations for
   communications between iFCP and iSCSI peer devices, IPsec ESP with
   null transform MUST be implemented, and non-null transform MAY be
   implemented.  If a non-null transform is implemented, then the DES
   encryption algorithm MUST NOT be used.

   If the iSNS server is used to distribute security policy for iFCP
   and iSCSI devices, then authentication, data integrity, and
   confidentiality must be supported and used.  Where confidentiality
   is desired or required, IPSec ESP with non-null transform SHOULD be
   used, and the DES encryption algorithm MUST NOT be used.

   In order to protect against an attacker masquerading as an iSNS
   server, client devices must support the ability to authenticate

Tseng, Gibbons, et al.     Standards Track                  [Page 77]


                 Internet Storage Name Service (iSNS)      August 2002

   broadcast or multicast messages such as the iSNS heartbeat.  The
   iSNS authentication block (which is identical in format to the SLP
   authentication block) may be used for this purpose.  Note that the
   authentication block is used only for iSNS broadcast or multicast
   messages, and SHOULD NOT be used in unicast iSNS messages.

   There is no requirement that the communicating identities in iSNS
   protocol messages be kept confidential.  Specifically, the identity
   and location of the iSNS server shall not be considered
   confidential.

   For protecting unicast iSNS protocol messages, iSNS servers
   supporting security MUST implement ESP in tunnel mode and MAY
   implement transport mode.

   All iSNS implementations supporting security MUST support the replay
   protection mechanisms of IPsec.

   iSNS security implementations MUST support both IKE Main Mode and
   Aggressive Mode for authentication, negotiation of security
   associations, and key management, using the IPSec DOI [RFC2407].
   Manual keying SHOULD NOT be used since it does not provide the
   necessary rekeying support.  Conformant iSNS security
   implementations MUST support authentication using a pre-shared key,
   and MAY support certificate-based peer authentication using digital
   signatures.  Peer authentication using the public key encryption
   methods outlined in IKE's sections 5.2 and 5.3 [RFC2409] SHOULD NOT
   be supported.

   Conformant iSNS implementations MUST support both IKE Main Mode and
   Aggressive Mode.  IKE Main Mode with pre-shared key authentication
   SHOULD NOT be used when either of the peers use dynamically assigned
   IP addresses. While Main Mode with pre-shared key authentication
   offers good security in many cases, situations where dynamically
   assigned addresses are used force the use a group pre-shared key,
   which is vulnerable to man-in-the-middle attack. IKE Identity
   Payload ID_KEY_ID MUST NOT be used.

   When digital signatures are used for authentication, either IKE Main
   Mode or IKE Aggressive Mode MAY be used.  In all cases, access to
   locally stored secret information (pre-shared key or private key for
   digital signing) MUST be suitably restricted, since compromise of
   the secret information nullifies the security properties of the
   IKE/IPsec protocols.

   When digital signatures are used to achieve authentication, an IKE
   negotiator SHOULD use IKE Certificate Request Payload(s) to specify
   the certificate authority (or authorities) that are trusted in
   accordance with its local policy.  IKE negotiators SHOULD check the
   pertinent Certificate Revocation List (CRL) before accepting a PKI
   certificate for use in IKE's authentication procedures.

   When the iSNS server is used without security, IP block storage
   protocol implementations MUST support a negative cache for

Tseng, Gibbons, et al.     Standards Track                  [Page 78]


                 Internet Storage Name Service (iSNS)      August 2002

   authentication failures. This allows implementations to avoid
   continually contacting discovered endpoints that fail authentication
   within IPsec or at the application layer (in the case of iSCSI
   Login).  The negative cache need not be maintained within the IPsec
   implementation, but rather within the IP block storage protocol
   implementation.

8.3      Discovering Security Requirements of Peer Devices

   Once communication between iSNS clients and the iSNS server have
   been secured through use of IPSec, the iSNS client devices have the
   capability to discover the security settings that they need to use
   for their peer-to-peer communications using the iSCSI and/or iFCP
   protocols.  This provides a potential scaling advantage over device-
   by-device configuration of individual security policies for each
   iSCSI and iFCP device.

   The iSNS server stores security settings for each iSCSI and iFCP
   device interface.  These security settings, which can be retrieved
   by authorized hosts, include use or non-use of IPSec, IKE, Main
   Mode, and Aggressive Mode.  For example, IKE may not be enabled for
   a particular interface of a peer device.  If a peer device can learn
   of this in advance by consulting the iSNS server, it will not need
   to waste time and resources attempting to initiate an IKE phase 1
   session with that peer device interface.

   If iSNS is used for this purpose, then the minimum information that
   should be learned from the iSNS server is the use or non-use of IKE
   and IPSec by each iFCP or iSCSI peer device interface.  This
   information is encoded in the Security Bitmap field of each Portal
   of the peer device, and is applicable on a per-interface basis for
   the peer device.  iSNS queries to acquire security configuration
   data about peer devices MUST be protected by IPSec/ESP
   authentication.

8.4      Configuring Security Policies of iFCP/iSCSI Devices

   Use of iSNS for distribution of security policies offers the
   potential to reduce the burden of manual device configuration, and
   decrease the probability of communications failures due to
   incompatible security policies.  If iSNS is used to distribute
   security policies, then IPSec authentication, data integrity, and
   confidentiality MUST be used to protect all iSNS protocol messages.

   The complete IKE/IPSec configuration of each iFCP and/or iSCSI
   device can be stored in the iSNS server, including policies that are
   used for IKE Phase 1 and Phase 2 negotiations between client
   devices.  The IKE payload format includes a series of one or more
   proposals that the iSCSI or iFCP device will use when negotiating
   the appropriate IPsec policy to use to protect iSCSI or iFCP
   traffic.

   In addition, the iSCSI Authentication Methods used by each iSCSI
   device can also be stored in the iSNS server.  The iSCSI AuthMethod

Tseng, Gibbons, et al.     Standards Track                  [Page 79]


                 Internet Storage Name Service (iSNS)      August 2002

   field (tag=42) contains a null-terminated string embedded with the
   text values indicating iSCSI authentication methods to be used by
   that iSCSI device.

   Note that iSNS distribution of security policy is not necessary if
   the security settings can be determined by other means, such as
   manual configuration or IPsec security policy distribution. If an
   entity has already obtained its security configuration via other
   mechanisms, then it MUST NOT request security policy via iSNS.

8.5      Resource Issues

   The iSNS protocol is lightweight, and will not generate a
   significant amount of traffic.  iSNS traffic is characterized by
   occasional registration, notification, and update messages that do
   not consume significant amounts of bandwidth.  Even software-based
   IPSec implementations should not have a problem handling the traffic
   loads generated by the iSNS protocol.

   To fulfill iSNS security requirements, the only additional resources
   needed beyond what is already required for iSCSI and iFCP involves
   the iSNS server.  Since iSCSI and iFCP end nodes are already
   required to implement IKE and IPSec, these existing requirements can
   also be used to fulfill IKE and IPSec requirements for iSNS clients.

8.6      iSNS Interaction with IKE and IPSec

   When IPSec security is enabled, each iSNS client that is registered
   in the iSNS database SHALL maintain at least one phase-1 and one
   phase-2 security association with the iSNS server.  All iSNS
   protocol messages between iSNS clients and the iSNS server SHALL be
   protected by a phase-2 security association.

   When an iSNS client is removed from the iSNS database, the iSNS
   server shall send a phase-1 delete message to the associated IKE
   peer, and tear down all phase-1 and phase-2 SA's associated with
   that iSNS client.


















Tseng, Gibbons, et al.     Standards Track                  [Page 80]


                 Internet Storage Name Service (iSNS)      August 2002

9.       Normative References

   [iSCSI]     Satran, J., et al., "iSCSI", Internet draft (work in
               progress), draft-ietf-ips-iSCSI-09.txt, November 2001

   [iFCP]      Monia, C., et al., "iFCP - A Protocol for Internet Fibre
               Channel Storage Networking", Internet draft (work in
               progress), draft-ietf-ips-ifcp-07.txt, November 2001

   [RFC2608]   Guttman, E., Perkins, C., Veizades, J., Day, M.,
               "Service Location Protocol, Version 2", RFC 2608, June
               1999

   [iSCSIName] Bakke, M., et al., "iSCSI naming and Discovery", draft-
               ietf-ips-iscsi-name-disc-03.txt, November 2001

   [iSCSI-SLP] Bakke, M., "Finding iSCSI Targets and Name Servers Using
               SLP", Internet draft (work in progress), draft-ietf-ips-
               iscsi-slp-01.txt, July 2001

   [RFC2119]   Bradner, S., "Key Words for Use in RFCs to Indicate
               Requirement Levels, BCP 14, RFC 2119, March 1997

   [SEC-IPS]   Aboba, B., et al., "Securing IP Block Storage
               Protocols", draft-ietf-ips-security-07.txt, December
               2001

   [RFC2401]   Atkinson, R., Kent, S., "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998

   [RFC2406]   Kent, S., Atkinson, R., "IP Encapsulating Security
               Payload (ESP)", RFC 2406, November 1998

   [RFC2407]   Piper, D., "The Internet IP Security Domain of
               Interpretation of ISAKMP", RFC 2407, November 1998

   [RFC2408]   Maughan, D., Schertler, M., Schneider, M., Turner, J.,
               "Internet Security Association and Key Management
               Protocol (ISAKMP), RFC 2408, November 1998

   [RFC2409]   Harkins, D., Carrel, D., "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998

   [RFC2412]   Orman, H., "The OAKLEY Key Determination Protocol", RFC
               2412, November 1998

   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
               793, September 1981

   [DSS]       FIPS PUB 186-2, National Institute of Standards and
               Technology, Digital Signature Standard (DSS), Technical
               Report



Tseng, Gibbons, et al.     Standards Track                  [Page 81]


                 Internet Storage Name Service (iSNS)      August 2002

   [EUI-64]    Guidelines for 64-bit Global Identifier (EUI-64)
               Registration Authority, May 2001, IEEE,
               http://standards.ieee.org/regauth/oui/tutorials/EUI64.ht
               ml

   [X.509]     ITU-T Recommendation X.509 (1997 E): Information
               Technology - Open Systems Interconnection - The
               Directory: Authentication Framework, June 1997

   [802-1990]  IEEE Standards for Local and Metropolitan Area Networks:
               Overview and Architecture, Technical Committee on
               Computer Communications of the IEEE Computer Society,
               May 31, 1990

   [FC-FS]     Fibre Channel Framing and Signaling Interface, NCITS
               Working Draft Project 1331-D

10.      Informative References

   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
               Specification, RFC 1035, November 1987

   [RFC1305]   Mills, D., Network Time Protocol (Version 3), RFC 1305,
               March 1992

   [FC-GS]     Fibre Channel Generic Services, ANSI X3.288:1996

   [FC-GS-2]   Fibre Channel Generic Services-2, ANSI NCITS 288

   [FC-GS-3]   Fibre Channel Generic Services-3, NCITS 348-2000

   [FC-GS-4]   Fibre Channel Generic Services-4, NCITS Working Draft
               Project 1505-D



   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
      3", BCP 9, RFC 2026, October 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997














Tseng, Gibbons, et al.     Standards Track                  [Page 82]


                 Internet Storage Name Service (iSNS)    November 2001

11.      Author's Addresses

   Josh Tseng
   Nishan Systems
   3850 North First Street
   San Jose, CA 95134-1702
   Phone: (408) 519-3749
   Email: jtseng@nishansystems.com

   Kevin Gibbons
   Nishan Systems
   3850 North First Street
   San Jose, CA 95134-1702
   Phone:  (408) 519-3756
   Email:  kgibbons@nishansystems.com

   Franco Travostino
   Nortel Networks
   3 Federal Street
   Billerica, MA  01821
   Phone:  978-288-7708
   Email:  travos@nortelnetworks.com

   Curt Du Laney
   IBM
   4205 South Miami Blvd
   Research Triangle Park, NC 27709
   Email:  dulaney@us.ibm.com
   Phone: (919) 254-5632

   Joe Souza
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   Email: joes@microsoft.com
   Phone: (425) 706-3135



















Gibbons, Tseng, Monia      Standards Track                  [Page 83]


                 Internet Storage Name Service (iSNS)    November 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."




























Tseng, Gibbons, et al.     Standards Track                  [Page 84]


                 Internet Storage Name Service (iSNS)    November 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 server, and have its access control policy subordinated to the
   iSNS server.

A.1.1    Simple iSCSI Target Registration

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

   +--------------------------+------------------+-------------------+
   |    iSCSI Target Device   |    iSNS Server   |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 |
   |      DevAttrReg--------->|                  | 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"          |                  |                   |
   |                          |<---DevAttrRegRsp |                   |
   |                          |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"                   |

Tseng, Gibbons, et al.     Standards Track                  [Page 85]


                 Internet Storage Name Service (iSNS)    November 2001

   |                          |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  |                  |                   |
   |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 Server   |Management Station |
   +--------------------------+------------------+-------------------+
   |Discover iSNS--SLP-->     |                  |/*mgmt station is  |
   |                          |<--SLP--iSNS Here:| administratively  |
   |                          |      192.36.53.1 | authorized to view|
   |      DevAttrReg-->       |                  | 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: "Storage Array 1" |jbod1.foo.com is  |                   |
   |tag=43: X.509 cert        |now registered in |                   |
   |tag=32: "NAMEefgh"        |iSNS, but is not  |                   |
   |tag=33: "Target"          |in any DD. Therefore,                 |
   |tag=34: "Storage Array 2" |no other devices  |                   |
   |tag=43: X.509 cert        |can "see" it.     |                   |
   |                          |*****************/|                   |
   |                          |<--DevAttrRegRsp  |                   |

Tseng, Gibbons, et al.     Standards Track                  [Page 86]


                 Internet Storage Name Service (iSNS)    November 2001

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


A.1.3    Initiator Registration and Target Discovery

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


Tseng, Gibbons, et al.     Standards Track                  [Page 87]


                 Internet Storage Name Service (iSNS)    November 2001

   +--------------------------+------------------+-------------------+
   |    iSCSI Initiator       |    iSNS          |Management Station |
   +--------------------------+------------------+-------------------+
   |Discover iSNS--SLP-->     |                  |/*mgmt station is  |
   |                          |<--SLP--iSNS Here:| administratively  |
   |                          |      192.36.53.1 | authorized to view|
   |DevAttrReg-->             |                  | 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 |                   |
   |tag=19: 5 seconds         |DD, so it is      |                   |
   |tag=32: "NAMEijkl"        |inaccessible by   |                   |
   |tag=33: "Initiator"       |other devices     |                   |
   |tag=34: "Server1"         |*****************/|                   |
   |tag=43: X.509 certificate |                  |                   |
   |                          |<--DevAttrRegRsp  |                   |
   |                          |SUCCESS           |                   |
   |                          |tag=1: "svr1.foo.com"                 |
   |                          |tag=16: "192.20.3.1"                  |
   |                          |tag=17: "5001"    |                   |
   |                          |tag=32: "NAMEijkl"|                   |
   |                          |                  |                   |
   |                          |       SCN------> |                   |
   |                          |  (or SNMP trap)  |                   |
   |                          |tag=1: svr1.foo.com                   |
   |                          |dest: mgmt.foo.com|                   |
   |                          |CHANGE IN NETWORK |                   |
   |                          |                  |                   |
   |                          |                  |<------SCNRsp      |
   |                          |                  |<----DevAttrQry    |
   |                          |                  |src: "mgmt.foo.com"|
   |                          |                  |key:  (tag=1)      |
   |                          |                  |  "svr1.foo.com"   |
   |                          |                  |Op Attr: (tag=2)   |
   |                          |                  |Op Attr: (tag=16)  |
   |                          |                  |Op Attr: (tag=17)  |
   |                          |                  |Op Attr: (tag=32)  |
   |                          | DevAttrQryRsp--> |                   |
   |                          |SUCCESS           |                   |
   |                          |tag=2:  "iSCSI"   |                   |
   |                          |tag=16:192.20.3.1 |                   |
   |                          |tag=17: "5001"    |                   |
   |                          |tag=32:"NAMEijkl" |                   |
   |                          |                  |/**Mgmt Station ***|
   |                          |                  |displays device,   |
   |                          |                  |the operator decides
   |                          |                  |to place "NAMEijkl"|
   |                          |                  |into Domain "DDxyz"|
   |                          |                  |with device NAMEabcd
   |                          |                  |******************/|
   |                          |                  |<--DDReg           |
   |                          |                  |src: (tag=1)       |

Tseng, Gibbons, et al.     Standards Track                  [Page 88]


                 Internet Storage Name Service (iSNS)    November 2001

   |                          |                  |  "mgmt.foo.com"   |
   |                          |                  |key: "DDxyz ID"    |
   |                          |                  |tag=32: "NAMEijkl  |
   |                          |                  |                   |
   |                          |     DDRegRsp---->|/******************|
   |                          |     SUCCESS      |"NAMEijkl" has been|
   |                          |                  |moved to "DDxyz"   |
   |                          |                  |******************/|
   |                          |<-----SCN         |                   |
   |                          |tag=32: "NAMEijkl"|                   |
   |                          |CHANGE IN DD MEMBERSHIP               |
   |    DevAttrQry----------->|                  |                   |
   |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=43)         |<-----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=43: X.509 cert|                   |
   |                          |                  |                   |
   |/***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.************/          |                   |
   +--------------------------+------------------+-------------------+
















Tseng, Gibbons, et al.     Standards Track                  [Page 89]