Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4171

Internet Storage Name Service (iSNS)

Pages: 123
Proposed Standard
Errata
Part 1 of 5 – Pages 1 to 21
None   None   Next

Top   ToC   RFC4171 - Page 1
Network Working Group                                           J. Tseng
Request for Comments: 4171                           Riverbed Technology
Category: Standards Track                                     K. Gibbons
                                                      McDATA Corporation
                                                           F. Travostino
                                                                  Nortel
                                                             C. Du Laney
                                             Rincon Research Corporation
                                                                J. Souza
                                                               Microsoft
                                                          September 2005


                 Internet Storage Name Service (iSNS)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) 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 capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof.
Top   ToC   RFC4171 - Page 2

Table of Contents

1. Introduction................................................... 6 1.1. Conventions Used in This Document........................ 6 1.2. Purpose of This Document................................. 6 2. iSNS Overview.................................................. 6 2.1. iSNS Architectural Components ........................... 7 2.1.1. iSNS Protocol (iSNSP) ........................... 7 2.1.2. iSNS Client...................................... 7 2.1.3. iSNS Server...................................... 7 2.1.4. iSNS Database ................................... 7 2.1.5. iSCSI............................................ 7 2.1.6. iFCP............................................. 7 2.2. iSNS Functional Overview................................. 8 2.2.1. Name Registration Service........................ 8 2.2.2. Discovery Domain and Login Control Service....... 8 2.2.3. State Change Notification Service............... 10 2.2.4. Open Mapping between Fibre Channel and iSCSI Devices................. 11 2.3. iSNS Usage Model........................................ 11 2.3.1. iSCSI Initiator................................. 12 2.3.2. iSCSI Target.................................... 12 2.3.3. iSCSI-FC Gateway................................ 12 2.3.4. iFCP Gateway.................................... 12 2.3.5. Management Station.............................. 12 2.4. Administratively Controlled iSNS Settings............... 13 2.5. iSNS Server Discovery .................................. 14 2.5.1. Service Location Protocol (SLP)................. 14 2.5.2. Dynamic Host Configuration Protocol (DHCP)...... 14 2.5.3. iSNS Heartbeat Message.......................... 14 2.6. iSNS and Network Address Translation (NAT).............. 14 2.7. Transfer of iSNS Database Records between iSNS Servers.. 15 2.8. Backup iSNS Servers..................................... 17 2.9. Transport Protocols..................................... 19 2.9.1. Use of TCP for iSNS Communication............... 19 2.9.2. Use of UDP for iSNS Communication............... 20 2.9.3. iSNS Multicast and Broadcast Messages........... 20 2.10. Simple Network Management Protocol (SNMP) Requirements.. 21 3. iSNS Object Model............................................. 21 3.1. Network Entity Object .................................. 22 3.2. Portal Object .......................................... 22 3.3. Storage Node Object..................................... 22 3.4. Portal Group Object..................................... 23 3.5. FC Device Object........................................ 24 3.6. Discovery Domain Object................................. 24 3.7. Discovery Domain Set Object............................. 24 3.8. iSNS Database Model..................................... 24 4. iSNS Implementation Requirements.............................. 25
Top   ToC   RFC4171 - Page 3
       4.1.  iSCSI Requirements...................................... 25
             4.1.1.  Required Attributes for Support of iSCSI........ 26
             4.1.2.  Examples: iSCSI Object Model Diagrams........... 28
             4.1.3.  Required Commands and
                     Response Messages for Support of iSCSI.......... 30
       4.2.  iFCP Requirements....................................... 31
             4.2.1.  Required Attributes for Support of iFCP......... 31
             4.2.2.  Example: iFCP Object Model Diagram.............. 32
             4.2.3.  Required Commands and
                     Response Messages for Support of iFCP........... 34
   5.  iSNSP Message Format.......................................... 35
       5.1.  iSNSP PDU Header........................................ 35
             5.1.1.  iSNSP Version................................... 36
             5.1.2.  iSNSP Function ID............................... 36
             5.1.3.  iSNSP PDU Length................................ 36
             5.1.4.  iSNSP Flags..................................... 36
             5.1.5.  iSNSP Transaction ID............................ 36
             5.1.6.  iSNSP Sequence ID............................... 37
       5.2.  iSNSP Message Segmentation and Reassembly............... 37
       5.3.  iSNSP PDU Payload....................................... 37
             5.3.1.  Attribute Value 4-Byte Alignment................ 38
       5.4.  iSNSP Response Status Codes............................. 39
       5.5.  Authentication for iSNS Multicast and Broadcast Messages 39
       5.6.  Registration and Query Messages......................... 41
             5.6.1.  Source Attribute................................ 42
             5.6.2.  Message Key Attributes.......................... 42
             5.6.3.  Delimiter Attribute............................. 42
             5.6.4.  Operating Attributes............................ 43
             5.6.5.  Registration and Query Request Message Types ... 44
       5.7.  Response Messages....................................... 66
             5.7.1.  Status Code..................................... 66
             5.7.2.  Message Key Attributes in Response.............. 66
             5.7.3.  Delimiter Attribute in Response................. 67
             5.7.4.  Operating Attributes in Response................ 67
             5.7.5.  Registration and Query Response Message Type.... 67
       5.8.  Vendor-Specific Messages................................ 72
   6.  iSNS Attributes............................................... 73
       6.1.  iSNS Attribute Summary.................................. 73
       6.2.  Entity Identifier-Keyed Attributes...................... 76
             6.2.1.  Entity Identifier (EID)......................... 76
             6.2.2.  Entity Protocol................................. 76
             6.2.3.  Management IP Address .......................... 77
             6.2.4.  Entity Registration Timestamp .................. 77
             6.2.5.  Protocol Version Range.......................... 77
             6.2.6.  Registration Period............................. 78
             6.2.7.  Entity Index.................................... 78
             6.2.8.  Entity Next Index............................... 79
             6.2.9.  Entity ISAKMP Phase-1 Proposals................. 79
Top   ToC   RFC4171 - Page 4
             6.2.10. Entity Certificate.............................. 79
       6.3.  Portal-Keyed Attributes................................. 80
             6.3.1.  Portal IP Address............................... 80
             6.3.2.  Portal TCP/UDP Port............................. 80
             6.3.3.  Portal Symbolic Name............................ 80
             6.3.4.  Entity Status Inquiry Interval.................. 81
             6.3.5.  ESI Port........................................ 82
             6.3.6.  Portal Index.................................... 82
             6.3.7.  SCN Port........................................ 82
             6.3.8.  Portal Next Index............................... 83
             6.3.9.  Portal Security Bitmap.......................... 83
             6.3.10. Portal ISAKMP Phase-1 Proposals................. 84
             6.3.11. Portal ISAKMP Phase-2 Proposals................. 84
             6.3.12. Portal Certificate.............................. 84
       6.4.  iSCSI Node-Keyed Attributes............................. 84
             6.4.1.  iSCSI Name...................................... 85
             6.4.2.  iSCSI Node Type................................. 85
             6.4.3.  iSCSI Node Alias................................ 86
             6.4.4.  iSCSI Node SCN Bitmap .......................... 86
             6.4.5.  iSCSI Node Index................................ 87
             6.4.6.  WWNN Token...................................... 87
             6.4.7.  iSCSI Node Next Index .......................... 89
             6.4.8.  iSCSI AuthMethod................................ 89
       6.5.  Portal Group (PG) Object-Keyed Attributes............... 89
             6.5.1.  Portal Group iSCSI Name......................... 90
             6.5.2.  PG Portal IP Addr............................... 90
             6.5.3.  PG Portal TCP/UDP Port.......................... 90
             6.5.4.  Portal Group Tag (PGT).......................... 90
             6.5.5.  Portal Group Index.............................. 90
             6.5.6.  Portal Group Next Index......................... 91
       6.6.  FC Port Name-Keyed Attributes .......................... 91
             6.6.1.  FC Port Name (WWPN)............................. 91
             6.6.2.  Port ID (FC_ID)................................. 91
             6.6.3.  FC Port Type.................................... 92
             6.6.4.  Symbolic Port Name.............................. 92
             6.6.5.  Fabric Port Name (FWWN)......................... 92
             6.6.6.  Hard Address.................................... 92
             6.6.7.  Port IP Address................................. 92
             6.6.8.  Class of Service (COS).......................... 93
             6.6.9.  FC-4 Types...................................... 93
             6.6.10. FC-4 Descriptor................................. 93
             6.6.11. FC-4 Features .................................. 93
             6.6.12. iFCP SCN Bitmap................................. 93
             6.6.13. Port Role....................................... 94
             6.6.14. Permanent Port Name (PPN)....................... 95
       6.7.  Node-Keyed Attributes .................................. 95
             6.7.1.  FC Node Name (WWNN)............................. 95
             6.7.2.  Symbolic Node Name.............................. 95
Top   ToC   RFC4171 - Page 5
             6.7.3.  Node IP Address................................. 95
             6.7.4.  Node IPA........................................ 96
             6.7.5.  Proxy iSCSI Name................................ 96
       6.8.  Other Attributes........................................ 96
             6.8.1.  FC-4 Type Code.................................. 96
             6.8.2.  iFCP Switch Name................................ 96
             6.8.3.  iFCP Transparent Mode Commands.................. 97
       6.9.  iSNS Server-Specific Attributes......................... 97
             6.9.1.  iSNS Server Vendor OUI.......................... 98
       6.10. Vendor-Specific Attributes.............................. 98
             6.10.1. Vendor-Specific Server Attributes............... 98
             6.10.2. Vendor-Specific Entity Attributes............... 98
             6.10.3. Vendor-Specific Portal Attributes............... 99
             6.10.4. Vendor-Specific iSCSI Node Attributes........... 99
             6.10.5. Vendor-Specific FC Port Name Attributes......... 99
             6.10.6. Vendor-Specific FC Node Name Attributes......... 99
             6.10.7. Vendor-Specific Discovery Domain Attributes..... 99
             6.10.8. Vendor-Specific Discovery Domain Set Attributes. 99
             6.10.9. Other Vendor-Specific Attributes................ 99
       6.11. Discovery Domain Registration Attributes............... 100
             6.11.1. DD Set ID Keyed Attributes..................... 100
             6.11.2. DD ID Keyed Attributes......................... 101
   7.  Security Considerations...................................... 103
       7.1.  iSNS Security Threat Analysis ......................... 103
       7.2.  iSNS Security Implementation and Usage Requirements.... 104
       7.3.  Discovering Security Requirements of Peer Devices...... 105
       7.4.  Configuring Security Policies of iFCP/iSCSI Devices.... 106
       7.5.  Resource Issues........................................ 107
       7.6.  iSNS Interaction with IKE and IPSec.................... 107
   8.  IANA Considerations.......................................... 107
       8.1.  Registry of Block Storage Protocols.................... 107
       8.2.  Registry of Standard iSNS Attributes .................. 108
       8.3.  Block Structure Descriptor (BSD) Registry.............. 108
   9.  Normative References......................................... 109
   10. Informative References....................................... 110
   Appendix A: iSNS Examples........................................ 112
       A.1.  iSCSI Initialization Example........................... 112
             A.1.1.  Simple iSCSI Target Registration............... 112
             A.1.2.  Target Registration and DD Configuration....... 114
             A.1.3.  Initiator Registration and Target Discovery.... 117
   Acknowledgements................................................. 121
Top   ToC   RFC4171 - Page 6

1. Introduction

1.1. Conventions Used in This Document

"iSNS" refers to the storage network model and associated services covered in the text of this document. 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 when sending and ignored when receiving.

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

2. 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 a level of intelligence comparable 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 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 are further discussed in Section 5. Use of iSNS is OPTIONAL for iSCSI and REQUIRED for iFCP.
Top   ToC   RFC4171 - Page 7

2.1. iSNS Architectural Components

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

2.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 that can register device attribute information, download information about other registered clients in a common Discovery Domain (DD), and receive asynchronous notification of 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.

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

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

2.1.5. iSCSI

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

2.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 [iFCP].
Top   ToC   RFC4171 - Page 8

2.2. iSNS Functional Overview

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

2.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-4, 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 one is required.

2.2.2. Discovery Domain and Login Control Service

The Discovery Domain (DD) Service facilitates the partitioning of Storage Nodes into more manageable groupings for administrative and login control purposes. It allows the administrator to limit the login process of each host to the more appropriate subset of targets registered in the iSNS. This is particularly important for reducing the number of unnecessary logins (iSCSI logins or Fibre Channel Port Logins), and for limiting the amount of time that the host spends initializing login relationships as the size of the storage network scales up. Storage Nodes must be in at least one common enabled DD in order to obtain information about each other. Devices can be members of multiple DDs simultaneously. Login Control allows targets to delegate their access control/authorization policies to the iSNS server. This is consistent with the goal of centralizing management of those storage devices using 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
Top   ToC   RFC4171 - Page 9
   initiators that match the required identification and authorization
   provided by the iSNS will be allowed access by that target Node
   during session establishment.

   Placing Portals of a Network Entity into Discovery Domains allows
   administrators to indicate the preferred IP Portal interface through
   which storage traffic should access specific Storage Nodes of that
   Network Entity.  If no Portals of a Network Entity have been placed
   into a DD, then queries scoped to that DD SHALL report all Portals of
   that Network Entity.  If one or more Portals of a Network Entity have
   been placed into a DD, then queries scoped to that DD SHALL report
   only those Portals that have been explicitly placed in the DD.

   DDs 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 delegates management of access
   control policy (i.e., the list of initiators allowed to log in to
   that target) to the management workstations that are managing the
   configuration 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 will
   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.

   The iSNS server uses the Source Attribute of each iSNSP message to
   determine the originator of the request and to scope the operation to
   a set of Discovery Domains.  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 (DDs) belong to at least one
   active Discovery Domain Set (DDS).  Discovery Domains that do not
   belong to an activated DDS are not enabled.  The iSNS server MUST
   maintain the state of DD membership for all Storage Nodes, even for
   those that have been deregistered.  DD membership is persistent
   regardless of whether a Storage Node is actively registered in the
   iSNS database.
Top   ToC   RFC4171 - Page 10

2.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 Storage Nodes. The iSNS client may register for notifications on behalf of its Storage Nodes for notification of events detected by the iSNS Server. SCNs notify iSNS clients of explicit or implicit changes to the iSNS database; they do not necessarily indicate the state of connectivity to peer storage devices in the network. The response of a storage device to receipt of an SCN is implementation-specific; the policy for responding to SCNs is outside of the scope of this document. There are two types of SCN registrations: regular registrations and management registrations. Management registrations result in management SCNs, whereas regular registrations result in regular SCNs. The type of registration and SCN message is indicated in the SCN bitmap (see Sections 6.4.4 and 6.6.12). A regular SCN registration indicates that the Discovery Domain Service SHALL be used to control the distribution of SCN messages. Receipt of regular SCNs is limited to the discovery domains in which the SCN-triggering event takes place. Regular SCNs do not contain information about discovery domains. A management SCN registration can only by requested by Control Nodes. Management SCNs resulting from management registrations are not bound by the Discovery Domain service. Authorization to request management SCN registrations may be administratively controlled. The iSNS server SHOULD be implemented with hardware and software resources sufficient to support the expected number of iSNS clients. However, if resources are unexpectedly exhausted, then the iSNS server MAY refuse SCN service by returning an 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 SCNs 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.
Top   ToC   RFC4171 - Page 11

2.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 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 and iSCSI devices. This allows management functions such as Discovery Domains and State Change Notifications to be applied seamlessly to both iSCSI and Fibre Channel devices, facilitating integration of IP networks with Fibre Channel devices and fabrics. Note that Fibre Channel attributes are stored as iFCP attributes, and that 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 6.1) contains a 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 the information internally within an iSCSI-FC gateway, where the mapping is inaccessible to other devices except by proprietary mechanisms.

2.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.
Top   ToC   RFC4171 - Page 12

2.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 (SCNs) so that it can be notified of new targets that appear on the network after the initial bootup and discovery. SCNs can also inform the iSCSI initiator of targets that have been removed from 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.

2.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 SCNs in order to detect the addition or removal of initiators for resource allocation purposes. The iSCSI target device may also register for Entity Status Inquiry (ESI) messages, which allow the iSNS to monitor the target device's availability in the storage network.

2.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 server to 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.

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

2.3.5. Management Station

A management station uses iSNS to monitor storage devices and to enable or disable storage sessions by configuring discovery domains. A management station usually interacts with the iSNS server as a
Top   ToC   RFC4171 - Page 13
   Control Node endowed with access to all iSNS database records and
   with special privileges to configure discovery domains.  Through
   manipulation of discovery domains, the management station controls
   the scope of device discovery for iSNS clients querying the iSNS
   server.

2.4. Administratively Controlled iSNS Settings

Some important operational settings for the iSNS server are configured using administrative means, such as a configuration file, a console port, an SNMP, or another implementation-specific method. These administratively-controlled settings cannot be configured using the iSNS Protocol, and therefore the iSNS server implementation MUST provide for such an administrative control interface. The following is a list of parameters that are administratively controlled for the iSNS server. In the absence of alternative settings provided by the administrator, the following specified default settings MUST be used. Setting Default Setting ------- --------------- ESI Non-Response Threshold 3 (see 5.6.5.13) Management SCNs (Control Nodes only) enabled (see 5.6.5.8) 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 network 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 SCNs. 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 DDs and DDSs.
Top   ToC   RFC4171 - Page 14
   Authorized Control Nodes: a list of Nodes identified by iSCSI Name or
                   FC Port Name WWPN that are authorized to register as
                   Control Nodes.

2.5. iSNS Server Discovery

2.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. A service template for using SLP to locate iSNS servers can be found in [iSCSI-SLP].

2.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 found in [iSNSOption].

2.5.3. iSNS Heartbeat Message

The iSNS heartbeat message is described in Section 5.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.

2.6. iSNS and Network Address Translation (NAT)

The existence of NAT will have an impact upon information retrieved from the iSNS server. If the iSNS client exists in an addressing domain different from that of 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.
Top   ToC   RFC4171 - Page 15
   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 not
   to query for nominal IP addresses.  Rather, the iSNS client 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 appropriate NAT
   translation rules implemented within the update mechanism in each
   server.

   Finally, note that it is possible for an iSNS server in the private
   addressing domain behind a NAT boundary to exclusively support iSNS
   clients that are operating in the global IP addressing domain.  If
   this is the case, the administrator only needs to ensure that the
   appropriate mappings are configured on the NAT gateways to allow the
   iSNS clients to initiate iSNSP sessions to the iSNS server.  All
   registered addresses contained in the iSNS server are thus public IP
   addresses for use outside the NAT boundary.  Care should be taken to
   ensure that there are no iSNS clients querying the server from inside
   the NAT boundary.

2.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 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.
Top   ToC   RFC4171 - Page 16
   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 for transferring 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 that 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 transferred 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".
Top   ToC   RFC4171 - Page 17
   +-------------------------+           +-------------------------+
   |+------+ 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
   retrieve (GET) the desired record for "dev C" manually, and then to
   store (SET) it on the local iSNS server directly.  Once the record is
   transferred to the local iSNS server in Network A, "dev C" becomes
   visible and accessible (provided that 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.

2.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. The failover mechanisms discussed in this document focus on the interaction between iSNS clients and iSNS servers. Specifically, what is covered in this document includes the following: - iSNS client behavior and the iSNS protocol interaction between the client and multiple iSNS servers, some of which are backup servers.
Top   ToC   RFC4171 - Page 18
   -  Required failover behaviors of the collection of iSNS servers that
      includes active and backup servers.

   However, note that this document does not specify the complete
   functional failover requirements of each iSNS server.  In particular,
   it does not specify the complete set of protocol interactions among
   the iSNS servers that are required to achieve stable failover
   operation in an interoperable manner.

   For the purposes of this discussion, the specified backup mechanisms
   pertain to interaction among different logical iSNS servers.  Note
   that it is possible to create multiple physical iSNS servers to form
   a single logical iSNS server cluster, and thus to distribute iSNS
   transaction processing among multiple physical servers.  However, a
   more detailed discussion of the interactions between physical servers
   within a logical iSNS server cluster is beyond the scope of this
   document.

   Multiple logical 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 2.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
   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 logical backup iSNS server SHALL exist at any
   individual IP address, in order to avoid conflicts from multiple
   servers listening on the same canonical iSNS TCP or UDP port number.

   The iSNS heartbeat can also be used to coordinate the designation and
   selection of primary and backup iSNS servers.

   Each backup server MUST note its relative precedence in the active
   server's list of backup servers.  If its precedence is not already
   known, each backup server MAY learn it from the iSNS heartbeat
   message, by noting the position of its IP address in the ordered list
Top   ToC   RFC4171 - Page 19
   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
   SHOULD 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 heartbeat messages for a period of time,
   then connectivity to the active server has been lost.  Alternatively,
   the backup server may establish TCP connections to the active server
   and other backup servers, with loss of connectivity determined
   through non-response to periodic echo or polling 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.

   Since the primary and backup iSNS servers maintain a coordinated
   database, no re-registration by an iSNS Client is required when a
   backup server takes the active server role.  Likewise, no re-
   registration by an iSNS Client is required when the previous primary
   server returns to the active server role.

2.9. Transport Protocols

The iSNS Protocol is transport-neutral. Query and registration messages are transported over TCP or UDP. iSNS heartbeat messages are transported using IP multicast or broadcast.

2.9.1. 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. To receive Entity Status Inquiry (ESI) (see Section 5.6.5.13) monitoring the use of TCP, the client registers the Portal ESI Interval and the
Top   ToC   RFC4171 - Page 20
   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 SCNs.  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.

2.9.2. Use of UDP for iSNS Communication

The iSNS server MAY accept UDP messages for client registrations. The iSNS server MUST accept registrations from clients requesting UDP-based ESI and SCN messages. 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 a Network 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 a Network 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 (see Section 5).

2.9.3. iSNS Multicast and Broadcast Messages

iSNS multicast messages are transported using IP multicast or broadcast. The iSNS heartbeat is the only iSNS multicast or broadcast message. This message is originated by the iSNS server and sent to all iSNS clients that are listening on the IP multicast address allocated for the iSNS heartbeat.
Top   ToC   RFC4171 - Page 21

2.10. Simple Network Management Protocol (SNMP) Requirements

The iSNS Server may be managed via the iSNS MIB [iSNSMIB] using an SNMP management framework [RFC3411]. For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. The iSNS MIB provides the ability to configure and monitor an iSNS server without using the iSNS protocol directly. SNMP management frameworks have several requirements for object indexing in order for objects to be accessed or added. SNMP uses an Object Identifier (OID) for object identification. The size of each OID is restricted to a maximum of 128 sub-identifiers. Both the iSCSI and iFCP protocol contain identifiers, such as the iSCSI Name, that are greater the 128 characters in length. Using such identifiers as an index would result in more than 128 sub- identifiers per OID. In order to support objects that have key identifiers whose maximum length is longer than the maximum SNMP- supported length, the iSNS server provides secondary non-zero integer index identifiers. These indexes SHALL be persistent for as long as the server is active. Furthermore, index values for recently deregistered objects SHOULD NOT be reused in the short term. Object attributes, including indexes, are described in detail in Section 6. For SNMP based management applications to create a new entry in a table of objects, a valid OID must be available to specify the table row. The iSNS server supports this by providing, for each type of object that can be added via SNMP, an object attribute that returns the next available non-zero integer index. This allows an SNMP client to request an OID to be used for registering a new object in the server. Object attributes, including next available index attributes, are described in detail in Section 6.


(page 21 continued on part 2)

Next Section