RFC 4171 - Internet Storage Name Service (iSNS)
(Formats: TXT)
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.
Tseng, et al. Standards Track [Page 1]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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
Tseng, et al. Standards Track [Page 2]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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
Tseng, et al. Standards Track [Page 3]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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
Tseng, et al. Standards Track [Page 4]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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
Tseng, et al. Standards Track [Page 5]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
Tseng, et al. Standards Track [Page 6]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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].
Tseng, et al. Standards Track [Page 7]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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
Tseng, et al. Standards Track [Page 8]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
Tseng, et al. Standards Track [Page 9]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
Tseng, et al. Standards Track [Page 10]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
Tseng, et al. Standards Track [Page 11]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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
Tseng, et al. Standards Track [Page 12]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
Tseng, et al. Standards Track [Page 13]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
Tseng, et al. Standards Track [Page 14]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
Tseng, et al. Standards Track [Page 15]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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".
Tseng, et al. Standards Track [Page 16]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-------------------------+ +-------------------------+
|+------+ 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.
Tseng, et al. Standards Track [Page 17]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
- 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
Tseng, et al. Standards Track [Page 18]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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
Tseng, et al. Standards Track [Page 19]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
Tseng, et al. Standards Track [Page 20]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
3. 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,
Discovery Domain, and Discovery Domain Set. Each of these objects is
described in greater detail in the following sections.
Tseng, et al. Standards Track [Page 21]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
3.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. The Entity Identifier
attribute uniquely distinguishes a Network Entity, and is the key
used to register a Network Entity object in an iSNS server. 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 in 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. Collectively, the multiple gateways
can be used to support a single logical Network Entity that is used
to contain all the devices in that Fibre Channel network.
3.2. Portal Object
The Portal object is an interface through which access to Storage
Nodes within the Network Entity can be obtained. The IP address and
TCP/UDP Port number attributes uniquely distinguish a Portal object,
and combined are the key used to register a Portal object in an iSNS
server. A Portal is contained in one and only one Network Entity,
and may be contained in one or more DDs (see Section 3.6).
3.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. For iSCSI, the iSCSI Name attribute
uniquely distinguishes a Storage Node, and is the key used to
register a Storage Node object in an iSNS Server. For iFCP, the FC
Port Name (WWPN) attribute uniquely distinguishes a Storage Node, and
is the key used to register a Storage Node object in the iSNS Server.
Storage Node is contained in only one Network Entity object and may
be contained in one or more DDs (see Section 3.6).
Tseng, et al. Standards Track [Page 22]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
3.4. Portal Group Object
The Portal Group (PG) object represents an association between a
Portal and an iSCSI Node. Each Portal and iSCSI Storage Node
registered in an Entity can be associated using a Portal Group (PG)
object. The PG Tag (PGT), if non-NULL, indicates that the associated
Portal provides access to the associated iSCSI Storage Node in the
Entity. All Portals that have the same PGT value for a specific
iSCSI Storage Node allow coordinated access to that node.
A PG object MAY be registered when a Portal or iSCSI Storage Node is
registered. Each Portal to iSCSI Node association is represented by
one and only one PG object. In order for a Portal to provide access
to an iSCSI Node, the PGT of the PG object MUST be non-NULL. If the
PGT value registered for a specified Portal and iSCSI Node is NULL,
or if no PGT value is registered, then the Portal does not provide
access to that iSCSI Node in the Entity.
The PGT value indicates whether access to an iSCSI Node can be
coordinated across multiple Portals. All Portals that have the same
PGT value for a specific iSCSI Node can provide coordinated access to
that iSCSI Node. According to the iSCSI Specification, coordinated
access to an iSCSI node indicates the capability of coordinating an
iSCSI session with connections that span these Portals [iSCSI].
The PG object is uniquely distinguished by the iSCSI Name, Portal IP
Address, and Portal TCP Port values of the associated Storage Node
and Portal objects. These are represented in the iSNS Server by the
PG iSCSI Name, PG Portal IP Address, and PG Portal TCP/UDP Port
attributes, respectively. The PG object is also uniquely
distinguished in the iSNS Server by the PG Index value.
A new PG object can only be registered by referencing its associated
iSCSI Storage Node or Portal object. A pre-existing PG object can be
modified or queried by using its Portal Group Index as message key,
or by referencing its associated iSCSI Storage Node or Portal object.
A 0-length Tag, Length, Value TLV is used to register a PGT NULL
value.
The PG object is deregistered if and only if its associated iSCSI
Node and Portal objects are both removed.
Tseng, et al. Standards Track [Page 23]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
3.5. 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. The FC Node Name (WWNN) attribute uniquely
distinguishes an FC Device, and is the key used to register an FC
Device object in the iSNS Server.
The FC Device is contained in one or more Storage Node objects.
3.6. Discovery Domain Object
Discovery Domains (DD) are a security and management mechanism used
to administer access and connectivity to storage devices. For query
and registration purposes, they are considered containers for Storage
Node and Portal objects. A query by an iSNS client that is not from
a Control Node only returns information about objects with which it
shares at least one active DD. The only exception to this rule is
with Portals; if Storage Nodes of a Network Entity are registered in
the DD without Portals, then all Portals of that Network Entity are
implicit members of that DD. The Discovery Domain ID (DD_ID)
attribute uniquely distinguishes a Discovery Domain object, and is
the key used to register a Discovery Domain object in the iSNS
Server.
A DD is considered active if it is a member of at least one active DD
Set. DDs that are not members of at least one enabled DDS are
considered disabled. A Storage Node can be a member of one or more
DDs. An enabled DD establishes connectivity among the Storage Nodes
in that DD.
3.7. Discovery Domain Set Object
The Discovery Domain Set (DDS) is a container object for Discovery
Domains (DDs). DDSs may contain one or more DDs. Similarly, each DD
can be a member of one or more DDSs. DDSs are a mechanism to store
coordinated sets of DD mappings in the iSNS server. Active DDs are
members of at least one active DD Set. Multiple DDSs may be
considered active at the same time. The Discovery Domain Set ID
(DDS_ID) attribute uniquely distinguishes a Discovery Domain Set
object, and is the key used to register a Discovery Domain Set object
in the iSNS Server.
3.8. Database Model
As presented to the iSNS client, each object of a specific type in
the iSNS database MUST have an implicit internal linear ordering
based on the key(s) for that object type. This ordering provides the
Tseng, et al. Standards Track [Page 24]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
ability to respond to DevGetNext queries (see Section 5.6.5.3). The
ordering of objects in the iSNS database SHOULD NOT be changed with
respect to that implied ordering, as a consequence of object
insertions and deletions. That is, the relative order of surviving
object entries in the iSNS database SHOULD be preserved so that the
DevGetNext message encounters generally reasonable behavior.
The following diagram shows the various objects described above and
their relationship to each other.
+--------------+ +-----------+
| NETWORK |1 *| |
| ENTITY |----| PORTAL |
| | | |
+--------------+ +-----------+
|1 |1 |*
| | |
| |* |
| +----------+ |
| | PORTAL | |
| | GROUP | |
| +----------+ |
| |* |
| | |
|* |1 |*
+-----------+ +--------------+ +-----------+ +-----------+
| FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY |
| DEVICE |----| NODE |----| DOMAIN |----| DOMAIN |
| | | | | | | SET |
+-----------+ +--------------+ +-----------+ +-----------+
* represents 0 to many possible relationships
4. 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 7.
4.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 may
also use SLP [RFC2608] to discover peer iSCSI devices. However, iSNS
is useful for scaling a storage network to a larger number of iSCSI
devices.
Tseng, et al. Standards Track [Page 25]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
4.1.1. Required Attributes for Support of iSCSI
The following attributes are available to support iSCSI. Attributes
indicated in the REQUIRED for Server column MUST be implemented by an
iSNS server used to support iSCSI. Attributes indicated in the
REQUIRED for Client column MUST be implemented by an iSCSI device
that elects to use the iSNS. Attributes indicated in the K (Key)
column uniquely identify the object type in the iSNS Server. A more
detailed description of each attribute is found in Section 6.
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
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 Index *
SCN Port *
Portal Security Bitmap *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
Portal Certificate
PORTAL GROUP PG iSCSI Name * * *
PG IP Address * * *
PG TCP/UDP Port * * *
PG Tag * *
PG Index *
Tseng, et al. Standards Track [Page 26]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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 Member iSCSI Node Index *
DD Member iSCSI Name *
DD Member Portal Index *
DD Member Portal IP Addr *
DD Member Portal TCP/UDP *
DD Features *
DISCOVERY DOMAIN DDS Identifier * *
SET DDS Symbolic Name *
DDS Status *
All iSCSI user-specified and vendor-specified attributes are OPTIONAL
to implement and use.
Tseng, et al. Standards Track [Page 27]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
4.1.2. Examples: 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
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 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | PORTAL GROUP| | | | PORTAL GROUP| |
| | -Prtl Tag 1 | | | | -Prtl Tag 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.example.com" | | "strg2.example.net" |
| -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, in
which each controller is accessible through any of multiple Portal
interfaces, possibly using multiple Portal Groups. 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, et al. Standards Track [Page 28]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL 1 | | PORTAL 2 | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| +-------+ +----------------+ +-------------------+ +------+ |
| | | | | | | |
| +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
| | | | | | | |
| | STORAGE NODE 1 | | STORAGE NODE 2 | | STORAGE NODE 3 | |
| | -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.example.com" |
| -Protocol: iSCSI |
| |
| Portal Group Object Table |
| Storage-Node Portal Portal-Group-Tag |
| 1 1 10 |
| 1 2 NULL (no access permitted) |
| 2 1 20 |
| 2 2 20 |
| 3 1 30 |
| 3 2 10 |
| |
+---------------------------------------------------------------+
Storage Node 1 is accessible via Portal 1 with a PGT of 10. It does
not have a Portal Group Tag (PGT) assigned for Portal 2, so Storage
Node 1 cannot be accessed via Portal 2.
Storage Node 2 can be accessed via both Portal 1 and Portal 2. Since
Storage Node 2 has the same PGT value assigned to both Portal 1 and
Portal 2, in this case 20, coordinated access via the Portals is
available [iSCSI].
Tseng, et al. Standards Track [Page 29]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
Storage Node 3 can be accessed via Portal 1 or Portal 2. However,
since Storage Node 3 has different PGT values assigned to each
Portal, in this case 10 and 30, access is not coordinated [iSCSI].
Because PGTs are assigned within the context of a Storage Node, the
PGT value of 10 used for Storage Node 1 and Storage Node 3 are not
interrelated.
4.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 for Server column MUST
be implemented in iSNS servers used for iSCSI devices. Messages
indicated in the REQUIRED for Client column MUST be implemented in
iSCSI devices that elect to use the iSNS server.
REQUIRED for:
Message Description Abbreviation Func_ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
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 *
Name Service Heartbeat Heartbeat 0x000E
RESERVED 0x000F-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFF
The following are iSNSP response messages used in support of iSCSI:
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
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 *
Tseng, et al. Standards Track [Page 30]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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 *
RESERVED 0x800E-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF
4.2. iFCP Requirements
In iFCP, use of iSNS is REQUIRED. No alternatives exist for support
of iFCP Naming & Discovery functions.
4.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 for Server column
MUST be implemented by the iSNS server that supports iFCP.
Attributes indicated in the REQUIRED for Client column MUST be
supported by iFCP gateways. Attributes indicated in the K (Key)
column uniquely identify the object type in the iSNS Server. A more
detailed description of each attribute is found in Section 6.
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
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 * * *
Symbolic Name *
ESI Interval *
ESI Port *
SCN Port *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
Tseng, et al. Standards Track [Page 31]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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 *
Permanent Port Name *
FC DEVICE FC Node Name (WWNN) * * *
(FC Node) Node Symbolic Name *
Node IP Address *
Node IPA *
Proxy iSCSI Name
DISCOVERY DOMAIN DD ID * * *
DD Symbolic Name *
DD Member FC Port Name *
DD Member Portal Index *
DD Member Portal IP Addr *
DD Member Portal TCP/UDP *
DISCOVERY DOMAIN DDS ID * *
SET DDS Symbolic Name *
DDS Status *
OTHER Switch Name
Preferred_ID
Assigned_ID
Virtual_Fabric_ID
All iFCP user-specified and vendor-specified attributes are OPTIONAL
to implement and use.
4.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.
Tseng, et al. Standards Track [Page 32]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.example.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 |
| | | |
+-------------+ +--------------------+
Tseng, et al. Standards Track [Page 33]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
4.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.
REQUIRED for:
Message Description Abbreviation Func ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
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 FC_DOMAIN_ID RqstDomId 0x0011
Release FC_DOMAIN_ID RlseDomId 0x0012
Get FC_DOMAIN_IDs GetDomId 0x0013
RESERVED 0x0014-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFF
The following are iSNSP response messages in support of iFCP:
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
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 *
Tseng, et al. Standards Track [Page 34]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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 FC_DOMAIN_ID Rsp RqstDomIdRsp 0x8011
Release FC_DOMAIN_ID Rsp RlseDomIdRsp 0x8012
Get FC_DOMAIN_IDs GetDomIdRsp 0x0013
RESERVED 0x8014-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF
5. 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/Broadcast) | L Bytes
+--------------------------------------------+
Total Length = 12 + N + L
5.1. iSNSP PDU Header
The iSNSP PDU header contains the iSNSP VERSION, FUNCTION ID, PDU
LENGTH, FLAGS, TRANSACTION ID, and SEQUENCE ID fields as defined
below.
Tseng, et al. Standards Track [Page 35]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
5.1.1. iSNSP Version
The iSNSP version described in this document is 0x0001. All other
values are RESERVED. The iSNS server MAY reject messages for iSNSP
version numbers that it does not support.
5.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, whereas
FUNCTION_ID values with the leading bit set indicate response
messages.
See Section 4 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 PDUs comprising an iSNSP message must have the
same FUNCTION_ID value.
5.1.3. iSNSP PDU Length
The iSNS PDU Length specifies the length of the PDU PAYLOAD field in
bytes. The PDU Payload contains TLV attributes for the operation.
Additionally, response messages contain a success/failure code. The
PDU Length MUST be 4-byte aligned.
5.1.4. iSNSP Flags
The FLAGS field indicates additional information about the message
and the type of Network Entity that generated the message. The
following table displays the valid flags:
Bit Position Enabled (1) means:
------------ -----------------
16 Sender is the iSNS client
17 Sender is the iSNS server
18 Authentication block is present
19 Replace flag (for DevAttrReg)
20 Last PDU of the iSNS message
21 First PDU of the iSNS message
22-31 RESERVED
5.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
Tseng, et al. Standards Track [Page 36]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
message is retransmitted, the original TRANSACTION ID value MUST be
used. All PDUs comprising an iSNSP message must have the same
TRANSACTION ID value.
5.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 in which the PDUs
are transmitted. Note that the two-byte SEQUENCE ID allows for up to
65536 PDUs per iSNS message.
5.2. iSNSP Message Segmentation and Reassembly
iSNS messages may be carried in one or more iSNS PDUs. 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 PDUs 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.
5.3. iSNSP PDU Payload
The iSNSP PDU PAYLOAD is of variable length and contains attributes
used for registration and query operations. The attribute data items
use a format similar to that of other protocols, such as DHCP
[RFC2131] options. Each iSNS attribute is specified in the PDU
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
Tseng, et al. Standards Track [Page 37]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
Attribute Tag: a 4-byte field that identifies the attribute as
defined in Section 6.1. This field contains the
tag value from the indicated table.
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 MUST
contain padding bytes, if necessary, in order to
achieve 4-byte alignment. A "zero-length TLV"
contains only the attribute tag and length fields.
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 PDU
Payload. Note that TLV boundaries need not be aligned with PDU
boundaries; PDUs may carry one or more TLVs, or any fraction thereof.
The Response Status Code, contained in response message PDU Payloads
and described below, is not in TLV format. PDU Payloads for messages
that do not contain iSNS attributes, such as the Name Service
Heartbeat, do not use the TLV format.
5.3.1. Attribute Value 4-Byte Alignment
All attribute values are aligned to 4-byte boundaries. For variable
length attributes, if necessary, the TLV length MUST be increased to
the next 4-byte boundary through padding with bytes containing zero
(0). If an attribute value is padded, a combination of the tag and
attribute value itself is used to determine the actual value length
and number of pad bytes. There is no explicit count of the number of
pad bytes provided in the TLV.
Tseng, et al. Standards Track [Page 38]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
5.4. iSNSP Response Status Codes
All iSNSP response messages contain a 4-byte Status Code field as the
first field in the iSNSP PDU PAYLOAD. If the original iSNSP request
message was processed normally by the iSNS server, or by the iSNS
client for ESI and SCN messages, then this field SHALL contain a
status code of 0 (Successful). A non-zero status code indicates
rejection of the entire iSNS client request message.
Status Code Status Description
----------- -----------------
0 Successful
1 Unknown Error
2 Message Format Error
3 Invalid Registration
4 RESERVED
5 Invalid Query
6 Source Unknown
7 Source Absent
8 Source Unauthorized
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 FC_DOMAIN_ID Not Available
20 FC_DOMAIN_ID Not Allocated
21 ESI Not Available
22 Invalid Deregistration
23 Registration Feature Not Supported
24 and above RESERVED
5.5. Authentication for iSNS Multicast and Broadcast Messages
For iSNS multicast and broadcast messages (see Section 2.9.3), 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.
Tseng, et al. Standards Track [Page 39]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
If a message contains an authentication block, then the
"Authentication block present" bit in the iSNSP PDU header FLAGS
field SHALL be enabled.
If a PKI is available with an [X.509] Certificate Authority (CA),
then public key authentication of the iSNS server is possible. The
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 31
+----------------------------------+
0 | BLOCK STRUCTURE DESCRIPTOR | 4 Bytes
+----------------------------------+
4 | AUTHENTICATION BLOCK LENGTH | 4 Bytes
+----------------------------------+
8 | TIMESTAMP | 8 Bytes
+----------------------------------+
16 | SPI STRING LENGTH | 4 Bytes
+----------------------------------+
20 | SPI STRING | N Bytes
+----------------------------------+
20 + N | STRUCTURED AUTHENTICATOR | M Bytes
+----------------------------------+
Total Length = 20 + N + M
BLOCK STRUCTURE DESCRIPTOR (BSD): Defines the structure and algorithm
to use for the STRUCTURED AUTHENTICATOR. BSD values from
0x00000000 to 0x00007FFF are assigned by IANA, while
values 0x00008000 to 0x00008FFF are for private use.
Tseng, et al. Standards Track [Page 40]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
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 an 8-byte unsigned, fixed-point integer giving the
number of seconds since 00:00:00 GMT on January 1, 1970.
SPI STRING LENGTH: The length of the SPI STRING field.
SPI STRING (Security Parameters Index): Index to the key and
algorithm used by the message recipient to decode the
STRUCTURED AUTHENTICATOR field.
STRUCTURED AUTHENTICATOR: Contains the digital signature. For the
default BSD value of 0x0002, this field SHALL contain the
binary ASN.1 encoding of output values from the DSA with
SHA-1 signature calculation as specified in Section 2.2.2
of [RFC3279].
5.6. Registration and Query Messages
The iSNSP registration and query message PDU Payloads contain a list
of attributes, and have the following format:
+----------------------------------------+
| Source Attribute (Requests Only) |
+----------------------------------------+
| Message Key Attribute[1] (if present) |
+----------------------------------------+
| Message Key Attribute[2] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| - Delimiter Attribute - |
+----------------------------------------+
| Operating Attribute[1] (if present) |
+----------------------------------------+
| Operating Attribute[2] (if present) |
+----------------------------------------+
| Operating Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
Each Source, Message Key, Delimiter, and Operating attribute is
specified in the PDU Payload using the Tag-Length-Value (TLV) data
format. iSNS Registration and Query messages are sent by iSNS Clients
Tseng, et al. Standards Track [Page 41]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
to the iSNS server IP Address and well-known TCP/UDP Port. The iSNS
Responses will be sent to the iSNS Client IP address and TCP/UDP port
number from the original request message.
5.6.1. Source Attribute
The Source Attribute is used to identify the Storage Node 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.
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 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 Network Entity
containing the added, deleted, or modified objects.
5.6.2. Message Key Attributes
Message Key attributes are used to identify matching objects in the
iSNS database for iSNS query and registration messages. If present,
the Message Key MUST be a Registration or Query Key for an object as
described in Sections 5.6.5 and 6.1. A Message Key is not required
when a query spans the entire set of objects available to the Source
or a registration is for a new Entity.
iSCSI Names used in the Message Key MUST be normalized according to
the stringprep template [STRINGPREP]. Entity Identifiers (EIDs) used
in the Message Key MUST be normalized according to the nameprep
template [NAMEPREP].
5.6.3. Delimiter Attribute
The Delimiter Attribute separates the Message Key attributes from the
Operating Attributes in a PDU Payload. The Delimiter Attribute has a
tag value of 0 and a length value of 0. The Delimiter Attribute is
always 8 bytes long (a 4-byte tag field and a 4-byte length field,
Tseng, et al. Standards Track [Page 42]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
all containing zeros). If a Message Key is not required for a
message, then the Delimiter Attribute immediately follows the Source
Attribute.
5.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.
Key attributes MUST precede the non-key attributes of each object in
the Operating Attributes. The tag value distinguishes the attribute
as an object key attribute (i.e., tag=1, 16&17, 32, 64, and 96) or a
non-key attribute. iSCSI Names used in the Operating Attributes MUST
be normalized according to the stringprep template [STRINGPREP].
Entity Identifiers (EIDs) used in the Operating Attributes MUST be
normalized according to the nameprep template [NAMEPREP].
The ordering of Operating Attributes in the message is important for
determining the relationships among objects and their ownership of
non-key attributes. iSNS protocol messages that violate these
ordering rules SHALL be rejected with the Status Code of 2 (Message
Format Error). See the message descriptions for proper operating
attribute ordering requirements.
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, 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. A group of key attributes of this
kind is treated as a single logical key attribute when identifying an
object.
Non-key attributes that immediately follow key attributes MUST be
attributes of the object referenced by the key attributes. All non-
key attributes of an object MUST be listed before the object key
attributes introducing the next object.
Objects MUST be listed in inheritance order, according to their
containment order. 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.
Tseng, et al. Standards Track [Page 43]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
Vendor-specific objects defined by tag values in the range 1537-2048
have the same requirements described above.
5.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.
5.6.5. Registration and Query Request Message Types
The following describes each query and message type.
5.6.5.1. Device Attribute Registration Request (DevAttrReg)
The DevAttrReg message type is 0x0001. The DevAttrReg message
provides the means for iSNS clients to update existing objects or
register new objects. The value of the replace bit in the FLAGs
field determines whether the DevAttrReg message updates or replaces
an existing registration.
The Source Attribute identifies the Node initiating the registration
request.
The Message Key identifies the object the DevAttrReg message acts
upon. It MUST contain the key attribute(s) identifying an object.
This object MUST contain all attributes and related subordinate
object attributes that will be included in the Operating Attributes
of the DevAttrReg PDU Payload. The key attribute(s) identifying this
object MUST also be included among the Operating Attributes.
If the Message Key contains an EID and no pre-existing objects match
the Message Key, then the DevAttrReg message SHALL create a new
Entity with the specified EID and any new object(s) specified by the
Operating Attributes. The replace bit SHALL be ignored.
If the Message Key does not contain an EID, and no pre-existing
objects match the Message Key, then the DevAttrReg message SHALL be
rejected with a status code of 3 (Invalid Registration).
If the Message Key is not present, then the DevAttrReg message
implicitly registers a new Network Entity. In this case, the replace
bit SHALL be ignored; a new Network Entity SHALL be created.
Existing entities, their objects, and their relationships remain
unchanged.
Tseng, et al. Standards Track [Page 44]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
The replace bit determines the kind of operation conducted on the
object identified in the DevAttrReg Message Key. The replace bit
only applies to the DevAttrReg message; it is ignored for all other
message types.
If the replace bit is set, then the objects, attributes, and
relationships specified in the Operating Attributes SHALL replace the
object identified by the Message Key. The object and all of its
subordinate objects SHALL be deregistered, and the appropriate SCNs
SHALL be sent by the iSNS server for the deregistered objects. The
objects listed in the Operating Attributes are then used to replace
the just-deregistered objects. Note that additional SCNs SHALL be
sent for the newly-registered objects, if appropriate. Existing
objects and relationships that are not identified or that are
subordinate to the object identified by the Message Key MUST NOT be
affected or changed.
If the replace bit is not set, then the message updates the
attributes of the object identified by the Message Key and its
subordinate objects. Existing object containment relationships MUST
NOT be changed. For existing objects, key attributes MUST NOT be
modified, but new subordinate objects MAY be added.
The Operating Attributes represent objects, attributes, and
relationships that are to be registered. Multiple related objects
and attributes MAY be registered in a single DevAttrReg message. The
ordering of the objects in this message indicates the structure of,
and associations among, the objects to be registered. At least one
object MUST be listed in the Operating Attributes. Additional
objects (if any) MUST be subordinate to the first object listed. Key
attributes MUST precede non-key attributes of each object. A given
object may only appear a maximum of once in the Operating Attributes
of a message. If the Node identified by the Source Attribute is not
a Control Node, then the objects in the operating attributes MUST be
members of the same Network Entity as the Source Node.
For example, to establish relationships between a Network Entity
object and its Portal and Storage Node objects, the Operating
Attributes list the key and non-key attributes of the Network Entity
object, followed by the key and non-key attributes of each Portal and
Storage Node object to be linked to that Network Entity. Similarly,
an FC Device object that follows a Storage Node object is considered
subordinate to that Storage Node.
New PG objects are registered when an associated Portal or iSCSI Node
object is registered. An explicit PG object registration MAY follow
a Portal or iSCSI Node object registration in a DevAttrReg message.
Tseng, et al. Standards Track [Page 45]
RFC 4171 Internet Storage Name Service (iSNS) September 2005
When a Portal is registered, the Portal attributes MAY immediately be
followed by a PGT attribute. The PGT attribute SHALL be followed by
the set of PG iSCSI Names representing nodes that will be associated
to the Portal using the indicated PGT value. Additional sets of PGTs
and PG iSCSI Names to be associated to the registered Portal MAY
follow. Indicated PGT values are assigned to the PG object
associated with the newly registered Portal and to the iSCSI Storage
Node(s) referenced immediately following the PGT attribute in the
operating attributes.
When an iSCSI Storage Node is registered, the Storage Node attribute |
