[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-tseng-ips-isns) 00 01 02 03
04 05 06 07 08 09 10 11 12 13 14 15
16 17 18 19 20 21 22 RFC 4171
IPS Josh Tseng
Internet Draft Kevin Gibbons
<draft-ietf-ips-isns-16.txt> Nishan Systems
Standards Track
Expires July 2003 Franco Travostino
Nortel Networks
Curt Du Laney
IBM
Joe Souza
Microsoft
January 2003
Internet Storage Name Service (iSNS)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Acknowledgements
Numerous individuals contributed to the creation of this draft
through their careful review and submissions of comments and
recommendations. We acknowledge the following persons for their
technical contributions to this document: Mark Bakke (Cisco), John
Hufferd (IBM), Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe
Czap (IBM), John Dowdy (IBM), Tom McSweeney (IBM), Jim Hafner
(IBM), Chad Gregory (Intel), Yaron Klein (Sanrad), Larry Lamers
(Adaptec), Jack Harwood (EMC), David Black (EMC), David Robinson
(Sun), Alan Warwick (Microsoft), Bob Snead (Microsoft), Fa Yoeu
(Intransa), Joe White (Nishan), Charles Monia (Nishan), Ken Hirata
(Vixel), Howard Hall (Pirus), Malikarjun Chadalapaka (HP), Marjorie
Krueger (HP), and Vinai Singh (American Megatrends).
Tseng, Gibbons, et al. Standards Track [Page 1]
Internet Storage Name Service (iSNS) January 2003
Comments
Comments should be sent to the IPS mailing list (ips@ece.cmu.edu)
or to the authors.
Tseng, Gibbons, et al. Standards Track [Page 2]
Internet Storage Name Service (iSNS) January 2003
Table of Contents
Status of this Memo..................................................1
Acknowledgements.....................................................1
Comments.............................................................2
1.Abstract...........................................................7
2.About this Document................................................7
2.1 Conventions Used in this Document................................7
2.2 Purpose of this Document.........................................7
3.iSNS Overview......................................................7
3.1 iSNS Architectural Components....................................8
3.1.1 iSNS Protocol (iSNSP)..........................................8
3.1.2 iSNS Client....................................................8
3.1.3 iSNS Server....................................................8
3.1.4 iSNS Database..................................................8
3.1.5 iSCSI..........................................................8
3.1.6 iFCP...........................................................9
3.2 iSNS Functional Overview.........................................9
3.2.1 Name Registration Service......................................9
3.2.2 Discovery Domain and Login Control Service.....................9
3.2.3 State Change Notification Service.............................10
3.2.4 Open Mapping Between Fibre Channel and iSCSI Devices..........11
3.3 iSNS Usage Model................................................12
3.3.1 iSCSI Initiator...............................................12
3.3.2 iSCSI Target..................................................12
3.3.3 iSCSI-FC Gateway..............................................13
3.3.4 iFCP Gateway..................................................13
3.3.5 Management Station............................................13
3.4 Administratively Controlled iSNS Settings.......................13
3.5 iSNS Server Discovery...........................................14
3.5.1 Service Location Protocol (SLP)...............................14
3.5.2 Dynamic Host Configuration Protocol (DHCP)....................14
3.5.3 iSNS Heartbeat Message........................................15
3.6 iSNS and NAT....................................................15
3.7 Transfer of iSNS Database Records between iSNS Servers..........15
3.8 Backup iSNS Servers.............................................17
3.9 Transport Protocols.............................................19
3.9.1 Use of TCP For iSNS Communication.............................19
3.9.2 Use of UDP For iSNS Communication.............................20
3.9.3 iSNS Multicast and Broadcast Messages.........................20
4.iSNS Object Model.................................................20
4.1 Network Entity Object...........................................20
4.2 Portal Object...................................................21
4.3 Storage Node Object.............................................21
4.4 FC Device Object................................................21
4.5 Discovery Domain Object.........................................22
4.6 Discovery Domain Set Object.....................................22
4.7 iSNS Database Model.............................................22
5.iSNS Implementation Requirements..................................23
5.1 iSCSI Requirements..............................................23
5.1.1 Required Attributes for Support of iSCSI......................23
5.1.2 Example iSCSI Object Model Diagrams...........................24
5.1.3 Required Commands and Response Messages for Support of iSCSI..26
5.2 iFCP Requirements...............................................27
Tseng, Gibbons, et al. Standards Track [Page 3]
Internet Storage Name Service (iSNS) January 2003
5.2.1 Required Attributes for Support of iFCP.......................27
5.2.2 Example iFCP Object Model Diagram.............................29
5.2.3 Required Commands and Response Messages for Support of iFCP...30
6.iSNSP Message Format..............................................31
6.1 iSNSP PDU Header................................................31
6.1.1 iSNSP Version.................................................31
6.1.2 iSNSP Function ID.............................................31
6.1.3 iSNSP PDU Length..............................................32
6.1.4 iSNSP Flags...................................................32
6.1.5 iSNSP Transaction ID..........................................32
6.1.6 iSNSP Sequence ID.............................................32
6.2 iSNSP Message Segmentation and Reassembly.......................32
6.3 iSNSP PDU Payload...............................................33
6.3.1 Attribute Value 4-Byte Alignment..............................33
6.4 iSNSP Response Status Codes.....................................34
6.5 Authentication for iSNS Multicast and Broadcast Messages........34
6.6 Registration and Query Messages.................................36
6.6.1 Source Attribute..............................................36
6.6.2 Message Key Attributes........................................37
6.6.3 Delimiter Attribute...........................................37
6.6.4 Operating Attributes..........................................37
6.6.5 Registration and Query Request Message Types..................38
6.7 Response Messages...............................................54
6.7.1 Status Code...................................................54
6.7.2 Message Key Attributes in Response............................55
6.7.3 Delimiter Attribute in Response...............................55
6.7.4 Operating Attributes in Response..............................55
6.7.5 Registration and Query Response Message Types.................55
6.8 Vendor Specific Messages........................................59
7.iSNS Attributes...................................................59
7.1 iSNS Attribute Summary..........................................60
7.2 Entity Identifier-Keyed Attributes..............................62
7.2.1 Entity Identifier (EID).......................................62
7.2.2 Entity Protocol...............................................63
7.2.3 Management IP Address.........................................63
7.2.4 Entity Registration Timestamp.................................63
7.2.5 Protocol Version Range........................................64
7.2.6 Registration Period...........................................64
7.2.7 Entity Index..................................................65
7.2.8 Entity Next Index.............................................65
7.2.9 Entity ISAKMP Phase-1 Proposals...............................65
7.2.10Entity Certificate............................................65
7.3 Portal-Keyed Attributes.........................................65
7.3.1 Portal IP Address.............................................66
7.3.2 Portal TCP/UDP Port...........................................66
7.3.3 Portal Symbolic Name..........................................66
7.3.4 Entity Status Inquiry Interval................................66
7.3.5 ESI Port......................................................67
7.3.6 Portal Group Tag..............................................67
7.3.7 Portal Index..................................................68
7.3.8 SCN Port......................................................68
7.3.9 Portal Next Index.............................................68
7.3.10Portal Security Bitmap........................................68
7.3.11Portal ISAKMP Phase-1 Proposals...............................69
Tseng, Gibbons, et al. Standards Track [Page 4]
Internet Storage Name Service (iSNS) January 2003
7.3.12Portal ISAKMP Phase-2 Proposals...............................69
7.3.13Portal Certificate............................................69
7.4 iSCSI Node-Keyed Attributes.....................................70
7.4.1 iSCSI Name....................................................70
7.4.2 iSCSI Node Type...............................................70
7.4.3 iSCSI Node Alias..............................................71
7.4.4 iSCSI Node SCN Bitmap.........................................71
7.4.5 iSCSI Node Index..............................................72
7.4.6 WWNN Token....................................................72
7.4.7 iSCSI Node Next Index.........................................73
7.4.8 iSCSI AuthMethod..............................................73
7.4.9 iSCSI Node Certificate........................................74
7.5 FC Port Name-Keyed Attributes...................................74
7.5.1 FC Port Name (WWPN)...........................................74
7.5.2 Port ID (FC_ID)...............................................74
7.5.3 FC Port Type..................................................74
7.5.4 Symbolic Port Name............................................75
7.5.5 Fabric Port Name (FWWN).......................................75
7.5.6 Hard Address..................................................75
7.5.7 Port IP Address...............................................75
7.5.8 Class of Service (COS)........................................75
7.5.9 FC-4 Types....................................................76
7.5.10FC-4 Descriptor...............................................76
7.5.11FC-4 Features.................................................76
7.5.12iFCP SCN Bitmap...............................................76
7.5.13Port Role.....................................................76
7.5.14Permanent Port Name (PPN).....................................77
7.5.15Port Certificate..............................................78
7.6 Node-Keyed Attributes...........................................78
7.6.1 FC Node Name (WWNN)...........................................78
7.6.2 Symbolic Node Name............................................78
7.6.3 Node IP Address...............................................78
7.6.4 Node IPA......................................................78
7.6.5 Node Certificate..............................................78
7.6.6 Proxy iSCSI Name..............................................78
7.7 Other Attributes................................................79
7.7.1 FC-4 Type Code................................................79
7.7.2 iFCP Switch Name..............................................79
7.7.3 iFCP Transparent Mode Commands................................79
7.8 iSNS Server-Specific Attributes.................................80
7.8.1 iSNS Server Vendor OUI........................................80
7.9 Vendor-Specific Attributes......................................80
7.9.1 Vendor-Specific Server Attributes.............................80
7.9.2 Vendor-Specific Entity Attributes.............................81
7.9.3 Vendor-Specific Portal Attributes.............................81
7.9.4 Vendor-Specific iSCSI Node Attributes.........................81
7.9.5 Vendor-Specific FC Port Name Attributes.......................81
7.9.6 Vendor-Specific FC Node Name Attributes.......................81
7.9.7 Vendor-Specific Discovery Domain Attributes...................81
7.9.8 Vendor-Specific Discovery Domain Set Attributes...............81
7.9.9 Other Vendor-Specific Attributes..............................81
7.10Discovery Domain Registration Attributes........................82
7.10.1DD Set ID Keyed Attributes....................................82
7.10.2DD ID Keyed Attributes........................................82
Tseng, Gibbons, et al. Standards Track [Page 5]
Internet Storage Name Service (iSNS) January 2003
8.Security Considerations...........................................84
8.1 iSNS Security Threat Analysis...................................84
8.2 iSNS Security Implementation and Usage Requirements.............85
8.3 Discovering Security Requirements of Peer Devices...............86
8.4 Configuring Security Policies of iFCP/iSCSI Devices.............87
8.5 Resource Issues.................................................87
8.6 iSNS Interaction with IKE and IPSec.............................87
9.IANA Considerations...............................................88
10. Normative References..........................................89
11. Informative References........................................90
12. Author's Addresses............................................92
Full Copyright Statement............................................93
Appendix A -- iSNS Examples.........................................94
A.1 iSCSI Initialization Example....................................94
A.1.1 Simple iSCSI Target Registration..............................94
A.1.2 Target Registration and DD Configuration......................95
A.1.3 Initiator Registration and Target Discovery...................96
Tseng, Gibbons, et al. Standards Track [Page 6]
Internet Storage Name Service (iSNS) January 2003
1. Abstract
This document specifies the iSNS protocol, which is used for
interaction between iSNS servers and iSNS clients in order to
facilitate automated discovery, management, and configuration of
iSCSI and Fibre Channel (FCP) devices on a TCP/IP network. iSNS
provides intelligent storage discovery and management services
comparable to those found in Fibre Channel networks, allowing a
commodity IP network to function in a similar capacity as a storage
area network. iSNS also facilitates a seamless integration of IP
and Fibre Channel networks, due to its ability to emulate Fibre
Channel fabric services, and manage both iSCSI and Fibre Channel
devices. iSNS thereby provides value in any storage network
comprised of iSCSI devices, Fibre Channel devices, or any
combination thereof.
2. About this Document
2.1 Conventions Used in this Document
iSNS refers to the framework consisting of the storage network
model and associated services.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", ôMAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
All frame formats are in big endian network byte order.
All unused fields and bitmaps, including those that are RESERVED,
SHOULD be set to zero.
2.2 Purpose of this Document
This is a standards track document containing normative text
specifying the iSNS Protocol, used by iSCSI and iFCP devices to
communicate with the iSNS server. This document focuses on the
interaction between iSNS servers and iSNS clients; interactions
among multiple authoritative primary iSNS servers are a potential
topic for future work.
3. iSNS Overview
iSNS facilitates scalable configuration and management of iSCSI and
Fibre Channel (FCP) storage devices in an IP network, by providing
a set of services comparable to that available in Fibre Channel
networks. iSNS thus allows a commodity IP network to function at a
comparable level of intelligence to a Fibre Channel fabric. iSNS
allows the administrator to go beyond a simple device-by-device
management model, where each storage device is manually and
individually configured with its own list of known initiators and
targets. Using the iSNS, each storage device subordinates its
discovery and management responsibilities to the iSNS server. The
Tseng, Gibbons, et al. Standards Track [Page 7]
Internet Storage Name Service (iSNS) January 2003
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.
3.1 iSNS Architectural Components
3.1.1 iSNS Protocol (iSNSP)
The iSNS Protocol (iSNSP) is a flexible and lightweight protocol
that specifies how iSNS clients and servers communicate. It is
suitable for various platforms, including switches and targets as
well as server hosts.
3.1.2 iSNS Client
iSNS clients initiate transactions with iSNS servers using the
iSNSP. iSNS clients are processes that are co-resident in the
storage device, and can register device 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.
3.1.3 iSNS Server
iSNS servers respond to iSNS protocol queries and requests, and
initiate iSNS protocol State Change Notifications. Properly
authenticated information submitted by a registration request is
stored in an iSNS database.
3.1.4 iSNS Database
The iSNS database is the information repository for the iSNS
server(s). It maintains information about iSNS client attributes.
A directory-enabled implementation of iSNS may store client
attributes in an LDAP directory infrastructure.
3.1.5 iSCSI
iSCSI (Internet SCSI) is an encapsulation of SCSI for a new
generation of storage devices interconnected with TCP/IP.
Tseng, Gibbons, et al. Standards Track [Page 8]
Internet Storage Name Service (iSNS) January 2003
3.1.6 iFCP
iFCP (Internet FCP) is a gateway-to-gateway protocol designed to
interconnect existing Fibre Channel and SCSI devices using TCP/IP.
iFCP maps the existing FCP standard and associated Fibre Channel
services to TCP/IP.
3.2 iSNS Functional Overview
There are four main functions of the iSNS:
1) A Name Service Providing Storage Resource Discovery
2) Discovery Domain (DD) and Login Control Service
3) State Change Notification Service
4) Open Mapping of Fibre Channel and iSCSI Devices
3.2.1 Name Registration Service
The iSNS provides a registration function to allow all entities in
a storage network to register and query the iSNS database. Both
targets and initiators can register in the iSNS database, as well
as query for information about other initiators and targets. This
allows, for example, a client initiator to obtain information about
target devices from the iSNS server. This service is modeled on the
Fibre Channel Generic Services Name Server described in FC-GS-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 required.
3.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 to
reduce the number of unnecessary logins (iSCSI logins or Fibre
Channel Port Logins), and to limit 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 a member of multiple DDs simultaneously.
Login Control allows targets to delegate their access
control/authorization policy 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 initiators that match the required identification and
Tseng, Gibbons, et al. Standards Track [Page 9]
Internet Storage Name Service (iSNS) January 2003
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.
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
login 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
are to 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 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 Storage Nodes that have been deregistered. DD membership is
persistent regardless of whether a Storage Node is actively
registered in the iSNS database.
3.2.3 State Change Notification Service
The State Change Notification (SCN) service allows the iSNS Server
to issue notifications about network events that affect the
operational state of 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
Tseng, Gibbons, et al. Standards Track [Page 10]
Internet Storage Name Service (iSNS) January 2003
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 SCN's, while regular registrations result in regular
SCN's. The type of registration and SCN message is indicated in the
SCN bitmap (see sections 7.4.4 and 7.5.12).
A regular SCN registration indicates that the Discovery Domain
Service SHALL be used to control the distribution of SCN messages.
Receipt of regular SCN's is limited to the discovery domains in
which the SCN-triggering event takes place. Regular SCN's do not
contain information about discovery domains.
A management SCN registration can only by requested by Control
Nodes. Management SCN's 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 sufficient hardware and
software resources needed to support the expected number of iSNS
clients. However, if resources are unexpectedly exhausted, then
the iSNS server MAY refuse SCN service by returning a SCN
Registration Rejected (Status Code 17). The rejection might occur
in situations where the network size or current number of SCN
registrations, has passed an implementation-specific threshold. A
client not allowed to register for SCNs may decide to monitor its
sessions with other storage devices directly.
The specific notification mechanism by which the iSNS server learns
of the events that trigger SCN's is implementation-specific, but
can include examples such as explicit notification messages from an
iSNS client to the iSNS server, or a hardware interrupt to a
switch-hosted iSNS server as a result of link failure.
3.2.4 Open Mapping Between Fibre Channel and iSCSI Devices
The iSNS database stores naming and discovery information about
both Fibre Channel and iSCSI devices. This allows the iSNS server
to store mappings of a Fibre Channel device to a proxy iSCSI device
"image" in the IP network. Similarly, mappings of an iSCSI device
to a "proxy WWN" can be stored under the WWNN Token field for that
that iSCSI device.
Furthermore, through use of iSCSI-FC gateways, Fibre Channel-aware
management stations can interact with the iSNS server to retrieve
information about Fibre Channel devices, and use this information
to manage Fibre Channel devices as well as iSCSI devices. This
allows management functions such as Discovery Domains and State
Change Notifications to be seamlessly applied for both iSCSI and
Tseng, Gibbons, et al. Standards Track [Page 11]
Internet Storage Name Service (iSNS) January 2003
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 the ability to store this information in the iSNS server is
useful even if the iFCP protocol is not implemented. In
particular, tag 101 can be used to store a "Proxy iSCSI Name" for
Fibre Channel devices registered in the iSNS server. This field is
used to associate the FC device with an iSCSI registration entry
that is used for the Fibre Channel device to communicate with iSCSI
devices in the IP network. Conversely, tag 37 (see section 7.1)
contains an WWNN Token field, which can be used to store an FC Node
Name (WWNN) value used by iSCSI-FC gateways to represent an iSCSI
device in the Fibre Channel domain.
By storing the mapping between Fibre Channel and iSCSI devices in
the iSNS server, this information becomes open to any authorized
iSNS client wishing to retrieve and use this information. In many
cases, this provides advantages over storing this information
internally within an iSCSI-FC gateway, where the mapping is
inaccessible to other devices except by proprietary mechanisms.
3.3 iSNS Usage Model
The following is a high-level description of how each type of
device in a storage network can utilize iSNS. Each type of device
interacts with the iSNS server as an iSNS client, and must register
itself in the iSNS database in order to access services provided by
the iSNS.
3.3.1 iSCSI Initiator
An iSCSI initiator will query the iSNS server to discover the
presence and location of iSCSI target devices. It may also request
state change notifications (SCN's) so that it can be notified of
new targets that appear on the network after the initial bootup and
discovery. SCN's can also inform the iSCSI initiator of targets
that are removed or no longer available in the storage network, so
that incomplete storage sessions can be gracefully terminated and
resources for non-existent targets can be reallocated.
3.3.2 iSCSI Target
An iSCSI target allows itself to be discovered by iSCSI initiators
by registering its presence in the iSNS server. It may also
register for SCN's in order to detect the addition or removal of
initiators for resource allocation purposes. The iSCSI target
device may also register for Entity Status Inquiry (ESI) messages,
which allow the iSNS to monitor the target device's availability in
the storage network.
Tseng, Gibbons, et al. Standards Track [Page 12]
Internet Storage Name Service (iSNS) January 2003
3.3.3 iSCSI-FC Gateway
An iSCSI-FC Gateway bridges devices in a Fibre Channel network to
an iSCSI/IP network. It may use the iSNS 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.
3.3.4 iFCP Gateway
An iFCP Gateway uses iSNS to emulate the services provided by a
Fibre Channel name server for FC devices in its gateway region.
iSNS provides basic discovery and zoning configuration information
to be enforced by the iFCP gateway. When queried, iSNS returns
information on the N_Port network address used to establish iFCP
sessions between FC devices supported by iFCP gateways.
3.3.5 Management Station
A management station uses iSNS to monitor storage devices and
enable or disable storage sessions by configuring discovery
domains. A management station usually interacts with the iSNS
server as a Control Node endowed with access to all iSNS database
records and special privileges to configure discovery domains.
Through manipulation of discovery domains, the management station
controls the scope of device discovery for iSNS clients querying
the iSNS server.
3.4 Administratively Controlled iSNS Settings
Some important operational settings for the iSNS server are
configured using administrative means, such as through a
configuration file, console port, SNMP, or other implementation-
specific method. These administratively controlled settings cannot
be configured using the iSNS Protocol, 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.
Tseng, Gibbons, et al. Standards Track [Page 13]
Internet Storage Name Service (iSNS) January 2003
Setting Default Setting
------- ---------------
ESI Non-Response Threshold 3 (see 6.6.5.13)
Management SCNs (Control Nodes only) enabled (see 6.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 SCN's.
Default DD/DDS - determines whether a newly registered device not
explicitly placed into a discovery domain (DD) and discovery domain
set (DDS) is placed into a default DD/DDS.
DD/DDS Modification - determines whether the specified type of Node
is allowed to add, delete or update DDs and DDSs.
Authorized Control Nodes - a list of Nodes identified by iSCSI Name
or FC Port Name WWPN that are authorized to register as Control
Nodes.
3.5 iSNS Server Discovery
3.5.1 Service Location Protocol (SLP)
The Service Location Protocol (SLP) provides a flexible and
scalable framework for providing hosts with access to information
about the existence, location, and configuration of networked
services, including the iSNS server. SLP can be used by iSNS
clients to discover the IP address or FQDN of the iSNS server. To
implement discovery through SLP, a Service Agent (SA) should be
cohosted in the iSNS server, and a User Agent (UA) should be in
each iSNS client. Each client multicasts a discovery message
requesting the IP address of the iSNS server(s). The SA responds
to this request. Optionally, the location of the iSNS server can
be stored in the SLP Directory Agent (DA).
Note that a complete description and specification of SLP can be
found in [RFC2608], and is beyond the scope of this document.
3.5.2 Dynamic Host Configuration Protocol (DHCP)
The IP address of the iSNS server can be stored in a DHCP server to
be downloaded by iSNS clients using a DHCP option. The DHCP option
Tseng, Gibbons, et al. Standards Track [Page 14]
Internet Storage Name Service (iSNS) January 2003
number to be used for distributing the iSNS server location is
found in [isnsoption].
3.5.3 iSNS Heartbeat Message
The iSNS heartbeat message is described in section 6.6.5.14. It
allows iSNS clients within the broadcast or multicast domain of the
iSNS server to discover the location of the active iSNS server and
any backup servers.
3.6 iSNS and NAT
The existence of NAT will have an impact upon information retrieved
from the iSNS server. If the iSNS client exists in a different
addressing domain than the iSNS server, then IP address information
stored in the iSNS server may not be correct when interpreted in
the domain of the iSNS client.
There are several possible approaches to allow operation of iSNS
within a NAT network. The first approach is to require use of the
canonical TCP port number by both targets and initiators when
addressing targets across a NAT boundary, and for the iSNS client
to not query for nominal IP addresses. Rather, the iSNS client
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.
3.7 Transfer of iSNS Database Records between iSNS Servers
Transfer of iSNS database records between iSNS servers has
important applications, including the following:
1) An independent organization needs to transfer storage
information to a different organization. Each organization
Tseng, Gibbons, et al. Standards Track [Page 15]
Internet Storage Name Service (iSNS) January 2003
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.
To support the above applications, information in an iSNS server
can be distributed to other iSNS servers either using the iSNS
protocol, or through out-of-band mechanisms using non-iSNS
protocols. The following examples illustrate possible methods to
transfer data records between iSNS servers. In the first example,
a back-end LDAP information base is used to support the iSNS
server, and the data is transferred using the LDAP protocol. Once
the record transfer of the remote device is completed, it becomes
visible and accessible to local devices using the local iSNS
server. This allows local devices to establish sessions with
remote devices (provided firewall boundaries can be negotiated).
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +--+---+ | WAN | +---+--+ |
|.dev C'. | | Link | | |
|........ | ============= | |
| | | | | |
| +--+---+ | | +---+--+ |
| | local|<--- <--- <--- <-|remote| |
| | LDAP | | LDAP: | | LDAP | |
| +------+ Xfer "dev C"| +------+ |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
In the above diagram, two business partners wish to share storage
"dev C". Using LDAP, the record for "dev C" can be transfered from
Network B to Network A. Once accessible to the local iSNS server
in Network A, local devices A and B can now discover and connect to
"dev C".
Tseng, Gibbons, et al. Standards Track [Page 16]
Internet Storage Name Service (iSNS) January 2003
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +------+ | WAN | +---+--+ |
|.dev C'. ^ | Link | | |
|........ | ============= v |
| | | | |SNMP |
| | | | | |
| +--+----+ | | v |
| | SNMP |<--- <--- <--- <---- |
| | Mgmt | | SNMP: Xfer "dev C" |
| |Station| | | |
| +-------+ | | |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
The above diagram illustrates a second example of how iSNS records
can be shared. This method uses an SNMP-based management station to
manually download the desired record for "dev C", and then directly
upload it to the local iSNS server. Once the record is transferred
to the local iSNS server in Network A, "dev C" becomes visible and
accessible (provided firewall boundaries can be negotiated) to
other devices in Network A.
Other methods, including proprietary protocols, can be used to
transfer device records between iSNS servers. Further discussion
and explanation of these methodologies is beyond the scope of this
document.
3.8 Backup iSNS Servers
This section offers a broad framework for implementation and
deployment of iSNS backup servers. Server failover and recovery
are topics of continuing research and adequate resolution of issues
such as split brain and primary server selection is dependent on
the specific implementation requirements and deployment needs. 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.
- Required failover behaviors of the collection of iSNS servers
that includes active and backup servers.
Tseng, Gibbons, et al. Standards Track [Page 17]
Internet Storage Name Service (iSNS) January 2003
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
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 3.7 above can be used to
transfer name server records to backup iSNS servers. Each backup
server maintains a redundant copy of the name server database found
in the primary iSNS server, and can respond to iSNS protocol
messages in the same way as the active server. Each backup server
SHOULD 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 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 not already known, each backup
server MAY learn its precedence from the iSNS heartbeat message, by
noting the position of its IP address in the ordered list of backup
server IP addresses. For example, if it is the first backup listed
in the heartbeat message, then its backup precedence is 1. If it
is the third backup server listed, then its backup precedence is 3.
If a backup server establishes that it has lost connectivity to the
active server and other backup servers of higher precedence, then
it SHOULD assume that it is the active server. The method of
Tseng, Gibbons, et al. Standards Track [Page 18]
Internet Storage Name Service (iSNS) January 2003
determining whether connectivity has been lost is implementation-
specific. One possible approach is to assume that if the backup
server does not receive iSNS hearbeat messages for a period of
time, then connectivity to the active server has been lost.
Alternately, the backup server may establish TCP connections to the
active server and other backup servers, and loss of connectivity
determined through non-response to periodic echo messages (using
iSNSP, SNMP, or other protocols).
When a backup server becomes the active server, it SHALL assume all
active server responsibilities, including (if used) transmission of
the iSNS heartbeat message. If transmitting the iSNS heartbeat,
the backup server replaces the active Server IP Address and TCP/UDP
Port entries with its own IP address and TCP/UDP Port, and begins
incrementing the counter field from the last known value from the
previously-active iSNS server. However, it MUST NOT change the
original ordered list of backup server IP Address and TCP/UDP Port
entries. If the primary backup server or other higher-precedence
backup server returns, then the existing active server is
responsible for ensuring that the new active server's database is
up-to-date before demoting itself to its original status as backup.
3.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.
3.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 (see section 6.6.5.13) monitoring
using TCP, the client registers the Portal ESI Interval and the
port number of the TCP port that will be used to receive ESI
messages. The iSNS server initiates the TCP connection used to
deliver the ESI message. This TCP connection does not need to be
continuously open.
To receive SCN notifications using TCP, the client registers the
iSCSI or iFCP SCN Bitmap and the port number of the TCP port in the
Portal used to receive SCN's. The iSNS server initiates the TCP
connection used to deliver the SCN message. This TCP connection
does not need to be continuously open.
It is possible for an iSNS client to use the same TCP connection
for SCN, ESI, and iSNS queries. Alternatively, separate
connections may be used.
Tseng, Gibbons, et al. Standards Track [Page 19]
Internet Storage Name Service (iSNS) January 2003
3.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 an
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 6).
3.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 messages 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.
4. iSNS Object Model
iSNS provides the framework for the registration, discovery, and
management of iSCSI devices and Fibre Channel-based devices (using
iFCP). This architecture framework provides elements needed to
describe various storage device objects and attributes that may
exist on an IP storage network. Objects defined in this
architecture framework include Network Entity, Portal, Storage
Node, FC Device, Discovery Domain, and Discovery Domain Set. Each
of these objects is described in greater detail in the following
sections.
4.1 Network Entity Object
The Network Entity object is a container of Storage Node objects
and Portal objects. It represents the infrastructure supporting
access to a unique set of one or more Storage Nodes. The Entity
Identifier attribute uniquely distinquishes 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.
Tseng, Gibbons, et al. Standards Track [Page 20]
Internet Storage Name Service (iSNS) January 2003
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. The multiple gateways
collectively can be used to support a single logical Network Entity
that is used to contain all of the devices in that Fibre Channel
network.
4.2 Portal Object
The Portal object is an interface through which access to any
Storage Node within the Network Entity can be obtained. 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 4.5 below).
4.3 Storage Node Object
The Storage Node object is the logical endpoint of an iSCSI or iFCP
session. In iFCP, the session endpoint is represented by the World
Wide Port Name (WWPN). In iSCSI, the session endpoint is
represented by the iSCSI Name of the device. 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. A Storage Node is contained in one and only
one Network Entity object, and may be contained in one or more DDs
(see section 4.5 below).
4.4 FC Device Object
The FC Device represents the Fibre Channel Node. This object
contains information that may be useful in the management of the
Fibre Channel device. 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.
Tseng, Gibbons, et al. Standards Track [Page 21]
Internet Storage Name Service (iSNS) January 2003
4.5 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 to be
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.
4.6 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.
4.7 iSNS 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 ability to respond to DevGetNext queries (see section 6.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 shows the various objects described above and their
relationship to each other.
Tseng, Gibbons, et al. Standards Track [Page 22]
Internet Storage Name Service (iSNS) January 2003
+--------------+ +-----------+
| NETWORK |1 *| |
| ENTITY |----| PORTAL |
| | | |
+--------------+ +-----------+
| 1 | *
| |
| |
| * | *
+-----------+ +--------------+ +-----------+ +-----------+
| FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY |
| DEVICE |----| NODE |----| DOMAIN |----| DOMAIN |
| | | | | | | SET |
+-----------+ +--------------+ +-----------+ +-----------+
* represents 0 to many possible relationships
5. iSNS Implementation Requirements
This section details specific requirements for support of each of
these IP storage protocols. Implementation requirements for
security are described in section 8.
5.1 iSCSI Requirements
Use of iSNS in support of iSCSI is OPTIONAL. iSCSI devices MAY be
manually configured with the iSCSI Name and IP address of peer
devices, without the aid or intervention of iSNS. iSCSI devices
also may use SLP [RFC 2608] to discover peer iSCSI devices.
However, iSNS is useful for scaling a storage network to a larger
number of iSCSI devices.
5.1.1 Required Attributes for Support of iSCSI
The following attributes are available to support iSCSI.
Attributes indicated in the REQUIRED 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 7.
REQUIRED REQUIRED
Object Attribute K for Server for
Client
------ --------- - ---------- ---------
-
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address
Timestamp *
Protocol Version Range *
Tseng, Gibbons, et al. Standards Track [Page 23]
Internet Storage Name Service (iSNS) January 2003
Registration Period *
Entity Index *
Entity IKE Phase-1 Proposal
Entity Certificate
PORTAL IP Address * * *
TCP/UDP Port * * *
Portal Symbolic Name *
ESI Interval *
ESI Port *
Portal Group Tag *
Portal Index *
SCN Port *
Portal Security Bitmap *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
Portal Certificate
STORAGE NODE iSCSI Name * * *
iSCSI Node Type * *
Alias *
iSCSI SCN Bitmap *
iSCSI Node Index *
WWNN Token
iSCSI AuthMethod
iSCSI Node Certificate
DISCOVERY DOMAIN DD ID * * *
DD Symbolic Name *
DD Member iSCSI Node Index *
DD Member iSCSI Node 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 *
Status *
DDS Member *
All iSCSI user-specified and vendor-specified attributes are
OPTIONAL to implement and use.
5.1.2 Example iSCSI Object Model Diagrams
The following diagram models how a simple iSCSI-based initiator and
target is represented using database objects stored in the iSNS
server. In this implementation, each target and initiator is
attached to a single Portal.
Tseng, Gibbons, et al. Standards Track [Page 24]
Internet Storage Name Service (iSNS) January 2003
+----------------------------------------------------------------+
| IP Network |
+------------+--------------------------------------+------------+
| |
| |
+-----+------+------+-----+ +-----+------+------+-----+
| | PORTAL | | | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | |
| | -TCP Port 1 | | | | -TCP Port 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| | | | | | | |
| +--------+ +--------+ | | +-------+ +--------+ |
| | | | | | | |
| | STORAGE NODE | | | | STORAGE NODE | |
| | -iSCSI Name | | | | -iSCSI Name | |
| | -Alias: "server1"| | | | -Alias: "disk1"| |
| | -Type: initiator | | | | -Type: target | |
| | | | | | | |
| +-------------------+ | | +------------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (FQDN): | | -Entity ID (FQDN): |
| "strg1.foo.com" | | "strg2.bar.com" |
| -Protocol: iSCSI | | -Protocol: iSCSI |
| | | |
+-------------------------+ +-------------------------+
The object model can be expanded to describe more complex devices,
such as an iSCSI device with more than one storage controller, each
controller accessible through any of multiple Portal interfaces.
The storage controllers on this device can be accessed through
alternate Portal interfaces if any original interface should fail.
The following diagram describes such a device:
Tseng, Gibbons, et al. Standards Track [Page 25]
Internet Storage Name Service (iSNS) January 2003
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL | | PORTAL | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| +-------+ +----------------+ +-------------------+ +------+ |
| | | | | | | |
| +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
| | | | | | | |
| | STORAGE NODE | | STORAGE NODE | | STORAGE NODE | |
| | -iSCSI Name 1 | | -iSCSI Name 2 | | -iSCSI Name 3 | |
| | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| |
| | -Type: target | | -Type: target | | -Type: target | |
| | | | | | | |
| +-----------------+ +-----------------+ +-----------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (FQDN): "dev1.foo.com" |
| -Protocol: iSCSI |
| |
+---------------------------------------------------------------+
5.1.3 Required Commands and Response Messages for Support of iSCSI
The following iSNSP messages and responses are available in support
of iSCSI. Messages indicated in the REQUIRED 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
------------------- ------------ ------- ------ ------
Device Attr Reg Request DevAttrReg 0x0001 * *
Dev Attr Query Request DevAttrQry 0x0002 * *
Dev Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DevDereg 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 * *
DD Deregister DDDereg 0x000A * *
DDS Register DDSReg 0x000B * *
DDS Deregister DDSDereg 0x000C * *
Entity Status Inquiry ESI 0x000D *
Tseng, Gibbons, et al. Standards Track [Page 26]
Internet Storage Name Service (iSNS) January 2003
Name Service Heartbeat Heartbeat 0x000E
RESERVED 0x000F-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x8000
The following are iSNSP response messages used in support of iSCSI:
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
Device Attr Register Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Dereg Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
SCN Deregister Rsp SCNDeregRsp 0x8006 *
SCN Event Rsp SCNEventRsp 0x8007 *
SCN Response SCNRsp 0x8008 *
DD Register Rsp DDRegRsp 0x8009 * *
DD Deregister Rsp DDDeregRsp 0x800A * *
DDS Register Rsp DDSRegRsp 0x800B * *
DDS Deregister Rsp DDSDeregRsp 0x800C * *
Entity Stat Inquiry Rsp ESIRsp 0x800D *
RESERVED 0x800E-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF
5.2 iFCP Requirements
In iFCP, use of iSNS is REQUIRED. No alternatives exist for
support of iFCP Naming & Discovery functions.
5.2.1 Required Attributes for Support of iFCP
The following table displays attributes that are used by iSNS to
support iFCP. Attributes indicated in the REQUIRED 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 7.
REQUIRED REQUIRED
Object Attribute K for Server for
Client
------ --------- - ---------- ---------
-
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address
Timestamp *
Protocol Version Range *
Registration period
Tseng, Gibbons, et al. Standards Track [Page 27]
Internet Storage Name Service (iSNS) January 2003
Entity Index
Entity IKE Phase-1 Proposal
Entity Certificate
PORTAL IP Address * * *
TCP/UDP Port * * *
Symbolic Name *
ESI Interval *
ESI Port *
SCN Port *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
Portal Certificate
Security Bitmap *
STORAGE NODE FC Port Name (WWPN) * * *
(FC Port) Port_ID * *
FC Port Type * *
Port Symbolic Name *
Fabric Port Name (FWWN) *
Hard Address *
Port IP Address *
Class of Service *
FC FC-4 Types *
FC FC-4 Descriptors *
FC FC-4 Features *
SCN Bitmap *
iFCP Port Role *
Permanent Port Name *
Port Certificate
FC DEVICE FC Node Name (WWNN) * * *
(FC Node) Node Symbolic Name *
Node IP Address *
Node IPA *
Node Certificate
Proxy iSCSI Name
DISCOVERY DOMAIN DD_ID * * *
DD_Symbolic Name *
DD 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 *
DDS Member *
OTHER Switch Name
Preferred_ID
Assigned_ID
Virtual_Fabric_ID
Tseng, Gibbons, et al. Standards Track [Page 28]
Internet Storage Name Service (iSNS) January 2003
All iFCP user-specified and vendor-specified attributes are
OPTIONAL to implement and use.
5.2.2 Example iFCP Object Model Diagram
The iFCP protocol allows native Fibre Channel devices or Fibre
Channel fabrics connected to an iFCP gateway to be directly
internetworked using IP.
When supporting iFCP, the iSNS server stores Fibre Channel device
attributes, iFCP gateway attributes, and Fibre Channel fabric
switch attributes that might also be stored in an FC name server.
The following diagram shows a representation of a gateway
supporting multiple Fibre Channel devices behind it. The two
Portal objects represent IP interfaces on the iFCP gateway that can
be used to access any of the three Storage Node objects behind it.
Note that the FC Device object is not contained in the Network
Entity object. However, each FC Device has a relationship to one
or more Storage Node objects.
+--------------------------------------------------------+
| IP Network |
+--------+-----------------+-----------------------------+
| |
+-+------+------+---+------+------+----------------------+
| | PORTAL | | PORTAL | NETWORK ENTITY |
| | -IP Addr 1 | | -IP Addr 2 | -Entity ID (FQDN): |
| | -TCP Port 1 | | -TCP Port 2 | "gtwy1.foo.com" |
| +-----+ +-----+ +-----+ +-----+ -Protocol: iFCP |
| | | | | |
| +-----+ +---------------+ +----------------------+ |
| +-----+ +---------------+ +-------------+ +------+ |
| | | | | | | |
| +-----+ +-----+ +----+ +------+ +----+ +------+ |
| |STORAGE NODE | |STORAGE NODE | |STORAGE NODE | |
| | -WWPN 1 | | -WWPN 2 | | -WWPN 3 | |
| | -Port ID 1 | | -Port ID 2 | | -Port ID 3 | |
| | -FWWN 1 | | -FWWN 2 | | -FWWN 3 | |
| | -FC COS | | -FC COS | | -FC COS | |
| +------+------+ +-------+-----+ +----+--------+ |
+--------|-------------------|------------|--------------+
| | |
+------+------+ +---+------------+---+
| FC DEVICE | | FC DEVICE |
| -WWNN 1 | | -WWNN 2 |
| | | |
+-------------+ +--------------------+
Tseng, Gibbons, et al. Standards Track [Page 29]
Internet Storage Name Service (iSNS) January 2003
5.2.3 Required Commands and Response Messages for Support of iFCP
The iSNSP messages and responses displayed in the following tables
are available to support iFCP gateways. Messages indicated in the
REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server
used by iFCP gateways. Messages indicated in the REQUIRED TO USE
column MUST be supported by the iFCP gateways themselves.
REQUIRED for:
Message Description Abbreviation Func ID Server Client
------------------- ------------ ------- ------ ------
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-0x8000
The following are iSNSP response messages in support of iFCP:
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
Device Attr Reg Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Deregister Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
SCN Deregister Rsp SCNDeregRsp 0x8006 *
SCN Event Rsp SCNEventRsp 0x8007 *
SCN Rsp SCNRsp 0x8008 *
DD Register Rsp DDRegRsp 0x8009 * *
DD Deregister Rsp DDDeregRsp 0x800A * *
DDS Register Rsp DDSRegRsp 0x800B * *
DDS Deregister Rsp DDSDeregRsp 0x800C * *
Entity Status Inquiry Rsp ESIRsp 0x800D *
NOT USED 0x800E
RESERVED 0x800F-0x8010
Tseng, Gibbons, et al. Standards Track [Page 30]
Internet Storage Name Service (iSNS) January 2003
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
6. iSNSP Message Format
The iSNSP message format is similar to the format of other common
protocols such as DHCP, DNS and BOOTP. An iSNSP message may be
sent in one or more iSNS Protocol Data Units (PDU). Each PDU is 4
byte aligned. The following describes the format of the iSNSP PDU:
Byte MSb LSb
Offset 0 15 16 31
+---------------------+----------------------+
0 | iSNSP VERSION | FUNCTION ID | 4 Bytes
+---------------------+----------------------+
4 | PDU LENGTH | FLAGS | 4 Bytes
+---------------------+----------------------+
8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes
+---------------------+----------------------+
12 | |
| PDU PAYLOAD | N Bytes
| ... |
+--------------------------------------------+
12+N | AUTHENTICATION BLOCK (Multicast/Broadcast) | L Bytes
+--------------------------------------------+
Total Length = 12 + N + L
6.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.
6.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.
6.1.2 iSNSP Function ID
The FUNCTION ID defines the type of iSNS message and the operation
to be executed. FUNCTION_ID values with the leading bit cleared
indicate query, registration, and notification messages, while
FUNCTION_ID values with the leading bit set indicate response
messages.
See section 5 under the appropriate protocol (i.e., iSCSI or iFCP)
for a mapping of the FUNCTION_ID value to the iSNSP Command or
Tseng, Gibbons, et al. Standards Track [Page 31]
Internet Storage Name Service (iSNS) January 2003
Response message. All PDU's comprising an iSNSP message must have
the same FUNCTION_ID value.
6.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.
6.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 Means:
------------ -------------
16 Sender is the iSNS client
17 Sender is the iSNS server
18 RESERVED
19 Replace Flag (for DevAttrReg)
20 Last PDU of the iSNS message
21 First PDU of the iSNS message
22-31 RESERVED
6.1.5 iSNSP Transaction ID
The TRANSACTION ID MUST be set to a unique value for each
concurrently outstanding request message. Replies MUST use the
same TRANSACTION ID value as the associated iSNS request message.
If a message is retransmitted, the original TRANSACTION ID value
MUST be used. All PDU's comprising an iSNSP message must have the
same TRANSACTION ID value.
6.1.6 iSNSP Sequence ID
The SEQUENCE ID has a unique value for each PDU within a single
transaction. The SEQUENCE_ID value of the first PDU transmitted in
a given iSNS message MUST be zero (0), and each SEQUENCE_ID value
in each PDU MUST be numbered sequentially in the order that the
PDU's are transmitted. Note that the two-byte SEQUENCE ID allows
for up to 65536 PDU's per iSNS message.
6.2 iSNSP Message Segmentation and Reassembly
iSNS messages may be carried in one or more iSNS PDU's. If only
one iSNS PDU is used to carry the iSNS message, then bit 21 (First
PDU) and bit 20 in the FLAGS field (Last PDU) SHALL both be set.
If multiple PDUs are used to carry the iSNS message, then bit 21
SHALL be set in the first PDU of the message, and bit 20 SHALL be
set in the last PDU.
Tseng, Gibbons, et al. Standards Track [Page 32]
Internet Storage Name Service (iSNS) January 2003
All PDU's comprising the same iSNSP message SHALL have the same
FUNCTION_ID and TRANSACTION_ID values. Each PDU comprising an
iSNSP message SHALL have a unique SEQUENCE_ID value.
6.3 iSNSP PDU Payload
The iSNSP PDU PAYLOAD is variable length and contains attributes
used for registration and query operations. The attribute data
items use a format similar to other protocols, such as DHCP [RFC
2131] options. Each iSNS attribute is specified in the 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
Attribute Tag - a 4-byte field that identifies the attribute as
defined in section 7.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.
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; PDU's may carry one or more TLV's, 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.
6.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
Tseng, Gibbons, et al. Standards Track [Page 33]
Internet Storage Name Service (iSNS) January 2003
is no explicit count of the number of pad bytes provided in the
TLV.
6.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 the
iSNS client for ESI and SCN messages, then this field SHALL contain
a status code of 0 (Successful).
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 And Above RESERVED
6.5 Authentication for iSNS Multicast and Broadcast Messages
For iSNS multicast and broadcast messages (see section 3.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.
If a PKI is available with an X.509 certificate authority, 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-
Tseng, Gibbons, et al. Standards Track [Page 34]
Internet Storage Name Service (iSNS) January 2003
PDU basis. The authentication block contains the following
information:
1. A time stamp, to prevent replay attacks
2. A structured authenticator containing a signature calculated
over the time stamp and the message being secured
3. An indicator of the cryptographic algorithm that was used to
calculate the signature.
4. An indicator of the keying material and algorithm parameters,
used to calculate the signature.
The authentication block is described in the following figure:
Byte MSb LSb
Offset 0 1 2 3 4 5 6 7
+----------------------------------+
0 | BLOCK STRUCTURE DESCRIPTOR | 2 Bytes
+----------------------------------+
2 | AUTHENTICATION BLOCK LENGTH | 2 Bytes
+----------------------------------+
4 | TIMESTAMP | 4 Bytes
+----------------------------------+
8 | SPI STRING LENGTH | 1 Byte
+----------------------------------+
9 | SPI STRING | N Bytes
+----------------------------------+
9 + N | STRUCTURED AUTHENTICATOR | M Bytes
+----------------------------------+
Total Length = 9 + N + M
BLOCK STRUCTURE DESCRIPTOR (BSD) - Defines the structure and
algorithm to use for the STRUCTURED AUTHENTICATOR. Currently, the
only defined value for BSD is 0x0002, which represents DSA with
SHA-1. Details on DSA can be found in [DSS]. BSD values from
0x0000 to 0x7FFF are assigned by IANA, while 0x8000 to 0x8FFF are
for private use. The BSD value 0x0002 is compatible with the X.509
PKI specification, allowing easy integration of the STRUCTURED
AUTHENTICATOR format with an existing PKI infrastructure.
AUTHENTICATION BLOCK LENGTH - Defines the length of the
authentication block, beginning with the BSD field and running
through the last byte of the STRUCTURED AUTHENTICATOR.
TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving
the number of seconds since 00:00:00 GMT on January 1, 1970.
SPI STRING LENGTH - The length of the SPI STRING field.
SPI STRING (Security Parameters Index) - Index to the key and
algorithm used by the message recipient to decode the STRUCTURED
AUTHENTICATOR field.
STRUCTURED AUTHENTICATOR - Contains the digital signature. For the
default BSD value of 0x0002, this field contains the binary ASN.1
Tseng, Gibbons, et al. Standards Track [Page 35]
Internet Storage Name Service (iSNS) January 2003
encoding of output values from the DSA with SHA-1 signature
calculation.
6.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 Tag-Length-Value (TLV) data
format. iSNS Registration and Query messages are sent by iSNS
Clients to 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.
6.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.
Tseng, Gibbons, et al. Standards Track [Page 36]
Internet Storage Name Service (iSNS) January 2003
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.
6.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 6.6.5 and 7.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].
6.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, all containing zeros). If a Message Key is not
required for a message, then the Delimiter Attribute immediately
follows the Source Attribute.
6.6.4 Operating Attributes
The Operating Attributes are a list of one or more key and non-key
attributes related to the actual iSNS registration or query
operation being performed.
Operating Attributes include object key attributes and non-key
attributes. Object key attributes uniquely identify iSNS objects.
The tag value distinguishes the attribute as an object key
attribute (i.e., tag=1, 16&17, 32, 64, and 96) or non-key
attribute. iSCSI Names used in the Operating Attributes MUST be
normalized according to the stringprep template [STRINGPREP].
Tseng, Gibbons, et al. Standards Track [Page 37]
Internet Storage Name Service (iSNS) January 2003
Entity Identifiers (EIDs) used in the Operating Attibutes MUST be
normalized according to the nameprep template [NAMEPREP].
The ordering of Operating Attributes in the message is important in
determining the relationships among objects and their ownership of
non-key attributes. iSNS protocol messages that violate these
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, each and every object key attribute of that object MUST
be listed sequentially by tag value in the message before non-key
attributes of that object, and key attributes of the next object.
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.
Vendor-specific objects defined by tag values in the range 1537-
2048 have the same requirements described above.
6.6.4.1 Operating Attributes for Query and Get Next Requests
In Query and Get Next request messages, TLV attributes with length
value of 0 are used to indicate which Operating Attributes are to
be returned in the corresponding response. Operating Attribute
values that match the TLV attributes in the original message are
returned in the response message.
6.6.5 Registration and Query Request Message Types
The following describes each query and message type.
6.6.5.1 Device Attribute Registration Request (DevAttrReg)
The DevAttrReg message type is 0x0001. The DevAttrReg message
provides 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.
Tseng, Gibbons, et al. Standards Track [Page 38]
Internet Storage Name Service (iSNS) January 2003
The Source Attribute identifies the Node initiating the
registration request.
The Message Key identifies the object that 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 no pre-existing objects match the
Message Key, then the DevAttrReg message SHALL create the new
object(s) as specified by the Operating Attributes.
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.
The replace bit determines the kind of operation conducted on the
object identified in the Message Key. 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 SCN's 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 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 and
subordinate objects. Existing object 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 indicate 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.
Tseng, Gibbons, et al. Standards Track [Page 39]
Internet Storage Name Service (iSNS) January 2003
For example, to establish relationships between a Network Entity
object and its Portal and Storage Node objects, the Operating
Attributes lists 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 to have a subordinate relationship with that Storage
Node.
A maximum of one Network Entity object can be created or updated
with a single DevAttrReg message. Consequently, the Operating
Attributes MUST NOT contain more than one Network Entity object.
There is no limit to the number of Portal, Storage Node, and FC
Device objects that can listed in the Operating Attributes,
provided they are all subordinate to the listed Network Entity
object.
If the Operating Attributes do not contain an EID attribute, or if
the EID attribute has a length of 0, then a new Network Entity
object SHALL be created and the iSNS server SHALL supply a unique
EID value for it. The assigned EID value SHALL be included in the
DevAttrReg Response message. If the Operating Attributes contains
an EID that does not match the EID of an existing Network Entity in
the iSNS database, then a new Network Entity SHALL be created and
assigned the value contained in that EID attribute. Finally, if
the Operating Attributes contains an EID that matches the EID of an
existing object in the iSNS database, then the objects, attributes,
and relationships specified in the Operating Attributes SHALL be
appended to the existing Network Entity identified by the EID.
A registration message that creates a new Network Entity object
MUST contain at least one Portal or one Storage Node. If the
message does not, then it SHALL be considered invalid and result in
a response with Status Code of 3 (Invalid Registration).
Note that the iSNS server may modify or reject the registration of
certain attributes, such as ESI Interval. In addition, the iSNS
server may assign values for additional Operating Attributes that
are not explicitly registered in the original DevAttrReg message,
such as the Portal Group Tag and WWNN Token. The values for such
attributes are returned in the Operating Attributes of the
corresponding DevAttrRegRsp message.
6.6.5.2 Device Attribute Query Request (DevAttrQry)
The DevAttrQry message type is 0x0002. The DevAttrQry message
provides an iSNS client with the means to query the iSNS server for
object attributes.
The Source Attribute identifies the Node initiating the request.
For non-Control Nodes initiating the DevAttrQry message, the query
is scoped to the Discovery Domains that initiating Node is a member
of. The DevAttrQry message SHALL only return information on
Storage Nodes and their related parent and subordinate objects,
Tseng, Gibbons, et al. Standards Track [Page 40]
Internet Storage Name Service (iSNS) January 2003
where the Storage Node has a common Discovery Domain with the Node
identified in the Source Attribute.
The Message Key may contain key or non-key attributes, or no
attributes at all. If multiple attributes are used as the Message
Key, then they MUST all be from the same object type (e.g., IP
address and TCP/UDP Port are attributes of the Portal object type).
A Message Key with non-key attributes may match multiple instances
of the specific object type. A Message Key with zero-length TLV(s)
is scoped to every object of the type indicated by the zero-length
TLV(s). An empty Message Key field indicates the query is scoped
to the entire database accessible by the source Node.
The DevAttrQry response message returns attributes of objects
listed in the Operating Attributes that are related to the Message
Key of the original DevAttrQry message. The Operating Attributes
of the DevAttrQry message contain zero-length TLV's that specify
the attributes that are to be returned in the DevAttrQryRsp
message. A Message Key containing zero-length TLV's indicates that
the set of attributes specified in the Operating Attributes are to
be returned for each object matching the type indicated by the
Message Key.
If the Message Key contains non-zero length TLVs, then Operating
Attributes for the object matching the Message Key SHALL be
returned in the DevAttrQryRsp message. Each attribute type (i.e.,
zero-length TLV) in the Operating Attributes indicates an attribute
from the object matching the Message Key, or other objects related
to the object matching the Message Key, is to be returned in the
response. The ordering of the attributes returned in the
DevAttrQry response message SHALL be the same as in the original
query message. If no objects match the Message Key, then the
DevAttrQryRsp message SHALL NOT return any operating attributes.
Such a message and its corresponding response SHALL NOT be
considered to be an error.
For example, an iSNS database contains an Network Entity having two
Portals and two Nodes. The DevAttrQry message contains a Message
Key entry matching one of the Nodes, and Operating Attributes with
zero-length TLV's listing first the Node attributes, and then
Portal attributes. The response message will therefore return
first the matching Node object's attributes, followed by the
requested attributes of one Portal, and finally requested
attributes of the remaining Portal. The order in which each
Portal's attributes are listed is the same as the ordering of the
Portal attributes in the Operating Attributes of the original
request message. The same applies to the Node's attributes.
If the Message Key Attribute contains zero-length TLV(s), then the
query returns requested attributes for all objects matching the
Message Key type (DD restrictions SHALL apply for non-Control
Nodes). If multiple objects match the Message Key type, then the
attributes for each object matching the Message Key MUST be listed
before the attributes for the next object are listed in the query
Tseng, Gibbons, et al. Standards Track [Page 41]
Internet Storage Name Service (iSNS) January 2003
response. In other words, the process described above must be
iterated in the message response for each object that matches the
Message Key type specified by the zero-length TLV(s).
For example, an iSNS database contains only one Network Entity
having two Portals and three Nodes. In the DevAttrQry message, the
Message Key contains a zero-length TLV specifying a Node type, and
Operating Attributes listing first the Node attributes, and then
the Portal attributes. The response message will return the first
Node attributes, followed by both Portals attributes, and then
attributes for the next Node object followed by those for the same
two Portals, and then finally attributes for the last Node object
followed by those for the same two Portals. If that same
DevAttrQry message had instead contained a zero-length TLV
specifying the Network Entity type, then the response message would
have returned attributes for all three Node objects, followed by
attributes for the two Portals.
If there is no Message Key Attribute, then the query returns all
attributes in the iSNS database (once again, DD restrictions SHALL
apply for non-Control Nodes). All attributes matching the type
specified by each zero-length TLV in the Operating Attributes SHALL
be listed. All attributes of each type SHALL be listed before the
attributes matching the next zero-length TLV are listed.
For example, an iSNS database contains two Entities, each having
two Nodes and two Portals. The DevAttrQry message contains no
Message Key attribute, and Operating Attributes list first the
Portal attributes, and then the Node attributes. The Operating
Attributes of the response message will return attributes from each
of the four Portals, followed by attributes from each of the four
nodes.
If a DevAttrQry message requests an attribute for which the iSNS
server has no value, then the server SHALL NOT return the requested
attribute in the query response. Such query and response messages
SHALL NOT be considered to be in error.
Registration and query messages for iSNS server-specific attributes
(i.e., tags in the range 132 to 384) SHALL be formatted using the
identifying key attribute of the Storage Node originating the query
(i.e., iSCSI Name or FC Port Name WWPN) for both the Source
Attribute and Message Key attribute. Operating Attributes SHALL
include the TLV of the server-specific attribute being requested.
The DevAttrQry message SHALL support the following minimum set of
Message Key Attributes:
Tseng, Gibbons, et al. Standards Track [Page 42]
Internet Storage Name Service (iSNS) January 2003
Valid Message Key Attributes for Queries
----------------------------------------
Entity Identifier
Entity Protocol
Portal IP-Address, Portal TCP/UDP Port
Portal Index
iSCSI Node Type
iSCSI Identifier
FC Port Name WWPN
FC Port Type
FC-4 Type
Discovery Domain ID
Discovery Domain Set ID
Source Attribute (for server-specific attributes)
Switch Name (FC Device WWNN--for Virtual_Fabric_ID queries)
6.6.5.3 Device Get Next Request (DevGetNext)
The DevGetNext message type is 0x0003. This message provides the
iSNS client with the means to retrieve each and every instance of
an object type exactly once.
The Source Attribute identifies the Node initiating the DevGetNext
request, and is used to scope the retrieval process to the
Discovery Domains that the initiating Node is a member of.
The Message Key Attribute may be an Entity Identifier (EID), iSCSI
Name, Portal IP Address and TCP/UDP Port, FC Node Name WWNN, or FC
Port Name WWPN. If the TLV length of the Message Key Attribute(s)
is zero, then the first object entry in the iSNS database matching
the Message Key type SHALL be returned in the Message Key of the
corresponding DevGetNextRsp message. If non-zero-length TLV
attribute(s) is contained in the Message Key, then the DevGetNext
response message SHALL return the next object stored after the
object identified by the Message Key in the original DevGetNext
request message.
If the Message Key provided matches the last object instance in the
iSNS database, then the Status Code of 9 (No Such Entry) SHALL be
returned in the response.
The Operating Attributes can be used specify the scope of the
DevGetNext request, and specify the attributes of the next object
that are to be returned in the DevGetNext response message. All
Operating Attributes MUST be attributes of the object type
identified by the Message Key. For example, if the Message Key is
an Entity_ID attribute, then the Operating Attributes MUST NOT
contain attributes of Portals.
Non-zero-length TLV attributes in the Operating Attributes are used
to scope the DevGetNext message. Only the next object with
attribute values that match the non-zero-length TLV attributes
SHALL be returned in the DevGetNext response message.
Tseng, Gibbons, et al. Standards Track [Page 43]
Internet Storage Name Service (iSNS) January 2003
Zero-length TLV attributes MUST be listed after non-zero-length
attributes in the Operating Attributes of the DevGetNext request
message. Zero-length TLV attributes specify the attributes of the
next object that are to be returned in the DevGetNext response
message.
Note that there are no specific requirements concerning the order
in which object entries are retrieved from the iSNS database; the
retrieval order of object entries using the DevGetNext message is
implementation specific.
The iSNS client is responsible for ensuring that information
acquired through use of the DevGetNext message is accurate and up-
to-date. There is no assurance that the iSNS database will not
change between successive DevGetNext request messages. If the
Message Key provided does not match an existing database entry,
then attributes for the next object key following the Message Key
provided SHALL be returned. For example, an object entry may have
been deleted between successive DevGetNext messages. This may
result in a DevGetNext request where the Message Key does not match
an existing object entry. In this case, attributes for the next
object stored in the iSNS database are returned.
6.6.5.4 Device Deregister Request (DevDereg)
The DevDereg message type is 0x0004. This message is used to
remove object entries from the iSNS database. One or more objects
may be removed through a single DevDereg message.
Upon receiving the DevDereg, the iSNS server removes all objects
identified by the Operating Attribute(s), as well as all associated
subordinate objects of those identified objects. For example,
removal of an Network Entity also results in removal of all
associated Portal, Storage Node, and FC Device objects associated
with that Network Entity.
The DevDereg request PDU Payload contains a Source Attribute and
Operating Attribute(s); there are no Message Key Attributes. If
the Node identified by the Source Attribute is not a Control Node,
then it MUST be from the same Network Entity as the object(s)
identified for removal by the Operating Attribute(s). Valid
Operating Attributes are shown below:
Valid Operating Attributes for DevDereg
---------------------------------------
Entity Identifier
Portal IP-Address, Portal TCP/UDP Port
iSCSI Name
FC Port Name WWPN
FC Node Name WWNN
The removal of the object may result in SCN messages to the
appropriate iSNS clients.
Tseng, Gibbons, et al. Standards Track [Page 44]
Internet Storage Name Service (iSNS) January 2003
Attempted deregistration of non-existeng entries SHALL not be
considered an error.
If all Nodes and Portals associated with a Network Entity are
deregistered, then the Network Entity SHALL also be removed.
6.6.5.5 SCN Register Request (SCNReg)
The SCNReg message type is 0x0005. The State Change Notification
Registration Request (SCNReg) message allows an iSNS client to
register a Storage Node to receive State Change Notification (SCN)
messages.
The SCN notifies the Storage Node of changes to any Storage Nodes
within any DD that it is a member of. If the Storage Node is a
Control Node, it SHALL receive SCN notifications for changes in the
entire network. Note that while SCNReg sets the SCN Bitmap field,
the DevAttrReg message registers the UDP or TCP Port used by each
Portal to receive SCN messages. If no SCN Port fields of any
Portals of the Storage Node are registered to receive SCN messages,
then the SCNReg message SHALL be rejected with Status Code 17 (SCN
Registration Rejected).
The SCNReg request PDU Payload contains a Source Attribute, Message
Key Attribute, and an Operating Attribute. Valid Message Key
Attributes for an SCNReg are shown below:
Valid Message Key Attributes for SCNReg
---------------------------------------
iSCSI Name
FC Port Name WWPN
The node with the iSCSI Name or FC Port Name WWPN attribute that
matches the Message Key in the SCNReg message is registered to
receive SCNs using the specified SCN bitmap. A maximum of one Node
SHALL be registered for each SCNReg message.
The SCN Bitmap is the only operating attribute of this message, and
it always overwrites the previous contents of this field in the
iSNS database. The bitmap indicates the SCN event types for which
the Node is registering.
Note that the settings of this bitmap determine whether the SCN
registration is for regular SCN's or management SCN's. Control
Nodes MAY conduct registrations for management SCN's; iSNS clients
that are not supporting Control Nodes MUST NOT conduct
registrations for management SCNs. Control Nodes that register for
management SCN's receive a copy of every SCN message generated by
the iSNS server. It is recommended that management registrations
be used only where needed in order to conserve iSNS server
resources. In addition, a Control Node that conducts such
registrations should be prepared to receive the anticipated volume
of SCN message traffic.
Tseng, Gibbons, et al. Standards Track [Page 45]
Internet Storage Name Service (iSNS) January 2003
6.6.5.6 SCN Deregister Request (SCNDereg)
The SCNDereg message type is 0x0006. The SCNDereg message allows an
iSNS client to no longer receive State Change Notification (SCN)
messages.
The SCNDereg request message PDU Payload contains a Source
Attribute and Message Key Attribute(s). Valid Message Key
Attributes for an SCNDereg are shown below:
Valid Message Key Attributes for SCNDereg
-----------------------------------------
iSCSI Name
FC Port Name WWPN
The node with an iSCSI Name or FC Port Name WWPN attribute that
matches the Message Key Attributes in the SCNDereg message is
deregistered for SCNs. The SCN bitmap field of such Nodes are
cleared. A maximum of one Node SHALL be deregistered for each
SCNDereg message.
There are no Operating Attributes in the SCNDereg message.
6.6.5.7 SCN Event (SCNEvent)
The SCNEvent message type is 0x0007. The SCNEvent is a message sent
by an iSNS client to request generation of a State Change
Notification (SCN) message by the iSNS server. The SCN, sent by
the iSNS server, then notifies iFCP, iSCSI, and Control Nodes
within the affected DD of the change indicated in the SCNEvent.
Most SCNs are automatically generated by the iSNS server when Nodes
are registered or deregistered from the directory database. SCNs
are also generated when a network management application or Control
Node makes changes to the DD membership in the iSNS server.
However, an iSNS client can trigger an SCN by using SCNEvent.
The SCNEvent message PDU Payload contains a Source Attribute,
Message Key Attribute, and Operating Attribute. Valid Key
Attributes for an SCNEvent are shown below:
Valid Message Key Attributes for SCNEvent
-----------------------------------------
iSCSI Name
FC Port Name WWPN
The Operating Attributes section SHALL contain the SCN Event Bitmap
attribute. The bitmap indicates the event that caused the SCNEvent
to be generated.
6.6.5.8 State Change Notification (SCN)
The SCN message type is 0x0008. The SCN is a message generated by
the iSNS server, notifying a registered Storage Node of changes.
Tseng, Gibbons, et al. Standards Track [Page 46]
Internet Storage Name Service (iSNS) January 2003
There are two types of SCN registrations: regular registrations and
management registrations. Regular SCN's notify iSNS clients of
events within the discovery domain. Management SCN's notify
Control Nodes that register for management SCN's of events
occurring anywhere in the network.
If no active TCP connection exists to the SCN recipient, then the
SCN message SHALL be sent to one Portal of the registered Storage
Node that has a registered TCP or UDP Port value in the SCN Port
field. If more than one Portal of the Storage Node has a registered
SCN Port value, then the SCN SHALL be delivered to any one of the
indicated Portals, provided that the selected Portal is not the
subject of the SCN.
The types of events that can trigger an SCN message, and the amount
of information contained in the SCN message, depend on the
registered SCN Event Bitmap for the Storage Node.
The format of the SCN PDU Payload is shown below:
+----------------------------------------+
| Destination Attribute |
+----------------------------------------+
| Timestamp |
+----------------------------------------+
| Source SCN Bitmap 1 |
+----------------------------------------+
| Source Attribute [1] |
+----------------------------------------+
| Source Attribute [2](if present) |
+----------------------------------------+
| Source Attribute [3](if present)_ |
+----------------------------------------+
| Source Attribute [n](if present) |
+----------------------------------------+
| Source SCN Bitmap 2 (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
All PDU Payload attributes are in TLV format.
The Destination Attribute is the Node identifier that is receiving
the SCN. The Destination Attribute can be an iSCSI Name, or FC
Port Name.
The Timestamp field, using the Timestamp TLV format, indicates the
time the SCN was generated.
The Source SCN Bitmap field indicates the type of SCN notification
(i.e., regular or management SCN), and the type of event that
caused the SCN to be generated; it does not necessarily correlate
with the original SCN bitmap registered in the iSNS server.
Tseng, Gibbons, et al. Standards Track [Page 47]
Internet Storage Name Service (iSNS) January 2003
Following the timestamp, the SCN message SHALL list the SCN bitmap,
followed by the key attribute (i.e., iSCSI Name or FC Port Name) of
the Storage Node affected by the SCN event. If the SCN is a
Management SCN, then the SCN message SHALL also list the DD_ID
and/or DDS_ID of the Discovery Domains and Discovery Domain Sets
(if any) that caused the change in state for that Storage Node.
These additional attributes (i.e., DD_ID and/or DDS_ID) shall
immediately follow the iSCSI Name or FC Port Name and precede the
next SCN bitmap for the next notification message (if any). The
SCN bitmap is used as a delineator for SCN messages providing
multiple state change notifications.
For example, a regular SCN to notify an iSNS client of a new Portal
available for a particular iSCSI target would contain the SCN
bitmap followed by the iSCSI Name of the target device as the
source attribute. If the SCN were a management SCN, then the iSCSI
Name would be followed by the DD_ID(s) of the shared Discovery
Domains that allow the destination Storage Node to have visibility
to the affected Storage Node. If a Discovery Domain Set (DDS) was
enabled in order to provide this visibility, then the appropriate
DDS_ID would be included as well.
A management SCN is also generated to notify a Control Node of the
creation, deletion, or modification of a Discovery Domain or
Discovery Domain Set. In this case, the DD_ID and/or DDS_ID of the
affected Discovery Domain and/or Discovery Domain Set would follow
the SCN bitmap.
For example, a management SCN to notify a Control Node of a new DD
within a Discovery Domain Set would contain both the DD_ID and the
DDS_ID of the affected Discovery Domain and Discovery Domain Set
among the Source Attributes.
See sections 7.4.4 and 7.5.12 for additional information on the SCN
Bitmap.
6.6.5.9 DD Register (DDReg)
The DDReg message type is 0x0009. This message is used to create a
new Discovery Domain (DD), update an existing DD Symbolic Name, and
add DD members.
DDs are uniquely defined using DD_IDs. DD registration attributes
are described in section 7.10.
The DDReg message PDU Payload contains the Source Attribute and
optionally, Message Key and Operating Attributes.
A DDReg message with no Message Key Attribute results in creation
of a new Discovery Domain (DD). If the DD_ID attribute (with non-
zero length) is included among the Operating Attributes in the
DDReg message, then the new Discovery Domain SHALL be assigned the
value contained in that DD_ID attribute. Otherwise, if the DD_ID
attribute is not contained among the Operating Attributes of the
Tseng, Gibbons, et al. Standards Track [Page 48]
Internet Storage Name Service (iSNS) January 2003
DDReg message, or if the DD_ID is an operating attribute with TLV
length of 0, then the iSNS server SHALL assign the DD_ID value that
is returned in the DDReg Response message.
The Operating Attributes can contain the iSCSI Node Index, iSCSI
Node Identifier, FC Port Name, Portal IP Address, Portal TCP/UDP
Port Number, or Portal Index of members to be added to the DD. It
may also contain the DD_Symbolic_Name of the DD.
This message SHALL add any DD members listed as Operating
Attributes to the Discovery Domain specified by the DD_ID. In
addition, if the DD_Symbolic_Name is an operating attribute, then
it SHALL be stored in the iSNS database as the DD_Symbolic_Name for
the specified Discovery Domain.
6.6.5.10 DD Deregister (DDDereg)
The DDDereg message type is 0x000A. This message allows an iSNS
client to deregister an existing Discovery Domain (DD) and remove
members from an existing DD.
DDs are uniquely identified using DD_IDs. DD registration
attributes are described in section 7.10.
The DDDereg message PDU Payload contains a Source Attribute,
Message Key Attribute, and Operating Attributes.
The Message Key Attribute for a DDDereg message is the DD ID for
the Discovery Domain being removed, or having members removed. If
the DD ID matches an existing DD, and there are no Operating
Attributes, then the DD SHALL be removed and a success Status Code
returned.
If the DD ID matches an existing DD, and there are Operating
Attributes matching DD members, then the DD members identified by
the Operating Attributes SHALL be removed from the DD and a
successful Status Code returned.
The attempted deregistration of non-existent DD entries SHALL not
be considered an error.
6.6.5.11 DDS Register (DDSReg)
The DDSReg message type is 0x000B. This message allows an iSNS
client to create a new Discovery Domain Set (DDS), update an
existing DDS Symbolic Name, or add DDS members.
DDSs are uniquely defined using DDS_IDs. DDS registration
attributes are described in section 7.10.1.
The DDSReg message PDU Payload contains the Source Attribute, and
optionally, Message Key and Operating Attributes.
Tseng, Gibbons, et al. Standards Track [Page 49]
Internet Storage Name Service (iSNS) January 2003
A DDSReg message with no Message Key Attribute results in creation
of a new Discovery Domain Set (DDS). If the DDS_ID attribute (with
non-zero length) is included among the Operating Attributes in the
DDSReg message, then the new Discovery Domain Set SHALL be assigned
the value contained in that DDS_ID attribute. Otherwise, if the
DDS_ID attribute is not contained among the Operating Attributes of
the DDSReg message, or if the DDS_ID is an operating attribute with
TLV length of 0, then the iSNS server SHALL assign the DDS_ID value
that is returned in the DDSReg Response message.
The Operating Attributes can contain the DDS_Symbolic_Name and the
DD_IDs of Discovery Domains to be added to the DDS.
This message SHALL add any DDS members listed as Operating
Attributes to the Discovery Domain Set specified by the DDS_ID
Message Key Attribute. In addition, if the DDS_Symbolic_Name is an
operating attribute, then it SHALL be stored in the iSNS database
as the DDS_Symbolic_Name for the specified Discovery Domain Set.
6.6.5.12 DDS Deregister (DDSDereg)
The DDSDereg message type is 0x000C. This message allows an iSNS
client to deregister an existing Discovery Domain Set (DDS) or
remove some DDs from an existing DDS.
The DDSDereg message PDU Payload contains a Source Attribute,
Message Key Attribute, and Operating Attributes.
The Message Key Attribute for a DDSDereg message is the DDS ID for
the set being removed, or having members removed. If the DDS ID
matches an existing DDS, and there are no Operating Attributes,
then the DDS SHALL be removed and a success Status Code returned.
If the DDS ID matches an existing DDS, and there are Operating
Attributes matching DDS members, then the DDS members SHALL be
removed from the DDS and a success Status Code returned.
The attempted deregistration of non-existent DDS entries SHALL not
be considered an error.
6.6.5.13 Entity Status Inquiry (ESI)
The ESI message type is 0x000D. This message is sent by the iSNS
server, and is used to verify that an iSNS client Portal is
reachable and available. The ESI message is sent to the ESI UDP
port provided during registration, or the TCP connection used for
ESI registration, depending on which communication type that is
being used.
The ESI message PDU Payload contains the following attributes in
TLV format and in the order listed: the current iSNS timestamp, the
EID, the Portal IP Address, and the Portal TCP/UDP Port. The
format of this message is shown below:
Tseng, Gibbons, et al. Standards Track [Page 50]
Internet Storage Name Service (iSNS) January 2003
+----------------------------------------+
| Timestamp |
+----------------------------------------+
| Entity_ID |
+----------------------------------------+
| Portal IP Address |
+----------------------------------------+
| Portal TCP/UDP Port |
+----------------------------------------+
The ESI response message PDU Payload echos the Attributes from the
original ESI message back to the server.
If the Portal fails to respond to an administratively-determined
number of consecutive ESI messages, then the iSNS server SHALL
remove that Portal from the iSNS database. If there are no other
remaining ESI monitored Portals for the associated Network Entity,
then the Network Entity SHALL also be removed. The appropriate
State Change Notifications, if any, SHALL be triggered.
6.6.5.14 Name Service Heartbeat (Heartbeat)
This message, if used, is only sent by the active iSNS server. It
allows iSNS clients and backup servers listening to a broadcast or
multicast address to discover the IP address of the primary and
backup iSNS servers. It also allows concerned parties to monitor
the health and status of the primary iSNS server.
This message is NOT in TLV format. There is no response message to
the Name Service Heartbeat.
Tseng, Gibbons, et al. Standards Track [Page 51]
Internet Storage Name Service (iSNS) January 2003
MSb LSb
0 31
+------------------------------------------------+
| Active Server IP-Address |
+------------------------------------------------+
| iSNS TCP Port | iSNS UDP Port |
+------------------------------------------------+
| Interval |
+------------------------------------------------+
| Counter |
+------------------------------------------------+
| RESERVED | Backup Servers |
+------------------------------------------------+
| Primary Backup Server IP Address(if any) |
+------------------------------------------------+
|Backup TCP Port(if any)|Backup UDP Port(if any) |
+------------------------------------------------+
| 2nd Backup Server IP Address(if any) |
+------------------------------------------------+
|Backup TCP Port(if any)|Backup UDP Port(if any) |
+------------------------------------------------+
| . . . |
+------------------------------------------------+
| VENDOR SPECIFIC |
+------------------------------------------------+
The heartbeat PDU Payload contains:
Active Server IP-Address: the IP_Address of the active iSNS server
in IPv6 format.
Active TCP Port: the TCP Port of the server currently in use
Active UDP Port: the UDP Port of the server currently in use,
otherwise 0
Interval: the interval, in seconds, of the heartbeat
Counter: a monotonically incrementing count of heartbeats sent
Backup Servers: the number of iSNS backup servers. The IP address,
TCP Port, and UDP Port of each iSNS backup server follow this
field. Note that if backup servers are used, then the active iSNS
server SHOULD list be among the list of backup servers.
The content of the remainder of this message after the list of
backup servers is vendor-specific. Vendors may use additional
fields to coordinate between multiple iSNS servers, and/or to
identify vendor specific features.
6.6.5.15 Request FC_DOMAIN_ID (RqstDomId)
The RqstDomId message type is 0x0011. This message is used for iFCP
Transparent Mode to allocate non-overlapping FC_DOMAIN_ID values
Tseng, Gibbons, et al. Standards Track [Page 52]
Internet Storage Name Service (iSNS) January 2003
between 1 and 239. The iSNS server becomes the address assignment
authority for the entire iFCP fabric. To obtain multiple
FC_DOMAIN_ID values, this request must be repeated multiple times
to the iSNS server. iSNS clients that acquire FC_DOMAIN_ID values
from an iSNS server MUST register for ESI monitoring from that iSNS
server.
The RqstDomId PDU Payload contains three TLV attributes in the
following order: the requesting Switch Name (WWN) as the Source
Attribute, the Virtual_Fabric_ID as the Message Key Attribute, and
Preferred ID as the operating attribute. The Virtual_Fabric_ID is a
string identifying the domain space for which the iSNS server SHALL
allocate non-overlapping integer FC_DOMAIN_ID values between 1 and
239. The Preferred_ID is the nominal FC_DOMAIN_ID value requested
by the iSNS client. If the Preferred_ID value is available and has
not been already allocated for the Virtual_Fabric_ID specified in
the message, the iSNS server SHALL return the requested
Preferred_ID value as the Assigned_ID to the requesting client.
The RqstDomId response contains a Status Code, and the TLV
attribute Assigned ID, which contains the integer value in the
space requested. If no further unallocated values are available
from this space, the iSNS server SHALL respond with the Status Code
18 "FC_DOMAIN_ID not available".
Once a FC_DOMAIN_ID value has been allocated to an iSNS client by
the iSNS server for a given Virtual_Fabric_ID, that FC_DOMAIN_ID
value SHALL NOT be reused until it has been deallocated, or until
ESI monitoring detects that the iSNS client no longer exists on the
network and objects for that client are removed from the iSNS
database.
The iSNS server and client SHALL use TCP to transmit and receive
RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
6.6.5.16 Release FC_DOMAIN_ID (RlseDomId)
The RlseDomId message type is 0x0012. This message may be used by
iFCP Transparent Mode to release integer identifier values used to
assign 3-byte Fibre Channel PORT_ID values.
The RlseDomId message contains three TLV attributes in the
following order: the requesting EID as the Source Attribute, the
Virtual_Fabric_ID as the Message Key Attribute, and Assigned_ID as
the operating attribute. Upon receiving the RlseDomId message, the
iSNS server SHALL deallocate the FC_DOMAIN_ID value contained in
the Assigned_ID attribute for the Virtual_Fabric_ID attribute
specified. Upon deallocation, that FC_DOMAIN_ID value can now be
requested by, and assigned to, a different iSNS client.
The iSNS server and client SHALL use TCP to transmit and receive
RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
Tseng, Gibbons, et al. Standards Track [Page 53]
Internet Storage Name Service (iSNS) January 2003
6.6.5.17 Get FC_DOMAIN_IDs (GetDomId)
The GetDomId message type is 0x0013. This message is used to learn
the currently-allocated FC_DOMAIN_ID values for a given
Virtual_Fabric_ID.
The GetDomId message PDU Payload contains a Source Attribute and
Message Key Attribute.
The Message Key Attribute for the GetDomId message is the
Virtual_Fabric_ID. The response to this message returns all of the
FC_DOMAIN_ID values that have been allocated for the
Virtual_Fabric_ID specified.
6.7 Response Messages
The iSNSP response message PDU Payloads contain a Status Code,
followed by a list of attributes, and have the following format:
MSb LSb
0 31
+----------------------------------------+
| 4-byte STATUS CODE |
+----------------------------------------+
| Message Key Attribute[1] (if present) |
+----------------------------------------+
| Message Key Attribute[2] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| - Delimiter Attribute - (if present) |
+----------------------------------------+
| Operating Attribute[1] (if present) |
+----------------------------------------+
| Operating Attribute[2] (if present) |
+----------------------------------------+
| Operating Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
The iSNSP Response messages SHALL be sent to the iSNS Client IP
Address and the originating TCP/UDP Port that was used for the
associated registration and query message.
6.7.1 Status Code
The first field in an iSNSP response message PDU Payload is the
Status Code for the operation that was performed. The Status Code
encoding is defined in section 6.4.
Tseng, Gibbons, et al. Standards Track [Page 54]
Internet Storage Name Service (iSNS) January 2003
6.7.2 Message Key Attributes in Response
Depending on the specific iSNSP request, the response message MAY
contain Message Key Attributes. Message Key Attributes generally
contain the interesting key attributes that are affected by the
operation specified in the original iSNS registration or query
message.
6.7.3 Delimiter Attribute in Response
The Delimiter Attribute separates the key and Operating Attributes
in a response message, if they exist. The Delimiter Attribute has
a tag value of 0 and a length value of 0. The Delimiter Attribute
is effectively 8 Bytes long, a 4 Byte tag containing 0x00000000,
and a 4 Byte length field containing 0x00000000.
6.7.4 Operating Attributes in Response
The Operating Attributes in a response are the results related to
the iSNS registration or query operation being performed. Some
response messages will not have Operating Attributes.
6.7.5 Registration and Query Response Message Types
The following describes each query and message type.
6.7.5.1 Device Attribute Registration Response (DevAttrRegRsp)
The DevAttrRegRsp message type is 0x8001. The DevAttrRegRsp
message contains the results for the DevAttrReg message with the
same TRANSACTION ID.
The Message Key in the DevAttrRegRsp message SHALL return the
Message Key in the original registration message. If the iSNS
server assigned the Entity Identifier for a Network Entity, then
the Message Key Attribute field SHALL contain the assigned Entity
Identifier.
The Operating Attributes of the DevAttrRegRsp message contain the
affected objects and attributes that have been modified or added by
the iSNS server. These attributes include key and non-key
attributes identifying the object and the modified or added
attribute. Among the Operating Attributes, each modified or added
non-key attribute SHALL be listed following its key attribute.
For example, three Portals are registered in the original
DevAttrReg request message. Due to lack of resources, the iSNS
server needs to modify the registered ESI Interval value of one of
those Portals. To accomplish this, the iSNS server returns the key
attributes identifying the Portal, followed by the non-key modified
ESI Interval attribute value, as Operating Attributes of the
corresponding DevAttrRegRsp message.
Tseng, Gibbons, et al. Standards Track [Page 55]
Internet Storage Name Service (iSNS) January 2003
If the iSNS server rejects a registration due to invalid attribute
values or types, then the indicated status code SHALL be 3 (invalid
registration). If this occurs, then the iSNS server MAY include
the list of invalid attributes in the Operating Attributes of the
DevAttrRsp message.
Some attributes values (e.g., ESI Interval, Registration Period) in
the original registration message MAY be modified by the iSNS
server. This can occur only for a limited set of attribute types,
as indicated in the table in section 7.1. When this occurs, the
registration SHALL be considered a success (with status code 0),
and the changed value(s) indicated in the Operating Attributes of
the DevAttrRsp message.
6.7.5.2 Device Attribute Query Response (DevAttrQryRsp)
The DevAttrQryRsp message type is 0x8002. The DevAttrQryRsp
message contains the results for the DevAttrQry message with the
same TRANSACTION ID.
The Message Key in the DevAttrQryRsp message SHALL return the
Message Key in the original query message.
If no Operating Attributes are included in the original query, then
all Operating Attributes SHALL be returned in the response.
For a successful query result, the DevAttrQryRsp Operating
Attributes SHALL contain the results of the original DevAttrQry
message.
6.7.5.3 Device Get Next Response (DevGetNextRsp)
The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message
contains the results for the DevGetNext message with the same
TRANSACTION ID.
The Message Key Attribute field returns the object keys for the
next object after the Message Key Attribute in the original
DevGetNext message.
The Operating Attribute field returns the Operating Attributes of
the next object as requested in the original DevGetNext message.
The values of the Operating Attributes are those associated with
the object identified by the Message Key Attribute field of the
DevGetNextRsp message.
6.7.5.4 Deregister Device Response (DevDeregRsp)
The DevDeregRsp message type is 0x8004. This message is the
response to the DevDereg request message.
This message response does not contain a Message Key, but MAY
contain Operating Attributes.
Tseng, Gibbons, et al. Standards Track [Page 56]
Internet Storage Name Service (iSNS) January 2003
In the event of an error, this response message contains the
appropriate status code as well as a list of objects from the
original DevDereg message that were not successfully deregistered
from the iSNS database. This list of objects is contained in the
Operating Attributes of the DevDeregRsp message. Note that an
attempted deregistration of a non-existent object does not
constitute an error, and non-existent entries SHALL not be returned
in the DevDeregRsp message.
6.7.5.5 SCN Register Response (SCNRegRsp)
The SCNRegRsp message type is 0x8005. This message is the response
to the SCNReg request message.
The SCNRegRsp message does not contain any Message Key or Operating
Attributes.
6.7.5.6 SCN Deregister Response (SCNDeregRsp)
The SCNDeregRsp message type is 0x8006. This message is the
response to the SCNDereg request message.
The SCNDeregRsp message does not contain any Message Key or
Operating Attributes.
6.7.5.7 SCN Event Response (SCNEventRsp)
The SCNEventRsp message type is 0x8007. This message is the
response to the SCNEvent request message.
The SCNEventRsp message does not contain any Message Key or
Operating Attributes.
6.7.5.8 SCN Response (SCNRsp)
The SCNRsp message type is 0x8008. This message is sent by an iSNS
client, and provides confirmation that the SCN message was received
and processed.
The SCNRsp response contains the SCN Destination Attribute
representing the Node identifier that received the SCN.
6.7.5.9 DD Register Response (DDRegRsp)
The DDRegRsp message type is 0x8009. This message is the response
to the DDReg request message.
The Message Key in the DDRegRsp message SHALL return the Message
Key in the original query message.
If successful, the DD ID of the DD created or updated during the
DDReg operation SHALL be returned as an operating attribute of the
message.
Tseng, Gibbons, et al. Standards Track [Page 57]
Internet Storage Name Service (iSNS) January 2003
6.7.5.10 DD Deregister Response (DDDeregRsp)
The DDDeregRsp message type is 0x800A. This message is the
response to the DDDereg request message.
The DDDeregRsp message does not contain any Message Key or
Operating Attributes.
6.7.5.11 DDS Register Response (DDSRegRsp)
The DDSRegRsp message type is 0x800B. This message is the response
to the DDSReg request message.
The Message Key in the DDSRegRsp message SHALL return the Message
Key in the original query message.
If successful, the DDS ID of the DDS created or updated during the
DDSReg operation SHALL be returned as an operating attribute of the
message.
6.7.5.12 DDS Deregister Response (DDSDeregRsp)
The DDSDeregRsp message type is 0x800C. This message is the
response to the DDSDereg request message.
The DDSDeregRsp message does not contain any Message Key or
Operating Attributes.
6.7.5.13 Entity Status Inquiry Response (ESIRsp)
The ESIRsp message type is 0x800D. This message is sent by an iSNS
client, and provides confirmation that the ESI message was received
and processed.
The ESIRsp response message PDU Payload contains the attributes
from the original ESI message. These attributes represent the
Portal that is responding to the ESI. The ESIRsp Attributes are in
the order they were provided in the original ESI message.
Upon receiving the ESIRsp from the iSNS client, the iSNS server
SHALL update the timestamp attribute for that Network Entity and
Portal.
6.7.5.14 Request FC_DOMAIN_ID Response (RqstDomIdRsp)
The RqstDomIdRsp message type is 0x8011. This message provides the
response for RqstDomId.
The RqstDomId response contains a Status Code and the TLV attribute
Assigned ID, which contains the integer value in the space
requested. If no further unallocated values are available from this
space, the iSNS server SHALL respond with the Status Code 19
"FC_DOMAIN_ID not available".
Tseng, Gibbons, et al. Standards Track [Page 58]
Internet Storage Name Service (iSNS) January 2003
Once a FC_DOMAIN_ID value is allocated by the iSNS server, it SHALL
not be reused until it has been deallocated by the iSNS client to
which the value was assigned, or the ESI message detects that the
iSNS client no longer exists on the network.
The iSNS server and client SHALL use TCP to transmit and receive
RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
6.7.5.15 Release FC_DOMAIN_ID Response (RlseDomIdRsp)
The RlseDomIdRsp message type is 0x8012. This message provides the
response for RlseDomId. The response contains an Error indicating
if the request was successful or not. If the Assigned_ID value in
the original RlseDomId message is not allocated, then the iSNS
server SHALL respond with this message using the Status Code 20
"FC_DOMAIN_ID not allocated".
The iSNS server and client SHALL use TCP to transmit and receive
RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
6.7.5.16 Get FC_DOMAIN_IDs Response (GetDomIdRsp)
The GetDomIdRsp message type is 0x8013. This message is used
determine which FC_DOMAIN_ID values have been allocated for the
Virtual_Fabric_ID specified in the original GetDomId request
message.
The GetDomId response message PDU Payload contains an Status Code
indicating if the request was successful, and a list of the
Assigned IDs from the space requested. The Assigned_ID attributes
are listed in TLV format.
6.8 Vendor Specific Messages
Vendor-specific iSNSP messages have a functional ID of between
0x0100 and 0x01FF, while vendor-specific responses have a
functional ID of between 0x8100 and 0x81FF. The first Message Key
Attribute in a vendor-specific message SHALL be the company OUI
(tag=256) identifying original creator of the proprietary iSNSP
message. The contents of the remainder of the message are vendor-
specific.
7. iSNS Attributes
Attributes can be stored in the iSNS server using iSNSP
registration messages, and they can be retrieved using iSNSP query
messages. Unless otherwise indicated, these attributes are
supplied by iSNS clients using iSNSP registration messages.
Tseng, Gibbons, et al. Standards Track [Page 59]
Internet Storage Name Service (iSNS) January 2003
7.1 iSNS Attribute Summary
The complete registry of iSNS attributes is maintained by IANA, and
the following table summarizes the initial set of iSNS attributes
available at time of publication of this document.
T Attributes Length Tag Reg Key Query Key
- ---------- ------ --- ------- ---------
Delimiter 0 0 N/A N/A
^ Entity Identifier (EID) 0-256 1 1 1|2|16,17|32|64
& Entity Protocol 4 2 1 1|2|16,17|32|64
Management IP Address 16 3 1 1|2|16,17|32|64
= Timestamp 8 4 1 1|2|16,17|32|64
Protocol Version Range 4 5 1 1|2|16,17|32|64
~ Registration Period 4 6 1 1|2|16,17|32|64
Entity Index 4 7 1 1|2|16,17|32|64
@ Entity Next Index 4 8 -- 1|2|16,17|32|64
Entity ISAKMP Phase-1 var 11 1 1|2|16,17|32|64
* Entity Certificate var 12 1 1|2|16,17|32|64
# Portal IP Address 16 16 1 1|16,17|32|64
$ Portal TCP/UDP Port 4 17 1 1|16,17|32|64
Portal Symbolic Name 0-256 18 16,17 1|16,17|32|64
~ ESI Interval 4 19 16,17 1|16,17|32|64
ESI Port 4 20 16,17 1|16,17|32|64
Portal Group Tag 4 21 16,17 1|16,17|32|64
Portal Index 4 22 16,17 1|16,17|32|64
SCN Port 4 23 16,17 1|16,17|32|64
@ Portal Next Index 4 24 ----- 1|16,17|32|64
Portal Security Bitmap 4 27 16,17 1|16,17|32|64
* Portal ISAKMP Phase-1 var 28 16,17 1|16,17|32|64
* Portal ISAKMP Phase-2 var 29 16,17 1|16,17|32|64
* Portal Certificate var 31 16,17 1|16,17|32|64
# iSCSI Name 0-256 32 1% 1|16,17|32|33
& iSCSI Node Type 4 33 32 1|16,17|32
iSCSI Alias 0-256 34 32 1|16,17|32
iSCSI SCN Bitmap 4 35 32 1|16,17|32
iSCSI Node Index 4 36 32 1|16,17|32
WWNN Token 8 37 32 1|16,17|32
@ iSCSI Node Next Index 4 38 -- 1|16,17|32
iSCSI AuthMethod var 42 32 1|16,17|32
* iSCSI Node Certificate var 43 32 1|16,17|32
# FC Port Name WWPN 8 64 1%
1|16,17|64|66|96|128
Port ID 4 65 64 1|16,17|64
FC Port Type 4 66 64 1|16,17|64
Symbolic Port Name 0-256 67 64 1|16,17|64
Fabric Port Name 8 68 64 1|16,17|64
Hard Address 4 69 64 1|16,17|64
Port IP-Address 16 70 64 1|16,17|64
Class of Service 4 71 64 1|16,17|64
FC-4 Types 32 72 64 1|16,17|64
FC-4 Descriptor 0-256 73 64 1|16,17|64
FC-4 Features 128 74 64 1|16,17|64
iFCP SCN bitmap 4 75 64 1|16,17|64
Tseng, Gibbons, et al. Standards Track [Page 60]
Internet Storage Name Service (iSNS) January 2003
Port Role 4 76 64 1|16,17|64
Permanent Port Name 8 77 Qry Only 1|16,17|64
* Port Certificate var 83 64 1|16,17|64
FC-4 Type Code 4 95 Query Key Only
# FC Node Name WWNN 8 96 64 1|16,17|64|96
Symbolic Node Name 0-256 97 96 64|96
Node IP-Address 16 98 96 64|96
Node IPA 8 99 96 64|96
* Node Certificate var 100 96 64|96
Proxy iSCSI Name 0-256 101 96 64|96
Switch Name 8 128 128
Preferred ID 4 129 128 128
Assigned ID 4 130 128 128
Virtual_Fabric_ID 0-256 131 128 128
RESERVED--server-specific 132-255 SOURCE SOURCE Attribute
iSNS Server Vendor OUI 4 256 ------ SOURCE Attribute
* Vendor-Spec iSNS Srvr var 257-384 SOURCE SOURCE Attribute
* Vendor-Spec Entity var 385-512 1 1|2|16,17|32|64
* Vendor-Spec Portal var 513-640 16,17 1|16,17|32|64
* Vendor-Spec iSCSI Node var 641-768 32 16,17|32
* Vendor-Spec FC Port Name var 769-896 64 1|16,17|64
* Vendor-Spec FC Node Name var 897-1024 96 64|96
* Vendor-Specific DDS var 1025-1280 2049 2049
* Vendor-Specific DD var 1281-1536 2065 2065
* Other Vendor-Specific var 1537-2048 vendor-defined
DD_Set ID 4 2049 @
1|32|64|2049|2065
DD_Set Sym Name 4-256 2050 2049 2049
DD_Set Status 4 2051 2049 2049
RESERVED 2052-2064
+ DD_ID 4 2065 @|2049
1|32|64|2049|2065
DD_Symbolic Name 4-256 2066 2065 2065
DD_Member iSCSI Index 4 2067 2065 2065
DD_Member iSCSI Node 0-256 2068 2065 2065
DD_Member iFCP Node 8 2069 2065 2065
DD Member Portal Index 4 2070 2065 2065
DD_Member Portal IP Addr 16 2071 2065 2065
DD Member Portal TCP/UDP 4 2072 2065 2065
RESERVED 2073-2077
DD_Features 4 2078 2065 2065
RESERVED 2079-65535
The following is a description of the columns used in the above
table:
Length - indicates the attribute length in bytes. Variable-length
identifiers are NULL-terminated (NULL is included in the length).
Tag - the IANA-assigned integer tag value used to identify the
attribute. All undefined tag values are reserved.
Reg Key - indicates the tag values for the object key in DevAttrReg
messages for registering a new attribute value in the database.
Tseng, Gibbons, et al. Standards Track [Page 61]
Internet Storage Name Service (iSNS) January 2003
These tags represent attributes defined as object keys in Section
5.
Query Key - indicates the possible tag values for the Message Key
and object key that used in the DevAttrQry messages for retrieving
a stored value from the iSNS database.
Attribute Type (T)
--------------------------------------------------------------
# : Required key for object registration
^ : Required key for object registration, unique value is
assigned by the iSNS server if value not provided during
initial
registration.
$ : Required as part of the key.
& : Attribute required during initial registration.
* : Optional to implement.
= : Cannot be used as a query key or be explicitly registered.
This
value is provided by the iSNS server.
| : used to separate the different sets of possible keys in the
table.
% : If an iSCSI Name or FC Port Name WWPN is registered without
an EID key, then an Network Entity SHALL be created and an EID
assigned. The assigned EID SHALL be returned in the response
as an Operating attribute.
+ : A DD ID is placed into a DD_Set by using the DD_Set ID
as the object key attribute.
~ : Indicates that the attribute value indicated in the
registration
may be modified by the iSNS server. The modified value SHALL
be
indicated in the registration response message.
@ : Virtual field which can only be queried. It is illegal to
register a value for this attribute.
7.2 Entity Identifier-Keyed Attributes
The following attributes are stored in the iSNS server using the
Entity Identifier attribute as the key.
7.2.1 Entity Identifier (EID)
The Entity Identifier (EID) is variable-length UTF-8 encoded NULL-
terminated text-based description for a Network Entity. This key
attribute uniquely identifies each Network Entity registered in the
iSNS server. The attribute length varies from 4 to 256 bytes
(including the NULL termination), and is a unique value within the
iSNS server.
If the iSNS client does not provide an EID during registration the
iSNS server SHALL generate one that is unique within the iSNS
database. If an EID is to be generated, then the EID attribute
Tseng, Gibbons, et al. Standards Track [Page 62]
Internet Storage Name Service (iSNS) January 2003
value in the registration message SHALL be empty (0 length). The
generated EID SHALL be returned in the registration response.
In environments where the iSNS server is integrated with a DNS
infrastructure, the Entity Identifier may be used to store the
Fully Qualified Domain Name (FQDN) of the iSCSI or iFCP device.
FQDN's of greater than 255 bytes MUST NOT be used.
If FQDN's are not used, the iSNS server can be used to generate
EIDs. EIDs generated by the iSNS server MUST begin with the string
"isns:". iSNS clients MUST NOT generate and register EIDs
beginning with the string "isns:".
This field MUST be normalized according to the nameprep template
[NAMEPREP] before it is stored in the iSNS database.
7.2.2 Entity Protocol
Entity Protocol is a required 4-byte integer attribute that
indicates the block storage protocol used by the registered NETWORK
ENTITY. Values used for this attribute are assigned and maintained
by IANA. The initial set of protocols supported by iSNS is as
follows:
Value Entity Protocol Type
----- --------------------
1 No Protocol
2 iSCSI
3 iFCP
All Others To be assigned by IANA
'No Protocol' is used to indicate that the Network Entity does not
support an IP block storage protocol. A Control Node or monitoring
Node would likely (but not necessarily) use this value.
7.2.3 Management IP Address
This field contains the IP Address used to manage the Network
Entity and all Storage Nodes contained therein through SNMP
[RFC1157] [iSNSMIB]. Some implementations MAY also use this IP
address to support vendor-specific proprietary management
protocols. The Management IP Address is a 16-byte field that may
contain a IPv4 or IPv6 address. When this field contains an IPv4
value, it is stored as an IPv4-mapped IPv6 address. That is, the
most significant 10 bytes are set to 0x00, with the next two bytes
set to 0xFFFF [RFC2373]. When this field contains an IPv6 value,
the entire 16-byte field is used. If this field is not set, then
in-band management through the IP address of one of the Portals of
the Network Entity is assumed.
7.2.4 Entity Registration Timestamp
This field indicates the most recent time that the Network Entity
registration occurred or an associated object attribute was updated
Tseng, Gibbons, et al. Standards Track [Page 63]
Internet Storage Name Service (iSNS) January 2003
or queried by the iSNS client registering the Network Entity. The
time format is, in seconds, the update period since the standard
base time of 00:00:00 GMT on January 1, 1970. This field cannot be
used as a query key or be explicitly registered.
7.2.5 Protocol Version Range
This field contains the minimum and maximum version of the block
storage protocol supported by the Network Entity. The most
significant two bytes contain the maximum version supported, and
the least significant two bytes contain the minimum version
supported. If a range is not registered then the Network Entity is
assumed to support all versions of the protocol. The value 0xffff
is a wildcard that indicates no minimum or maximum. If the Network
Entity does not support a protocol, then this field SHALL be set to
0.
7.2.6 Registration Period
This 4-byte unsigned integer field indicates the maximum period, in
seconds, that the registration SHALL be maintained by the server
without receipt of an iSNS message from the iSNS client that
registered the Network Entity. Entities that are not registered
for ESI monitoring MUST have a non-zero Registration Period. If a
Registration Period is not requested by the iSNS client and Entity
Status Inquiry (ESI) messages are not enabled for that client, then
the Registration Period SHALL be set to a non-zero value by the
iSNS server. This implementation-specific value for the
Registration Period SHALL be returned in the registration response
to the iSNS client. The Registration Period may be set to zero,
indicating its non-use, only if ESI messages are enabled for that
Network Entity.
The registration SHALL be removed from the iSNS database if an iSNS
Protocol message is not received from the iSNS client before the
registration period has expired. Receipt of any iSNS Protocol
message from the iSNS client automatically refreshes the Entity
Registration Period and Entity Registration Timestamp. To prevent a
registration from expiring, the iSNS client should send an iSNS
Protocol message to the iSNS server at intervals shorter than the
registration period. Such a message can be as simple as a query
for one of its own attributes, using its associated iSCSI Name or
FC Port Name WWPN as the Source attribute.
For an iSNS client that is supporting a Network Entity with
multiple Storage Node objects, receipt of an iSNS message from any
Storage Node of that Network Entity is sufficient to refresh the
registration for all Storage Node objects of the Network Entity.
If ESI support is requested as part of a Portal registration, the
ESI Response message received from the iSNS client by the iSNS
server SHALL refresh the registration.
Tseng, Gibbons, et al. Standards Track [Page 64]
Internet Storage Name Service (iSNS) January 2003
7.2.7 Entity Index
The Entity Index is a 4-byte integer value that uniquely
identifies each Network Entity registered in the iSNS server.
Upon initial registration of an Network Entity, the iSNS server
assigns an unused value for the Entity Index. Each Network Entity
in the iSNS database MUST be assigned a value for the Entity Index
that is not assigned to any other Network Entity. Furthermore,
Entity Index values for recently deregistered Network Entities
SHOULD NOT be reused in the short term.
The Entity Index MAY be used to represent the Network Entity in
situations when the Entity Identifier is too long or otherwise
inappropriate.
7.2.8 Entity Next Index
This is a virtual attribute containing a 4-byte integer value that
indicates the next available (i.e., unused) Entity Index value.
This attribute may only be queried; the iSNS server SHALL return an
error code of 3 (Invalid Registration) to any client that attempts
to register a value for this attribute.
7.2.9 Entity ISAKMP Phase-1 Proposals
This field contains the IKE Phase-1 proposal listing in decreasing
order of preference the protection suites acceptable to protect all
IKE Phase-2 messages sent and received by the Network Entity. This
includes Phase-2 SA's from the iSNS client to the iSNS server as
well as to peer iFCP and/or iSCSI devices. This attribute contains
the SA payload, proposal payload(s), and transform payload(s) in
the ISAKMP format defined in [RFC2408].
This field should be used if the implementer wishes to define a
single phase-1 SA security configuration used to protect all phase-
2 IKE traffic. If the implementer desires to have a different
phase-1 SA security configuration to protect each Portal interface,
then the Portal Phase-1 Proposal (section 7.3.11) should be used.
7.2.10 Entity Certificate
This attribute contains one or more X.509 certificate that are
bound to the Network Entity. This certificate is uploaded and
registered to the iSNS server by clients wishing to allow other
clients to authenticate themselves and access the services offered
by that Network Entity. The format of the X.509 certificate is
found in [X.509].
7.3 Portal-Keyed Attributes
The following Portal attributes are registered in the iSNS database
using the combined Portal IP-Address and Portal TCP/UDP Port as the
key. Each Portal is associated with one Entity Identifier object
key.
Tseng, Gibbons, et al. Standards Track [Page 65]
Internet Storage Name Service (iSNS) January 2003
7.3.1 Portal IP Address
This attribute is the IP address of the Portal through which a
Storage Node can transmit and receive storage data. The Portal IP
Address is a 16-byte field that may contain an IPv4 or IPv6
address. When this field contains an IPv4 address, it is stored as
an IPv4-mapped IPv6 address. That is, the most significant 10
bytes are set to 0x00, with the next 2 bytes set to 0xFFFF
[RFC2373]. When this field contains an IPv6 address, the entire
16-byte field is used. The Portal IP Address along with the Portal
TCP/UDP Port number (see 7.3.2 below), is used as a key to uniquely
identify a Portal.
7.3.2 Portal TCP/UDP Port
The TCP/UDP port of the Portal through which a Storage Node can
transmit and receive storage data. Bits 16 to 31 represents the
TCP/UDP port number. Bit 15 represents the port type. If bit 15
is set, then the port type is UDP. Otherwise it is TCP. Bits 0 to
14 are reserved.
If the field value is 0, then the port number is the implied
canonical port number and type of the protocol indicated by the
associated Entity Type.
The Portal IP-Address along with the Portal TCP/UDP Port number is
used as a key to uniquely identify a Portal.
7.3.3 Portal Symbolic Name
A variable-length UTF-8 encoded NULL-terminated text-based
description of up to 256 bytes. The Portal Symbolic Name is a user-
readable description of the Portal entry in the iSNS server.
7.3.4 Entity Status Inquiry Interval
This field indicates the requested time, in seconds, between Entity
Status Inquiry (ESI) messages sent from the iSNS server to this
Network Entity. ESI messages can be used to verify that a Portal
registration continues to be valid. To request monitoring by the
iSNS server, an iSNS client registers a non-zero value for this
Portal attribute using a DevAttrReg message. The client must also
register an ESI Port on at least one of its Portals to receive the
ESI monitoring.
If the iSNS server does not receive an expected response to an ESI
message, it SHALL attempt an administratively configured number of
re-transmissions of the ESI message. The ESI Interval period
begins with the iSNS server's receipt of the last ESI Response.
All re-transmissions MUST be sent before twice the ESI Interval
period has passed. If no response is received from any of the ESI
messages, then the Portal SHALL be deregistered. Note that only
Portals that have registered a value in their ESI Port field can be
deregistered in this way.
Tseng, Gibbons, et al. Standards Track [Page 66]
Internet Storage Name Service (iSNS) January 2003
If all Portals associated with a Network Entity that have
registered for ESI messages are deregistered due to non-response,
and no registrations have been received from the client for at
least two ESI Interval periods, then the Network Entity and all
associated objects (including Storage Nodes) SHALL be deregistered.
If the iSNS server is unable to support ESI messages or the ESI
Interval requested, it SHALL reject the ESI request by returning an
"ESI Not Available" Status Code.
If at any time an iSNS client that is registered for ESI messages
has not received an ESI message to any of its Portals as expected,
then the client MAY attempt to query the iSNS server using a
DevAttrQry message using its Entity_ID as the key. If the query
result is the error "no such entry", then the client SHALL close
all remaining TCP connections to the iSNS server and assume that it
is no longer registered in the iSNS database. Such a client MAY
attempt re-registration.
7.3.5 ESI Port
This field contains the TCP or UDP port used for ESI monitoring by
the iSNS server at the Portal IP Address. Bit 16 to 31 represents
the port number. If bit 15 is set, then the port type is UDP.
Otherwise, the port is TCP. Bits 0 to 14 are reserved.
If the iSNS client registers a valid TCP or UDP port number in this
field, then the client SHALL allow ESI messages to be received at
the indicated TCP or UDP port. If a TCP port is registered and a
pre-existing TCP connection from that TCP port to the iSNS server
does not already exist, then the iSNS client SHALL accept new TCP
connections from the iSNS server at the indicated TCP port.
The iSNS server SHALL return an error if a Network Entity is
registered for ESI monitoring and none of the Portals of that
Network Entity has an entry for the ESI Port field. If multiple
Portals have a registered ESI port, then the ESI message may be
delivered to any one of the indicated Portals.
7.3.6 Portal Group Tag
This field is used to group Portals into aggregation groups. The
least significant two bytes of this field contain the integer
Portal Group Tag value for the Portal. The most significant two
bytes are reserved. All Portals MUST be members of a Portal Group.
For further details on use of Portal Groups, see [iSCSI].
If a registration message creating a new Portal entry does not
contain a Portal Group Tag attribute, or contains the Portal Group
Tag attribute with TLV length of 0, then the iSNS server SHALL
assign a 16-bit Portal Group Tag value for that Portal that is
unique for that Network Entity. The generated Portal Group Tag
value SHALL be returned in the registration response as an
operating attribute.
Tseng, Gibbons, et al. Standards Track [Page 67]
Internet Storage Name Service (iSNS) January 2003
7.3.7 Portal Index
The Portal Index is a 4-byte integer value that uniquely identifies
each Portal registered in the iSNS database. Upon initial
registration of a Portal, the iSNS server assigns an unused value
for the Portal Index of that Portal. Each Portal in the iSNS
database MUST be assigned a value for the Portal Index that is not
assigned to any other Portal. Furthermore, Portal Index values for
recently deregistered Portals SHOULD NOT be reused in the short
term.
The Portal Index can be used to represent a registered Portal in
situations where the Portal IP-Address and Portal TCP/UDP Port is
unwieldy to use. An example of this is when SNMP tables are used
to access the contents of the iSNS server. In this case, the
Portal Index may be used as the Registered Portal table index.
7.3.8 SCN Port
This field contains the TCP or UDP port used by the iSNS client to
receive SCN messages from the iSNS server. When a value is
registered for this attribute, an SCN message may be received on
the indicated port for any of the Storage Nodes supported by the
Portal. Bits 16 to 31 contain the port number. If bit 15 is set,
then the port type is UDP. Otherwise, the port type is TCP. Bits
0 to 14 are reserved.
If the iSNS client registers a valid TCP or UDP port number in this
field, then the client SHALL allow SCN messages to be received at
the indicated TCP or UDP port. If a TCP port is registered and a
pre-existing TCP connection from that TCP port to the iSNS server
does not already exist, then the iSNS client SHALL accept new TCP
connections from the iSNS server at the indicated TCP port.
The iSNS server SHALL return an error if an SCN registration
message is received and none of the Portals of the Network Entity
has an entry for the SCN Port. If multiple Portals have a
registered SCN Port, then the SCN SHALL be delivered to any one of
the indicated Portals of that Network Entity.
7.3.9 Portal Next Index
This is a virtual attribute containing a 4-byte integer value that
indicates the next available (i.e., unused) Portal Index value.
This attribute may only be queried; the iSNS server SHALL return an
error code of 3 (Invalid Registration) to any client that attempts
to register a value for this attribute.
7.3.10 Portal Security Bitmap
This 4-byte field contains flags that indicate security attribute
settings for the Portal. Bit 31 (Lsb) of this field must be 1
(enabled) in order for this field to contain significant
information. If Bit 31 is enabled, this signifies the iSNS server
Tseng, Gibbons, et al. Standards Track [Page 68]
Internet Storage Name Service (iSNS) January 2003
can be used to store and distribute security policies and settings
for iSNS clients (i.e., iSCSI devices). Bit 30 must be 1 in order
for bits 25-29 to contain significant information. All other bits
are reserved for non-IKE/IPSec security mechanisms to be specified
in the future.
Bit Position Flag Description
------------ ----------------
25 1 = Tunnel Mode Preferred; 0 = No Preference
26 1 = Transport Mode Preferred; 0 = No Preference
27 1 = PFS Enabled; 0 = PFS Disabled
28 1 = Aggressive Mode Enabled; 0 = Disabled
29 1 = Main Mode Enabled; 0 = MM Disabled
30 1 = IKE/IPSec Enabled; 0 = IKE/IPSec Disabled
31 (Lsb) 1 = Bitmap VALID; 0 = INVALID
All others reserved
7.3.11 Portal ISAKMP Phase-1 Proposals
This field contains the IKE Phase-1 proposal listing in decreasing
order of preference of the protection suites acceptable to protect
all IKE Phase-2 messages sent and received by the Portal. This
includes Phase-2 SA's from the iSNS client to the iSNS server as
well as to peer iFCP and/or iSCSI devices. This attribute contains
the SA payload, proposal payload(s), and transform payload(s) in
the ISAKMP format defined in [RFC2408].
This field should be used if the implementer wishes to define
phase-1 SA security configuration on a per-Portal basis, as opposed
to on a per-Network Entity basis. If the implementer desires to
have a single phase-1 SA security configuration to protect all
phase-2 traffic regardless of the interface used, then the Entity
Phase-1 Proposal (section 7.2.9) should be used.
7.3.12 Portal ISAKMP Phase-2 Proposals
This field contains the IKE Phase-2 proposal, in ISAKMP format
[RFC2408], listing in decreasing order of preference the security
proposals acceptable to protect traffic sent and received by the
Portal. This field is used only if bits 31, 30 and 29 of the
Security Bitmap (see 7.3.10) are enabled. This attribute contains
the SA payload, proposal payload(s), and associated transform
payload(s) in the ISAKMP format defined in [RFC2408].
7.3.13 Portal Certificate
This attribute contains one or more X.509 certificates that is a
credential of the Portal. This certificate is used to identify and
authenticate communications to the IP address supported by the
Portal. The format of the X.509 certificate is specified in
[X.509]
Tseng, Gibbons, et al. Standards Track [Page 69]
Internet Storage Name Service (iSNS) January 2003
7.4 iSCSI Node-Keyed Attributes
The following attributes are stored in the iSNS database using the
iSCSI Name attribute as the key. Each set of Node-Keyed attributes
is associated with one Entity Identifier object key.
Although the iSCSI Name key is associated with one Entity
Identifier, it is unique across the entire iSNS database.
7.4.1 iSCSI Name
A variable-length UTF-8 encoded NULL-terminated text-based
description of up to 256 bytes. This key attribute is required for
iSCSI Storage Nodes, and is provided by the iSNS client. The
registered iSCSI Name MUST be conformant to the format described in
[iSCSI] for iSCSI Names.
If an iSCSI Name is registered without an EID key, then an Network
Entity SHALL be created and an EID assigned. The assigned EID
SHALL be returned in the registration response as an operating
attribute.
This field MUST be normalized according to the stringprep template
[STRINGPREP] before it is stored in the iSNS database.
7.4.2 iSCSI Node Type
This required 32-bit field is a bitmap indicating the type of iSCSI
Storage Node. The bit positions are defined below. An set bit (1)
indicates that the Node has the corresponding characteristics.
Bit Position Node Type
------------ ---------
29 Control
30 Initiator
31 (Lsb) Target
All Others RESERVED
If the Target bit is set to 1, then the Node represents an iSCSI
target. Setting of the Target bit MAY be performed by iSNS clients
using the iSNSP.
If the Initiator bit is set to 1, then the Node represents an iSCSI
initiator. Setting of the Initiator bit MAY be performed by iSNS
clients using the iSNSP.
If the control bit is set to 1, then the Node represents a gateway,
management station, backup iSNS server, or other device which is
not an initiator or target, but requires the ability to send and
receive iSNSP messages, including state change notifications.
Setting of the control bit is an administrative task that MUST be
performed on the iSNS server; iSNS clients SHALL NOT be allowed to
change this bit using the iSNSP.
Tseng, Gibbons, et al. Standards Track [Page 70]
Internet Storage Name Service (iSNS) January 2003
This field MAY be used by the iSNS server to distinguish among
permissions by different iSCSI Node types for accessing various
iSNS functions. More than one Node Type bit may be simultaneously
enabled.
7.4.3 iSCSI Node Alias
A variable-length UTF-8 encoded NULL-terminated text-based
description of up to 256 bytes. The Alias is a user-readable
description of the Node entry in the iSNS database.
7.4.4 iSCSI Node SCN Bitmap
The iSCSI Node SCN Bitmap indicates those events for which the
registering iSNS client wishes to receive a notification message.
The following table displays events that result in notifications,
and the bit field in the SCN Bitmap that when enabled, results in
the corresponding notification.
Note that this field is of dual use--it is used in the SCN
registration process to define interested events that will trigger
an SCN message, and it is also contained in each SCN message
itself, to indicate the type of event that triggered the SCN
message. A set bit (1) indicates the corresponding type of SCN.
Bit Position Flag Description
------------ ----------------
24 INITIATOR AND SELF INFORMATION ONLY
25 TARGET AND SELF INFORMATION ONLY
26 MANAGEMENT REGISTRATION/SCN
27 OBJECT REMOVED
28 OBJECT ADDED
29 OBJECT UPDATED
30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
All others RESERVED
DD/DDS MEMBER REMOVED indicates that an existing member of a
Discovery Domain and/or Discovery Domain Set has been removed.
DD/DDS MEMBER ADDED indicates that a new member was added to an
existing DD and/or DDS.
OBJECT REMOVED, OBJECT ADDED, and OBJECT UPDATED indicate a Network
Entity, Portal, Storage Node, FC Device, DD, and/or DDS object was
removed from, added to, or updated in the Discovery Domain or in
the iSNS database (Control Nodes only).
Regular SCNs provide information about objects that are updated,
added or removed from Discovery Domains that the Storage Node is a
member of. An SCN or SCN registration is considered a regular SCN
or regular SCN registration if the MANAGEMENT REGISTRATION/SCN flag
is cleared. All iSNS clients may register for regular SCN's.
Tseng, Gibbons, et al. Standards Track [Page 71]
Internet Storage Name Service (iSNS) January 2003
Management SCNs provide information about all changes to the
network, regardless of discovery domain membership. Registration
for management SCN's is indicated by setting bit 26 to 1. Only
Control Nodes may register for management SCNs. Bits 30 and 31 may
only be enabled if bit 26 is set to 1.
TARGET AND SELF INFORMATION ONLY SCN's (bit 25) provides
information only about changes to target devices, or if the iSCSI
Node itself has undergone a change. Similarly, INITIATOR AND SELF
INFORMATION ONLY SCN's (bit 24) provides information only about
changes to initiator Nodes, or the target itself. At least one of
bit 25 or 26 MUST be enabled.
7.4.5 iSCSI Node Index
The iSCSI Node Index is a 4-byte integer value used as a key that
uniquely identifies each iSCSI Node registered in the iSNS
database. Upon initial registration of the iSCSI Node, the iSNS
server assigns an unused value for the iSCSI Node Index. Each
iSCSI Node MUST be assigned a value for the iSCSI Node Index that
is not assigned to any other iSCSI Node. Furthermore, iSCSI Node
Index values for recently deregistered iSCSI Nodes SHOULD NOT be
reused in the short term.
The iSCSI Node Index may be used as a key to represent a registered
Node in situations where the iSCSI Name is too long to be used as a
key. An example of this is when SNMP tables are used to access the
contents of the iSNS server. In this case, the iSCSI Node Index
may be used as the registered iSCSI Node table index.
7.4.6 WWNN Token
This field contains a globally unique 64-bit integer value that can
be used to represent the World Wide Node Name of the iSCSI device
in a Fibre Channel fabric. This identifier is used during the
device registration process, and MUST conform to the requirements
in [FC-FS].
The FC-iSCSI gateway uses the value found in this field to register
the iSCSI device in the Fibre Channel name server. It is stored in
the iSNS server to prevent conflict when assigning "proxy" WWNN
values to iSCSI initiators establishing storage sessions to devices
in the FC fabric.
If the iSNS client does not assign a value for WWNN Token, then the
iSNS server SHALL provide a value for this field upon initial
registration of the iSCSI Node. The process by which the WWNN
Token is assigned by the iSNS server MUST conform to the following
requirements:
1. The assigned WWNN Token value MUST be unique among all WWN
entries in the existing iSNS database, as well as among all devices
that can potentially be registered in the iSNS database.
Tseng, Gibbons, et al. Standards Track [Page 72]
Internet Storage Name Service (iSNS) January 2003
2. Once assigned, the iSNS server MUST persistently save the
mapping between the WWNN Token value and registered iSCSI Name.
That is, successive re-registrations of the iSCSI Node keyed by the
same iSCSI Name maintains the original mapping to the associated
WWNN Token value in the iSNS server. Similarly, the mapping SHALL
be persistent across iSNS server reboots. Once assigned, the
mapping can only be changed if a DevAttrReg message from an
authorized iSNS client explicitly provides a different WWNN Token
value.
3. Once a WWNN Token value has been assigned and mapped to an
iSCSI name, that WWNN Token value SHALL NOT be reused or mapped to
any other iSCSI name.
4. The assigned WWNN Token value MUST conform to the formatting
requirements of [FC-FS] for World Wide Names (WWN's).
An iSNS client, such as an FC-iSCSI gateway or the iSCSI initiator,
MAY register its own WWNN Token value or overwrite the iSNS Server-
supplied WWNN Token value, if it wishes to supply its own iSCSI-FC
name mapping. This is accomplished using the DevAttrReg message
with the WWNN Token (tag=37) as an operating attribute. Once
overwritten, the new WWNN Token value MUST be stored and saved by
the iSNS server, and all requirements specified above continue to
apply. If an iSNS client attempts to register a value for this
field that is not unique in the iSNS database or is otherwise
invalid, then the registration SHALL be rejected with an Status
Code of 3 (Invalid Registration).
There MAY be a matching records in the iSNS database for the Fibre
Channel device specified by the WWNN Token. These records for the
FC device may contain device attributes for that FC device
registered in the Fibre Channel fabric name server.
7.4.7 iSCSI Node Next Index
This is a virtual attribute containing a 4-byte integer value that
indicates the next available (i.e., unused) iSCSI Node Index value.
This attribute may only be queried; the iSNS server SHALL return an
error code of 3 (Invalid Registration) to any client that attempts
to register a value for this attribute.
7.4.8 iSCSI AuthMethod
This attribute contains a NULL-terminated string containing UTF-8
text listing the iSCSI authentication methods enabled for this
iSCSI Node, in order of preference. The text values used to
identify iSCSI authentication methods are embedded in this string
attribute and delineated by a comma. The text values are identical
to those found in the main iSCSI draft [iSCSI]; additional vendor-
specific text values are also possible.
Tseng, Gibbons, et al. Standards Track [Page 73]
Internet Storage Name Service (iSNS) January 2003
Text Value Description Reference
---------- ----------- ---------
KB5 Kerberos V5 RFC 1510
SPKM1 Simple Public Key GSS-API RFC 2025
SPKM2 Simple Public Key GSS-API RFC 2025
SRP Secure Remote Password RFC 2945
CHAP Challenge Handshake Protocol RFC 1994
none No iSCSI Authentication
7.4.9 iSCSI Node Certificate
This attribute contains one or more X.509 certificates that may be
a credential used to authenticate the iSCSI Node during iSCSI
authentication. This certificate MAY be used for the SPKM Public
Key authentication method. The format of the X.509 certificate is
specified in [X.509].
7.5 FC Port Name-Keyed Attributes
The following attributes are registered in the iSNS database using
the FC Port World Wide Name (WWPN) attribute as the key. Each set
of FC Port-Keyed attributes is associated with one Entity
Identifier object key.
Although the FC Port World Wide Name is associated with one Entity
Identifier, it is also globally unique.
7.5.1 FC Port Name (WWPN)
This 64-bit identifier uniquely defines the FC Port, and is the
World Wide Port Name (WWPN) of the corresponding Fibre Channel
device. This attribute is the key for the iFCP Storage Node. This
globally unique identifier is used during the device registration
process, and uses a value conforming to IEEE EUI-64 [EUI-64].
7.5.2 Port ID (FC_ID)
The Port Identifier is a Fibre Channel address identifier assigned
to an N_Port or NL_Port during fabric login. The format of the
Port Identifier is defined in [FC-FS]. The least significant 3
bytes contain this address identifier. The most significant byte
is RESERVED.
7.5.3 FC Port Type
Indicates the type of FC port. Encoded values for this field are
listed in the following table:
Tseng, Gibbons, et al. Standards Track [Page 74]
Internet Storage Name Service (iSNS) January 2003
Type Description
---- -----------
0x0000 Unidentified/Null Entry
0x0001 Fibre Channel N_Port
0x0002 Fibre Channel NL_Port
0x0003 Fibre Channel F/NL_Port
0x0004-0080 RESERVED
0x0081 Fibre Channel F_Port
0x0082 Fibre Channel FL_Port
0x0083 RESERVED
0x0084 Fibre Channel E_Port
0x0085-00FF RESERVED
0xFF11 RESERVED
0xFF12 iFCP Port
0xFF13-FFFF RESERVED
7.5.4 Symbolic Port Name
A variable-length UTF-8 encoded NULL-terminated text-based
description of up to 256 bytes that is associated with the iSNS-
registered FC Port Name in the network.
7.5.5 Fabric Port Name (FWWN)
This 64-bit identifier uniquely defines the fabric port. If the
port of the FC Device is attached to a Fibre Channel fabric port
with a registered Port Name, then that fabric Port Name SHALL be
indicated in this field.
7.5.6 Hard Address
This field is the requested hard address 24-bit NL Port Identifier,
included in the iSNSP for compatibility with Fibre Channel
Arbitrated Loop devices and topologies. The least significant 3
bytes of this field contain the address. The most significant byte
is RESERVED.
7.5.7 Port IP Address
The Fibre Channel IP address associated with the FC Port. When an
IPv4 value is contained in this field, then the most significant 12
bytes are set to 0x00. When an IPv6 value is contained in this
field, then the entire 16-byte field is used.
7.5.8 Class of Service (COS)
This 32-bit bit-map field indicates the Fibre Channel Class of
Service types that are supported by the registered port. In the
following table, a set bit (1) indicates a Class of Service
supported.
Tseng, Gibbons, et al. Standards Track [Page 75]
Internet Storage Name Service (iSNS) January 2003
Bit Position Description
------------ -----------
29 Fibre Channel Class 2 Supported
28 Fibre Channel Class 3 Supported
7.5.9 FC-4 Types
This 32-byte field indicates the FC-4 protocol types supported by
the associated port. This field can be used to support Fibre
Channel devices and is consistent with FC-GS-4.
7.5.10 FC-4 Descriptor
A variable-length UTF-8 encoded NULL-terminated text-based
description of up to 256 bytes, that is associated with the iSNS-
registered device port in the network. This field can be used to
support Fibre Channel devices and is consistent with FC-GS-4.
7.5.11 FC-4 Features
This is a 128-byte array, 4 bits per type, for the FC-4 protocol
types supported by the associated port. This field can be used to
support Fibre Channel devices and is consistent with FC-GS-4.
7.5.12 iFCP SCN Bitmap
This field indicates the events that the iSNS client is interested
in. These events can cause SCN to be generated. SCNs provide
information about objects that are updated, added or removed from
Discovery Domains that the source and destination are a member of.
Management SCNs provide information about all changes to the
network. A set bit (1) indicates the type of SCN for the bitmap as
follows:
Bit Position Flag Description
------------ ----------------
24 INITIATOR AND SELF INFORMATION ONLY
25 TARGET AND SELF INFORMATION ONLY
26 MANAGEMENT REGISTRATION/SCN
27 OBJECT REMOVED
28 OBJECT ADDED
29 OBJECT UPDATED
30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
All others RESERVED
Further information on use of the above specified bit positions can
be found in section 7.4.4.
7.5.13 Port Role
This required 32-bit field is a bitmap indicating the type of iFCP
Storage Node. The bit fields are defined below. An set bit
indicates the Node has the corresponding characteristics.
Tseng, Gibbons, et al. Standards Track [Page 76]
Internet Storage Name Service (iSNS) January 2003
Bit Position Node Type
------------ ---------
29 Control
30 FCP Initiator
31 (Lsb) FCP Target
All Others RESERVED
If the 'Target' bit is set to 1, then the port represents an FC
target. Setting of the 'Target' bit MAY be performed by iSNS
clients using the iSNSP.
If the 'Initiator' bit is set to 1, then the port represents an FC
initiator. Setting of the 'Initiator' bit MAY be performed by iSNS
clients using the iSNSP.
If the 'Control' bit is set to 1, then the port represents a
gateway, management station, iSNS backup server, or other device.
This is usually a special device that is neither an initiator nor
target, which requires the ability to send and receive iSNSP
messages including state change notifications. Setting of the
control bit is an administrative task that MUST be administratively
configured on the iSNS server; iSNS clients SHALL NOT be allowed to
change this bit using the iSNSP.
This field MAY be used by the iSNS server to distinguish among
permissions by different iSNS clients. For example, an iSNS server
implementation may be administratively configured to allow only
targets to receive ESI's, or for only Control Nodes to have
permission to add, modify, or delete discovery domains.
7.5.14 Permanent Port Name (PPN)
The Permanent Port Name attribute is the FC Port Name WWPN of the
first Storage Node registered in the iSNS Database that is
associated with a particular FC Device (FC Node). The PPN of all
subsequent Storage Node registrations that are associated with that
FC Device (FC Node) SHALL be set to the FC Port Name WWPN of the
first Storage Node. The same PPN MUST be used for all Storage Node
registrations associated with each FC Device. The value of PPN for
a Storage Node is set and determined by the iSNS Server. If the
Storage Node associated with the PPN is deregistered, then the iSNS
Server SHALL update the PPN of all remaining Storage Nodes for the
FC Device by selecting one of the remaining Storage Node FC Port
Name WWPNÆs as the PPN. The appropriate SCN messages SHALL be
generated for the respective changes in object registration(s).
The PPN attribute value cannot be registered by an iSNS client.
This field can be used to support Fibre Channel devices and is
consistent with FC-GS-4 [FC-GS-4]. The format of the PPN is
identical to the FC Port Name WWPN attribute format.
Tseng, Gibbons, et al. Standards Track [Page 77]
Internet Storage Name Service (iSNS) January 2003
7.5.15 Port Certificate
This attribute contains one or more X.509 certificates that is a
credential of the iFCP Storage Node. The format of the X.509
certificate is found in [X.509].
7.6 Node-Keyed Attributes
The following attributes are registered in the iSNS database using
the FC Node Name (WWNN) attribute as the key. Each set of FC Node-
Keyed attributes represents a single device, and can be associated
with many FC Ports.
The FC Node Name is unique across the entire iSNS database.
7.6.1 FC Node Name (WWNN)
The FC Node Name is a 64-bit identifier that is the World Wide Node
Name (WWNN) of the corresponding Fibre Channel device. This
attribute is the key for the FC Device. This globally unique
identifier is used during the device registration process, and uses
a value conforming to IEEE EUI-64 [EUI-64].
7.6.2 Symbolic Node Name
A variable-length UTF-8 encoded NULL-terminated text-based
description of up to 256 bytes that is associated with the iSNS-
registered FC Device in the network.
7.6.3 Node IP Address
This IP address is associated with the device Node in the network.
This field is included for compatibility with Fibre Channel. When
an IPv4 value is contained in this field, the most significant 12
bytes are set to 0x00. When an IPv6 value is contained in this
field, then the entire 16-byte field is used.
7.6.4 Node IPA
This field is the 8 byte Fibre Channel Initial Process Associator
(IPA) associated with the device Node in the network. The initial
process associator is used for communication between Fibre Channel
devices.
7.6.5 Node Certificate
This attribute contains an X.509 certificate that is bound to the
FC Node of the iSNS client. The format of the X.509 certificate is
specified in [X.509].
7.6.6 Proxy iSCSI Name
A variable-length UTF-8 encoded NULL-terminated text-based field
that contains the iSCSI Name used to represent the FC Node in the
Tseng, Gibbons, et al. Standards Track [Page 78]
Internet Storage Name Service (iSNS) January 2003
IP network. It is used as a pointer to the matching iSCSI Name
entry in the iSNS server. Its value is usually registered by an
FC-iSCSI gateway connecting the IP network to the fabric containing
the FC device.
Note that if this field is used, there SHOULD be a matching entry
in the iSNS database for the iSCSI device specified by the iSCSI
name. The database entry should include the full range of iSCSI
attributes needed for discovery and management of the "iSCSI proxy
image" of the FC device.
7.7 Other Attributes
The following are not attributes of the previously-defined objects.
7.7.1 FC-4 Type Code
This is a 4-byte field, and is used to provide a FC-4 type during a
FC-4 Type query. The FC-4 types are consistent with the FC-4 Types
as defined in FC-FS. Byte 0 contains the FC-4 type. All other
bytes are reserved.
7.7.2 iFCP Switch Name
The iFCP Switch Name is a 64-bit World Wide Name (WWN) identifier
that uniquely identifies a distinct iFCP gateway in the network.
This globally unique identifier is used during the switch
registration/FC_DOMAIN_ID assignment process. The iFCP Switch Name
value used MUST conform to the requirements stated in [FC-FS] for
World Wide Names. The iSNS server SHALL track the state of all
FC_DOMAIN_ID values that have been allocated to each iFCP Switch
Name. If a given iFCP Switch Name is deregistered from the iSNS
database, then all FC_DOMAIN_ID values allocated to that iFCP
Switch Name SHALL be returned to the unused pool of values.
7.7.3 iFCP Transparent Mode Commands
7.7.3.1 Preferred ID
This is a 4-byte unsigned integer field, and is the requested value
that the iSNS client wishes to use for the FC_DOMAIN_ID. The iSNS
server SHALL grant the iSNS client the use of the requested value
as the FC_DOMAIN_ID, if the requested value has not been already
allocated. If the requested value is not available, the iSNS
server SHALL return a different value that has not been allocated.
7.7.3.2 Assigned ID
This is a 4-byte unsigned integer field that is used by an iFCP
gateway to reserve its own unique FC_DOMAIN_ID value from the range
1 to 239. When a FC_DOMAIN_ID is no longer required, it SHALL be
released by the iFCP gateway using the RlseDomId message. The iSNS
server MUST use the Entity Status Inquiry message to determine if
an iFCP gateway is still present on the network.
Tseng, Gibbons, et al. Standards Track [Page 79]
Internet Storage Name Service (iSNS) January 2003
7.7.3.3 Virtual_Fabric_ID
This is a variable-length UTF-8 encoded NULL-terminated text-based
field of up to 256 bytes. The Virtual_Fabric_ID string is used as
a key attribute to identify a range of non-overlapping FC_DOMAIN_ID
values to be allocated using RqstDomId. Each Virtual_Fabric_ID
string submitted by an iSNS client SHALL have its own range of non-
overlapping FC_DOMAIN_ID values to be allocated to iSNS clients.
7.8 iSNS Server-Specific Attributes
Access to the following attributes for through either registration
or query messages may be administratively controlled. These
attributes are specific to the iSNS server instance; the same value
is returned for all iSNS clients accessing the iSNS server.
A registration or query for iSNS Server-Specific attribute MUST
contain the identifying key attribute (i.e., iSCSI Name or FC Port
Name WWPN) of the Node originating the registration or query
message as the Source and Message Key attributes. The Operating
Attributes are the server-specific attributes being registered or
queried.
7.8.1 iSNS Server Vendor OUI
This attribute is the OUI (Organizationally Unique Identifier)
[802-1990] identifying the specific vendor implementing the iSNS
server. This attribute can only be queried; iSNS clients SHALL NOT
be allowed to register a value for the iSNS Server Vendor OUI.
7.9 Vendor-Specific Attributes
Specific iSNS server implementations MAY define vendor-specific
attributes for private use. The tag values reserved for vendor-
specific and user-specific use are defined in section 7.1. To
avoid misinterpreting proprietary attributes, vendor's own OUI
(Organizationally Unique Identifier) MUST be placed in the upper
three bytes of the attribute field itself.
The OUI is defined in IEEE Std 802-1990, and is the same constant
used to generate 48 bit Universal LAN MAC addresses. A vendor's
own iSNS implementation will then be able to recognize the OUI in
the vendor-specific or user-specific attribute field, and be able
to execute vendor-specific handling of the attribute.
7.9.1 Vendor-Specific Server Attributes
Attributes with tags in the range 257 to 384 are vendor-specific or
site-specific attributes of the iSNS server. Registration and/or
query access to these attribute may be administratively controlled.
These attributes are unique for each logical iSNS server instance.
Query and registration messages for these attributes SHALL use the
key identifier (i.e., iSCSI Name or FC Port Name WWPN) for both the
Source attribute and Message Key attribute.
Tseng, Gibbons, et al. Standards Track [Page 80]
Internet Storage Name Service (iSNS) January 2003
7.9.2 Vendor-Specific Entity Attributes
Attributes in the range 385 to 512 are vendor-specific or site-
specific attributes used to describe the Network Entity object.
These attributes are keyed by the Entity Identifier attribute
(tag=1).
7.9.3 Vendor-Specific Portal Attributes
Attributes in the range 513 to 640 are vendor-specific or site-
specific attributes used to describe the Portal object. These
attributes are keyed by the Portal IP-Address (tag=16) and Portal
TCP/UDP Port (tag=17).
7.9.4 Vendor-Specific iSCSI Node Attributes
Attributes in the range 641 to 768 are vendor-specific or site-
specific attributes used to describe the iSCSI Node object. These
attributes are keyed by the iSCSI Name (tag=32).
7.9.5 Vendor-Specific FC Port Name Attributes
Attributes in the range 769 to 896 are vendor-specific or site-
specific attributes used to describe the N_Port Port Name object.
These attributes are keyed by the FC Port Name WWPN (tag=64).
7.9.6 Vendor-Specific FC Node Name Attributes
Attributes in the range 897 to 1024 are vendor-specific or site-
specific attributes used to describe the FC Node Name object.
These attributes are keyed by the FC Node Name WWNN (tag=96).
7.9.7 Vendor-Specific Discovery Domain Attributes
Attributes in the range 1025 to 1280 are vendor-specific or site-
specific attributes used to describe the Discovery Domain object.
These attributes are keyed by the DD_ID (tag=104).
7.9.8 Vendor-Specific Discovery Domain Set Attributes
Attributes in the range 1281 to 1536 are vendor-specific or site-
specific attributes used to describe the Discovery Domain Set
object. These attributes are keyed by the DD Set ID (tag=101)
7.9.9 Other Vendor-Specific Attributes
Attributes in the range 1537 to 2048 can be used for key and non-
key attributes that describe new vendor-specific objects specific
to the vendor's iSNS server implementation.
Tseng, Gibbons, et al. Standards Track [Page 81]
Internet Storage Name Service (iSNS) January 2003
7.10 Discovery Domain Registration Attributes
7.10.1 DD Set ID Keyed Attributes
7.10.1.1 Discovery Domain Set ID (DDS ID)
The DDS ID is an unsigned integer identifier used in the iSNS
directory database as a key to uniquely indicate a Discovery Domain
Set. A DDS is a collection of Discovery Domains that can be
enabled or disabled by a management station. This value is used as
a key for DDS attribute queries. When a Discovery Domain is
registered it is initially not in any DDS.
If the iSNS client does not provide a DDS_ID in a DDS registration
request message, the iSNS server SHALL generate a DDS_ID value that
is unique within the iSNS database for that new DDS. The created
DDS ID SHALL be returned in the response message. The DDS ID value
of 0 is reserved, and the DDS ID value of 1 is used for the default
DDS (see section 3.2.2).
7.10.1.2 Discovery Domain Set Symbolic Name
A variable-length UTF-8 encoded NULL-terminated text-based field of
up to 256 bytes. This is an user-readable field used to assist a
network administrator in tracking the DDS function. When
registered by a client, the DDS symbolic name SHALL be verified to
be unique by the iSNS server. If the DDS symbolic name is not
unique, then the DDS registration SHALL be rejected with an
"Invalid Registration" Status Code. The invalid attribute(s), in
this case the DDS symbolic name, SHALL be included in the response.
7.10.1.3 Discovery Domain Set Status
The DDS_Status field is a 32-bit bitmap indicating the status of
the DDS. Bit 0 of the bitmap indicates whether the DDS is Enabled
(1) or Disabled (0). The default value for the DDS Enabled flag is
Disabled (0).
Bit Position DDS Status
------------ ---------
31 (Lsb) DDS Enabled (1) / DDS Disabled (0)
All Others RESERVED
7.10.2 DD ID Keyed Attributes
7.10.2.1 Discovery Domain ID (DD ID)
The DD ID is an unsigned integer identifier used in the iSNS
directory database as a key to uniquely identify a Discovery
Domain. This value is used as the key for any DD attribute query.
If the iSNS client does not provide a DD_ID in a DD registration
request message, the iSNS server SHALL generate a DD_ID value that
is unique within the iSNS database for that new DD (i.e., the iSNS
client will be registered in a new DD). The created DD ID SHALL be
Tseng, Gibbons, et al. Standards Track [Page 82]
Internet Storage Name Service (iSNS) January 2003
returned in the response message. The DD ID value of 0 is
reserved, and the DD ID value of 1 is used for the default DD (see
section 3.2.2).
7.10.2.2 Discovery Domain Symbolic Name
A variable-length UTF-8 encoded NULL-terminated text-based field of
up to 256 bytes. When registered by a client, the DD symbolic name
SHALL be verified to be unique by the iSNS server. If the DD
symbolic name is not unique, then the DD registration SHALL be
rejected with an "Invalid Registration" Status Code. The invalid
attribute(s), in this case the DD symbolic name, SHALL be included
in the response.
7.10.2.3 Discovery Domain iSCSI Node Index
This is the iSCSI Node Index of a Storage Node that is a member of
the DD. The DD may have a list of 0 to n members. The iSCSI Node
Index is one alternative representation of membership in a
Discovery Domain, the other alternative being the iSCSI Name. The
Discovery Domain iSCSI Node Index is a 4-byte integer value.
The iSCSI Node Index can be used to represent a DD member in
situations where the iSCSI Name is too long to be used. An example
of this is when SNMP tables are used to access the contents of the
iSNS server.
The iSCSI Node Index and iSCSI Name stored as a member in a DD
SHALL be consistent with the iSCSI Node Index and iSCSI Name
attributes registered for the Storage Node object in the iSNS
server.
7.10.2.4 Discovery Domain Member--iSCSI Name
A variable-length UTF-8 encoded NULL-terminated text-based field of
up to 256 bytes. It indicates membership for the specified iSCSI
Storage Node in the Discovery Domain. There is no limit to the
number of members that may be in a DD. Membership is represented by
the iSCSI Name of the iSCSI Storage Node.
7.10.2.5 Discovery Domain Member--FC Port Name
This 64-bit identifier attribute indicates membership for an iFCP
Storage Node (FC Port) in the Discovery Domain . There is no limit
to the number of members that may be in a DD. Membership is
represented by the FC Port Name (WWPN) of the iFCP Storage Node.
7.10.2.6 Discovery Domain Member--Portal Index
This attribute indicates membership in the Discovery Domain for a
Portal. It is an alternative representation for Portal membership
to the Portal IP Address and Portal TCP/UDP Port.
Tseng, Gibbons, et al. Standards Track [Page 83]
Internet Storage Name Service (iSNS) January 2003
7.10.2.7 Discovery Domain Member--Portal IP Address
This attribute, along with the Portal TCP/UDP Port attribute,
indicates membership in the Discovery Domain for the specified
Portal.
7.10.2.8 Discovery Domain Member--Portal TCP/UDP Port
This attribute, along with the Portal IP Address attribute,
indicates membership in the Discovery Domain for the specified
Portal.
7.10.2.9 Discovery Domain Features
The Discovery Domain Features is a bitmap indicating the features
of this DD. The bit positions are defined below. A bit set to 1
indicates the DD has the corresponding characteristics.
Bit Position DD Feature
------------ ----------
31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)
All Others RESERVED
Boot List: this feature indicates that the targets in this DD
provide boot capabilities for the member initiators, as described
in [iSCSI-boot].
8. Security Considerations
8.1 iSNS Security Threat Analysis
When the iSNS protocol is deployed, the interaction between iSNS
server and iSNS clients are subject to the following security
threats:
a) An attacker could alter iSNS protocol messages, such as to
direct iSCSI and iFCP devices to establish connections with rogue
peer devices, or to weaken/eliminate IPSec protection for iSCSI or
iFCP traffic.
b) An attacker could masquerade as the real iSNS server using
false iSNS heartbeat messages. This could cause iSCSI and iFCP
devices to use rogue iSNS servers.
c) An attacker could gain knowledge about iSCSI and iFCP devices
by snooping iSNS protocol messages. Such information could aid an
attacker in mounting a direct attack on iSCSI and iFCP devices,
such as a denial-of-service attack or outright physical theft.
To address these threats, the following capabilities are needed:
a) Unicast iSNS protocol messages may need to be authenticated.
In addition, to protect against threat [3] above, confidentiality
Tseng, Gibbons, et al. Standards Track [Page 84]
Internet Storage Name Service (iSNS) January 2003
support is desirable, and REQUIRED when certain functions of iSNS
server are utilized.
b) Multicast iSNS protocol messages such as the iSNS heartbeat
message may need to be authenticated. These messages need not be
confidential since they do not leak critical information.
8.2 iSNS Security Implementation and Usage Requirements
If the iSNS server is used to distribute authorizations for
communications between iFCP and iSCSI peer devices, IPsec ESP with
null transform MUST be implemented, and non-null transform MAY be
implemented. If a non-null transform is implemented, then the DES
encryption algorithm SHOULD NOT be used.
If the iSNS server is used to distribute security policy for iFCP
and iSCSI devices, then authentication, data integrity, and
confidentiality MUST be supported and used. Where confidentiality
is desired or required, IPSec ESP with non-null transform SHOULD be
used, and the DES encryption algorithm SHOULD NOT be used.
In order to protect against an attacker masquerading as an iSNS
server, client devices MUST support the ability to authenticate
broadcast or multicast messages such as the iSNS heartbeat. The
iSNS authentication block (which is identical in format to the SLP
authentication block) may be used for this purpose. Note that the
authentication block is used only for iSNS broadcast or multicast
messages, and MUST NOT be used in unicast iSNS messages.
There is no requirement that the communicating identities in iSNS
protocol messages be kept confidential. Specifically, the identity
and location of the iSNS server is not considered confidential.
For protecting unicast iSNS protocol messages, iSNS servers
supporting security MUST implement ESP in tunnel mode and MAY
implement transport mode.
All iSNS implementations supporting security MUST support the
replay protection mechanisms of IPsec.
iSNS security implementations MUST support both IKE Main Mode and
Aggressive Mode for authentication, negotiation of security
associations, and key management, using the IPSec DOI [RFC2407].
Manual keying SHOULD NOT be used since it does not provide the
necessary rekeying support. Conformant iSNS security
implementations MUST support authentication using a pre-shared key,
and MAY support certificate-based peer authentication using digital
signatures. Peer authentication using the public key encryption
methods outlined in IKE's sections 5.2 and 5.3 [RFC2409] SHOULD NOT
be supported.
Conformant iSNS implementations MUST support both IKE Main Mode and
Aggressive Mode. IKE Main Mode with pre-shared key authentication
SHOULD NOT be used when either of the peers use dynamically
Tseng, Gibbons, et al. Standards Track [Page 85]
Internet Storage Name Service (iSNS) January 2003
assigned IP addresses. While Main Mode with pre-shared key
authentication offers good security in many cases, situations where
dynamically assigned addresses are used force the use a group pre-
shared key, which is vulnerable to man-in-the-middle attack. IKE
Identity Payload ID_KEY_ID MUST NOT be used.
When digital signatures are used for authentication, either IKE
Main Mode or IKE Aggressive Mode MAY be used. In all cases, access
to locally stored secret information (pre-shared key or private key
for digital signing) MUST be suitably restricted, since compromise
of the secret information nullifies the security properties of the
IKE/IPsec protocols.
When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload(s) to specify
the certificate authority (or authorities) that are trusted in
accordance with its local policy. IKE negotiators SHOULD check the
pertinent Certificate Revocation List (CRL) before accepting a PKI
certificate for use in IKE's authentication procedures.
When the iSNS server is used without security, IP block storage
protocol implementations MUST support a negative cache for
authentication failures. This allows implementations to avoid
continually contacting discovered endpoints that fail
authentication within IPsec or at the application layer (in the
case of iSCSI Login). The negative cache need not be maintained
within the IPsec implementation, but rather within the IP block
storage protocol implementation.
8.3 Discovering Security Requirements of Peer Devices
Once communication between iSNS clients and the iSNS server have
been secured through use of IPSec, the iSNS client devices have the
capability to discover the security settings that they need to use
for their peer-to-peer communications using the iSCSI and/or iFCP
protocols. This provides a potential scaling advantage over
device-by-device configuration of individual security policies for
each iSCSI and iFCP device.
The iSNS server stores security settings for each iSCSI and iFCP
device interface. These security settings, which can be retrieved
by authorized hosts, include use or non-use of IPSec, IKE, Main
Mode, and Aggressive Mode. For example, IKE may not be enabled for
a particular interface of a peer device. If a peer device can
learn of this in advance by consulting the iSNS server, it will not
need to waste time and resources attempting to initiate an IKE
phase 1 session with that peer device interface.
If iSNS is used for this purpose, then the minimum information that
should be learned from the iSNS server is the use or non-use of IKE
and IPSec by each iFCP or iSCSI peer device interface. This
information is encoded in the Security Bitmap field of each Portal
of the peer device, and is applicable on a per-interface basis for
the peer device. iSNS queries to acquire security configuration
Tseng, Gibbons, et al. Standards Track [Page 86]
Internet Storage Name Service (iSNS) January 2003
data about peer devices MUST be protected by IPSec/ESP
authentication.
8.4 Configuring Security Policies of iFCP/iSCSI Devices
Use of iSNS for distribution of security policies offers the
potential to reduce the burden of manual device configuration, and
decrease the probability of communications failures due to
incompatible security policies. If iSNS is used to distribute
security policies, then IPSec authentication, data integrity, and
confidentiality MUST be used to protect all iSNS protocol messages.
The complete IKE/IPSec configuration of each iFCP and/or iSCSI
device can be stored in the iSNS server, including policies that
are used for IKE Phase 1 and Phase 2 negotiations between client
devices. The IKE payload format includes a series of one or more
proposals that the iSCSI or iFCP device will use when negotiating
the appropriate IPsec policy to use to protect iSCSI or iFCP
traffic.
In addition, the iSCSI Authentication Methods used by each iSCSI
device can also be stored in the iSNS server. The iSCSI AuthMethod
field (tag=42) contains a null-terminated string embedded with the
text values indicating iSCSI authentication methods to be used by
that iSCSI device.
Note that iSNS distribution of security policy is not necessary if
the security settings can be determined by other means, such as
manual configuration or IPsec security policy distribution. If a
network entity has already obtained its security configuration via
other mechanisms, then it MUST NOT request security policy via
iSNS.
8.5 Resource Issues
The iSNS protocol is lightweight, and will not generate a
significant amount of traffic. iSNS traffic is characterized by
occasional registration, notification, and update messages that do
not consume significant amounts of bandwidth. Even software-based
IPSec implementations should not have a problem handling the
traffic loads generated by the iSNS protocol.
To fulfill iSNS security requirements, the only additional
resources needed beyond what is already required for iSCSI and iFCP
involves the iSNS server. Since iSCSI and iFCP end nodes are
already required to implement IKE and IPSec, these existing
requirements can also be used to fulfill IKE and IPSec requirements
for iSNS clients.
8.6 iSNS Interaction with IKE and IPSec
When IPSec security is enabled, each iSNS client with at least one
Storage Node that is registered in the iSNS database SHALL maintain
at least one phase-1 security association with the iSNS server.
Tseng, Gibbons, et al. Standards Track [Page 87]
Internet Storage Name Service (iSNS) January 2003
All iSNS protocol messages between iSNS clients and the iSNS server
SHALL be protected by a phase-2 security association.
When a Network Entity is removed from the iSNS database, the iSNS
server SHALL send a phase-1 delete message to the associated iSNS
client IKE peer, and tear down all phase-1 and phase-2 SA's
associated with that iSNS client.
9. IANA Considerations
The well-known TCP and UDP port number for iSNS is 3205.
In order to maintain a registry of block storage protocols
supported by iSNSP, IANA MUST assign a 32-bit unsigned integer
number for each protocol. This number is stored in the iSNS
database as the Entity Protocol. The initial set of values to be
maintained by IANA for Entity Protocol is indicated in the table in
section 7.2.2. Additional values for new block storage protocols
to be supported by iSNS SHALL be assigned by IANA on a First Come,
First Served basis.
IANA is responsible for maintaining the complete list of iSNS
attributes described in section 7. This information MUST include
for each iSNS attribute, its tag value, the attribute length, and
the set of permissible registration and query keys that can be used
for that attribute. The initial list of iSNS attributes to be
maintained by IANA is indicated in section 7.1.
Additions of new attributes to the iSNS attribute list that use tag
values currently indicated as RESERVED in section 7.1 SHALL require
proper documentation. This documentation SHALL include as a
minimum, the new attribute tag value, attribute length, and the set
of permissible registration and query keys that can be used for the
new attribute. Possible forms of documentation include, but are
not limited to, RFCs or the product of another standards body.
Other requests may also be accepted, under the advice of a
"designated expert". (Contact the IANA for the contact information
of the current expert.)
Finally, IANA is also responsible for assigning values to be used
for the Block Structure Descriptor for the Authentication Block
(see section 6.5). Section 15 of [RFC2608] describes the process
for allocation of new BSD values.
Tseng, Gibbons, et al. Standards Track [Page 88]
Internet Storage Name Service (iSNS) January 2003
10. Normative References
[iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in
progress), draft-ietf-ips-iSCSI-19.txt, November 2002
[iFCP] Monia, C., et al., "iFCP - A Protocol for Internet
Fibre Channel Storage Networking", Internet draft
(work in progress), draft-ietf-ips-ifcp-14.txt,
December 2002
[iSNSOption]Tseng, Gibbons, Monia, "DHCP Options for Internet
Storage Name Service", Internet draft (work in
progress), draft-ietf-dhc-isnsoption-04.txt, December
2002
[RFC2608] Guttman, E., Perkins, C., Veizades, J., Day, M.,
"Service Location Protocol, Version 2", RFC 2608, June
1999
[iSCSIName] Bakke, M., et al., "iSCSI naming and Discovery",
draft-ietf-ips-iscsi-name-disc-08.txt, September 2002
[iSCSI-SLP] Bakke, M., "Finding iSCSI Targets and Name Servers
Using SLP", Internet draft (work in progress), draft-
ietf-ips-iscsi-slp-04.txt, October 2002
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997
[SEC-IPS] Aboba, B., et al., "Securing Block Storage Protocols
over IP", draft-ietf-ips-security-18.txt, December
2002
[STRINGPREP]Bakke, M. "String Profile for iSCSI Names", draft-
ietf-ips-string-prep-03.txt, October 2002
[NAMEPREP] Hoffman, P. "Nameprep: A Stringprep Profile for
Internationalized Domain Names", July 2002
[RFC1157] Case, J. "A Simple Network Management Protocol
(SNMP)", RFC 1157, May 1990
[RFC2401] Atkinson, R., Kent, S., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998
[RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation of ISAKMP", RFC 2407, November 1998
Tseng, Gibbons, et al. Standards Track [Page 89]
Internet Storage Name Service (iSNS) January 2003
[RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J.,
"Internet Security Association and Key Management
Protocol (ISAKMP), RFC 2408, November 1998
[RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981
[RFC2373] Hinden, R., "IP Version 6 Addressing Architecture",
RFC2373, July 1998
[DSS] FIPS PUB 186-2, National Institute of Standards and
Technology, Digital Signature Standard (DSS),
Technical Report
[EUI-64] Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority, May 2001, IEEE,
http://standards.ieee.org/regauth/oui/tutorials/EUI64.
html
[X.509] ITU-T Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - The
Directory: Authentication Framework, June 1997
[802-1990] IEEE Standards for Local and Metropolitan Area
Networks: Overview and Architecture, Technical
Committee on Computer Communications of the IEEE
Computer Society, May 31, 1990
[FC-FS] Fibre Channel Framing and Signaling Interface, NCITS
Working Draft Project 1331-D
[iSNSMIB] Gibbons, K., Definitions of Managed Objects for iSNS
(Internet Storage name Service), draft-ietf-ips-isns-
mib-03.txt, December 2002
11. Informative References
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification, RFC 1035, November 1987
[RFC1305] Mills, D., Network Time Protocol (Version 3), RFC
1305, March 1992
[FC-GS-3] Fibre Channel Generic Services-3, NCITS 348-2000
[FC-GS-4] Fibre Channel Generic Services-4, NCITS Working Draft
Project 1505-D
Tseng, Gibbons, et al. Standards Track [Page 90]
Internet Storage Name Service (iSNS) January 2003
[RFC2026] Bradner, S. "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996
[RFC1510] Kohl, J., The Kerberos Network Authentication Service
(V5), RFC 1510, September 1993
[RFC2025] Adams, C., The Simple Public-Key GSS-API Mechanism
(SPKM), RFC 2025, October 1996
[RFC2945] Wu, T., The SRP Authentication and Key Exchange
System, RFC 2945, September 2000
[RFC1994] Simpson, W., PPP Challenge Handshake Authentication
Protocol (CHAP), August 1996
[RFC2131] Droms, R., Dynamic Host Configuration Protocol, March
1997
Tseng, Gibbons, et al. Standards Track [Page 91]
Internet Storage Name Service (iSNS) January 2003
12. Author's Addresses
Josh Tseng
Nishan Systems
3850 North First Street
San Jose, CA 95134-1702
Phone: (408) 519-3749
Email: jtseng@nishansystems.com
Kevin Gibbons
Nishan Systems
3850 North First Street
San Jose, CA 95134-1702
Phone: (408) 519-3756
Email: kgibbons@nishansystems.com
Franco Travostino
Nortel Networks
3 Federal Street
Billerica, MA 01821
Phone: 978-288-7708
Email: travos@nortelnetworks.com
Curt Du Laney
IBM
4205 South Miami Blvd
Research Triangle Park, NC 27709
Email: dulaney@us.ibm.com
Phone: (919) 254-5632
Joe Souza
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email: joes@microsoft.com
Phone: (425) 706-3135
Tseng, Gibbons, et al. Standards Track [Page 92]
Internet Storage Name Service (iSNS) January 2003
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Tseng, Gibbons, et al. Standards Track [Page 93]
Internet Storage Name Service (iSNS) January 2003
Appendix A -- iSNS Examples
A.1 iSCSI Initialization Example
This example assumes an SLP Service Agent (SA) has been implemented
on the iSNS host, and an SLP User Agent (UA) has been implemented
on the iSNS initiator. See [RFC2608] for further details on SA's
and UA's. This example also assumes the target is configured to
use the iSNS server, and have its access control policy
subordinated to the iSNS server.
A.1.1 Simple iSCSI Target Registration
In this example, a simple target with a single iSCSI name registers
with the iSNS server. The target has not been assigned a Fully
Qualified Domain Name (FQDN) by the administrator.
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS Server |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP------->| |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.36.53.1 | authorized to view|
| | | all DDs. Device |
| | | NAMEabcd has been |
| DevAttrReg--------->| | previously placed |
|Oper Attrs: | | into DDabcd******/|
|tag=1: NULL | | |
|tag=2: "iSCSI" | | |
|tag=16: "192.36.4.5" | | |
|tag=17: "5001" | | |
|tag=19: 0 | | |
|tag=32: "NAMEabcd" | | |
|tag=33: "target" | | |
|tag=34: "disk 1" | | |
| |<---DevAttrRegRsp | |
| |SUCCESS | |
| |tag=1: "isns:0001"| |
| |tag=16: "192.36.4.5" |
| |tag=17: "5001" | |
| |tag=32: "NAMEabcd"| |
| | | |
| DevAttrQry--------->| SCN-------->| |
|Src:(tag=32) "NAMEabcd" |(or SNMP trap) | |
|Key:(tag=2) "iSCSI" |tag=1: "isns:0001" |
|Key:(tag=33) "initiator" |dest: "mgmt.foo.com" |
|Oper Attrs: |CHANGE IN NETWORK | |
|tag=16: NULL | | |
|tag=17: NULL | |<-------SCNRsp |
|tag=32: NULL | | |
|/*Query asks for all iSCSI| | |
|devices' IP address, port |<---DevAttrQryRsp | |
|number, and Name*/ |SUCCESS | |
| |tag=16:"192.36.4.1" |
Tseng, Gibbons, et al. Standards Track [Page 94]
Internet Storage Name Service (iSNS) January 2003
| |tag=17:"50000" | |
| |tag=32:"devpdq" | |
| |tag=16:"192.1.3.2"|<-----DevAttrQry |
| |tag=17:"50000" |src: "MGMTname1" |
| |tag=32:"devrst" |key:(tag=1)isns:0001
| | |Op Attrs: |
|/*************************| |tag=16: NULL |
|Our target "isns:0001" | |tag=17: NULL |
|discovers two initiators | |tag=32: NULL |
|in the same DD. It will | | |
|accept iSCSI logins from | | |
|these two identified | | |
|initiators presented by | | |
|iSNS*********************/| DevAttrQryRsp--->| |
| |SUCCESS | |
| |tag=16: 192.36.4.5| |
| |tag=17: 5001 | |
| |tag=32: NAMEabcd | |
+--------------------------+------------------+-------------------+
A.1.2 Target Registration and DD Configuration
In this example, a more complex target registers with the iSNS.
This target has been configured with a Fully Qualified Domain Name
(FQDN) in the DNS servers, and the user wishes to use this
identifier for the device. Also, the user wishes to use public key
certificates in the iSCSI login authentication.
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS Server |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.36.53.1 | authorized to view|
| DevAttrReg--> | | all DDs ********/|
|Oper Attrs: | | |
|tag=1: "jbod1.foo.com" | | |
|tag=2: "iSCSI" | | |
|tag=16: "192.36.34.4" | | |
|tag=17: "5001" | | |
|tag=19: "5 seconds" | | |
|tag=16: "192.36.53.5" | | |
|tag=17: "5001" | | |
|tag=32: "NAMEabcd" | | |
|tag=33: "Target" |/*****************| |
|tag=34: "Storage Array 1" |jbod1.foo.com is | |
|tag=43: X.509 cert |now registered in | |
|tag=32: "NAMEefgh" |iSNS, but is not | |
|tag=33: "Target" |in any DD. Therefore, |
|tag=34: "Storage Array 2" |no other devices | |
|tag=43: X.509 cert |can "see" it. | |
| |*****************/| |
| |<--DevAttrRegRsp | |
Tseng, Gibbons, et al. Standards Track [Page 95]
Internet Storage Name Service (iSNS) January 2003
| |SUCCESS | |
| |tag=1: "jbod1.foo.com" |
| |tag=16: "192.36.34.4" |
| |tag=17: "5001" | |
| |tag=16: "192.36.53.5" |
| |tag=17: "5001" | |
| |tag=32: "NAMEabcd"| |
| |tag=32: "NAMEefgh"| |
| | | |
| | SCN------> | |
| | (or SNMP trap) | |
| |tag=1: "jbod1.foo.com" |
| |dest: "mgmt.foo.com" |
| |CHANGE IN NETWORK | |
| | | |
| | |<--SCNRsp |
| | |<--DevAttrQry |
| | |src: "mgmt.foo.com"|
| | |key: (tag=1) |
| | | "jbod1.foo.com" |
| | |Op Attr: (tag=2) |
| | |Op Attr: (tag=16) |
| | |Op Attr: (tag=17) |
| | |Op Attr: (tag=32) |
| | | |
| | DevAttrQryRsp--> | |
| |SUCCESS | |
| |tag=2: "iSCSI" | |
| |tag=16: 192.36.34.4 |
| |tag=17: 5001 | |
| |tag=16: 192.36.53.5 |
| |tag=17: 5001 |/**Mgmt Station ***|
| |tag=32:"NAMEabcd" |displays device, |
| |tag=32:"NAMEefgh" |the operator decides
| | |to place "NAMEabcd"|
| | |into Domain "DDxyz"|
|/*************************| |******************/|
|Target is now registered | | |
|in iSNS. It has been placed |<--DDReg |
|in DDxyz by management | |src: "mgmt.foo.com"|
|station. | |key: "DDxyz ID" |
|*************************/| |Op Attr: |
| | |tag=32: "NAMEabcd" |
| | DDRegRsp----->| |
| | SUCCESS | |
+--------------------------+------------------+-------------------+
A.1.3 Initiator Registration and Target Discovery
The following example illustrates a new initiator registering with
the iSNS, and discovering the target NAMEabcd from the example in
A.1.2.
Tseng, Gibbons, et al. Standards Track [Page 96]
Internet Storage Name Service (iSNS) January 2003
+--------------------------+------------------+-------------------+
| iSCSI Initiator | iSNS |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.36.53.1 | authorized to view|
|DevAttrReg--> | | all DDs ********/|
|Oper Attrs: | | |
|tag=1: "svr1.foo.com" | | |
|tag=2: "iSCSI" | | |
|tag=16: "192.20.3.1" |/*****************| |
|tag=17: "5001" |Device not in any | |
|tag=19: 5 seconds |DD, so it is | |
|tag=32: "NAMEijkl" |inaccessible by | |
|tag=33: "Initiator" |other devices | |
|tag=34: "Server1" |*****************/| |
|tag=43: X.509 certificate | | |
| |<--DevAttrRegRsp | |
| |SUCCESS | |
| |tag=1: "svr1.foo.com" |
| |tag=16: "192.20.3.1" |
| |tag=17: "5001" | |
| |tag=32: "NAMEijkl"| |
| | | |
| | SCN------> | |
| | (or SNMP trap) | |
| |tag=1: svr1.foo.com |
| |dest: mgmt.foo.com| |
| |CHANGE IN NETWORK | |
| | | |
| | |<------SCNRsp |
| | |<----DevAttrQry |
| | |src: "mgmt.foo.com"|
| | |key: (tag=1) |
| | | "svr1.foo.com" |
| | |Op Attr: (tag=2) |
| | |Op Attr: (tag=16) |
| | |Op Attr: (tag=17) |
| | |Op Attr: (tag=32) |
| | DevAttrQryRsp--> | |
| |SUCCESS | |
| |tag=2: "iSCSI" | |
| |tag=16:192.20.3.1 | |
| |tag=17: "5001" | |
| |tag=32:"NAMEijkl" | |
| | |/**Mgmt Station ***|
| | |displays device, |
| | |the operator decides
| | |to place "NAMEijkl"|
| | |into Domain "DDxyz"|
| | |with device NAMEabcd
| | |******************/|
| | |<--DDReg |
| | |src: (tag=1) |
Tseng, Gibbons, et al. Standards Track [Page 97]
Internet Storage Name Service (iSNS) January 2003
| | | "mgmt.foo.com" |
| | |key: "DDxyz ID" |
| | |tag=32: "NAMEijkl |
| | | |
| | DDRegRsp---->|/******************|
| | SUCCESS |"NAMEijkl" has been|
| | |moved to "DDxyz" |
| | |******************/|
| |<-----SCN | |
| |tag=32: "NAMEijkl"| |
| |CHANGE IN DD MEMBERSHIP |
| DevAttrQry----------->| | |
|src: "NAMEabcd" |/*****************| |
|key:(tag=2) "iSCSI" |Note that NAMEabcd| |
|key:(tag=33) "Target" |also receives an | |
|Op Attr: (tag=16) |SCN that NAMEijkl | |
|Op Attr: (tag=17) |is in the same DD | |
|Op Attr: (tag=32) |*****************/| |
|Op Attr: (tag=34) | | |
|Op Attr: (tag=43) |<-----AttrQryRsp | |
| |SUCCESS | |
| |tag=16: 192.36.34.4 |
| |tag=17: 5001 | |
| |tag=16: 192.36.53.5 |
| |tag=17: 5001 | |
| |tag=32: NAMEabcd | |
| |tag=34: Volume 1 | |
| |tag=43: X.509 cert| |
| | | |
|/***The initiator has discovered | |
|the target, and has everything | |
|needed to complete iSCSI login | |
|The same process occurs on the | |
|target side; the SCN prompts the | |
|target to download the list of | |
|authorized initiators from the | |
|iSNS (i.e., those initiators in the | |
|same DD as the target.************/ | |
+--------------------------+------------------+-------------------+
Tseng, Gibbons, et al. Standards Track [Page 98]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/