Internet Draft Kevin Gibbons
<draft-ietf-ips-isns-01.txt> Josh Tseng
Expires September 2001 Charles Monia
Nishan Systems
Franco Travostino
Nortel Networks
Ken Hirata
Vixel Corporation
Mark Bakke
Cisco Systems
Jim Hafner
IBM Research
Howard Hall
Pirus Networks
March 2001
iSNS Internet Storage Name Service
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Acknowledgements
Numerous individuals contributed to the creation of this draft
through their careful review and submissions of comments and
recommendations. We acknowledge the following persons for their
technical contributions to this document: John Hufferd (IBM),
Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe Czap (IBM), Yaron
Gibbons, Tseng, Monia Standards Track
iSNS March 2001
Klein (Sanrad), Larry Lamers (SAN Valley), Jack Harwood (EMC),
David Black (EMC), and David Robinson (Sun).
Comments
Comments should be sent to the IPS mailing list (ips@ece.cmu.edu)
or to the authors.
1. Abstract
This document provides a generic framework centering around use of
the iSNS for discovery and management of storage entities in an
enterprise-scale IP storage network. iSNS is an application that
stores client attributes and monitors the availability and
reachability of storage assets in an integrated IP storage network.
Due to its role as a consolidated information repository, iSNS
provides for more efficient and scalable management of IP storage
assets.
2. Conventions used in this document
iSNS refers to the framework consisting of the storage network
model and associated services.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
All frame formats are in big endian network byte order.
3. iSNS Overview
The iSNS provides a common framework used to provide naming,
discovery, and resource management services for enterprise-scale IP
storage networks. iSNS can be implemented to support iSCSI, iFCP,
and/or FCIP protocols as needed; an iSNS implementation MAY provide
support for any one, two, or all three of these protocols as
desired by the implementer. Implementation requirements within
each of these protocols is further discussed in section 5. Although
use of iSNS is optional for iSCSI and FCIP, these protocols will
benefit from iSNS as the number of devices in the storage network
increases.
3.1 iSNS Architectural Components
3.1.1 iSNS Client
Entities that initiate transactions using the iSNSP are referred to
as iSNS clients. Using the iSNSP, iSNS clients can register their
attribute information, download information about other registered
clients in a common DD, and receive asynchronous notification of
topology events that occur in their DD(s). Management stations are
Gibbons, Tseng, Monia Standards Track 2
iSNS March 2001
a special type of iSNS client that have access to all DDs stored in
the iSNS.
3.1.2 iSNS Server
The iSNS server responds to iSNS protocol queries and requests, and
initiates iSNS protocol State Change Notifications. Properly
authenticated information submitted by a registration request is
stored in an internal or external database.
The iSNS server MAY be discovered by iSNS clients through a
multicast discovery message, although the protocol format for this
discovery mechanism is beyond the scope of this document.
3.1.3 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.4 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.2 iSNS Functional Components
There are three main functional components of the iSNS:
1) A Name Service Providing Storage Resource Discovery
2) Discovery Domain (DD) and Login Control Service
3) State Change Notification Service
3.2.1 Name Registration Service
The iSNS provides a registration function to allow all entities in
a storage network to register and query the directory. Both
targets and initiators can register in the iSNS, as well as query
for information about other initiators and targets. This allows,
for example, a client initiator to obtain information about target
devices from the iSNS server. This service is modeled on the Fibre
Channel Generic Services Name Server described in FC-GS-3, with
extensions, operating within the context of an IP network.
In order to maintain consistency between DNS Name-to-IP address
mappings stored in the iSNS, and the same mapping which may exist
in DNS servers, a common backend database storing such mappings MAY
be implemented to support both DNS and iSNS. This backend database
can be based upon a standard network directory service such as
LDAP.
Gibbons, Tseng, Monia Standards Track 3
iSNS March 2001
The naming registration service also provides the ability to obtain
a network unique Domain ID for iFCP gateways and Fibre Channel
Autonomous Regions (AR's), when required.
3.2.2 Discovery Domain and Login Control Service
The Discovery Domain (DD) Service facilitates the partitioning of
iSNS client devices into more manageable groupings for
administrative and login control purposes. With DD's, an
administrator can partition groups of initiators and targets into
more manageable groups in order to limit the login process to the
more appropriate subset of targets registered in the iSNS. iSNS
clients must be in at least one common DD in order to obtain
information about each other from the iSNS. iSNS clients can be a
member of multiple DD's simultaneously.
The DD information stored in the iSNS can be used by various
enforcement points in the network to provide enhanced security.
For example, a DD-aware switch can block storage initiators from
accessing targets that are not in the same DD, even if the
initiator somehow obtained address information for a target outside
of its DD. This functionality is the equivalent of the _Hard
Zoning_ functionality in a Fibre Channel network.
Login Control allows targets to "slave" their access control
mechanism to the iSNS. The target downloads the list of authorized
initiators from the iSNS. Each initiator is uniquely identified by
an iSCSI WWUI, iFCP Port Name, or FCIP IP Address. Only initiators
that match the required identification and authenticating
information provided by the iSNS will be allowed access by that
target during the initiator's session login (e.g., the iSCSI login
process). If spoofing of initiator identities is a concern, the
target MAY use the public key certificate of the authorized
initiator, obtained from the iSNS server, to authenticate the
initiator.
DD's can be managed offline by a separate management workstation,
through the iSNSP or through SNMP. If the target opts to use the
Login Control feature of the iSNS, the target subordinates
management of access control policy (i.e., the list of initiators
allowed to login to that target) to the management workstations
that are manipulating information in the iSNS database.
If authorized, a target can upload its own Login Control list.
This is accomplished using the RegDevDD message and listing the
WWUI of each initiator to be registered in the Target's DD.
Devices that do not belong to any Discovery Domain SHALL NOT be
accessible to any other device (except the management station).
Depending on the implementation, newly registered devices that have
not explicitly been placed into a DD by the management station MAY
be placed into a "default DD" where they are visible to other
Gibbons, Tseng, Monia Standards Track 4
iSNS March 2001
devices in that DD. Other implementations MAY decide that they are
registered with no DD, making them inaccessible to any other
devices in the iSNS database.
3.2.3 State Change Notification Service
The State Change Notification (SCN) service allows the iSNS to
issue notifications about network events that affect the
operational state of iSNS client entities. The iSNS client has the
ability to register for these notifications of events detected by
the iSNS. The types of events for which SCNs can be sent include
change in Discovery Domain (DD) membership and device registration
updates.
The State Change Notification service utilizes the Discovery Domain
Service, as described in section 3.1.2, to control the distribution
of notification messages. Notifications about changes within a DD
are limited to members of that DD.
If the iSNS is unable to service an SCN registration it SHALL
reject the SCN registration request, returning a SCN Registration
Rejected error code. The rejection might occur in situations where
the network size, or current level of SCN registrations, has passed
an implementation-specific threshold. A client not allowed to
register for SCNs SHOULD monitor its sessions with other storage
devices directly.
The specific notification mechanism by which the iSNS learns of the
events is implementation-specific, but can include examples such as
explicit notification messages from an iSNS client to the iSNS
server, or a hardware interrupt to a switch-hosted iSNS as a result
of link failure. The iSNS is equivalent to the Fibre Channel State
Change Notification service, with extensions, operating within the
context of an IP network.
3.3 iSNS and Domain Name System (DNS)
A directory-enabled iSNS implementation may use LDAP to store iSNS
client attributes. If this is the case, then LDAP can be used to
support both the iSNS and DNS server infrastructures, maintaining
consistency in Domain Name-to-IP address mappings used by DNS and
iSNS.
A detailed description of the Domain Name System (DNS) protocol is
found in [RFC 1035], and is beyond the scope of this document. If a
common LDAP information base is used to support both DNS and iSNS
servers, then Domain-Name-to-IP address mappings for storage
devices can be obtained from either DNS servers or the iSNS.
3.4 iSNS and LDAP
LDAP is a generic protocol to access directory services through the
network. It is a passive service designed to deliver scalable
Gibbons, Tseng, Monia Standards Track 5
iSNS March 2001
directory services using a get/set model. Applications designed
and tailored to specific user requirements interact with LDAP for
their generic directory service needs. On the other hand, iSNS is
an application that goes beyond the simple get/set model, and
provides specific capabilities needed to monitor and manage an
enterprise-scale storage network. iSNS is one example of an
application that can leverage the services of LDAP. By layering
iSNS on top of LDAP, the capabilities of both iSNS and LDAP can be
leveraged to manage and scale the enterprise IP storage network.
The iSNS application provides capabilities that LDAP alone is not
designed to achieve. This includes the following:
1) Client Attribute Awareness - The iSNS server application
interprets attribute values submitted by clients in registration
messages, and can take appropriate action based upon specific
registered attribute values.
2) State Change Notification - An iSNS server may initiate
notification messages to clients in the event of a change in the
network, such as the non-availability or reachability of a storage
device, or a specific change in the value of a client attribute.
3) Monitoring of Clients - iSNS provides a Entity Status Inquiry
message to verify the availability and reachability of storage
devices.
4) Lightweight - iSNSP is a simple and lightweight protocol
suitable for implementation on embedded devices such as switches
and targets. There are no unused or "wasted" features that may bog
down the performance of the host device.
3.5 iSNS Discovery and 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. SLP MAY be used by iSNS clients to discover the IP
address of the iSNS server. To implement discovery through SLP, a
Service Agent (SA) should be cohosted in the iSNS server, and a
User Agent (UA) should be in each iSNS client. Each client
multicasts a discovery message requesting the IP address of the
iSNS server(s). The SA responds to this request. Optionally, the
location of the iSNS can be stored in the SLP Directory Agent (DA).
If iSNS is not used, then the IP address of the iSNS server should
be manually configured in each iSNS client.
Note that a complete description and specification of SLP can be
found in [RFC2608], and is beyond the scope of this document.
Additional details on use of SLP to discover iSNS can be found in
the document draft-bakke-iscsi-slp-00.txt.
Gibbons, Tseng, Monia Standards Track 6
iSNS March 2001
3.6 iSNS and NAT
The existence of NAT will have an impact upon information retrieved
from the iSNS. If the iSNS client exists in a different addressing
domain than the iSNS server, then IP address information stored in
the iSNS server may not be correct when interpreted in the domain
of the iSNS client.
There are several possible approaches to allow operation of iSNS
within a NAT network. The first approach is to require use of the
canonical TCP port number by both targets and initiators when
addressing targets across a NAT boundary, and for the iSNS client
to not query for nominal IP addresses. Rather, an iSNS client
initiator SHALL query for the DNS Fully Qualified Domain Name
(i.e., Entity Identifier) when seeking addressing information.
Once retrieved, the DNS name can be interpreted in each address
domain and mapped to the appropriate IP address by local DNS
servers.
A second approach is to deploy a distributed network of iSNS
servers. Local iSNS servers are deployed inside and outside NAT
boundaries, with each local server storing relevant IP addresses
for their respective NAT domains. Updates among the network of
decentralized, local iSNS servers are handled using LDAP and using
appropriate NAT translation rules implemented within the update
mechanism in each server.
A final approach is to simply disallow use of NAT in between
communication between the iSNS server and any iSNS client.
3.7 Interactions Between iSNS Infrastructures
Each individual iSNS deployment is designed to be operated in
networks under the control of a single administrative authority.
This administrative authority facilitates a seamless, integrated
policy for iSNS usage, including security, naming and registration
of storage assets, and management of Discovery Domains. Through
leverage of an Internet-based database framework such as LDAP, the
iSNS not only scales to large storage networks, but also to support
interactions among multiple independently managed storage
infrastructures, each managed by its own administrative authority.
The information registered in the iSNS can be shared with other
iSNS servers managed by other administrative authorities through
out-of-band, non-iSNS protocols. By importing registration
information from a remote iSNS server, storage connectivity can be
established to devices managed by that server.
The following examples illustrate possible methods to transfer iSNS
records of devices between autonomous, independently-administered
iSNS servers. In the first example, a back-end LDAP information
base is used to support the iSNS server. The following diagram
illustrates use of the LDAP protocol to import iSNS registration
Gibbons, Tseng, Monia Standards Track 7
iSNS March 2001
information from one iSNS server to another. Once the record
transfer of the remote device is completed, it becomes visible and
accessible to local devices on the local iSNS server. This allows
local devices to establish sessions with remote devices (provided
firewall boundaries can be negotiated).
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ | | | | | | +-----+ |
|........ +--+---+ | WAN | +---+--+ |
|.dev C'. | | Link | | |
|........ | ============= | |
| | | | | |
| +--+---+ | | +---+--+ |
| | local|<--- <--- <--- <-|remote| |
| | LDAP | | LDAP: | | LDAP | |
| +------+ Xfer "dev C"| +------+ |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
In the above diagram, two business partners wish to share storage
"dev C". Using LDAP, the record for "dev C" can be transfered from
Network B to Network A. Once accessible to the local iSNS in
Network A, local devices A and B can now discover and connect to
"dev C".
Gibbons, Tseng, Monia Standards Track 8
iSNS March 2001
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ | | | | | | +-----+ |
|........ +------+ | WAN | +---+--+ |
|.dev C'. ^ | Link | | |
|........ | ============= v |
| | | | |SNMP |
| | | | | |
| +--+----+ | | v |
| | SNMP |<--- <--- <--- <---- |
| | Mgmt | | SNMP: Xfer "dev C" |
| |Station| | | |
| +-------+ | | |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
The above diagram illustrates a second example of how iSNS records
can be shared. In this case, the iSNS servers are not using LDAP
to store records. This method uses an SNMP-based management
station to manually download the desired record for "dev C", and
then directly upload it to the local iSNS. Once the record is
transfered to the local iSNS in Network A, "dev C" becomes visible
and accessible (provided firewall boundaries can be negotiated) to
other devices in Network A.
Other methods, including proprietary protocols, can be used to
transfer device records between independently-administered iSNS
servers. Further discussion and explanation of these methodologies
is beyond the scope of this document.
3.8 Deployment Architecture Diagram
The following diagram displays examples of where and how iSNS can
be deployed, and of the various IP-based storage entities that it
can support.
Gibbons, Tseng, Monia Standards Track 9
iSNS March 2001
+------------+ +-----------+ +-----------+
| | LDAP | Directory | LDAP | iSNS |
| DNS Server |<-------->| Database |<-------->| Server |
| | | | | |
+------+-----+ +-----+-----+ +-----+-----+
| | |
| DNS | LDAP iSNSP |
|Queries | |
+------+----------------------+----------------------+---------+
| |
| IP Network |
| |
+----+-----------+----------+---------------+-------------+----+
| | | | |
| | +-----+-----+ +------+-----+ +----+----+
| | |iSCSI-/ | |iFCP / | | FCIP |
| | | FC /iSNS | |Switch/iSNS | | Gateway |
| | |Gtwy/Server| | /Server| | |
| | +----+------+ +-+-------+--+ +----+----+
| | | | | |
+----+----+ +----+---+ +---+----+ +----+-+ +---+----+ +---+----+
| iSCSI | | iSCSI | | Fibre | | FC | | Fibre | | Fibre |
|Initiator| | Target | |Channel | |Device| |Channel | |Channel |
+---------+ +--------+ |Network | +------+ |Network | |Network |
+--------+ +--------+ +--------+
iSNS Client Entities
4. iSNS Object Model
iSNS provides the framework for the registration and discovery of
iSCSI devices, Fibre Channel-based devices using iFCP, and FCIP
tunnel endpoint gateways. This architecture defines common objects
that can be used to represent components referenced by each of
these three protocols. In iSCSI, the IP-based storage end devices
(NICs, controllers, etc...) are registered in the iSNS. In iFCP,
the iFCP gateway and its supported Fibre Channel-based storage end
devices (HBA's, controllers, etc...) have their attributes
registered in the iSNS by the iFCP gateway. Finally, for FCIP,
only the FCIP gateway and its supported tunnel endpoints are
registered in the iSNS by the FCIP gateway.
The following architecture framework provides elements needed to
describe various storage device objects and attributes that may
exist on an IP storage network. Five object entities are defined
in this architecture framework. They are PORTAL, NETWORK ENTITY,
STORAGE NODE, STORAGE PORT, and DISCOVERY DOMAIN. Each of these
objects are described in greater detail in sections 4.1 to 4.5.
The object containment hierarchy starts with the DISCOVERY DOMAIN.
The DISCOVERY DOMAIN contains a set of NETWORK ENTITY objects,
STORAGE NODE objects, and/or PORTAL objects. Conversely, an
individual NETWORK ENTITY, STORAGE NODE, or PORTAL can be contained
Gibbons, Tseng, Monia Standards Track 10
iSNS March 2001
in one or more DISCOVERY DOMAIN objects. The NETWORK ENTITY object
describes a device or gateway visible to the IP network. It can
contain one or more STORAGE NODE objects, and one or more PORTAL
objects. STORAGE NODE objects are used to represent an initiator
or target storage controller, while a PORTAL represents an IP
Address and Port Number which can be used to access any of the
STORAGE NODE objects within that NETWORK ENTITY object. Within the
STORAGE NODE are one or more STORAGE PORTS. Each object has a set
of attributes described in section 5. Not all objects are
applicable to each protocol (i.e., iSCSI, iFCP, and FCIP) supported
by iSNS. For example, the STORAGE PORT object is not used in
iSCSI. In the diagrams below, objects are denoted in all CAPITAL
letters.
4.1 NETWORK ENTITY Object
The NETWORK ENTITY object represents a device or gateway that is
accessible from the IP network. This device or gateway may support
one or more initiators or target controllers that are either
internal to the storage device, or accessible through a network
behind the gateway. Each individual initiator or target controller
is represented by subordinate STORAGE NODE objects.
Applicability Primary
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
Entity Identifier * * * *
Entity Type * * *
Management IP Address * * *
ESI Interval * * *
Timestamp * * *
Entity Certificate * * *
SCN Event Bitmap * * *
ESI TCP/UDP Port * * *
4.2 PORTAL Object
The PORTAL object is a port through which access to any STORAGE
NODE within the NETWORK ENTITY can be obtained. A NETWORK ENTITY
must have one or more PORTALs, each of which is usable by STORAGE
NODEs contained in that NETWORK ENTITY to gain access to the IP
network.
Applicability Primary
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
IP Address * * * *
TCP/UDP Port * * * *
Portal Symbolic Name * * *
4.3 STORAGE NODE Object
Gibbons, Tseng, Monia Standards Track 11
iSNS March 2001
The STORAGE NODE object defines an individual storage initiator or
target. This entity may be a RAID controller, a Fibre Channel HBA,
or other individual storage controller. The STORAGE NODE may have
one or more STORAGE PORT objects. There may be one or more STORAGE
NODE objects within the NETWORK ENTITY.
Applicability Primary
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
WWUI * *
Node Name (WWNN) * *
Node Type * *
Alias/Node Symbolic Name * *
FC Node IP-Address *
FC Node IPA *
Node Certificate * *
The primary key used to uniquely identify an iSCSI-based STORAGE
ENTITY is WWUI, while the key for an iFCP/Fibre Channel-based
STORAGE ENTITY is WWNN. iFCP/Fibre Channel-based Nodes contain 1
or more STORAGE PORT objects, which are keyed with a WWPN.
4.4 DISCOVERY DOMAIN Object
DISCOVERY DOMAINS are a security and management mechanism used to
partition storage resources. Zoning prevents initiators from
potentially logging in to every possible target during device
discovery. When queried, the iSNS server will only provide
information on storage entities in a common DD. Initiators will
thus not be able to "see" devices that are not in a common DD.
Applicability Primary
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
DD_ID * * * *
DD_Symbolic Name * * * *
DD_Member (WWUI) * *
DD_Member (WWPN) * *
DD_Member (WWNN) * *
DD_Member (IP Address) * * *
4.5 STORAGE PORT Object
The STORAGE PORT object defines an individual service delivery port
that services a STORAGE ENTITY. An iSCSI device does not have a
STORAGE PORT, and this object is therefore unused for an iSCSI
device. For a Fibre Channel device, the STORAGE PORT describes an
N_PORT interface.
Gibbons, Tseng, Monia Standards Track 12
iSNS March 2001
Applicability Primary
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
Port Name (WWPN) * *
Port_ID *
Port_Type *
Port_Symbolic Name *
FC Fabric Port Name (FWWN) *
FC Hard Address *
FC Port IP Address *
FC Class of Service *
FC FC-4 Types *
FC FC-4 Descriptors *
FC FC-4 Features *
4.6 Diagram Examples
In each of the following subsections, the attributes described for
each object are covered in more detail in section 5.4. The Key
Attribute column indicates that the attribute is a search key which
can be used to query for that object.
4.6.1 iSCSI
The following diagram models how a simple iSCSI-based initiator and
target is represented using database objects stored in the iSNS.
In this implementation, each target and initiator is attached to a
single PORTAL. Since the devices shown are iSCSI, the STORAGE PORT
object does not apply. All required attributes are also shown in
this diagram:
Gibbons, Tseng, Monia Standards Track 13
iSNS March 2001
+----------------------------------------------------------------+
| IP Network |
+------------+--------------------------------------+------------+
| |
| |
+-----+------+------+-----+ +-----+------+------+-----+
| | PORTAL | | | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | |
| | -TCP Port 1 | | | | -TCP Port 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| | | | | | | |
| +--------+ +--------+ | | +-------+ +--------+ |
| | | | | | | |
| | STORAGE NODE | | | | STORAGE NODE | |
| | -WWUI | | | | -WWUI | |
| | -Alias: "server1"| | | | -Alias: "disk1"| |
| | -Type: initiator | | | | -Type: target | |
| | | | | | | |
| +-------------------+ | | +------------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (FQDN): | | -Entity ID (FQDN): |
| "strg1.foo.com" | | "strg2.bar.com" |
| -Type: iSCSI | | -Type: iSCSI |
| | | |
+-------------------------+ +-------------------------+
The object model can be expanded to describe more complex devices,
such as an iSCSI device with more than one storage controller, each
controller accessible through any of multiple PORTAL interfaces.
The storage controllers on this highly-available device which can
be accessed through alternate PORTAL interfaces, if any original
interface should fail. The following diagram describes such a
device:
Gibbons, Tseng, Monia Standards Track 14
iSNS March 2001
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL | | PORTAL | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| +-------+ +----------------+ +-------------------+ +------+ |
| | | | | | | |
| +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
| | | | | | | |
| | STORAGE NODE | | STORAGE NODE | | STORAGE NODE | |
| | -WWUI 1 | | -WWUI 2 | | -WWUI 3 | |
| | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| |
| | -Type: target | | -Type: target | | -Type: target | |
| | | | | | | |
| +-----------------+ +-----------------+ +-----------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (FQDN): "dev1.foo.com" |
| -Type: iSCSI |
| |
+---------------------------------------------------------------+
4.6.2 iFCP
The iFCP protocol allows native Fibre Channel devices, or Fibre
Channel fabrics connected to an iFCP gateway, to be directly
internetworked using IP.
When supporting iFCP, the iSNS stores the attributes of the Fibre
Channel devices themselves, attributes of the iFCP gateway, as well
as 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 the two Fibre Channel devices behind it. The
NETWORK ENTITY object represents the iFCP gateway itself, while
each of the STORAGE NODE objects represents an actual Fibre Channel
device. One of the target devices has two ports, each represented
by a STORAGE PORT object.
Gibbons, Tseng, Monia Standards Track 15
iSNS March 2001
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL | | PORTAL | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| | Fibre Channel Loop or Fabric | |
| +-------+ +-----------------+ +----------------+ +--------+ |
| | | | | | | |
| +-+-----+ +-----+-+ +--+----+ +------+---+-----+ +-----+--+ |
| | |STORAGE PORT | | | |STORAGE PORT | |STORAGE PORT | | |
| | | -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 | | |
| | +-------------+ | | +-------------+ +-------------+ | |
| | | | | |
| | STORAGE NODE | | STORAGE NODE | |
| | -WWNN 1 | | -WWNN 2 | |
| | -Symbolic Name| | -Symbolic Name | |
| | -FC Node IPA | | -FC Node IPA | |
| | -Type: target | | -Type: target | |
| | | | | |
| +-----------------+ +-------------------------------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (FQDN): "gtwy1.foo.com" |
| -Type: iFCP |
| |
+---------------------------------------------------------------+
4.6.3 FCIP
Gibbons, Tseng, Monia Standards Track 16
iSNS March 2001
The following diagram depicts FCIP gateways stored in the iSNS. In
FCIP, the iSNS is only used for tunnel endpoint discovery.
Therefore, no information about the storage end nodes are
registered in the iSNS, and the STORAGE PORT and STORAGE NODE
objects are not applicable.
+----------------------------------------------------------------+
| IP Network |
+-------------+-------------------------+----------------+-------+
| | |
| | |
+-----+-------+------+----+ +-+------+------+--+------+-----+-+
| | PORTAL | | | | PORTAL | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | | -IP Addr 3 | |
| | -TCP Port 1 | | | | -TCP Port 2 | | -TCP Port 3| |
| +--------------+ | | +-------------+ +------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (FQDN): | | -Entity ID (FQDN): |
| "Tunnelgtwy1.foo.com" | | "Tunnelgtwy2.bar.com" |
| -Type: FCIP | | -Type: FCIP |
+-------------------------+ +---------------------------------+
5. iSNS Implementation Requirements
iSNS can be implemented with features to support any combination of
the following protocols: iSCSI, iFCP, and FCIP. Implementation of
support for any or all of these protocols is OPTIONAL. IF iSNS is
implemented to support a particular protocol, then a minimum set of
attributes and iSNSP commands is REQUIRED for support of that
protocol. This section details specific requirements for support of
each of these IP storage protocols.
5.1 iSCSI Requirements
Use of iSNS in support of iSCSI is OPTIONAL. iSCSI devices MAY be
manually configured with the WWUI and IP address of peer devices,
without the aid or intervention of iSNS. iSCSI devices also MAY
use SLP [RFC 2608] to discover peer iSCSI devices. However, for
scaling a storage network to a larger number of iSCSI devices, use
of iSNS is RECOMMENDED.
5.1.1 Required Attributes for Support of iSCSI
The following attributes are available to support iSCSI.
Attributes indicated in the REQUIRED TO IMPLEMENT column MUST be
supported by an iSNS server used to support iSCSI. Attributes
indicated in the REQUIRED TO USE column MUST be supported by an
iSCSI device that elects to use the iSNS.
Gibbons, Tseng, Monia Standards Track 17
iSNS March 2001
REQUIRED REQUIRED
Object Attribute to Implement to Use
------ --------- ------------ --------
NETWORK ENTITY Entity Identifier * *
Entity Type * *
Management IP Address
ESI Interval *
Timestamp *
Entity Certificate *
SCN Event Bitmap *
ESI TCP/UDP Port * *
PORTAL IP Address * *
TCP/UDP Port * *
Portal Symbolic Name *
STORAGE NODE WWUI * *
Node Type * *
Alias/Symbolic Node Name *
Node Certificate *
DISCOVERY DOMAIN DD_ID * *
DD_Symbolic Name *
DD Member (Entity ID) *
DD_Member (WWUI) * *
DD_Member (IP Address) *
All iSCSI user-specified and vendor-specified attributes are
optional to implement and use.
5.1.2 Attribute Descriptions for iSCSI Storage Systems
The iSNS attributes used to represent iSCSI Storage Systems are
shown and described in the following diagram:
Gibbons, Tseng, Monia Standards Track 18
iSNS March 2001
- iSCSI NETWORK ENTITY
|
- Entity Identifier
| By convention this is the DNS name of the
| Portal IP-Address(es). If it is not registered
| the iSNS will assign a unique alphanumeric
| identifier to it.
- Entity Type
| Indicates this is an iSCSI registration
- Mgt IP-Address
| If it is not registered then in-band management
| is assumed.
- Entity Status Inquiry Interval
| If 0 no status inquiry is used
- Timestamp
| Timestamp of last registration update
- Entity Certificate
| X.509 certificate bound to the Entity (FQDN)
- SCN Event Bitmap
| Indicates current SCN state
- ESI TCP/UDP Port
Destination port number for ESI messages
- PORTAL (1 - n per ENTITY)
| |
| - IP-Address
| - TCP/UDP Port
| | The IP-Addr and Port together uniquely
| | define a portal.
| - Portal Symbolic Name
|
- STORAGE NODE (1 - m per ENTITY)
|
- WWUI (World-Wide Unique Identifier)
- Node Type (initiator / target / ...)
- Alias/Symbolic Node Name
- Node Certificate
5.1.3 Example iSCSI Object Model Diagrams
The following diagram models how a simple iSCSI-based initiator and
target is represented using database objects stored in the iSNS.
In this implementation, each target and initiator is attached to a
single PORTAL. Since the devices shown are iSCSI, the STORAGE PORT
object does not apply. All required attributes are also shown in
this diagram:
Gibbons, Tseng, Monia Standards Track 19
iSNS March 2001
+----------------------------------------------------------------+
| IP Network |
+------------+--------------------------------------+------------+
| |
| |
+-----+------+------+-----+ +-----+------+------+-----+
| | PORTAL | | | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | |
| | -TCP Port 1 | | | | -TCP Port 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| | | | | | | |
| +--------+ +--------+ | | +-------+ +--------+ |
| | | | | | | |
| | STORAGE NODE | | | | STORAGE NODE | |
| | -WWUI | | | | -WWUI | |
| | -Alias: "server1"| | | | -Alias: "disk1"| |
| | -Type: initiator | | | | -Type: target | |
| | | | | | | |
| +-------------------+ | | +------------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (FQDN): | | -Entity ID (FQDN): |
| "strg1.foo.com" | | "strg2.bar.com" |
| -Type: iSCSI | | -Type: iSCSI |
| | | |
+-------------------------+ +-------------------------+
The object model can be expanded to describe more complex devices,
such as an iSCSI device with more than one storage controller, each
controller accessible through any of multiple PORTAL interfaces.
The storage controllers on this highly-available device which can
be accessed through alternate PORTAL interfaces, if any original
interface should fail. The following diagram describes such a
device:
Gibbons, Tseng, Monia Standards Track 20
iSNS March 2001
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL | | PORTAL | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| +-------+ +----------------+ +-------------------+ +------+ |
| | | | | | | |
| +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
| | | | | | | |
| | STORAGE NODE | | STORAGE NODE | | STORAGE NODE | |
| | -WWUI 1 | | -WWUI 2 | | -WWUI 3 | |
| | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| |
| | -Type: target | | -Type: target | | -Type: target | |
| | | | | | | |
| +-----------------+ +-----------------+ +-----------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (FQDN): "dev1.foo.com" |
| -Type: iSCSI |
| |
+---------------------------------------------------------------+
5.1.4 Required Commands and Response Messages for Support of iSCSI
The following are iSNSP messages and responses are available in
support of iSCSI. Messages indicated in the REQUIRED TO IMPLEMENT
column MUST be implemented in iSNS servers used for iSCSI devices.
Messages indicated in the REQUIRED TO USE column must be
implemented in iSCSI devices that elect to use the iSNS.
Gibbons, Tseng, Monia Standards Track 21
iSNS March 2001
REQUIRED TO:
Message Description Abbreviation Func ID Implement Use
------------------- ------------ ------- --------- ---
Register Dev Attr Req RegDevAttr 0x0001 * *
Dev Attr Query Request DevAttrQry 0x0002 * *
Dev Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DeregDev 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
Register DD RegDD 0x0009 * *
Deregister DD DeregDD 0x000A * *
Register Dev in DD RegDevDD 0x000B * *
Deregister Dev in DD DeregDevDD 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E
NOT USED 0x000F
Request Network Time RqstTime 0x0010
NOT USED 0x0011-0x0012
RESERVED 0x0013-0x8000
The following are iSNSP response messages used in support of iSCSI:
REQUIRED TO:
Response Message Desc Abbreviation Func_ID Implement Use
--------------------- ------------ ------- --------- ---
Register Dev Attr Rsp RegDevRsp 0x8001 * *
Dev Attr Query Resp DevAttrQryRsp 0x8002 * *
Dev Get Next Resp DevGetNextRsp 0x8003 *
Deregister Dev Resp DeregDevRsp 0x8004 * *
SCN Register Resp SCNRegRsp 0x8005 *
SCN Deregister Resp SCNDeregRsp 0x8006 *
SCN Event Resp SCNEventRsp 0x8007 *
SCN Response SCNRsp 0x8008 *
Register DD Resp RegDDRsp 0x8009 * *
Deregister DD Resp DeregDDRsp 0x800A * *
Register Dev in DD Resp RegDevDDRsp 0x800B * *
Deregister Dev in DD Resp DeregDevDDRsp 0x800C * *
Entity Stat Inquiry Resp ESIRsp 0x800D *
NOT USED 0x800E-0x800F
Request Net Time Resp RqstTimeRsp 0x8010
NOT USED 0x8011-0x8012
RESERVED 0x8013-0xFFFF
5.2 iFCP Requirements
In iFCP, use of iSNS is REQUIRED. No alternatives exist for
support of iFCP Naming & Discovery functions. iSNS is integral to
the operation of iFCP, in order to allow iFCP gateways to execute
Fibre Channel S_ID and D_ID address mappings to remote gateways.
5.2.1 Required Attributes for Support of iFCP
Gibbons, Tseng, Monia Standards Track 22
iSNS March 2001
The following table displays attributes that are used by iSNS to
support iFCP. Attributes indicated in the REQUIRED TO IMPLEMENT
column MUST be supported by the iSNS server that supports iFCP.
Attributes indicated in the REQUIRED TO USE column MUST be
supported by iFCP gateways.
REQUIRED REQUIRED
Object Attribute to Implement to Use
------ --------- ------------ --------
NETWORK ENTITY Entity Identifier * *
Entity Type * *
Management IP Address
ESI Interval * *
Timestamp *
Entity Certificate *
SCN Event Bitmap *
ESI TCP/UDP Port * *
PORTAL IP Address * *
TCP/UDP Port * *
Portal Symbolic Name *
STORAGE NODE Node Name * *
Node Type * *
Alias/Node Symbolic Name *
FC Node IP Address *
FC Node IPA *
Node Certificate *
DISCOVERY DOMAIN DD_ID * *
DD_Symbolic Name *
DD Member (Entity ID) *
DD_Member (IP Address) *
DD Member (WWPN) * *
DD Member (WWNN) *
STORAGE PORT Port Name (WWPN) * *
Port_ID * *
Port Type * *
Port Symbolic Name *
FC Fabric Port Name (FWWN) *
FC Hard Address *
FC Port IP Address *
FC Class of Service *
FC FC-4 Types *
FC FC-4 Descriptors *
FC FC-4 Features *
5.2.2 Attribute Descriptions for iFCP Gateways and FC devices
The iSNS attributes used to represent iFCP Storage Systems are
shown and described in the following figure:
Gibbons, Tseng, Monia Standards Track 23
iSNS March 2001
- iFCP NETWORK ENTITY
|
- Entity Identifier
| By convention this is the DNS name of the
| Portal IP-Address(es). If it is not registered
| the iSNS will assign a unique alphanumeric
| identifier to it.
- Entity Type
| Indicates this is an iFCP registration
- Management IP-Address
| If it is not registered then in-band management
| is assumed.
- Entity Status Inquiry Interval
| 0 if no status inquiry is used
- Timestamp
| Last registration update. Maintained by the iSNS.
- Entity Certificate
| X.509 certificate bound to the Entity (FQDN)
- SCN Event Bitmap
| Indicates current SCN state
- ESI TCP/UDP Port
| Destination port number for ESI messages
|
- PORTAL (1 - n per ENTITY)
| |
| - IP-Address
| - TCP/UDP Port
| | The IP-Address and Port combined uniquely
| | define a portal.
| - Portal Symbolic Name
|
- NODE (1 - m per ENTITY)
|
- Node Name (WWNN)
- Node Type (initiator / target / ...)
- Alias/Node Symbolic Name
- FC Node IP-Address
- FC Node IPA
- Node Certificate
|
- PORT (1 - k per NODE)
|
- Port Name (WWPN)
- Port ID
- Port Type
- Port Symbolic Name
- FC Fabric Port Name (FWWN)
- FC Hard Address
- FC Port IP Address
- FC Class of Service
- FC FC-4 Types
- FC FC-4 Descriptor
Gibbons, Tseng, Monia Standards Track 24
iSNS March 2001
- FC FC-4 Features
5.2.3 iFCP Attribute Requirements
5.2.3.1 Port_ID
Port_ID assignments for each STORAGE PORT object within a single
NETWORK ENTITY SHALL be unique. For each NETWORK ENTITY (i.e.,
iFCP gateway), no more than one STORAGE PORT can be assigned a
given PORT_ID value.
5.2.4 Example iFCP Object Model Diagram
The iFCP protocol allows native Fibre Channel devices, or Fibre
Channel fabrics connected to an iFCP gateway, to be directly
internetworked using IP.
When supporting iFCP, the iSNS stores the attributes of the Fibre
Channel devices themselves, attributes of the iFCP gateway, as well
as 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 the two Fibre Channel devices behind it. The
NETWORK ENTITY object represents the iFCP gateway itself, while
each of the STORAGE NODE objects represents an actual Fibre Channel
device. One of the target devices has two ports, each represented
by a STORAGE PORT object.
Gibbons, Tseng, Monia Standards Track 25
iSNS March 2001
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL | | PORTAL | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| | Fibre Channel Loop or Fabric | |
| +-------+ +-----------------+ +----------------+ +--------+ |
| | | | | | | |
| +-+-----+ +-----+-+ +--+----+ +------+---+-----+ +-----+--+ |
| | |STORAGE PORT | | | |STORAGE PORT | |STORAGE PORT | | |
| | | -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 | | |
| | +-------------+ | | +-------------+ +-------------+ | |
| | | | | |
| | STORAGE NODE | | STORAGE NODE | |
| | -WWNN 1 | | -WWNN 2 | |
| | -Symbolic Name| | -Symbolic Name | |
| | -FC Node IPA | | -FC Node IPA | |
| | -Type: target | | -Type: target | |
| | | | | |
| +-----------------+ +-------------------------------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (FQDN): "gtwy1.foo.com" |
| -Type: iFCP |
| |
+---------------------------------------------------------------+
5.2.5 Required Commands and Response Messages for Support of iFCP
The iSNSP messages and responses displayed in the following tables
are available to support iFCP gateways. Messages indicated in the
REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server
used by iFCP gateways. Messages indicated in the REQUIRED TO USE
column MUST be supported by the iFCP gateways themselves.
Gibbons, Tseng, Monia Standards Track 26
iSNS March 2001
REQUIRED TO:
Message Description Abbreviation Func ID Implement Use
------------------- ------------ ------- --------- ---
Register Dev Attr Req RegDevAttr 0x0001 * *
Dev Attr Query Request DevAttrQry 0x0002 * *
Dev Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DeregDev 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
Register DD RegDD 0x0009 * *
Deregister DD DeregDD 0x000A * *
Register Dev in DD RegDevDD 0x000B * *
Deregister Dev in DD DeregDevDD 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E *
Reserved Reserved 0x000F
Request Network Time RqstTime 0x0010
Request Domain ID RqstDmnId 0x0011
Release Domain ID RlseDmnId 0x0012
Get Domain IDs GetDmnIds 0x0013
RESERVED 0x0014-0x8000
The following are iSNSP response messages in support of iFCP:
REQUIRED TO:
Response Message Desc Abbreviation Func_ID Implement Use
--------------------- ------------ ------- --------- ---
Register Dev Attr Rsp RegDevRsp 0x8001 * *
Dev Attr Query Resp DevAttrQryRsp 0x8002 * *
Dev Get Next Resp DevGetNextRsp 0x8003 *
Deregister Dev Resp DeregDevRsp 0x8004 * *
SCN Register Resp SCNRegRsp 0x8005 *
SCN Deregister Resp SCNDeregRsp 0x8006 *
SCN Event Resp SCNEventRsp 0x8007 *
SCN Response SCNRsp 0x8008 *
Register DD Resp RegDDRsp 0x8009 * *
Deregister DD Resp DeregDDRsp 0x800A * *
Register Dev in DD Resp RegDevDDRsp 0x800B * *
Deregister Dev in DD Resp DeregDevDDRsp 0x800C * *
Entity Stat Inquiry Resp ESIRsp 0x800D *
NOT USED 0x800E-0x800F
Request Net Time Resp RqstTimeRsp 0x8010
Request Domain ID Resp RqstDmnIdRsp 0x8011
Release Domain ID Resp RlseDmnIdRsp 0x8012
Get Domain IDs GetDmnIds 0x0013
RESERVED 0x8014-0xFFFF
5.3 FCIP Requirements
Use of iSNS in support of FCIP is OPTIONAL. iSNS MAY be used to
provide dynamic tunnel endpoint discovery. iSNS MAY also be used
Gibbons, Tseng, Monia Standards Track 27
iSNS March 2001
to allocate DOMAIN_ID addresses, in an FCIP/Fibre Channel fabric
implementation with multiple Autonomous Regions.
5.3.1 Required Attributes for Support of FCIP
The following lists attributes used in support of FCIP. Attributes
indicated in the REQUIRED TO IMPLEMENT column MUST be supported by
the iSNS server. Attributes indicated in the REQUIRED TO USE
column MUST be supported by an FCIP gateway that elects to use the
iSNS for dynamic tunnel endpoint discovery.
REQUIRED REQUIRED
Object Attribute to Implement to Use
------ --------- ------------ --------
NETWORK ENTITY Entity Identifier * *
Entity Type * *
Management IP Address
ESI Interval * *
Timestamp *
Entity Certificate *
SCN Event Bitmap *
ESI TCP/UDP Port *
PORTAL IP Address * *
TCP/UDP Port * *
Portal Symbolic Name *
5.3.2 Attribute Descriptions for FCIP Gateways
The iSNS attributes used to represent FCIP gateways are shown and
described in the following figure:
- FCIP NETWORK ENTITY
|
- Entity Identifier
| By convention this is the DNS name of the
| Portal IP-Address(es). If it is not registered
| the iSNS will assign a unique alphanumeric
| identifier to it.
- Entity Type
| Indicates this is an FCIP registration
- Mgt IP-Address
| If it is not registered then in-band management
| is assumed.
- Entity Status Inquiry Interval
| 0 if no status inquiry is used
- Timestamp
| Last registration update / status inquiry received
- Entity Certificate
| X.509 certificate bound to the Entity (FQDN)
- SCN Event Bitmap
| Indicates current SCN state
- ESI TCP/UDP Port
Gibbons, Tseng, Monia Standards Track 28
iSNS March 2001
| Destination port number for ESI messages
- PORTAL (1 - n per ENTITY)
|
- Index
- IP-Address
- TCP/UDP Port
| The IP-Addr and Port combined uniquely
| define a portal.
- Portal Symbolic Name
5.3.3 Example FCIP Object Model Diagram
The following diagram depicts FCIP gateways stored in the iSNS. In
FCIP, the iSNS is only used for tunnel endpoint discovery.
Therefore, no information about the storage end nodes are
registered in the iSNS, and the STORAGE PORT and STORAGE NODE
objects are not applicable.
+----------------------------------------------------------------+
| IP Network |
+-------------+-------------------------+----------------+-------+
| | |
| | |
+-----+-------+------+----+ +-+------+------+--+------+-----+-+
| | PORTAL | | | | PORTAL | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | | -IP Addr 3 | |
| | -TCP Port 1 | | | | -TCP Port 2 | | -TCP Port 3| |
| +--------------+ | | +-------------+ +------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (FQDN): | | -Entity ID (FQDN): |
| "Tunnelgtwy1.foo.com" | | "Tunnelgtwy2.bar.com" |
| -Type: FCIP | | -Type: FCIP |
+-------------------------+ +---------------------------------+
5.3.4 Required Commands and Response Messages for Support of FCIP
The following tables display iSNS messages and responses that are
used to support FCIP. Messages indicated in the REQUIRED TO
IMPLEMENT column MUST be supported by the iSNS server used to
support FCIP. Messages indicated in the REQUIRED TO USE column
MUST be supported by the FCIP gateway that elects to use the iSNS.
Gibbons, Tseng, Monia Standards Track 29
iSNS March 2001
REQUIRED TO:
Message Description Abbreviation Func ID Implement Use
------------------- ------------ ------- --------- ---
Register Dev Attr Req RegDevAttr 0x0001 * *
Dev Attr Query Request DevAttrQry 0x0002 * *
Dev Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DeregDev 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
Register DD RegDD 0x0009 * *
Deregister DD DeregDD 0x000A * *
Register Dev in DD RegDevDD 0x000B * *
Deregister Dev in DD DeregDevDD 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E *
Reserved Reserved 0x000F
Request Network Time RqstTime 0x0010
Request Domain ID RqstDmnId 0x0011
Release Domain ID RlseDmnId 0x0012
Get Domain IDs GetDmnIds 0x0013
RESERVED 0x0014-0x8000
The following are iSNSP response messages in support of FCIP:
REQUIRED TO:
Response Message Desc Abbreviation Func_ID Implement Use
--------------------- ------------ ------- --------- ---
Register Dev Attr Rsp RegDevRsp 0x8001 * *
Dev Attr Query Resp DevAttrQryRsp 0x8002 * *
Dev Get Next Resp DevGetNextRsp 0x8003 *
Deregister Dev Resp DeregDevRsp 0x8004 * *
SCN Register Resp SCNRegRsp 0x8005 *
SCN Deregister Resp SCNDeregRsp 0x8006 *
SCN Event Resp SCNEventRsp 0x8007 *
SCN Response SCNRsp 0x8008 *
Register DD Resp RegDDRsp 0x8009 * *
Deregister DD Resp DeregDDRsp 0x800A * *
Register Dev in DD Resp RegDevDDRsp 0x800B * *
Deregister Dev in DD Resp DeregDevDDRsp 0x800C * *
Entity Stat Inquiry Resp ESIRsp 0x800D *
NOT USED 0x800E-0x800F
Request Net Time Resp RqstTimeRsp 0x8010
Request Domain ID Resp RqstDmnIdRsp 0x8011
Release Domain ID Resp RlseDmnIdRsp 0x8012
Get Domain IDs Resp GetDmnIdsRsp 0x8013
RESERVED 0x8014-0xFFFF
5.4 Attribute Descriptions for Discovery Domain Registration
Gibbons, Tseng, Monia Standards Track 30
iSNS March 2001
Discovery Domains are a required iSNS attribute for all protocols.
The iSNS attributes for Discovery Domain registration are shown in
the following figure:
DISCOVERY DOMAIN
|
- DD_ID
- DD_Symbolic Name
DD_MEMBER
|
- DD_ID
- Entity Identifier, WWUI, WWNN, WWPN, IP-Address or FWWN
Members of a Discovery Domain can be defined by registering one of
the following storage entity attributes in a Discovery Domain:
- Entity Identifier: this places all contained iSCSI or
iFCP storage nodes, or FCIP gateways,
in the Discovery Domain
- WWUI : this places the individual iSCSI
storage node in the Discovery Domain
- WWNN : this places all associated iFCP
ports in the Discovery Domain
- WWPN : this places the associated iFCP
port in the Discovery Domain
- FWWN : this places all iFCP ports
attached to the Fabric Port in
the Discovery Domain
- IP-Address : this places all associated iSCSI storage
nodes or FCIP storage entities in the
Discovery Domain
Discovery Domains are logical groupings of initiators and targets
that are used to limit the login process to the appropriate subset
of devices registered in the iSNS. Discovery Domains are described
in Section 3.1.2.
6. iSNS Message Protocol
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). The following
describes the format of the iSNSP PDU:
Gibbons, Tseng, Monia Standards Track 31
iSNS March 2001
Byte MSb LSb
Offset 31 0
+---------------------+----------------------+
0 | iSNSP VERSION | FUNCTION ID | 4 Bytes
+---------------------+----------------------+
4 | PDU LENGTH | FLAGS | 4 Bytes
+---------------------+----------------------+
8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes
+---------------------+----------------------+
12 | |
| PDU PAYLOAD | N Bytes
| ... |
+--------------------------------------------+
12 + N | AUTHENTICATION BLOCK (if present) | L Bytes
+--------------------------------------------+
Total Length = 12 + N
6.1 iSNS PDU Header
The iSNSP header contains the iSNSP VERSION, FUNCTION ID, PDU
LENGTH, FLAGS, TRANSACTIONID, and SEQUENCE ID fields as defined
below:
iSNSP VERSION - Currently 0x0001
FUNCTION ID defines the type of iSNS message. It indicates the
function the message is supporting. See section 5 under the
appropriate protocol (i.e., iSCSI, iFCP, and/or FCIP) for a mapping
of the FUNCTION_ID value to the iSNSP Command or Response message.
All PDU's comprising an iSNSP message must have the same
FUNCTION_IDand TRANSACTION ID value.
iSNS PDU LENGTH - Specifies the length of the PDU PAYLOAD field in
bytes.The payload contains the data/attribute values for the
operation.
FLAGS - Indicates additional information about the message and the
type of iSNS entity that generated the message. The following
table displays the valid flags:
Bit Field Enabled Means:
--------- -------------
0-9 RESERVED
10 First PDU of the iSNS message
11 Last PDU of the iSNS message
12 Update Flag (used only for RegDevAttr)
13 Authentication Block Present
14 Sender is the iSNS server
15 Sender is the iSNS client
TRANSACTION ID - Is set to a unique random value for each request
message. Replies MUST use the same TRANSACTION ID value as the
Gibbons, Tseng, Monia Standards Track 32
iSNS March 2001
associated iSNS request message. If a message is retransmitted,
the same TRANSACTION ID value MUST be used.
SEQUENCE ID - Is set to a unique value for each PDU within a single
transaction. Each SEQUENCE_ID value in each PDU SHALL be numbered
sequentially in the order that the PDU's are transmitted. If a
message is retransmitted, then the same SEQUENCE_ID value MUST be
used for all PDU's in the message.
6.2 iSNS Message Segmentation and Reassembly
iSNS messages may be carried in one or more iSNS PDU's. If only
one iSNS PDU is used to carry the iSNS message, then bit 10 (First
PDU) and bit 11 in the FLAGS field (Last PDU) SHALL both be
enabled. If multiple PDUs are used to carry the iSNS message, then
bit 10 SHALL be enabled in the first PDU of the message, and bit 11
SHALL be enabled in the last PDU.
All PDU's comprising the same iSNSP message SHALL have the same
FUNCTION_ID and TRANSACTION_ID values. Each PDU comprising an
iSNSP message SHALL have a unique SEQUENCE_ID value. The recipient
of the iSNSP message SHALL NOT process the message until it
receives
The authentication operation described in section 6.4 SHALL be
performed on a per-PDU basis.
6.3 iSNS Message Payload
The MESSAGE PAYLOAD is variable length and contains attributes used
for registration and query operations. The attribute data items
use a format similar to other protocols, such as DHCP (RFC 2131)
options. Each iSNS attribute is specified in the iSNSP message
payload using Tag-Length-Value (TLV) data format, as shown below:
Byte MSb LSb
Offset 31 0
+--------------------------------------------+
0 | Attribute Tag | 4 Bytes
+--------------------------------------------+
4 | Attribute Length (N) | 4 Bytes
+--------------------------------------------+
8 | |
| Attribute Value | N Bytes
| |
+--------------------------------------------+
Total Length = 8 + N
Attribute Tag - a 4-byte tag field that identifies the attribute as
defined in section 5.5. This field contains the ID of the
indicated attribute.
Gibbons, Tseng, Monia Standards Track 33
iSNS March 2001
Attribute Length - a 4-byte field that indicates the length, in
bytes, of the attribute value to follow.
Attribute Value - a variable-length field containing the attribute
value.
The above format is used to identify each attribute in the iSNS
message payload. Each iSNSP request message contains several
attributes in the above format to identify the requesting iSNS
client and register or query for attribute values in the iSNS
server.
For iSNS response messages sent by the iSNS server to the client, a
4-byte ERROR CODE field is included as the first field in the iSNSP
PAYLOAD. This field contains 0x00000000 (NO ERROR) if the original
iSNSP request message was processed normally by the iSNS server.
Error Code Error Description
---------- -----------------
0 No Error
1 Unknown Error
2 Message Format Error
3 Invalid Registration
4 Invalid Registration Update
4 Invalid Query
5 Authentication Unknown
6 Authentication Absent
7 Authentication Failed
8 No Such Entry
9 Version Not Supported
10 Internal Bus Error
11 Busy Now
12 Option Not Understood
13 Invalid Update
14 Message Not Supported
15 SCN Event Rejected
16 SCN Registration Rejected
17 Entity Status Inquiry (ESI) Not Available
18 DOMAIN_ID not available
For iSNS State Change Notification message and Request Network Time
Response messages, a 4-byte TIMESTAMP field is included. The
TIMESTAMP is a 4-byte unsigned, fixed-point integer giving the
number of seconds since 00:00:00 GMT on January 1, 1970.
6.4 Message Authentication
iSNSP provides an optional PDU authentication capability. Network
interactions using iSNSP occur in short transactions, and are
generally not session based. The iSNS client connects to the iSNS
server only when information needs to be registered or queried.
Gibbons, Tseng, Monia Standards Track 34
iSNS March 2001
Public Key Encryption MAY be used for message authentication. If a
public key infrastructure is not available, a shared secret
algorithm MAY alternatively be used. A shared secret mechanism may
leverage a Kerberos server, or may involve manual distribution of a
private key to the iSNS server and each iSNS client.
If a PKI is available with an X.509 certificate authority, then
public key authentication of clients is possible. The
authentication block leverages the DSA with SHA-1 algorithm, which
can easily integrate into a public key infrastructure.
The SNSP optional authentication block is a digital signature for
the iSNSP PDU. The digital signature is calculated on a per-PDU
basis. The authentication block contains the following
information:
1. A time stamp, to prevent replay attacks
2. A structured authenticator containing a signature calculated
over the time stamp and the message being secured
3. An indicator of the cryptographic algorithm that was used to
calculate the signature.
4. An indicator of the keying material and algorithm parameters,
used to calculate the signature.
The authentication block is described in the following figure:
Byte MSb LSb
Offset 7 6 5 4 3 2 1 0
+----------------------------------+
0 | AUTHENTICATION BLOCK LENGTH | 2 Bytes
+----------------------------------+
2 | BLOCK STRUCTURE DESCRIPTOR | 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
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.
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
Gibbons, Tseng, Monia Standards Track 35
iSNS March 2001
PKI specification, allowing easy integration of the STRUCTURED
AUTHENTICATOR format with an existing PKI infrastructure.
TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving
the number of seconds since 00:00:00 GMT on January 1, 1970.
SPI STRING LENGTH - The length of the SPI STRING field.
SPI STRING (Security Parameters Index) - Index to the key and
algorithm used by the message recipient to decode the STRUCTURED
AUTHENTICATOR field.
STRUCTURED AUTHENTICATOR - Contains the digital signature. For the
default BSD value of 0x0002, this field contains the binary ASN.1
encoding of output values from the DSA with SHA-1 signature
calculation.
6.5 iSNS Client Registration Attributes
When an iSNS client registers with the iSNS server, it provides
attribute values to describe the entity characteristics and
capabilities. The attributes are also returned by the iSNS server
in response to queries.
The following table lists all iSNSP message attributes for device
registration and queries:
Gibbons, Tseng, Monia Standards Track 36
iSNS March 2001
Attribute Name Length(bytes) Tag Reg Key Query Keys
-------------- ------------- --- ------- ----------
Delimiter 0 0 N/A N/A
Entity Identifier 0-255 1 N/A 1,3,17,32,34,64
Entity Type 4 2 1 1,3,17,32,34,64
Management IP Address 16 3 1 1,3,17,32,34,64
ESI Interval 4 4 1 1,3,17,32,34,64
ESI TCP/UDP Port 4 5 1 32,1&33,34,64
Timestamp 8 6 1 1,3,17,32,34,64
Entity Event Bitmap 4 7 1 32,1&33,34,64
Entity Certificate variable 8 1 32,1&33,34,64
Portal IP Address 16 16 1 1,32,64
Portal TCP/UDP Port 4 17 1 1,32,64
Portal Symbolic Name 0-255 18 16&17 1,32,64
WWUI 4-255 32 1 1,32,1&33
Node Name (WWNN) 8 33 1 1,34,64
Node Type 4 34 32 or 33 32,1&33,34,64
Alias/Symbolic Node Name 0-255 35 32 or 33 32,1&33,34,64
FC Node IP Address 16 36 33 34,64
FC Node IPA 8 37 33 34,64
Node Certificate variable 38 32 or 33 32,1&33,34,64
Port Name (WWPN) 8 64 33 1,34,66,68,71,72
Port ID 4 65 64 64,17,65
Port Type 4 66 64 64,17&65
Port Symbolic Name 0-255 67 64 64,17&65
Fabric Port Name (FWWN) 8 68 64 64,17&65
FC Hard Address 4 69 64 64,17&65
FC Port IP Address 16 70 64 64,17&65
FC Class of Service 4 71 64 64,17&65
FC FC-4 Types 32 72 64 64,17&65
FC FC-4 Descriptor 0-255 73 64 64,17&65
FC FC-4 Features 128 74 64 64,17&65
User-Specific-Entity 0-65536 128-255 1 --user defined--
User-Specific-Portal 0-65536 256-383 16&17 --user defined--
User-Spec-iSCSI-Node 0-65536 384-511 32 --user defined--
User-Spec-iFCP-Node 0-65536 512-639 33 --user defined--
User-Spec-iFCP-Port 0-65536 640-767 64 --user defined--
RESERVED 768-895
Vendor-Specific-DD 0-65536 896-1023 101 --vendor defined--
Vendor-Specific-DD 0-65536 896-1023 101 --vendor defined--
Vendor-Specific 0-65536 1024-2047 --vendor defined--
RESERVED 2048-65535
The following is a description of the columns used in the above
table:
Size - indicates the attribute length. Variable-length identifiers
are NULL character terminated, which is included in the length.
Tag - the value used to identify the attribute. All undefined tag
values are reserved.
Gibbons, Tseng, Monia Standards Track 37
iSNS March 2001
Reg Key - indicates the attribute ID(s) that is (are) the unique
key used for attribute registration. This attribute is also known
as the primary key for the iSNS directory database entry.
Query Keys - indicates the attribute IDs that can be used to query
the iSNS directory database.
iSNS client attributes are defined below.
6.5.1 Entity Identifier-Keyed Attributes
The following attributes are registered in the iSNS using the
Entity Identifier attribute as the key.
6.5.1.1 Entity Identifier (DNS Name)
The Entity Identifier is a variable length identifier that uniquely
identifies an entity registered in the iSNS. The attribute length
varies from 1 to 255 bytes, and is a unique value within the iSNS.
By convention the Entity Identifier is the DNS Name used by the
entity. The Entity Identifier along with the Alias can be used to
uniquely identify and address any associated STORAGE NODE.
If the iSNS client does not provide an Entity Identifier during
registration, the iSNS shall generate one that is unique within the
iSNS.
6.5.1.2 Entity Type
Entity Type is a 2-byte field that indicates the type of network
entity that is being registered and is provided by the iSNS client.
The valid types are defined as below.
Type Value Entity Type
---------_ -----------
1 iSCSI
2 iFCP
3 FCIP
All Others RESERVED
6.5.1.3 Management IP Address
This optional field is provided by the iSNS client. It contains
the IP Address used to manage the entity. The Management IP
Address is a 16-byte field that may contain either a 32-bit IPv4 or
128-bit IPv6 address. When this field contains an IPv4 value, the
most significant 12 bytes are set to 0x00. If the network entity
is capable of being managed and this field is not set, then in-band
management is assumed.
6.5.1.4 Entity Status Inquiry Interval
Gibbons, Tseng, Monia Standards Track 38
iSNS March 2001
This optional field is provided by the iSNS client. It indicates
the minimum time, in seconds, between Entity Status Inquiry (ESI)
messages sent from the iSNS to a client. ESI messages can be used
to verify that a client registration continues to be valid. To
request monitoring by the iSNS, an iSNS client registers a non-zero
value for this attribute using a RegDevAttr message. If the value
is 0 then entity status messages SHALL not be sent.
If the iSNS is unable to issue ESI messages, it SHALL reject the
ESI request by returning a "ESI Not Available" error code. The
rejection might occur in situations where the resulting frequency
of ESI messages being issued to clients would pass an
implementation-specific threshold. If the registration is part of
a multi-attribute RegDevAttr message and the registration is
rejected with _ESI Not Available_, then the multi-attribute
registration SHALL be resent with a ESI value of 0.
6.5.1.5 ESI TCP/UDP Port
This is the TCP or UDP Port Number of the iSNS client entity uses
to receive ESI messages from the iSNS server and transmit ESI
responses.
6.5.1.6 Entity Registration Timestamp
Indicates the time the client registration occurred, or the most
recent response from the iSNS client to the Client Status Inquiry
message, whichever is later. It is the time, in milliseconds,
after the standard base time of 00:00:00 GMT on January 1, 1970,
that the update occurred. The timestamp can be used to ensure the
SNS directory does not contain entries for non-existent devices.
An implementation may decide to remove stale registrations of iSNS
clients that exceed an implementation-specific threshhold age
limit.
6.5.1.7 Entity Event Bitmap
This optional field is provided by the iSNS client. It indicates
the events that the client is interested in. These events can
cause SCN to be generated.
Bit Field Flag Description
--------- ----------------
0 CHANGE IN DD MEMBERSHIP
1 CHANGE IN NETWORK
2 CHANGE IN DEVICE REGISTRATION PARAMETERS
3 DEVICE ADDED
4 DEVICE REMOVED
5 CLIENT STATUS UPDATE REQUESTED (for CSI message)
6.5.1.8 Entity Certificate
Gibbons, Tseng, Monia Standards Track 39
iSNS March 2001
This optional attribute contains an X.509 certificate that is bound
to the NETWORK ENTITY of the iSNS client. For example, in FCIP
this X.509 certificate may have the Fully Qualified Domain Name of
the FCIP gateway device. This certificate is uploaded and
registered to the iSNS by clients wishing to allow other clients to
authenticate themselves and access the services offered by that
NETWORK ENTITY. This certificate MAY also be used to set up the
TLS association between the iSNS client and server, as well as to
key the authentication block in the iSNSP.
6.5.2 Portal-Keyed Attributes
The following attributes are registered in the iSNS using the
combined Portal IP-Address and Portal TCP/UDP Port as the key.
Each set of Portal-Keyed attributes is also associated with one
Entity Identifier object key.
Although the combined Portal IP-Address and Portal TCP/UDP Port key
is associated with one Entity Identifier, it is unique across the
entire iSNS.
6.5.2.1 Portal IP Address
The IP address of the PORTAL through which a STORAGE NODE can
transmit and receive storage data. This required field is provided
by the iSNS client. When an IPv4 value is contained in this field,
the most significant 12 bytes are set to 0x00. The Portal IP
Address along with the Portal TCP/UDP Port number uniquely
identifies a Network Entity Portal.
6.5.2.2 Portal TCP/UDP Port
The TCP/UDP port of the PORTAL through which a STORAGE NODE can
transmit and receive storage data. This required field is provided
by the iSNS client. If the value is 0, then the port number is the
implied canonical port number of the protocol being used. The
Portal IP Address along with the Portal TCP/UDP Port number
uniquely identifies a Network Entity Portal.
6.5.2.3 Portal Symbolic Name
This is an optional, variable-length text-based value from 0 to 255
bytes. The text field contains user-readable ASCII text, and is
terminated with at least one NULL character. The Portal Symbolic
Name is a user-readable description of the Portal entry in the
iSNS.
6.5.3 Node-Keyed Attributes
The following attributes are registered in the iSNS using the WWUI
(for iSCSI) or WWNN (for iFCP) attribute as the key. Each set of
Node-Keyed attributes is also associated with one Entity Identifier
object key.
Gibbons, Tseng, Monia Standards Track 40
iSNS March 2001
Although the WWUI (for iSCSI) or WWNN (for iFCP) key is associated
with one Entity Identifier, it is unique across the entire iSNS.
6.5.3.1 World Wide Unique Identifier (WWUI)
This identifier uniquely defines an iSCSI STORAGE NODE. This field
is required for iSCSI STORAGE NODEs, and is provided by the iSNS
client.
6.5.3.2 Alias/Symbolic Node Name
This is an optional, variable-length text-based value from 0 to 255
bytes. The text field contains user-readable ASCII text, and is
terminated with at least one NULL character. The Alias is a user-
readable description of the node entry in the iSNS. The Node
Symbolic Name is available for use by both Fibre Channel and iSCSI
clients.
6.4.3.3 Node Name (WWNN)
Node Name is a 64-bit identifier that uniquely identifies the iFCP
device node in the network, and is provided by a Fibre Channel-
based iSNS client entity. This globally unique identifier is used
during the device registration process, and uses a value conforming
to IEEE Naming Assignment Authority (NAA) type 1, 2, 5, or 6. This
format is found in ANSI/IEEE Std 802-1990 [802-1990].
6.5.3.4 Node Type
This 16-bit field is a bitmap indicating the type of STORAGE NODE.
The fields are defined as below. An enabled bit indicates the node
has the corresponding characteristics.
Bit Field Node Type
--------- ---------
0 (Lsb) Target
1 Initiator
All Others RESERVED
This field will be consistent with the FC-4 Feature bits described
in [FC-GS-3] if the node represents a Fibre Channel device. The
default value for this field is 0x0000, which is "unknown".
6.5.3.5 FC Node IP Address
This optional IP address is associated with the device node in the
network. This field is included for compatibility with Fibre
Channel. When an IPv4 value is contained in this field, the most
significant 12 bytes are set to 0x00. This value is provided by
the iSNS client.
6.5.3.5 FC Node IPA
Gibbons, Tseng, Monia Standards Track 41
iSNS March 2001
This optional 8 byte Fibre Channel Initial Process Associator (IPA)
is associated with the device node in the network. This field is
included for compatibility with Fibre Channel, and is provided by a
Fibre Channel-based iSNS client entity. The initial process
associator can be used for communication between Fibre Channel
devices.
6.5.3.6 Node Certificate
This optional attribute contains an X.509 certificate that is bound
to the STORAGE NODE of the iSNS client. For example, in iSCSI this
X.509 certificate may have the WWUI of the target device. This
certificate is uploaded and registered to the iSNS by clients
wishing to allow other clients to authenticate themselves and
access the STORAGE NODE. This certificate SHOULD NOT be used to
set up the authenticating SA supporting the iSNSP authentication
block.
6.5.4 Storage Port-Keyed Attributes
The following attributes are registered in the iSNS using the Port
Name (WWPN) attribute as the key. Each set of Port-Keyed
attributes is also associated with one Node-Keyed object.
Although the Port Name (WWPN) key is associated with one Node-Keyed
object, it is unique across the entire iSNS.
6.5.4.1 Port Name (WWPN)
This 64-bit identifier uniquely defines the iFCP device port, and
is provided by a Fibre Channel-based iSNS client entity. This
globally unique identifier is used during the device registration
process, and uses a value conforming to IEEE Naming Assignment
Authority (NAA) type 1, 2, 5, or 6. This format is found in
ANSI/IEEE Std 802-1990 [802-1990].
6.5.4.2 Port ID
Along with the IP Address, this field uniquely identifies a native
Fibre Channel device port in the network, and maps one-to-one to a
specific Port Name (WWPN) entry. The Port ID is used for iFCP
based storage devices.
6.5.4.3 Port Type
Indicates the type of iFCP device port. This is provided by the
iSNS client entity. Encoded values for this field are listed in
the following table:
Gibbons, Tseng, Monia Standards Track 42
iSNS March 2001
Type Description
---- -----------
0x0000 Unidentified/Null Entry
0x0001 Fibre Channel N_Port
0x0002 Fibre Channel NL_Port
0x0003 Fibre Channel F/NL_Port
0x0004-0080 RESERVED
0x0081 Fibre Channel F_Port
0x0082 Fibre Channel FL_Port
0x0083 RESERVED
0x0084 Fibre Channel E_Port
0x0085-00FF RESERVED
0xFF11 mFCP Port
0xFF12 iFCP Port
0xFF13-FFFF RESERVED
6.5.4.4 Port Symbolic Name
A variable-length text-based description of up to 255 bytes, that
is associated with the iSNS-registered device port in the network.
The text field contains user-readable ASCII text and is terminated
with at least one NULL character. This optional field is normally
provided by the iSNS client during registration. However, network
management application can update this field as required.
6.5.4.5 Fabric Port Name (FWWN)
This 64-bit identifier uniquely defines the fabric port. If the
iSNS client is attached to a Fibre Channel fabric port with a
registered Port Name, then that fabric Port Name shall be indicated
in this field. This field is included in the iSNSP for
compatibility with Fibre Channel fabric devices and topologies.
The Fabric Port may itself be registered as a port in the iSNS. In
that case, the Fabric Port Name (FWWN) attribute of fabric attached
ports will match the Port Name (WWPN) of the Fabric Port
registration.
6.5.4.6 FC Hard Address
This optional field is the requested hard address 24-bit NL Port
Identifier, included in the iSNSP for compatibility with Fibre
Channel Arbitrated Loop devices and topologies.
6.5.4.7 FC Port IP Address
The IP address associated with the device port in the network.
This optional field is included for compatibility with Fibre
Channel. When an IPv4 value is contained in this field, the most
significant 12 bytes are set to 0x00. This value is provided by
the iSNS client.
6.5.4.8 FC Class of Service (COS)
Gibbons, Tseng, Monia Standards Track 43
iSNS March 2001
This 32-bit bit-map field indicates the FC COS types that are
supported by the registered port. This field is provided by the
Fibre Channel-based iSNS client. The COS values are equivalent to
Fibre Channel COS values. The valid COS types, and associated bit-
map, are listed in the following table:
Class of Service Description Bit-Map
---------------- ----------- ---------
2 Delivery Confirmation Provided bit 2 set
3 Delivery Confirmation Not Provided bit 3 set
RESERVED other
6.5.4.9 FC FC-4 Types
This 32-byte field indicates the FC-4 protocol types supported by
the associated port. This required field for iFCP ports is
provided by the iSNS client. This field can be used to support
Fibre Channel devices.
6.5.4.10 FC FC-4 Descriptor
A variable-length text-based description of up to 255 bytes, that
is associated with the iSNS-registered device port in the network.
This optional field for iFCP ports is provided by the iSNS client.
This field can be used to support Fibre Channel devices.
6.5.4.11 FC FC-4 Features
This is a 128-byte array, 4 bits per type, for the FC-4 protocol
types supported by the associated port. This optional field for
iFCP ports is provided by the iSNS client. This field can be used
to support Fibre Channel devices.
6.5.5 Domain ID
This is a 4-byte field, with a valid value range of 1 _ 239. This
optional field is for iFCP Transparent Mode. When in iFCP
Transparent Mode, the Request Domain ID message SHALL be used by an
iFCP gateway to reserve an available Domain ID for use. When a
Domain ID is no longer required, it SHALL be released by the iFCP
gateway using the Release Domain ID message. The iSNS MAY use the
Client Status Inquiry message to determine if an iFCP gateway is
still present on the network.
6.6 Discovery Domain Registration Attributes
iSNS clients can be placed into areas of control belonging to one
or more Discovery Domains. When an iSNS client or Network
Management System registers a DD, it provides attribute values to
describe the DD characteristics and capabilities. The following
table lists the iSNSP DD attributes:
Gibbons, Tseng, Monia Standards Track 44
iSNS March 2001
Attribute Name Size(bytes) ID Reg Key Query Key
-------------- ----------- -- ------- ---------
DD_ID 4 101 101
DD_Symbolic Name 1-64 102 101 101
DD Member (Ent Ident) 0-255 103 101 101
DD_Member (WWUI) 4-255 104 101 101
DD_Member (WWPN) 8 105 101 101
DD_Member (WWNN) 8 106 101 101
DD_Member (FWWN) 8 107 101 101
DD_Member (IP Addr) 16 108 101 101
Vendor-Specific 0-65535 640-767 101 101
DD_ID - a unique identifier used in the iSNS directory database to
indicate the DD. This value is used as the key for any DD
attribute query. If the iSNS client does not provide a DD_ID in a
DD registration request message, the iSNS shall generate a DD_ID
value that is unique within the iSNS database for that new DD
(i.e., the iSNS client will be registered in a new DD). The DD ID
value of 0 is reserved.
DD_Symbolic Name - an ASCII, variable-length string that is NULL-
terminated. This is an optional user-readable field used to assist
a network administrator in tracking the DD function. When
registered by a client, the DD symbolic name SHALL be verified
unique by the iSNS. If the DD symbolic name is not unique, then
the DD registration SHALL be rejected with an _Invalid
Registration_ error code. The invalid attribute(s), in this case
the DD symbolic name, SHALL be included in the response.
DD_Member (WWUI) - the Entity Identifier of an iSNS client that is
a member of the DD. The DD may have a list of 0 to n members.
Membership is represented by the Entity Identifier of the iSNS
client being listed.
DD_Member (WWUI) - the World Wide Unique Identifier of an iSNS
client that is a member of the DD. The DD may have a list of 0 to
n members. Membership is represented by the WWUI of the iSNS
client being listed.
DD_Member (WWPN) - the Port Name of an iSNS client that is a member
of the DD. The DD may have a list of 0 to n members. Membership
is represented by the Port Name (WWPN) of the iSNS client being
listed.
DD_Member (WWNN) - the Node Name of an iSNS client that is a member
of the DD. The DD may have a list of 0 to n members. Membership
is represented by the Node Name (WWNN) of the iSNS client being
listed.
DD_Member (FWWN) - the Fabric World Wide Name of an iSNS client
that is a member of the DD. The DD may have a list of 0 to n
members. Membership is represented by the FWWN of the iSNS client
being listed.
Gibbons, Tseng, Monia Standards Track 45
iSNS March 2001
DD_Member (IP Addr) - the IP address of an iSNS client that is a
member of the DD. The DD may have a list of 0 to n members. This
IP address indicates that all storage entities using this IP
address are members of the DD.
6.7 Vendor-Specific and User-Specific Attributes
Specific iSNS implementations MAY define vendor-specific attributes
for private use. The tag values reserved for vendor-specific and
user-specific use are defined in section 6.5 and 6.6. To avoid
misinterpreting proprietary attributes, it is RECOMMENDED that the
vendor's own OUI (Organizationally Unique Identifier) be placed in
the upper three bytes of the attribute field itself. If the OUI is
not used, then some other unique marker recognizable by the vendor
SHOULD be used. The OUI is defined in IEEE Std 802-1990, and is
the same constant used to generate 48 bit Universal LAN MAC
addresses. A vendor's own iSNS implementation will then be able to
recognize the OUI in the vendor-specific or user-specific attribute
field, and be able to execute vendor-specific handling of the
attribute.
6.8 State Change Notification and Client Status Inquiry Flags
A State Change Notification (SCN) allows an iSNS client to be
notified of changes within a DD, network, or existing device
attribute values in the iSNS directory database. An iSNS client
registers for SCN's using the SCN Registration Request command.
The SCN message is sent to the iSNS client by the iSNS server.
The types of changes for which SCNs are sent is based on flags set
in the EVENT TYPE FLAGS field. The EVENT TYPE FLAGS field is a 16-
bit mask containing flags for different event types.
Client Status Inquiry (CSI) allows an iSNS server to verify that an
iSNS client entity is still connected to the network. The CSI
message is sent to the iSNS client by the server to verify client
status. If enabled, the iSNS server will send a CSI to request a
Client Status Inquiry Update message from the SCE.
The following table displays the flags in the EVENT TYPE FLAGS
field used in SCNReg, SCN and CSI messages:
Bit Field Flag Description
--------- ----------------
0 CHANGE IN DD MEMBERSHIP
1 CHANGE IN NETWORK
2 CHANGE IN DEVICE REGISTRATION PARAMETERS
3 DEVICE ADDED
4 DEVICE REMOVED
5 CLIENT STATUS UPDATE REQUESTED (for CSI message)
Gibbons, Tseng, Monia Standards Track 46
iSNS March 2001
CHANGE IN DD MEMBERSHIP - indicates a change has occurred in a DD
that the iSNS client is a member of. A client can be a member of
multiple DDs. This flag indicates that a change in registration
parameters or membership has occured, either an addition or
deletion, to a DD that the client is a member of.
CHANGE IN NETWORK - indicates a change in the network has occurred.
The change may be anywhere in the network of devices. This flag is
administratively controlled, and may not be allowed by the iSNS
server except for use by an IP address associated with a Network
Management Station.
CHANGE TO DEVICE REGISTRATION PARAMETERS - indicates a change in a
device registration in the network or DDs that the client is a
member of. This flag is used in conjunction with CHANGE IN DD
MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the change
in device registration occurred in a DD or the network. This flag
may be administratively enabled/disabled.
DEVICE ADDED - indicates a device addition has occurred in the
network or DD. This flag is used in conjunction with CHANGE IN DD
MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the
addition occurred in a DD or the network.
DEVICE REMOVED - indicates a device removal has occurred in the
network or DD. This flag is used in conjunction with CHANGE IN DD
MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the removal
occurred in a DD or the network.
7. iSNSP Message Descriptions
The iSNSP PDU payload follows the iSNSP PDU header described in
section 6.1. The message payload contains a list of attributes,
each in TLV format described in section 6.3.
7.1 Registration and Query Messages
The iSNSP registration and query message payloads contain a list of
attributes, and have the following format:
Gibbons, Tseng, Monia Standards Track 47
iSNS March 2001
MSb LSb
31 0
+----------------------------------------+
| Source Attribute |
+----------------------------------------+
| Key Attribute[1] |
+----------------------------------------+
| Key Attribute[2] (if present) |
+----------------------------------------+
| Key Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| - Delimiter Attribute - |
+----------------------------------------+
| Operating Attribute[1] |
+----------------------------------------+
| Operating Attribute[2] (if present) |
+----------------------------------------+
| Operating Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
iSNS Registration and Query messages, sent by iSNS Clients, are
sent to the iSNS IP-Address and TCP/UDP Port. The iSNS Responses
will be sent to the iSNS Client IP-Address and the originating
TCP/UDP Port used for the associated registration and query
message.
7.1.1 Source Attribute
The source attribute is used to identify the iSNS client to the
iSNS server. The source attribute is an attribute that uniquely
identifies the source of the message. Valid source attribute types
are shown below.
Valid Source Attributes
-----------------------
Entity Identifier
WWUI (iSCSI only)
Node WWN (iFCP only)
Port WWN (iFCP only)
The source attribute is used to bind the scope of a query into the
Discovery Domains of which the source is a member.
The iSNS may validate that the Source Attribute matches client
certificate information. If the iSNS is validating Source
Attribute information, and the Source Attribute does not match the
client certificate, then the request will be rejected with an
authentication error code.
Gibbons, Tseng, Monia Standards Track 48
iSNS March 2001
7.1.1.1 Source Attribute for Initial Registration
A length value of 0 in the source attribute TLV is valid for
initial client registration when the iSNS is being used to assign a
unique Entity Identifier to the client. In this case, since the
Entity Identifier will not yet have been assigned, the source
attribute field will contain a 0 length Entity Identifier. The
response message to the registration will contain the assigned
identifier.
7.1.2 Key Attribute
Key attributes are used to identify the object (or objects) in the
iSNS server that the registration or query operation will be
performed on. The number of Key Attributes depends on the specific
iSNSP request or query operation being performed. Following the
set of Key Attributes is a Delimiter Attribute, whose tag value is
0.
7.1.2.1 Key Attribute for Initial Registration
A length value of 0 in the key attribute TLV is valid for initial
client registration when the iSNS is being used to assign a unique
Entity Identifier to the client. In this case, the Entity
Identifier will not yet have been assigned. The key attribute
field will contain a 0 length Entity Identifier. The response
message to the registration will contain the assigned identifier.
7.1.3 Delimiter Attribute
The Delimiter Attribute separates the key and operating attributes
in a message. The Delimiter Attribute has a tag value of 0 and a
length value of 0. The Delimiter Attribute is effectively 8 Bytes
long, a 4 Byte tag containing 0x00000000, and a 4 Byte length field
containing 0x00000000.
7.1.4 Operating Attributes
The Operating Attributes are a list of one or more attributes
related to the actual iSNS registration or query operation being
performed.
The number of Operating Attributes depends on the specific iSNSP
request or query. For example, the Operating Attributes in a
Device Attribute Query message are the set of attributes to be
returned in the associated Device Attribute Query Response message
that match the Key Attributes of the query.
Some iSNSP messages do not require any Operating Attributes.
7.1.4.1 Operating Attributes for Query and Get Next Requests
Gibbons, Tseng, Monia Standards Track 49
iSNS March 2001
A length value of 0 in an Operating Attribute TLV is valid for
query request and get next messages, where the iSNS will be
returning matching attribute values in the response message. In
this case the Operating Attributes indicate the desired attributes
to be returned in the response and therefore do not require values.
The response message will contain valid values for the Operating
Attributes if the Key Attributes in the query or get next are
matched.
7.1.5 Registration and Query Message Types
The following describes each query and message type.
7.1.5.1 Register Device Attribute Request (RegDevAttr)
The RegDevAttr message type is 0x0001. The RegDevAttr message
provides an iSNS client with the means to register network
entities. The iSNS client formulates a RegDevAttr by specifying a
Source, Key Attribute(s), and list of Operating Attributes to
register. All values are in Tag Length Value (TLV) format. The
Source attribute of the RegDevAttr message is as defined in Section
7.1.1.
For the initial network entity registration the Key Attribute SHALL
be the Entity Identifier. A length value of 0 in the key attribute
TLV is valid for initial client registration when the iSNS is being
used to assign a unique Entity Identifier to the client.
The operating attributes are the elements that will be registered
and associated with the key attributes. Multiple attributes
associated with the one key attribute can be registered in one
RegDevAttr.
One RegDevAttr message can contain attributes for Entity, Portal,
Node, and Port objects if they are contained in the same Entity.
When the registration contains attributes for the Entity, Portal,
Node or Port objects together, then the appropriate Portal, Node
and Port key attributes must be registered as part of the operating
attributes.
Ordering of the attributes is important in multi object
registrations. For example, Node Attributes follow a valid Node
key.
When a registration of a Portal, Node or Port is performed, the
appropriate associations between objects will be created in the
iSNS.
Attributes following the Delimiter Attribute are Operating
Attributes. Depending on the setting of the Update bit in the
FLAGS field, the Operating attribute values in the RegDevAttr
message will either replace existing value(s), or be added to
existing value(s) of the specified operating attribute.
Gibbons, Tseng, Monia Standards Track 50
iSNS March 2001
7.1.5.1.1 Update Flag
The Update Flag, contained in the message header FLAGS field,
indicates the RegDevAttr message is an update to an existing entry.
If the key attributes match an existing object in the iSNS
directory database, and the Update bit in the flags field is not
set, then the registration will replace the existing registration.
The existing object shall be de-registered. A new registration
will be created with the new attribute value(s) in the registration
request. Existing associations between objects will be updated to
reflect the new information. For example, an existing Node object
may be de-registered and reregistered with a different Entity
object as part of a registration.
If the key attributes match an existing entry in the iSNS database
and the Update bit in the FLAGS field is enabled, then the new
attribute value(s) in the registration request SHALL update
existing values or add additional attributes in the key entry.
Existing associations between objects will be maintained. If the
Update bit is set and the registration would cause a change in
associations, then the error _Invalid Registration Update_ SHALL be
returned. For example, if a RegDevAttr message with an Entity
Identifier key for one entity contains a Node WWUI attribute
associated with another entity, then an error shall be returned.
7.1.5.2 Device Attribute Query Request (DevAttrQry)
The DevAttrQry message type is 0x0002. The DevAttrQry message
provides an iSNS client with the means to query the iSNS server for
network entity attributes.
The Source attribute of the DevAttrQry message is as defined in
Section 7.1.1. The source is used to scope the query to the
Discovery Domains that the source attribute is a member of.
The Key Attribute(s) follow the source attribute in the message
payload. The attributes returned by the query will be from objects
WHERE the Key Attribute(s) match the object. The Key Attributes
map to a type of object.
The DevAttrQry message shall support the following Key Attributes:
Gibbons, Tseng, Monia Standards Track 51
iSNS March 2001
Valid Key Attributes for Queries
--------------------------------
Entity Identifier
Entity Type
Node Type
Portal IP-Address
Portal IP-Address, Portal TCP/UDP Port
WWUI (iSCSI only)
Node WWN (iFCP only)
Port WWN (iFCP only)
If the network entities matching key attributes are not in the same
Discovery Domain as the Source Attribute, then the results for the
network entity will not be included in the response message.
The Operating Attributes are the attributes whose values are being
queried.
7.1.5.3 Device Get Next Request (DevGetNext)
The DevGetNext message type is 0x0003. This message provides the
iSNS client with the means to sequentially retrieve Entity
Identifiers, IP Addresses, WWUI's, Node Names and Port Names from
devices in DDs to which the client has access.
The Source attribute of the DevGetNext message is as defined in
Section 7.1.1. The source is used to scope the Get Next process to
the Discovery Domains that the source attribute is a member of. It
is the Entity Identifier, WWUI, Node Name, Port Name, or the IP-
Address of the client performing the query.
The Key Attribute follows the source attribute in the message
payload. The Key Attribute is a Entity Identifier, WWUI, IP
Address, Node Name, or Port Name. If the key length value entered
is zero, signifying an empty key value field, the first accessible
a Entity Identifier, WWUI, IP Address, Node Name, or Port Name
instance shall be returned to the client.
There are no Delimiter or Operating Attributes in the DevGetNext
request message.
7.1.5.4 Deregister Device Request (DeregDev)
The DeregDev message type is 0x0004. An iSNS client port or device
is removed from the iSNS directory database by using DeregDev.
Upon receiving the DeregDev, the iSNS server removes all object
registrations associated with the Key Attribute in the payload.
The DeregDev request message payload contains a Source Attribute
and Key Attribute(s). The Source attribute of the DeregDev message
is as defined in Section 7.1.1. Valid Key Attributes are shown
below:
Gibbons, Tseng, Monia Standards Track 52
iSNS March 2001
Valid Key Attributes for DeregDev
---------------------------------
Entity Identifier
Portal IP-Address
Portal IP-Address, Portal TCP/UDP Port
WWUI (iSCSI only)
Node WWN (iFCP only)
Port WWN (iFCP only)
The removal of the object will initiate an SCN message to
registered iSNS clients that are in the same DD as the removed
device or port. After removing the port or device, the iSNS server
sends back an acknowledgement to the iSNS client.
7.1.5.5 SCN Register Request (SCNReg)
The SCNReg message type is 0x0005. The State Change Notification
Registration Request (SCNReg) message allows an iSNS client to
register a network entity to receive State Change Notification
(SCN) messages. SCN messages allow an iSNS client to be notified
of changes within the DD or network (if administratively allowed)
that the device port is a member of.
The SCNReg request message payload contains a Source Attribute, Key
Attribute(s), and Operating Attributes. The Source attribute of
the SCNReg message is as defined in Section 7.1.1. Valid Key
Attributes for an SCNReg are shown below:
Valid Key Attributes for SCNReg
--------------------------------
Entity Identifier
Portal IP-Address
Portal IP-Address, Portal TCP/UDP Port
WWUI (iSCSI only)
Node WWN (iFCP only)
Port WWN (iFCP only)
The network entities matching the Key Attributes are registered to
receive SCNs.
The Operating Attributes section contains the Entity Event Bitmap
attribute. The bitmap indicates the INTERESTED EVENT TYPE FLAGS
that the network entity is registering for.
Section 6.8 describes each flag used in the EVENT TYPE FLAGS field.
7.1.5.6 SCN Deregister Request (SCNDereg)
Gibbons, Tseng, Monia Standards Track 53
iSNS March 2001
The SCNDereg message type is 0x0006. The SCNDereg message allows an
iSNS client to deregister a network entity to receive State Change
Notification (SCN) messages.
The SCNDereg request message payload contains a Source Attribute
and Key Attribute(s). The Source attribute of the SCNDereg message
is as defined in Section 7.1.1. Valid Key Attributes for an
SCNDereg are shown below:
Valid Key Attributes for SCNDereg
--------------------------------
Entity Identifier
Portal IP-Address
Portal IP-Address, Portal TCP/UDP Port
WWUI (iSCSI only)
Node WWN (iFCP only)
Port WWN (iFCP only)
The network entities matching the Key Attributes are deregistered
for SCNs.
There are no Delimiter or Operating Attributes in the SCNDereg
message.
7.1.5.7 SCN Event (SCNEvent)
The SCNEvent message type is 0x0007. The SCNEvent is a special
message generated by a network entity for the iSNS. The SCNEvent
allows a network entity to request generation of a State Change
Notification (SCN) message by the iSNS. The SCN, sent by the iSNS,
then notifies other registered network entities within a DD or
network (if administratively allowed) of the change indicated in
the SCNEvent.
Most SCNs are automatically generated by the iSNS when network
entities are registered or deregistered from the directory
database. SCNs are also be generated when a network management
application makes changes to the DD membership in the iSNS.
However, a network entity can trigger a SCN by using the SCNEvent.
The format of the SCNEvent message is shown below:
MSb LSb
31 0
+----------------------------------------+
| Source Attribute |
+----------------------------------------+
| Source Event Bitmap |
+----------------------------------------+
The Source Attribute is the object that caused the SCN to be
generated. The Source Attribute can be an Entity Identifier, WWUI,
Node Name or Port Name.
Gibbons, Tseng, Monia Standards Track 54
iSNS March 2001
The Source Event Bitmap indicates the event that caused the SCN to
be generated. The Event Bitmap is a 32 bit field, with the
following definitions:
Bit Field Flag Description
--------- ----------------
0 CHANGE IN DD MEMBERSHIP
1 CHANGE IN NETWORK
2 CHANGE IN DEVICE REGISTRATION PARAMETERS
3 DEVICE ADDED
4 DEVICE REMOVED
5 CLIENT STATUS UPDATE REQUESTED (for CSI message)
All Others Reserved
7.1.5.8 State Change Notification (SCN)
The SCN message type is 0x0008. The SCN is a special message
generated by the iSNS which allows a registered network entity to
be notified of changes within a DD, network (if administratively
allowed), or about device registration parameter updates in the
iSNS directory database.
The types of events that a network entity will be notified about
are based on the value of the Entity Event Bitmap, as described in
Section 6.8.
The format of the SCN message is shown below:
MSb LSb
31 0
+----------------------------------------+
| Destination Attribute |
+----------------------------------------+
| Timestamp |
+----------------------------------------+
| Source Attribute[1] |
+----------------------------------------+
| Source Event Bitmap[1] |
+----------------------------------------+
| Source Attribute [2](if present) |
+----------------------------------------+
| Source Event Bitmap [2](if present) |
+----------------------------------------+
| Source Attribute [3](if present) |
+----------------------------------------+
| Source Event Bitmap [3](if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
Gibbons, Tseng, Monia Standards Track 55
iSNS March 2001
The Destination Attribute is the object that is receiving the SCN.
The Destination Attribute can be an Entity Identifier, WWUI, Node
Name or Port Name.
The Timestamp field indicates the time the SCN Event was generated.
The timestamp is a 4-byte unsigned, fixed-point integer giving the
number of seconds since 00:00:00 GMT on January 1, 1970.
The Source Attribute is the object that caused the SCN to be
generated. The Source Attribute can be an Entity Identifier, WWUI,
Node Name or Port Name.
The Source Event Bitmap indicates the event that caused the SCN to
be generated. The Event Bitmap is a 32 bit field, with the
following definitions:
Bit Field Flag Description
--------- ----------------
0 CHANGE IN DD MEMBERSHIP
1 CHANGE IN NETWORK
2 CHANGE IN DEVICE REGISTRATION PARAMETERS
3 DEVICE ADDED
4 DEVICE REMOVED
5 CLIENT STATUS UPDATE REQUESTED (for CSI message)
All Others Reserved
7.1.5.9 Register DD (RegDD)
The RegDD message type is 0x0009. This message allows an iSNS
client to create a new Discovery Domain (DD) or update an existing
DD Symbolic Name. Once created, network identities can be added
and deleted from the DD.
DDs are uniquely defined using DD_IDs. DD registration attributes
are described in section 5.5.
The RegDD message payload contains the Source Attribute, Key
Attributes and Operating Attributes. The Source attribute of the
RegDD message is as defined in Section 7.1.1.
The Key Attribute for a RegDD message is the DD ID for the domain
being added or updated. If the DD ID matches an existing DD, then
the DD Symbolic Name will be updated with the value contained in
the Operating Attribute payload. If the DD ID does not match an
existing DD, then a new DD is registered with the DD ID. The new
DD Symbolic Name will be the value contained in the Operating
Attribute payload.
The Operating Attribute for a RegDD message is the DD_Symbolic Name
for the DD.
7.1.5.10 Deregister DD (DeregDD)
Gibbons, Tseng, Monia Standards Track 56
iSNS March 2001
The DeregDD message type is 0x000A. This message allows an iSNS
client to deregister an existing Discovery Domain (DD).
DDs are uniquely defined using DD_IDs. DD registration attributes
are described in section 5.5.
The DeregDD message payload contains Source Attribute and Key
Attributes. The Source attribute of the DeregDD message is as
defined in Section 7.1.1.
The Key Attribute for a DeregDD message is the DD ID for the domain
being removed. If the DD ID matches an existing DD, then the DD
will be removed and a success error code returned. If the DD ID
does not match an existing DD then the error code _No Such Entry_
will be returned.
7.1.5.11 Register Device in DD (RegDevDD)
The RegDevDD message type is 0x000B. This message allows an iSNS
client to add network identities to the DD. DD registration
attributes are described in section 5.5.
The RegDevDD message payload contains the Source Attribute, Key
Attribute and Operating Attributes. The Source attribute of the
RegDevDD message is as defined in Section 7.1.1. The Key Attribute
for a RegDevDD message is the DD ID for the Discovery Domain (DD)
to which the network entity will be added. If the DD ID matches an
existing DD, then the network entity will be added to the DD. If
the DD ID does not match an existing DD then the error code _No
Such Entry_ will be returned.
The Operating Attribute for a RegDevDD message is the member to be
added to the DD. Valid members for a DD are shown in section 4.4.
The network identities matching the Key Attributes will be added to
the DD.
7.1.5.12 Deregister Device in DD (DeregDevDD)
The DeregDevDD message type is 0x000C. This message allows an iSNS
client to remove network identities from a DD. DD attributes are
described in section 5.5.
The DeregDevDD message payload contains the Source Attribute, Key
Attribute and Operating Attributes. The Source attribute of the
DeregDevDD message is as defined in Section 7.1.1. The Key
Attribute for a DeregDevDD message is the DD ID for the Discovery
Domain (DD) from which the network entity will be deregistered. If
the DD ID matches an existing DD, then the network entity will be
removed to the DD. If the DD ID does not match an existing DD then
the error code _No Such Entry_ will be returned.
The Operating Attributes for a DeregDevDD message are the members
to be deregistered from the DD. Valid members for a DD are shown
Gibbons, Tseng, Monia Standards Track 57
iSNS March 2001
in section 4.4. The network identities matching the Operating
Attributes will be deregistered from the DD indicated in the Key
Attribute.
If any of the Operating Attributes do not match a network entity in
the DD then the error code _No Such Entry_ will be returned. All
other matching network entities will be removed.
7.1.5.13 Entity Status Inquiry (ESI)
The ESI message type is 0x000D. This message is used to verify that
an individual iSNS client is reachable and available.
The ESI response message payload contains the destination attribute
specifying the Entity Identifier of the iSNS client.
If the iSNS client fails to respond to three consecutive ESI
messages, then the iSNS shall remove that client from the iSNS
database and trigger the appropriate State Change Notifications, if
any.
7.1.5.14 Request Network Time (RqstTime)
The RqstTime message type is 0x0010. This is a special message
that returns the network time as stored in the iSNS. The iSNS uses
NTP to obtain and maintain the network time provided in the
RqstTime message.
There are no Key or Operating attributes in this message.
7.1.5.15 Request Domain ID (RqstDmnId)
The RqstDmnId message type is 0x0011. This optional message is used
for FCIP and iFCP Transparent Mode to allocate DOMAIN_ID values
used to assign 3-byte Fibre Channel PORT_ID values. In the case of
FCIP, the iSNS client may be an address assignment authority for an
Autonomous Region of a Fibre Channel fabric. In the case of iFCP,
the iSNS server becomes the address assignment authority for the
entire iFCP fabric.
The iSNS server responds to RqstDmnID with the DOMAIN_ID values
from the range 1 to 239 that have not been previously allocated to
other iSNS clients. If no further unallocated DOMAIN_ID values are
available from this range, the iSNS server SHALL respond with the
error code 18 "DOMAIN_ID not available".
Once a 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 CSI message detects that the
iSNS client no longer exists on the network.
The iSNS server and client SHALL use TCP to transmit and receive
RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages.
Gibbons, Tseng, Monia Standards Track 58
iSNS March 2001
7.1.5.16 Release Domain ID (RlseDmnId)
The RlseDmnId message type is 0x0012. This optional message is used
for FCIP and iFCP Transparent Mode to release DOMAIN_ID values used
to assign 3-byte Fibre Channel PORT_ID values. In the case of FCIP,
the iSNS client may be an address assignment authority for an
Autonomous Region of a Fibre Channel fabric. In the case of iFCP,
the iSNS server becomes the address assignment authority for the
entire iFCP fabric.
Once a 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 CSI message detects that the
iSNS client no longer exists on the network.
The iSNS server and client SHALL use TCP to transmit and receive
RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages.
7.1.5.17 Get Domain IDs (GetDmnIds)
The GetDmnIds message type is 0x0013. This optional message is used
for FCIP and iFCP Transparent Mode to query for the currently used
DOMAIN_ID values used to assign 3-byte Fibre Channel PORT_ID
values. In the case of FCIP, the iSNS client may be an address
assignment authority for an Autonomous Region of a Fibre Channel
fabric. In the case of iFCP, the iSNS server becomes the address
assignment authority for the entire iFCP fabric.
The GetDmnIds message payload contains Source Attribute and Key
Attributes. The Source attribute of the GetDmnIds message is as
defined in Section 7.1.1.
The Key Attribute for a GetDmnIds message is the Domain, used as a
Scope, for the query. The Operating Attribute is the Domain
attribute. If the Domain Scope matches a domain, then the utilized
Area Codes will be returned in the Operating Attribute. If the
Domain used as a key is 0, then all currently used Domain IDs will
be returned. If the Domain Scope is non-zero and does not match an
existing Domain then the error code _No Such Entry_ will be
returned.
7.2 Response Messages
The iSNSP response message payloads contain an Error Code, followed
by a list of attributes, and have the following format:
Gibbons, Tseng, Monia Standards Track 59
iSNS March 2001
MSb LSb
31 0
+----------------------------------------+
| 4-byte ERROR CODE |
+----------------------------------------+
| Key Attribute[1] (if present) |
+----------------------------------------+
| Key Attribute[2] (if present) |
+----------------------------------------+
| Key Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| - Delimiter Attribute - (if present) |
+----------------------------------------+
| Operating Attribute[1] (if present) |
+----------------------------------------+
| Operating Attribute[2] (if present) |
+----------------------------------------+
| Operating Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
The iSNS Response messages will be sent to the iSNS Client IP-
Address and the originating TCP/UDP Port that was used for the
associated registration and query message.
7.2.1 Error Code
The iSNSP response message payloads contain a 4-byte ERROR CODE
field. If the operation completed successfully the Error Code
field will contain No Error, represented by 0x00000000. The list
of valid Error Codes are shown below:
Gibbons, Tseng, Monia Standards Track 60
iSNS March 2001
Error Code Error Description
---------- -----------------
0 No Error
1 Unknown Error
2 Message Format Error
3 Invalid Registration
4 Invalid Registration Update
4 Invalid Query
5 Authentication Unknown
6 Authentication Absent
7 Authentication Failed
8 No Such Entry
9 Version Not Supported
10 Internal Bus Error
11 Busy Now
12 Option Not Understood
13 Invalid Update
14 Message Not Supported
15 SCN Event Rejected
16 SCN Registration Rejected
17 Client Status Inquiry Not Available
18 DOMAIN_ID not available
7.2.2 Key Attributes in Response
Depending on the specific iSNSP request, the response message will
contain Key Attributes. For example, a Register Device Attribute
Response message will contain the Key Attributes used in the Device
Attribute Registration with the assigned values, if they were
assigned by the iSNS.
7.2.3 Delimiter Attribute in Response
The Delimiter Attribute separates the key and operating attributes
in a response message, if they exist. The Delimiter Attribute has
a tag value of 0 and a length value of 0. The Delimiter Attribute
is effectively 8 Bytes long, a 4 Byte tag containing 0x00000000,
and a 4 Byte length field containing 0x00000000.
7.2.4 Operating Attributes in Response
The Operating Attributes in a response are the results related to
the iSNS registration or query operation being performed.
The number of Operating Attributes in the response depends on the
specific iSNSP request or query response. For example, the
Operating Attributes in a Device Attribute Query Response message
are the set of Operating Attributes from network entity entries
that matched the Key Attributes in the associated Device Attribute
Query message.
7.2.5 Registration and Query Message Types
Gibbons, Tseng, Monia Standards Track 61
iSNS March 2001
The following describes each query and message type.
7.2.5.1 Register Device Attribute Rsp (RegDevRsp)
The RegDevRsp message type is 0x8001. The RegDevRsp message
contains the results for the RegDevAttr message with the same
TRANSACTION ID.
The Error Code contains the operation results. If the registration
completed successfully the code of _No Error_ is returned. If an
error occurred then the appropriate code will be returned.
The Key Attribute contains the key used for the Register Device
Attribute message. If the RegDevAttr registration message was used
to assign a unique Entity Identifier to the network entity, then
the key attribute field contains the assigned Entity Identifier.
There are no Operating Attributes in the RegDevRsp message.
7.2.5.2 Device Attribute Query Response (DevAttrQryRsp)
The DevAttrQryRsp message type is 0x8002. The DevAttrQryRsp
message contains the results for the DevAttrQry message with the
same TRANSACTION ID.
The Error Code contains the operation results. If the query
completed successfully the code of _No Error_ is returned. If an
error occurred then the appropriate code will be returned.
For a successful query result, the DevAttrQryRsp Operating
Attribute field will contain the set of results that match the
original DevAttrQry Key Attributes.
7.2.5.3 Device Get Next Response (DevGetNextRsp)
The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message
contains the results for the DevGetNext message with the same
TRANSACTION ID.
The Error Code contains the operation results. If the operation
completed successfully the code of _No Error_ is returned. If an
error occurred then the appropriate code will be returned.
The Key Attribute field contains the next key, in lexicographical
order, after the Key Attribute used in the DevGetNext message.
The Operating Attribute field contains the same attributes as were
in the DevGetNext message. The values of the Operating Attributes
are the attribute values associated with the key returned.
7.2.5.4 Deregister Device Response (DeregDevRsp)
Gibbons, Tseng, Monia Standards Track 62
iSNS March 2001
The DeregDevRsp message type is 0x8004. If the DeregDev operation
completed successfully then the code of _No Error_ is returned. If
an error occurred then the appropriate code will be returned.
The DeregDevRsp message does not contain any key or operating
attributes.
7.2.5.5 SCN Register Response (SCNRegRsp)
The SCNRegRsp message type is 0x8005. If the SCNReg operation
completed successfully then the code of _No Error_ is returned. If
an error occurred then the appropriate code will be returned.
The SCNRegRsp message does not contain any key or operating
attributes.
7.2.5.6 SCN Deregister Response (SCNDeregRsp)
The SCNDeregRsp message type is 0x8006. If the SCNDereg operation
completed successfully then the code of _No Error_ is returned. If
an error occurred then the appropriate code will be returned.
The SCNDeregRsp message does not contain any key or operating
attributes.
7.2.5.7 SCN Event Response (SCNEventRsp)
The SCNEventRsp message type is 0x8007. If the SCNEvent operation
completed successfully then the code of _No Error_ is returned. If
an error occurred then the appropriate code will be returned.
The SCNEventRsp message does not contain any key or operating
attributes.
7.2.5.5 SCN Response (SCNRsp)
The SCNRsp message type is 0x8008. If the SCN operation completed
successfully then the code of _No Error_ is returned. If an error
occurred then the appropriate code will be returned.
The SCNRsp message does not contain any key or operating
attributes.
7.2.5.9 Register DD Response (RegDDRsp)
The RegDDRsp message type is 0x8009. If the RegDD operation
completed successfully then the code of _No Error_ is returned. If
an error occurred then the appropriate code will be returned.
The RegDDRsp message does not contain any key or operating
attributes.
7.2.5.10 Deregister DD Response (DeregDDRsp)
Gibbons, Tseng, Monia Standards Track 63
iSNS March 2001
The DeregDDRsp message type is 0x800A. If the DeregDD operation
completed successfully then the code of _No Error_ is returned. If
an error occurred then the appropriate code will be returned.
The DeregDDRsp message does not contain any key or operating
attributes.
7.2.5.11 Register Device in DD Response (RegDevDDRsp)
The RegDevDDRsp message type is 0x800B. If the RegDevDD operation
completed successfully then the code of _No Error_ is returned. If
an error occurred then the appropriate code will be returned.
The DeregDDRsp message does not contain any key or operating
attributes.
7.2.5.12 Deregister Device in DD Response (DeregDevDDRsp)
The DeregDevDDRsp message type is 0x800C. If the DeregDevDD
operation completed successfully then the code of _No Error_ is
returned. If an error occurred then the appropriate code will be
returned.
The DeregDevDDRsp message does not contain any key or operating
attributes.
7.2.5.13 Entity Status Inquiry Response (ESIRsp)
The ESIRsp message type is 0x800D. This message provides
confirmation that the ESI message was received and processed by the
iSNS client.
The ESIRsp response message payload contains the source attribute
of the iSNS client network entity.
Upon receiving the ESIRsp from the iSNS client, the iSNS server
SHALL update the timestamp attribute for that client.
If the ESI operation completed successfully on the iSNS client then
the code of _No Error_ is returned. If an error occurred then the
appropriate code will be returned.
The ESIRsp message does not contain any key or operating
attributes.
7.2.5.14 Request Network Time Response (RqstTimeRsp)
The RqstTimeRsp message type is 0x8010. The format of the
RqstTimeRsp payload is different then other response message
payloads, and is shown below:
Gibbons, Tseng, Monia Standards Track 64
iSNS March 2001
MSb LSb
31 0
+----------------------------------------+
| 4-byte ERROR CODE |
+----------------------------------------+
| 4-byte TIMESTAMP |
+----------------------------------------+
The TIMESTAMP is a 4-byte unsigned, fixed-point integer giving the
number of seconds since 00:00:00 GMT on January 1, 1970. The
Network Time Protocol can be used by the iSNS to generate the
timestamp provided. The iSNS TIMESTAMP shall only be considered to
be locally significant.
7.2.5.15 Request Domain ID Response (RqstDmnIdRsp)
The RqstDmnIdRsp message type is 0x8011. This optional message
provides the response for RqstDmnID, and is used for FCIP and iFCP
Transparent Mode to allocate DOMAIN_ID values used to assign 3-byte
Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client
may be an address assignment authority for an Autonomous Region of
a Fibre Channel fabric. In the case of iFCP, the iSNS server
becomes the address assignment authority for the entire iFCP
fabric.
The iSNS server responds to RqstDmnID with the DOMAIN_ID values
from the range 1 to 239 that have not been previously allocated to
other iSNS clients. If no further unallocated DOMAIN_ID values are
available from this range, the iSNS server SHALL respond with the
error code 18 "DOMAIN_ID not available".
Once a 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 CSI message detects that the
iSNS client no longer exists on the network.
The iSNS server and client SHALL use TCP to transmit and receive
RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages.
7.2.5.16 Release Domain ID Response (RlseDmnIdRsp)
The RlseDmnIdRsp message type is 0x8012. This optional message
provides the response for RlseDmnId, and is used for FCIP and iFCP
Transparent Mode to release DOMAIN_ID values used to assign 3-byte
Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client
may be an address assignment authority for an Autonomous Region of
a Fibre Channel fabric. In the case of iFCP, the iSNS server
becomes the address assignment authority for the entire iFCP
fabric.
Once a DOMAIN_ID value is allocated by the iSNS server, it shall
not be reused until it has been deallocated by the iSNS client to
Gibbons, Tseng, Monia Standards Track 65
iSNS March 2001
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
RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages.
7.2.5.17 Get Domain IDs Response (GetDmnIdsResp)
The GetDmnIdsResp message type is 0x8013. This optional message is
used for FCIP and iFCP Transparent Mode to return the results of a
query for the currently-allocated DOMAIN_ID values used to assign
3-byte Fibre Channel PORT_ID values. In the case of FCIP, the iSNS
client may be an address assignment authority for an Autonomous
Region of a Fibre Channel fabric. In the case of iFCP, the iSNS
server becomes the address assignment authority for the entire iFCP
fabric.
If the Domain Scope matches a domain, then the utilized Area Codes
will be returned in the Operating Attribute. If the Domain used as
a key is 0, then all currently used Domain IDs will be returned.
If the Domain Scope is non-zero and does not match an existing
Domain then the error code _No Such Entry_ will be returned.
8. Security Considerations
8.1 Data Integrity and Authentication
Data integrity and authentication requirements for communication
between iSNS clients and server can be achieved through use of the
authentication block described in section 6.4.
8.2 Confidentiality
If the operational evironment requires confidentiality in iSNSP
queries and responses, then the iSNSP shall be used with Transport
Layer Security (TLS). However, there will be many instances where
confidentiality will not be a requirement. None of the information
stored in the iSNS database is inherently confidential. This
includes X.509 certificates, which should contain only public keys.
In these cases where confidentiality is not required, the iSNS can
be used only with the message authentication block described in
section 6.4.
8.3 Security Model
The iSNS server will leverage existing security mechanisms
currently used to secure resources such as DNS servers, e-mail
relays servers, and other sensitive and otherwise vulnerable
network resources. Existing firewalls technology can protect
against active attacks from the Public Internet.
9. References
Gibbons, Tseng, Monia Standards Track 66
iSNS March 2001
[RFC1035] Domain Implementation and Specification
[STD0035] Domain Name System
[RFC2065] Domain Name System Security Extensions
[RFC2608] Service Location Protocol, Version 2
[FC-GS-2] Fibre Channel Generic Services-2, ANSI NCITS 288
[FC-GS-3] Fibre Channel Generic Services-3, NCITS Working
Draft Rev 7.01, November 28, 2000
[RFC2609] Service Templates and Service
[IEEE802.1Q] Standard for Virtual Bridged Local Area Networks
[RFC1510] The Kerberos Network Authentication Service
[DSS] FIPS PUB 186-2, National Institute of Standards and
Technology, Digital Signature Standard(DSS),
Technical Report
[802-1990] ANSI/IEEE Std 802-1990, Name: IEEE Standards for
Local and Metropolitan Area Networks: Overview and
Architecture
[SPC] SCSI-3 Primary Commands, ANSI NCITS 995D, Revision
11a
[iSCSI-SLP] Finding iSCSI Targets and Name Servers Using SLP,
draft-bakke-iscsi-slp-00.txt
[iSCSI-NDR] iSCSI Naming and Discovery Requirements,
draft-ietf-ips-iscsi-name-disc-00.txt
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Gibbons, Tseng, Monia Standards Track 67
iSNS March 2001
10. Author's Addresses
Josh Tseng
Kevin Gibbons
Charles Monia
Nishan Systems
3850 North First Street
San Jose, CA 95134-1702
Phone: (408) 519-3749
Email: jtseng@nishansystems.com
Franco Travostino
Nortel Networks
3 Federal Street
Billerica, MA 01821
Phone: 978-288-7708
Email: travos@nortelnetworks.com
Kenneth Hirata
Vixel Corporation
Irvine, CA 92618
Phone: (949) 450-6100
Email: khirata@vixel.com
Mark Bakke
Cisco Systems
6450 Wedgewood Road
Maple Grove, MN 55311
Phone: 763-398-1054
Email: mbakke@cisco.com
Jim Hafner
IBM Research
Almaden Research Center K53-B2
650 Harry Road
San Jose, CA 95120-6099
Email: hafner@almaden.ibm.com
Phone: 408-927-1892
Howard Hall
Pirus Networks
43 Nagog Park
Acton, MA 01720
Email: howard@pirus.com
Phone: 978-206-9103
Gibbons, Tseng, Monia Standards Track 68
iSNS March 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Gibbons, Tseng, Monia Standards Track 69
iSNS March 2001
Appendix A - iSNS Examples
A.1 iSCSI Initialization Example
This example assumes an SLP Service Agent (SA) has been implemented
on the iSNS host, and an SLP User Agent (UA) has been implemented
on the iSNS initiator. See [RFC2608] for further details on SA's
and UA's. This example also assumes the target is configured to
use the iSNS, and have its access control policy "slaved" to the
iSNS.
Gibbons, Tseng, Monia Standards Track 70
iSNS March 2001
A.1.1 Simple iSCSI Target Registration
In this example, a simple target with a single WWUI registers with
the iSNS. The target has not been assigned a Fully Qualified
Domain Name (FQDN) by the administrator.
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP------->| |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.36.53.1 | authorized to view|
| | | all DD's. Device |
| | | WWUIabcd has been |
| RegDevAttr--------->| | previously placed |
|Src:(tag=1) NULL | | into DDabcd******/|
|Key:(tag=1) NULL | | |
|tag=2: "iSCSI" | | |
|tag=4: 0 | | |
|tag=16: "192.36.4.5" | | |
|tag=17: "5001" | | |
|tag=32: "WWUIabcd" | | |
|tag=34: "target" | | |
|tag=35: "disk 1" | | |
| |<---RegDevAttrRsp | |
| |tag=1: "iSNS:0001"| |
| | | |
| DevAttrQry--------->| SCN-------->| |
|Src:(tag=32) "WWUIabcd" |(or SNMP trap) | |
|Key:(tag=2) "iSCSI" |src: "iSNS:0001" | |
|Key:(tag=34) "initiator" |dest: "mgmt.foo.com" |
|tag=16: NULL |CHANGE IN NETWORK | |
|tag=32: NULL | |<-------SCNRsp |
|/*Query asks for all iSCSI| | |
|devices' IP address, port |<---DevAttrQryRsp | |
|number, and WWUI*/ |tag=16:"192.36.4.1" |
| |tag=32:"WWUIpdq" |<-----DevAttrQry |
| |tag=16:"192.1.3.2"|src: mgmt.foo.com |
| |tag=32:"WWUIrst" |key:(tag=1)iSNS:0001
|/*************************| |Op Attr: (tag=16) |
|Our target "iSNS:0001" | |Op Attr: (tag=17) |
|discovers two initiators | |Op Attr: (tag=32) |
|in the same DD. It will | | |
|accept iSCSI logins from | | |
|these two identified | | |
|initiators presented by | | |
|iSNS*********************/| DevAttrQryRsp--->| |
| |tag=16: 192.36.4.5| |
| |tag=17: 5001 | |
| |tag=32: WWUIabcd | |
+--------------------------+------------------+-------------------+
Gibbons, Tseng, Monia Standards Track 71
iSNS March 2001
A.1.2 Target Registration and DD Configuration
In this example, a more complex target registers with the iSNS.
This target has been configured with a Fully Qualified Domain Name
(FQDN) in the DNS servers, and the user wishes to use this
identifier for the device. Also, the user wishes to use public key
certificates in the iSCSI login authentication.
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.36.53.1 | authorized to view|
| RegDevAttr--> | | all DD's ********/|
|Src:(tag=1)"jbod1.foo.com"| | |
|Key:(tag=1)"jbod1.foo.com"| | |
|tag=1: "jbod1.foo.com" | | |
|tag=2: "iSCSI" | | |
|tag=4: 5 seconds | | |
|tag=16: "192.36.34.4" | | |
|tag=17: "5001" | | |
|tag=16: "192.36.53.5" | | |
|tag=17: "5001" | | |
|tag=32: "WWUIabcd" | | |
|tag=35: "Target" |/*****************| |
|tag=36: "Volume 1" |jbod1.foo.com is | |
|tag=39: X.509 cert blob 1 |now registered in | |
|tag=32: "WWUIefgh" |iSNS, but is not | |
|tag=35: "Target" |in any DD. Therefore, |
|tag=36: "Volume 2" |no other devices | |
|tag=39: X.509 cert blob 2 |can "see" it. | |
| |*****************/| |
| |<--DevAttrRsp | |
| | | |
| | SCN------> | |
| | (or SNMP trap) | |
| |src: 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--> | |
Gibbons, Tseng, Monia Standards Track 72
iSNS March 2001
| |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:"WWUIabcd" |displays device, |
| |tag=32:"WWUIefgh" |the operator decides
| | |to place "WWUIabcd"|
| | |into Domain "DDxyz"|
|/*************************| |******************/|
|Target is now registered | | |
|in iSNS. It has been placed |<--RegDevDD |
|in DDxyz by management | |src:(tag=1)
|station. | | "mgmt.foo.com" |
|*************************/| |key: "DDxyz" |
| | |tag=32: "WWUIabcd" |
| | | |
| | RegDevRsp---->| |
+--------------------------+------------------+-------------------+
Gibbons, Tseng, Monia Standards Track 73
iSNS March 2001
A.1.3 Initiator Registration and Target Discovery
The following example illustrates a new initiator registering with
the iSNS, and discovering the target WWUIabcd from the example in
A.1.1.
+--------------------------+------------------+-------------------+
| iSCSI Initiator | iSNS |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.36.53.1 | authorized to view|
|RegDevAttr--> | | all DD's ********/|
|Src:(tag=1)"svr1.foo.com" | | |
|Key:(tag=1)"svr1.foo.com" | | |
|tag=1: "svr1.foo.com" | | |
|tag=2: "iSCSI" | | |
|tag=4: 5 seconds |/*****************| |
|tag=16: "192.20.3.1" |Device not in any | |
|tag=17: "5001" |DD, so it is | |
|tag=32: "WWUIijkl" |inaccessible by | |
|tag=35: "Initiator" |other devices | |
|tag=36: "Server1" |*****************/| |
|tag=39: X.509 cert blob 3 | | |
| |<--DevAttrRsp | |
| | | |
| | SCN------> | |
| | (or SNMP trap) | |
| |src: 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--> | |
| |tag=2: "iSCSI" | |
| |tag=17:192.20.3.1 | |
| |tag=32:"WWUIijkl" | |
| | |/**Mgmt Station ***|
| | |displays device, |
| | |the operator decides
| | |to place "WWUIijkl"|
| | |into Domain "DDxyz"|
| | |with device WWUIabcd
| | |******************/|
Gibbons, Tseng, Monia Standards Track 74
iSNS March 2001
| | |<--RegDevDD |
| | |src: (tag=1) |
| | | "mgmt.foo.com" |
| | |key: "DDxyz" |
| | |tag=32: "WWUIijkl |
| | | |
| | RegDevRsp--->|/******************|
| | |"WWUIijkl" has been|
| | |moved to "DDxyz" |
| | |******************/|
| |<-----SCN | |
| |src: "WWUIijkl" | |
| |dest: "WWUIijkl" | |
| |CHANGE IN DD MEMBERSHIP |
| DevAttrQry----------->| | |
|src: "WWUIabcd" |/*****************| |
|key:(tag=2) "iSCSI" |Note that WWUIabcd| |
|key:(tag=35) "Target" |also receives an | |
|Op Attr: (tag=16) |SCN that WWUIijkl | |
|Op Attr: (tag=17) |is in the same DD | |
|Op Attr: (tag=32) |*****************/| |
|Op Attr: (tag=36) | | |
|Op Attr: (tag=39) |<-----AttrQryRsp | |
| |tag=16: 192.36.34.4 |
| |tag=17: 5001 | |
| |tag=16: 192.36.53.5 |
| |tag=17: 5001 | |
| |tag=32: WWUIabcd | |
| |tag=36: Volume 1 | |
| |tag=39: X.509 cert blob 2 |
| | | |
|/***The initiator has discovered | |
|the target, and has everything | |
|needed to complete iSCSI login | |
|The same process occurs on the | |
|target side; the SCN prompts the | |
|target to download the list of | |
|authorized initiators from the | |
|iSNS (i.e., those initiators in the | |
|same DD as the target.************/ | |
+--------------------------+------------------+-------------------+
Gibbons, Tseng, Monia Standards Track 75
iSNS March 2001
Appendix B _ SNMP Management MIB
The following SNMP MIB is for iSNS network management. The
definition is based on SNMPv2c. This is the first general release
of the MIB.
iSNS DEFINITIONS ::= BEGIN
--
-- iSNS.mib: IETF IPS Internet Storage Name Service (iSNS)
management
-- v1.0
--
IMPORTS
enterprises,
MODULE-IDENTITY,
OBJECT-TYPE,
NOTIFICATION-TYPE,
IpAddress,
Counter32
FROM SNMPv2-SMI
Gauge
FROM RFC1155-SMI
OBJECT-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION,
DisplayString,
DateAndTime,
RowStatus,
PhysAddress,
TimeStamp
FROM SNMPv2-TC;
FCIDtype ::= OCTET STRING (SIZE (3))
WWNtype ::= OCTET STRING (SIZE (8))
EntIdx ::= INTEGER
PortalIdx ::= INTEGER
NodeIdx ::= INTEGER
EIDtype ::= OCTET STRING
NodeType ::= OCTET STRING (SIZE (2))
EntType ::= INTEGER {iSCSI(1), FCIP(2), iFCP(3)}
WWUItype ::= OCTET STRING
DDIDtype ::= INTEGER
TFtype ::= INTEGER {true(1), false(2)}
iSNS MODULE-IDENTITY
LAST-UPDATED "200103010000Z"
ORGANIZATION "IETF IPS iSNS Working Group"
CONTACT-INFO "
Gibbons, Tseng, Monia Standards Track 76
iSNS March 2001
Attn: Kevin Gibbons / Josh Tseng
Nishan Systems
3850 North First Street
San Jose, CA 95134
USA
Tel : +1 408 519-3700
email : snmp@nishansystems.com "
DESCRIPTION "The MIB for internet Storage Name Service (iSNS)
Management."
::= {experimental 1}
--
-- Internet Storage Name Service Management
--
iSnsVersion OBJECT-TYPE
SYNTAX INTEGER (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The version of this iSNS instance. The header of each iSNSP
message contains iSNS version information."
::= {iSNS 1}
--
-- Discovery Domain Membership Information --------------------
--
iSnsDdMmbrs OBJECT IDENTIFIER ::= {iSNS 2}
--
-- Naming Service's Discovery Domain Information --------------
--
iSnsNumDomains OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current total number of Discovery Domain entries
in the iSNS."
::= {iSnsDdMmbrs 1}
iSnsNewDomainMemberStatus OBJECT-TYPE
SYNTAX INTEGER {inNoDomain(0), inDefaultDomain(1)}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The Domain Status for a new device when added to the network.
Either the
new device will not be in a domain, or go into a default domain.
The
default domain is by convention DD ID 1."
Gibbons, Tseng, Monia Standards Track 77
iSNS March 2001
::= {iSnsDdMmbrs 2}
iSnsDDTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsDDtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing configuration information for each
Discovery Domain (DD) configured in the network
managed by the iSNS."
::= {iSnsDdMmbrs 3}
iSnsDDtInfoEntry OBJECT-TYPE
SYNTAX iSnsDDtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Configuration information for each Discovery Domain
(DD) configured in the network."
INDEX {iSnsDDtId}
::= {iSnsDDTable 1}
iSnsDDtInfoEntry ::=
SEQUENCE {
iSnsDDtId DDIDtype,
iSnsDDtSymbolicName OCTET STRING,
iSnsDDtRowStatus RowStatus
}
iSnsDDtId OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The ID that refers to this Discovery Domain."
::= {iSnsDDtInfoEntry 1}
iSnsDDtSymbolicName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0 .. 64))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The Discovery Domain Symbolic Name field contains
a variable length description (from 0 to 64) that is
associated with the DD. If the DD Sym Name is not
registered, then the length of this field is set to zero
bytes."
::= {iSnsDDtInfoEntry 2}
iSnsDDtRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
Gibbons, Tseng, Monia Standards Track 78
iSNS March 2001
DESCRIPTION
"This object indicates the status of this entry.
active (1), read-write
notInService (2), read-write
notReady (3), read-only
createAndGo (4), write-only
createAndWait (5), write-only
destroy (6), write-only"
::= {iSnsDDtInfoEntry 3}
--
-- DD Entity Membership Assignment
--
iSnsDDMemberEntityTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsDDEIDtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing Entity Identifiers that
have been assigned to specific DDs."
::= {iSnsDdMmbrs 4}
iSnsDDEIDtInfoEntry OBJECT-TYPE
SYNTAX iSnsDDEIDtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"DD membership information for Entity Identifiers."
INDEX {iSnsDDEIDtId}
::= {iSnsDDMemberEntityTable 1}
iSnsDDEIDtInfoEntry ::=
SEQUENCE {
iSnsDDEIDtId INTEGER,
iSnsDDEIDtEID EIDtype,
iSnsDDEIDtRowStatus RowStatus
}
iSnsDDEIDtId OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The ID that refers to the Discovery Domain that
the entity is a member of."
::= {iSnsDDEIDtInfoEntry 1}
iSnsDDEIDtEID OBJECT-TYPE
SYNTAX EIDtype
MAX-ACCESS read-write
STATUS current
DESCRIPTION
Gibbons, Tseng, Monia Standards Track 79
iSNS March 2001
"The Enity ID of the entity that is a member of the DD."
::= {iSnsDDEIDtInfoEntry 2}
iSnsDDEIDtRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates the status of this entry.
active (1), read-write
notInService (2), read-write
notReady (3), read-only
createAndGo (4), write-only
createAndWait (5), write-only
destroy (6), write-only"
::= {iSnsDDEIDtInfoEntry 3}
--
-- DD Portal Membership Assignment
--
iSnsDDMemberPortalIPAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsDDPIPtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing Portal IP Addreses that
have been assigned to specific DDs."
::= {iSnsDdMmbrs 5}
iSnsDDPIPtInfoEntry OBJECT-TYPE
SYNTAX iSnsDDPIPtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"DD membership information for Portal IP Addresses."
INDEX {iSnsDDPIPtId}
::= {iSnsDDMemberPortalIPAddrTable 1}
iSnsDDPIPtInfoEntry ::=
SEQUENCE {
iSnsDDPIPtId INTEGER,
iSnsDDPIPtPIPA IpAddress,
iSnsDDPIPtRowStatus RowStatus
}
iSnsDDPIPtId OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The ID that refers to the Discovery Domain that
the portal is a member of."
Gibbons, Tseng, Monia Standards Track 80
iSNS March 2001
::= {iSnsDDPIPtInfoEntry 1}
iSnsDDPIPtPIPA OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The Portal IP Address of the entity that is a member of the DD."
::= {iSnsDDPIPtInfoEntry 2}
iSnsDDPIPtRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates the status of this entry.
active (1), read-write
notInService (2), read-write
notReady (3), read-only
createAndGo (4), write-only
createAndWait (5), write-only
destroy (6), write-only"
::= {iSnsDDPIPtInfoEntry 3}
--
-- DD Node Membership Assignment
--
-- By WWUI
iSnsDDMemberNodeWWUITable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsDDNWWUItInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing Node WWUIs that
have been assigned to specific DDs."
::= {iSnsDdMmbrs 6}
iSnsDDNWWUItInfoEntry OBJECT-TYPE
SYNTAX iSnsDDNWWUItInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"DD membership information for Node WWUIs."
INDEX {iSnsDDNWWUItId}
::= {iSnsDDMemberNodeWWUITable 1}
iSnsDDNWWUItInfoEntry ::=
SEQUENCE {
iSnsDDNWWUItId INTEGER,
iSnsDDNWWUItWWUI WWUItype,
iSnsDDNWWUItRowStatus RowStatus
}
Gibbons, Tseng, Monia Standards Track 81
iSNS March 2001
iSnsDDNWWUItId OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The ID that refers to the Discovery Domain that
the node is a member of."
::= {iSnsDDNWWUItInfoEntry 1}
iSnsDDNWWUItWWUI OBJECT-TYPE
SYNTAX WWUItype
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The WWUI the node that is a member of the DD."
::= {iSnsDDNWWUItInfoEntry 2}
iSnsDDNWWUItRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates the status of this entry.
active (1), read-write
notInService (2), read-write
notReady (3), read-only
createAndGo (4), write-only
createAndWait (5), write-only
destroy (6), write-only"
::= {iSnsDDNWWUItInfoEntry 3}
-- DD Node Membership By Node Name WWN
iSnsDDMemberNodeWWNTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsDDNWWNtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing Node WWNs that
have been assigned to specific DDs."
::= {iSnsDdMmbrs 7}
iSnsDDNWWNtInfoEntry OBJECT-TYPE
SYNTAX iSnsDDNWWNtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"DD membership information for Node WWNs."
INDEX {iSNSDDNWWNtId}
::= {iSnsDDMemberNodeWWNTable 1}
iSnsDDNWWNtInfoEntry ::=
Gibbons, Tseng, Monia Standards Track 82
iSNS March 2001
SEQUENCE {
iSnsDDNWWNtId INTEGER,
iSnsDDNWWNtNodeWWN WWNtype,
iSnsDDNWWNtRowStatus RowStatus
}
iSnsDDNWWNtId OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The ID that refers to the Discovery Domain that
the node is a member of."
::= {iSnsDDNWWNtInfoEntry 1}
iSnsDDNWWNtNodeWWN OBJECT-TYPE
SYNTAX WWNtype
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The WWN the node that is a member of the DD."
::= {iSnsDDNWWNtInfoEntry 2}
iSnsDDNWWNtRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates the status of this entry.
active (1), read-write
notInService (2), read-write
notReady (3), read-only
createAndGo (4), write-only
createAndWait (5), write-only
destroy (6), write-only"
::= {iSnsDDNWWNtInfoEntry 3}
--
-- DD Port Membership Assignment
--
iSnsDDMemberPortWWNTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsDDPWWNtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing Port WWNs that
have been assigned to specific DDs."
::= {iSnsDdMmbrs 8}
iSnsDDPWWNtInfoEntry OBJECT-TYPE
SYNTAX iSnsDDPWWNtInfoEntry
MAX-ACCESS not-accessible
Gibbons, Tseng, Monia Standards Track 83
iSNS March 2001
STATUS current
DESCRIPTION
"DD membership information for Port WWNs."
INDEX {iSnsDDPWWNtId}
::= {iSnsDDMemberPortWWNTable 1}
iSnsDDPWWNtInfoEntry ::=
SEQUENCE {
iSnsDDPWWNtId INTEGER,
iSnsDDPWWNtPortWWN WWNtype,
iSnsDDPWWNtRowStatus RowStatus
}
iSnsDDPWWNtId OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The ID that refers to the Discovery Domain that
the port is a member of."
::= {iSnsDDPWWNtInfoEntry 1}
iSnsDDPWWNtPortWWN OBJECT-TYPE
SYNTAX WWNtype
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The WWN the port that is a member of the DD."
::= {iSnsDDPWWNtInfoEntry 2}
iSnsDDPWWNtRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates the status of this entry.
active (1), read-write
notInService (2), read-write
notReady (3), read-only
createAndGo (4), write-only
createAndWait (5), write-only
destroy (6), write-only"
::= {iSnsDDPWWNtInfoEntry 3}
--
-- iSNS Registered Objects ----------------------------------------
----------
--
iSnsRegObj OBJECT IDENTIFIER ::= {iSNS 3}
--
Gibbons, Tseng, Monia Standards Track 84
iSNS March 2001
-- iSNS Content Information ---------------------------------------
-----------
--
--
-- iSNS Registered Entity Information
--
iSnsNumEntities OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current total number of Entity entries in the iSNS."
::= {iSnsRegObj 1}
--
-- iSNS Registered Entities Table
--
iSnsRegEntityTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsREtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing the registered entities in the iSNS."
::= {iSnsRegObj 2}
iSnsREtInfoEntry OBJECT-TYPE
SYNTAX iSnsREtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on registered entities in the iSNS."
INDEX {iSnsREtEIdx}
::= {iSnsRegEntityTable 1}
iSnsREtInfoEntry ::=
SEQUENCE {
iSnsREtEIdx EntIdx,
iSnsREtEID EIDtype,
iSnsREtType EntType,
iSnsREtMgtIpAddr IpAddress,
iSnsREtESIintvl INTEGER,
iSnsREtESIport INTEGER,
iSnsREtTimestamp DateAndTime,
iSnsREtESCNmap OCTET STRING
}
iSnsREtEIdx OBJECT-TYPE
SYNTAX EntIdx
MAX-ACCESS read-only
STATUS current
Gibbons, Tseng, Monia Standards Track 85
iSNS March 2001
DESCRIPTION
"The Entity Index for this entity. The index is
derived for mapping between objects."
::= {iSnsREtInfoEntry 1}
iSnsREtEID OBJECT-TYPE
SYNTAX EIDtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Entity Identifier for this entity as defined in
the iSNS Specification."
::= {iSnsREtInfoEntry 2}
iSnsREtType OBJECT-TYPE
SYNTAX EntType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Entity Type as defined in the iSNS Specification.
Type Value Entity Type
---------- -----------
1 iSCSI
2 iFCP
3 FCIP
All Others Reserved
"
::= {iSnsREtInfoEntry 3}
iSnsREtMgtIpAddr OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Entity Management IP address for this entity as
defined in the iSNS Specification."
::= {iSnsREtInfoEntry 4}
iSnsREtESIintvl OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"ESI interval as defined in the iSNS Specification."
::= {iSnsREtInfoEntry 5}
iSnsREtESIport OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The TCP/UDP port used for ESI updates as defined
in the iSNS Specification."
Gibbons, Tseng, Monia Standards Track 86
iSNS March 2001
::= {iSnsREtInfoEntry 6}
iSnsREtTimestamp OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The entity registration timestamp as defined in the
iSNS Specification."
::= {iSnsREtInfoEntry 7}
iSnsREtESCNmap OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The entity SCN notification map as defined in the
iSNS Specification."
::= {iSnsREtInfoEntry 8}
--
-- iSNS Registered Portal Information
--
iSnsNumPortals OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current total number of registered Portals in iSNS."
::= {iSnsRegObj 3}
--
-- iSNS Registered Portals Table
--
iSnsRegPortalTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsRPRTLtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing the registered portals in the iSNS."
::= {iSnsRegObj 4}
iSnsRPRTLtInfoEntry OBJECT-TYPE
SYNTAX iSnsRPRTLtInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on registered entity portals in the iSNS."
INDEX {iSnsRPRTLtEIdx, iSnsRPRTLtPrtlIdx}
::= {iSnsRegPortalTable 1}
Gibbons, Tseng, Monia Standards Track 87
iSNS March 2001
iSnsRPRTLtInfoEntry ::=
SEQUENCE {
iSnsRPRTLtEIdx EntIdx,
iSnsRPRTLtPrtlIdx PrtlIdx,
iSnsRPRTLtEID EIDtype,
iSnsRPRTLtIpAddr IpAddress,
iSnsRPRTLtPort INTEGER
}
iSnsRPRTLtEIdx OBJECT-TYPE
SYNTAX EntIdx
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Entity Index of the entity associated with this portal.
The index is derived for mapping between objects."
::= {iSnsRPRTLtInfoEntry 1}
iSnsRPRTLtPrtlIdx OBJECT-TYPE
SYNTAX PortalIdx
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Portal Index for this node. The index is derived for
mapping between objects."
::= {iSnsRPRTLtInfoEntry 2}
iSnsRPRTLtEID OBJECT-TYPE
SYNTAX EIDtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Entity Identifier of the entity associated with this portal."
::= {iSnsRPRTLtInfoEntry 3}
iSnsRPRTLtIpAddr OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP Address for this portal as defined in the iSNS
Specification."
::= {iSnsRPRTLtInfoEntry 4}
iSnsRPRTLtPort OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The TCP/UDP port for this portal as defined in the iSNS
Specification."
::= {iSnsRPRTLtInfoEntry 5}
Gibbons, Tseng, Monia Standards Track 88
iSNS March 2001
--
-- iSNS Registered Node Information by WWUI,
--
iSnsNumWWUINodes OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current total number of Node entries, by WWUI, in the iSNS."
::= {iSnsRegObj 5}
--
-- iSNS Registered Node Table by WWUI
--
iSnsRegWWUINodeTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsRegWWUINtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing the registered Nodes, by WWUI, in the iSNS."
::= {iSnsRegObj 6}
iSnsRegWWUINtEntry OBJECT-TYPE
SYNTAX iSnsRegWWUINtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on registered entity nodes, by WWUI, in the iSNS."
INDEX {iSnsRegWWUINtEIdx, iSnsRegWWUINtNodeIdx}
::= {iSnsRegWWUINodeTable 1}
iSnsRegWWUINtEntry ::= SEQUENCE {
iSnsRegWWUINtEIdx EntIdx,
iSnsRegWWUINtNodeIdx NodeIdx,
iSnsRegWWUINtEID EIDtype,
iSnsRegWWUINtNodeWWUI WWUItype,
iSnsRegWWUINtNodeType NodeType,
iSnsRegWWUINtNodeAliasSymb OCTET STRING
}
iSnsRegWWUINtEIdx OBJECT-TYPE
SYNTAX EntIdx
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Entity Index of the Entity associated with this node. The
index is derived for mapping between objects."
::= {iSnsRegWWUINtEntry 1}
iSnsRegWWUINtNodeIdx OBJECT-TYPE
SYNTAX NodeIdx
Gibbons, Tseng, Monia Standards Track 89
iSNS March 2001
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Node Index for this node. The index is derived for
mapping between objects."
::= {iSnsRegWWUINtEntry 2}
iSnsRegWWUINtEID OBJECT-TYPE
SYNTAX EIDtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Entity Identifier of the Entity associated with this node."
::= {iSnsRegWWUINtEntry 3}
iSnsRegWWUINtNodeWWUI OBJECT-TYPE
SYNTAX WWUItype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The WWUI for this node as defined in the iSNS Specification."
::= {iSnsRegWWUINtEntry 4}
iSnsRegWWUINtNodeType OBJECT-TYPE
SYNTAX NodeType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Node Type bit-map as defined in the iSNS Specification.
Bit Field Node Type
--------- ---------
0 (Lsb) Target
1 Initiator
All Others RESERVED
"
::= {iSnsRegWWUINtEntry 5}
iSnsRegWWUINtNodeAliasSymb OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Alias/Symbolic Name of the node as defined in the
iSNS Specification. This is a variable-length text-based
description of up to 255 bytes."
::= {iSnsRegWWUINtEntry 6}
--
-- iSNS Registered Node, by WWN, Information
--
iSnsNumWWNNodes OBJECT-TYPE
SYNTAX INTEGER
Gibbons, Tseng, Monia Standards Track 90
iSNS March 2001
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current total number of Node entries, by WWN, in the iSNS."
::= {iSnsRegObj 7}
--
-- iSNS Registered Node Table by WWN
--
iSnsRegWWNNodeTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsRegWWNNtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing the registered Nodes, by WWN, in the iSNS."
::= {iSnsRegObj 8}
iSnsRegWWNNtEntry OBJECT-TYPE
SYNTAX iSnsRegWWNNtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on registered entity nodes, by WWN, in the iSNS."
INDEX {iSnsRegWWNNtNodeWwn}
::= {iSnsRegWWNNodeTable 1}
iSnsRegWWNNtEntry ::= SEQUENCE {
iSnsRegWWNNtNodeWwn WWNtype,
iSnsRegWWNNtEIdx EntIdx,
iSnsRegWWNNtEID EIDtype,
iSnsRegWWNNtNodeType NodeType,
iSnsRegWWNNtNodeAliasSymb OCTET STRING,
iSnsRegWWNNtFcNodeIpAddress IpAddress,
iSnsRegWWNNtFcNodeIPA OCTET STRING
}
iSnsRegWWNNtNodeWwn OBJECT-TYPE
SYNTAX WWNtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Node WorldWideName as defined in the iSNS Specification."
::= {iSnsRegWWNNtEntry 1}
iSnsRegWWNNtEIdx OBJECT-TYPE
SYNTAX EntIdx
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Entity Index of the Entity associated with this node. The
index is derived for mapping between objects."
::= {iSnsRegWWNNtEntry 2}
Gibbons, Tseng, Monia Standards Track 91
iSNS March 2001
iSnsRegWWNNtEID OBJECT-TYPE
SYNTAX EIDtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Entity Identifier of the Entity associated with this node."
::= {iSnsRegWWNNtEntry 3}
iSnsRegWWNNtNodeType OBJECT-TYPE
SYNTAX NodeType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Node Type bit-map as defined in the iSNS Specification.
Bit Field Node Type
--------- ---------
0 (Lsb) Target
1 Initiator
All Others RESERVED
"
::= {iSnsRegWWNNtEntry 4}
iSnsRegWWNNtNodeAliasSymb OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Alias/Symbolic Name of the node as defined in the
iSNS Specification. This is a variable-length text-based
description of up to 255 bytes."
::= {iSnsRegWWNNtEntry 5}
iSnsRegWWNNtFcNodeIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The FC Node IP address of the node as defined in the
iSNS Specification."
::= {iSnsRegWWNNtEntry 6}
iSnsRegWWNNtFcNodeIPA OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The object identifies the FC Initial Process Associator
of the node for the entry as defined in the iSNS
Specification."
::= {iSnsRegWWNNtEntry 7}
--
Gibbons, Tseng, Monia Standards Track 92
iSNS March 2001
-- iSNS Registered Port Information
--
iSnsNumPorts OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current total number of Port entries in the iSNS.
This is only applicable to iFCP entries."
::= {iSnsRegObj 9}
--
-- iSNS Port Table
--
iSnsRegWWNPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF iSnsRegWWNPtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on registered entity ports, by WWN, in the iSNS."
::= {iSnsRegObj 10}
iSnsRegWWNPtEntry OBJECT-TYPE
SYNTAX iSnsRegWWNPtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on registered entity ports, by WWN, in the iSNS."
INDEX {iSnsRegWWNPtPortWwn}
::= {iSnsRegWWNPortTable 1}
iSnsRegWWNPtEntry ::= SEQUENCE {
iSnsRegWWNPtPortWwn WWNtype,
iSnsRegWWNPtPortID FCIDtype,
iSnsRegWWNPtPortType INTEGER,
iSnsRegWWNPtPortSymb OCTET STRING,
iSnsRegWWNPtNodeWwn WWNtype,
iSnsRegWWNPtFabricPortWwn WWNtype,
iSnsRegWWNPtFcHA FCIDtype,
iSnsRegWWNPtFcPortIpAddress IpAddress,
iSnsRegWWNPtFcCos INTEGER,
iSnsRegWWNPtFcFc4Types OCTET STRING,
iSnsRegWWNPtFcFc4Descr OCTET STRING,
iSnsRegWWNPtFcFc4Features OCTET STRING
}
iSnsRegWWNPtPortWwn OBJECT-TYPE
SYNTAX WWNtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Gibbons, Tseng, Monia Standards Track 93
iSNS March 2001
"The Port WWN as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 1}
iSnsRegWWNPtPortID OBJECT-TYPE
SYNTAX FCIDtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Port ID as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 2}
iSnsRegWWNPtPortType OBJECT-TYPE
SYNTAX INTEGER {
unknown (0),
n-port (1),
nl-port (2),
f-nl-port (3),
f-port (129), -- x'81'
fl-port (130), -- x'82'
e-port (132), -- x'84'
b-port (133), -- x'85'
mFCP-port (65297), -- x'FF11'
iFCP-port (65298), -- x'FF12'
unknown-end (65535)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Port Type as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 3}
iSnsRegWWNPtPortSymb OBJECT-TYPE
SYNTAX OCTET STRING(SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Port Symbolic Name as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 4}
iSnsRegWWNPtNodeWwn OBJECT-TYPE
SYNTAX WWNtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Node WWN associated with this Port as defined in the iSNS
Specification."
::= {iSnsRegWWNPtEntry 5}
iSnsRegWWNPtFabricPortWwn OBJECT-TYPE
SYNTAX WWNtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Gibbons, Tseng, Monia Standards Track 94
iSNS March 2001
"The Fabric Port WWN associated with this Port as defined in the
iSNS Specification."
::= {iSnsRegWWNPtEntry 6}
iSnsRegWWNPtFcHA OBJECT-TYPE
SYNTAX FCIDtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The FC Hard Address as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 7}
iSnsRegWWNPtFcPortIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The FC Port IP Address as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 8}
iSnsRegWWNPtFcCos OBJECT-TYPE
SYNTAX INTEGER {
-- class-unknown (0),
class-F (1),
class-1 (2),
class-F-1 (3),
class-2 (4),
class-F-2 (5),
class-1-2 (6),
class-F-1-2 (7),
class-3 (8),
class-F-3 (9),
class-1-3 (10),
class-F-1-3 (11),
class-2-3 (12),
class-F-2-3 (13),
class-1-2-3 (14),
class-F-1-2-3 (15)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The FC Class of Service as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 9}
iSnsRegWWNPtFcFc4Types OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The FC FC-4 Types as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 10}
Gibbons, Tseng, Monia Standards Track 95
iSNS March 2001
iSnsRegWWNPtFcFc4Descr OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The FC FC-4 Descriptors as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 11}
iSnsRegWWNPtFcFc4Features OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The FC FC-4 Features as defined in the iSNS Specification."
::= {iSnsRegWWNPtEntry 12}
END
Gibbons, Tseng, Monia Standards Track 96
Datatracker
Report a datatracker bug
draft-ietf-ips-isns-01
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4171.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |