[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
Internet Draft K. Gibbons
<draft-tseng-ips-isns-01.txt> J. Tseng
Expires April 2001 C. Monia
Nishan Systems
October 2000
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.
Comments
Comments should be sent to the ips mailing list (ips@ece.cmu.edu)
or to the authors.
1. Abstract
The Internet Storage Name Service (iSNS) provides a generic
framework for configuring and managing various storage entities and
their usage attributes in an IP-based storage network. iSNS
integrates Fibre Channel name server and DNS mechanisms into a
common naming and resource-discovery framework. The iSNS Protocol
(iSNSP) defines how entities communicate with the iSNS server to
discover and utilize available networked storage resources. The
iSNS server MAY be supported by a consolidated iSNS directory
database, which serves as a repository to store information about
various storage resources, providing easy access to topology
information for storage entities.
2. Conventions used in this document
iSNS refers to the framework consisting of the storage network
model and associated services.
Gibbons, Tseng, Monia 2
iSNS October 2000
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].
3. iSNS Overview
IP network entities use the Domain Name System (DNS) to resolve
mappings of DNS names to IP addresses. Fibre Channel-based storage
entities use a Storage Name Server (SNS) to discover other storage
entities and their addressing information. The iSNSP provides a
common framework to supply both DNS and SNS services for all
storage entities.
Although the DNS and SNS infrastructures MAY be managed separately,
nevertheless they must provide consistent naming and addressing
information to both IP-based and Fibre Channel-based storage
entities. The iSNS Protocol (iSNSP) provides a common framework
for integration of these naming services for both IP and Fibre
Channel-based storage entities.
This framework builds upon the association of IP and Fibre Channel
objects, and the resulting consistency guarantees among these
objects. Regardless of the underlying implementation, the framework
presents the illusion of common IP and Fibre Channel objects. .
Some attributes of these database objects may be applicable to
Fibre Channel-based entities, while other attributes may be
applicable only to IP-based iSCSI entities. Still other attributes
such as World Wide Port Name may be used by both Fibre Channel and
iSCSI entities. Values stored as attributes for both iSCSI and
Fibre Channel devices SHALL be consistent regardless of whether
they are accessed for use by iSCSI or Fibre Channel devices. The
consistency guarantee MAY be implemented through a consolidated
information base.
Gibbons, Tseng, Monia 3
iSNS October 2000
The following diagram shows an example of Fibre Channel clients and IP
clients accessing SNS and DNS data via iSNS server and DNS server:
+------------+ +-----------+ +-----------+
| | LDAP | Directory | LDAP | iSNS |
| DNS Server |<-------->| Database |<-------->| Server |
| | | | | |
+------+-----+ +-----+-----+ +-----+-----+
| | |
| DNS | LDAP iSNSP |
|Queries | |
+------+----------------------+----------------------+-----+
| |
| IP Network |
| |
+------+----------------------+----------------------+-----+
| | |
| +-------+------+ |
| | FC-IP / | |
| |Gateway /iSNS | |
| | Proxy /Server| |
| +-------+------+ |
| | |
+----+----+ +----+----+ +----+----+
| iSCSI | | Fibre | | iSCSI |
|Initiator| | Channel | | Target |
| | | Network | | |
+---------+ +---------+ +---------+
iSNS Client Entities
In the above example, each iSNS Client Entity has its attributes
committed to the directory database, regardless of whether the
client is a Fibre Channel entity, or an IP-based entity.
A DNS server receiving a DNS resolve request can use the directory
database to resolve DNS names to IP addresses. Changes to DNS name
mappings due to DNS Zone transfers and other DNS protocol events
will be reflected directory update messages to the database, and
consistently reflected in subsequent iSNSP queries and SCN's.
The iSNS server may be a standalone entity, or it may be integrated
into another network entity such as a Fibre Channel-iSCSI gateway
proxy device. The iSNS directory database may be cohosted with the
iSNS server, or it may be a separate infrastructure based on
distributed directory database services such as LDAP.
3.1 iSNS Functional Components
Gibbons, Tseng, Monia 4
iSNS October 2000
There are four functional components required by devices operating
in a IP-based storage network:
1) A Name Service Providing Storage Resource Discovery
2) State Change Notification Service
3) Network Zoning Service
4) Domain Name System (DNS) Service (see RFC 1035)
3.1.1 Name Registration Service
The iSNS provides a registration function to allow all entities in
a storage network to register and query the directory. This allows
an iSNS client initiator to obtain information about iSNS client
target devices from the iSNS server. This service is modeled on the
Fiber Channel Name Services described in FC-GS-2, with extensions,
operating within the context of an IP network.
3.1.2 State Change Notification Service
The State Change Notification service provides functionality for
issuing notifications about network events that may affect the
operational state of iSNS entities. The State Change Notification
service gives an iSNS client the ability to register for
notification of events detected or received by the iSNS server from
an iSNS client entity. This service provides the Fiber Channel
State Change Notification service, with extensions, operating
within the context of an IP network.
3.1.3 Network Zoning Service
The Network Zoning Service implements the functionality to support
grouping of iSNS client devices into domains for administrative and
access control purposes. Devices must be in common zones in order
to "see" each other and communicate through the network. Devices
can be a member of multiple zones simultaneously.
3.1.4 DNS Name Service
The iSNS framework unifies the above storage services used in Fibre
Channel with the Domain Name System (DNS) service in IP-based
networks. A detailed description of the Domain Name System (DNS)
protocol is found in [RFC 1035], and is beyond the scope of this
document. In the iSNS framework, the DNS host names can be given to
storage controllers, HBA's, gateways, and iSCSI NICs. To create a
unified iSNS framework, DNS naming features now coexist with
storage concepts such as World Wide Names (WWN's). For example,
WWN's can now be used as a key in an iSNS query to discover the DNS
Name and Path of a particular storage device. Similarly, the iSNS
directory database can be used to support queries by DNS resolvers.
Gibbons, Tseng, Monia 5
iSNS October 2000
3.2 iSNS Architectural Components
3.2.1 iSNS Client
Entities which initiate transactions using the iSNS protocol will
hereafter be referred to as iSNS clients. iSNS clients register
their attribute information in the iSNS server through use of the
iSNS protocol.
3.2.2 iSNS Server
The iSNS server resides at an IP address in the network, and
responds to TCP and UDP-based iSNSP messages at a TBD port. It may
be implemented on a stand-alone host computer or network management
station, or integrated into one or more switches in the network.
Administration of the iSNS server is similar to established
processes for administering DNS servers. The primary functional
difference between the iSNS and classical DNS is the ability for
client entities to write information to the server database using
the iSNSP.
The iSNS server responds to iSNS and DNS protocol queries and
requests, and initiates iSNS protocol State Change Notifications.
Properly authenticated registration request information is stored
in an internal or external database.
3.2.3 iSNS Directory Database
The iSNS database is a repository for the iSNS server(s) and DNS
server(s) to store information about DNS Names, IP Addresses, Fibre
Channel storage attributes (WWNN, Port ID, etc...), and iSCSI
storage attributes. The database SHALL guarantee consistency
between data stored and retrieved by iSNS server(s) and DNS
server(s). This database MAY be implemented using a distributed
directory database such as LDAP, and MAY be implemented using a
single common database for both iSNS servers and DNS servers.
3.2.4 World Wide Name (WWN) Identifiers
iSNS client entities use a set of identifiers to uniquely identify
the device (Node) and each network interface (Port) associated with
the device. A unique 64-bit World Wide Name (WWN) is assigned to
each node and each port on the device. The three WWN types are
Node Name (WWNN), Port Name (WWPN), and Fabric Port Name (FWWN).
These globally unique identifiers are used during the device
registration process, and are assigned values 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].
Editor's note: iSCSI naming conventions are TBD by IPS working
group.
Gibbons, Tseng, Monia 6
iSNS October 2000
3.2.5 IP Address
The IP address is used to identify a network interface of an IP
storage gateway or native device in an IP network.
3.2.6 DNS Name
A DNS Name is assigned to a network node having one or more storage
devices. Each IP storage device is distinguished by the Path
field. The DNS Name uses a hierarchical name space consisting of
one or more labels, each of at most 63 characters. A period is
used to separate the labels. The iSNS uses a fully qualified
domain name consisting of up to 255 characters. Each Domain Name
maps to an IP Address. More information about the DNS Domain Name
can be found in RFC 1035.
3.3 Compatible Naming Convention Example
The above components of the iSNS architectural framework support
the use of Fibre Channel naming conventions as well as the URL
convention common in IP networking. The framework allows iSCSI
naming conventions to be mapped to naming conventions used in Fibre
Channel. For example, the following URL format can be implemented
and translated to the Fibre Channel naming convention through use
of the iSNS server:
iscsi://server1.nishansystems.com/device3?WWPN=c2ae3253f3
The iSCSI client parsing this URL would submit an iSNSP query to
the iSNS server, using the keys DNS Name =
"server1.nishansystems.com", Path = "device3" and WWPN =
"c2ae3253f3". The iSNS directory database would retrieve the
attribute IP Address = ww.xx.yy.zz as the proxy IP gateway address
to the Fibre Channel fabric. DevGetNext queries to the iSNS server
will allow the iSCSI client to further discover additional targets
in the Fibre Channel fabric by returning their WWPN's.
3.4 iSNS Applicability
iSNSP functions in networks under cooperative administrative
control. Such networks permit a policy to be implemented regarding
security, multicast routing, and organization of services and
clients into groups. Through leveraging of an Internet-based
distributed database framework such as LDAP, iSNS functionality can
be broadly extended to the Public Internet. Additionally, the iSNS
framework leverages existing DNS mechanisms, where zone transfer of
domain information may take place from upstream authorities in the
DNS hierarchy.
Gibbons, Tseng, Monia 7
iSNS October 2000
The iSNSP provides a common framework for providing the above
services for IP-based storage devices such as native iSCSI storage
products, as well as FCP-based devices such as existing Fibre
Channel storage devices.
4. iSCSI/Fibre Channel Database Objects
iSNS provides the framework for archiving and retrieval of topology
information of iSCSI and Fibre Channel-based storage devices. This
architecture defines objects which represent storage entity
components in both Fibre Channel and IP-based storage devices.
The following architecture framework includes all elements needed
to describe both iSCSI-based and FCP-based (Fibre Channel) storage
device attributes in the iSNS directory database. Existing Fibre
Channel storage resources can now be described to iSCSI-based iSNS
clients for access through a proxy iSCSI/Fibre Channel gateway.
Four object entities are defined in this architecture framework.
They are IP STORAGE NODE, STORAGE ENTITY, ZONE and STORAGE PORT.
Each of these objects are defined in sections 4.1, 4.2, 4.3, and
4.4.
The following diagram shows how database objects are used to
represent storage components (with the exception of Zones). Each
object has a set of attributes described in section 5., which may
be applicable in either a iSCSI or Fibre Channel network, or both.
Objects are denoted in all CAPITAL letters.
Gibbons, Tseng, Monia 8
iSNS October 2000
+----------------------------------------------------------------+
| IP Network |
+--------------------+---------------------+---------------------+
| |
IP Address 1 o o IP Address 2
| |
+--------------------|---------------------|---------------------+
| | | |
| +----------------+---------------------+-----------------+ |
| | Service Delivery Subsystem (FC or internal dev bus) | |
| +--------+ +---------------------+ +-----------+ +-------+ |
| | | | | | | |
| | | | | | | |
| +--------+ +-------+ +-----+ +-----------+ +-------+ |
| | |STORAGE| | | |STORAGE| |STORAGE| | |
| | | PORT | | | | PORT | | PORT | | |
| | +-------+ | | +-------+ +-------+ | |
| | | | | |
| | | | 000000000000000000000 | |
| | | | Logical Units | |
| | | | | |
| | initiator | | target | |
| | STORAGE ENTITY | | STORAGE ENTITY | |
| +------------------+ +-----------------------------+ |
| |
| IP STORAGE NODE |
+----------------------------------------------------------------+
4.1 IP Storage Node Object
The IP Storage Node object defines an IP endpoint node that
originates or terminates a TCP/IP connection. An IP End Node may
contain one or more Storage Entity objects. This object may be
used to define a native iSCSI storage device, iSCSI NIC, a Fibre
Channel-iSCSI gateway, or any other storage device with an IP
address. In the case of a Fibre Channel to IP gateway, the IP
storage node object may support one or more native Fibre Channel
storage devices. One or more IP address attribute values may be
assigned to an IP Storage Node object entity.
The following are attributes of the IP Storage Node object. Each
attribute is described in more detail in section 5.4.
Applicability indicates whether the attribute is used by an iSCSI
device or a Fibre Channel device, or both. A gateway device will
need to support both iSCSI and Fibre Channel attributes.
The following attributes are described in more detail in sections
5.4.
The Key Attribute column indicates the attribute is a search key
used to query the database.
Gibbons, Tseng, Monia 9
iSNS October 2000
Applicability
Attribute iSCSI Fibre Channel Key Attribute
--------- ----- ------------- -------------
IP Address * *
Management IP Address * *
DNS Name * *
Client Certificate
Port Number
4.2 Storage Entity Object
The Storage Entity object defines an individual storage initiator
or target. This entity may be a RAID device, a Fibre Channel HBA,
or other individual storage device. The Storage Entity may have
one or more Storage Port objects.
The following are attributes of the Storage Entity object. Each
attribute is described in more detail in section 5.4. Applicability
indicates whether the attribute is used by an iSCSI device or a
Fibre Channel device, or both. A gateway device will need to
support both iSCSI and Fibre Channel attributes.
The following attributes are described in more detail in sections
5.4.
Applicability
Attribute iSCSI Fibre Channel Key Attribute
--------- ----- ------------- -------------
Node Name * *
Node Symbolic Name *
FC Node IPA *
Node Type * *
4.3 Zone Object
Zoning is 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 zone. Initiators will thus not be able to
"see" devices that are not in a common zone.
A Zone entity contains one or more Storage Ports. Storage Ports
that are in the same Zone entity can "see" each other, and can thus
communicate without restrictions.
The following are attributes of the Zone object. Each attribute is
described in more detail in section 5.4. Applicability indicates
whether the attribute is used by an iSCSI device or a Fibre Channel
device, or both. A gateway device will need to support both iSCSI
and Fibre Channel attributes.
Gibbons, Tseng, Monia 10
iSNS October 2000
The following attributes are described in more detail in sections
5.4.
Applicability
Attribute iSCSI Fibre Channel Key Attribute
--------- ----- ------------- -------------
Zone ID * * *
Zone Tag * * *
Zone Symbolic Name * *
Zone Member (WWPN) * *
Zone Member (IP Address) *
Zone Member Priority * *
4.4 Storage Port Object
The Storage Port object defines an individual service delivery port
that services a Storage Entity. The Storage Port provides the
interconnect between the Storage Entity and its Logical Units with
the Service Delivery Subsystem. The Service Delivery Subsytem may
be a Fibre Channel interconnect, or an internal device bus,
depending on the specific type of Storage Entity being supported by
the Storage Port. A Storage Port may be a member of one or more
Zone entities.
The following attributes are described in more detail in sections
5.4.
Applicability
Attribute iSCSI Fibre Channel Key Attribute
--------- ----- ------------- -------------
Port Name (WWPN) * * *
FC Hard Address *
Fabric Port Name (FWWN) * *
Port_ID *
Port_Symbolic Name *
Port_Type * *
FC Class of Service *
FC Port IP Address *
Path *
5. iSNS Message Protocol
The following describes the format of the iSNS Protocol:
Gibbons, Tseng, Monia 11
iSNS October 2000
Byte MSb LSb
Offset 7 6 5 4 3 2 1 0
+----------------------------------+
0 | iSNSP VERSION | 2 Bytes
+----------------------------------+
2 | FUNCTION ID | 2 Bytes
+----------------------------------+
4 | MESSAGE LENGTH | 2 Bytes
+----------------------------------+
6 | FLAGS | 2 Bytes
+----------------------------------+
8 | TRANSACTION ID | 2 Bytes
+----------------------------------+
10 | MESSAGE PAYLOAD | N Bytes
+----------------------------------+
10 + N | AUTHENTICATION BLOCK (if present)| L Bytes
+----------------------------------+
Total Length = 10 + N + L
5.1 iSNS Message Header
The iSNSP header contains the iSNSP VERSION, FUNCTION ID, MESSAGE
LENGTH, FLAGS, and TRANSACTION ID fields as defined below:
iSNSP VERSION - Currently 0x0001
FUNCTION ID defines the type of iSNS message. It contains a value
as defined in the "ID" column in the tables below. The following
messages are iSNSP request messages:
Message Description Abbreviation Func ID Support
------------------- ------------ ------- -------
Register Device Attribute Req RegDevAttr 0x0001 Required
Device Attribute Query Request DevAttrQry 0x0002 Required
Device Get Next Request DevGetNext 0x0003 Optional
Deregister Device Request DeregDev 0x0004 Required
SCN Register Request SCNReg 0x0005 Required
State Change Notification SCN 0x0006 Required
Register Zone RegZone 0x0007 Required
Deregister Zone DeregZone 0x0008 Required
Register Device in Zone RegDevZone 0x0009 Required
Deregister Device in Zone DeregDevZone 0x000A Required
Port Status Inquiry PSI 0x000B Optional
PSI Update PSIUpdate 0x000C Optional
Name Service Heartbeat Heartbeat 0x000D Required
RESERVED 0x0000-8000
The following are iSNSP response messages:
Gibbons, Tseng, Monia 12
iSNS October 2000
Response Message Description Abbreviation Func_ID Support
---------------------------- ------------ ------- -------
Register Device Attribute RegDevRsp 0x8001 Required
Device Attribute Query Response DevAttrQryRsp 0x8002 Required
Device Get Next Response DevGetNextRsp 0x8003 Optional
Deregister Device Response DeregDevRsp 0x8004 Required
SCN Register Response SCNRegRsp 0x8005 Required
Register Zone Response RegZoneRsp 0x8006 Required
Deregister Zone Response DeregZoneRsp 0x8007 Required
Register Device in Zone Response RegDevZoneRsp 0x8008 Required
Deregister Device in Zone Resp DeregDevZoneRsp 0x8009 Required
RESERVED 0x800A-FFFF
iSNS MESSAGE LENGTH - Specifies the length of the MESSAGE PAYLOAD
field in bytes.
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 Flag
--------- ----
0-12 RESERVED
13 Authentication Block Present
14 Sender is the iSNS server
15 Sender is the iSNS client
TRANSACTION ID - Is set to a unique value for each request message.
Replies must use the same TRANSACTION ID value as the associated
iSNS request message. If a message is retransmitted, the same
TRANSACTION ID value must be used.
5.2 iSNS Message Payload
The MESSAGE PAYLOAD is of variable length and contains attributes
used for registration and query operations. Each iSNS attribute is
specified in the iSNSP message payload using Tag-Length-Value (TLV)
format, as shown below:
+----------+----------+-------------------+
| attr_id | attr_len | attr_val |
+----------+----------+-------------------+
attr_id (ID) - a 2-byte field that identifies the attribute as
defined in section 5.4. This field contains the ID of the
indicated attribute.
attr_len (Length) - a 2-byte field that indicates the length, in
bytes, of the attribute value to follow.
Gibbons, Tseng, Monia 13
iSNS October 2000
attr_val (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 prepended to the MESSAGE PAYLOAD. This
field contains 0x0000 (NO ERROR) if the original iSNSP request
message was processed normally by the iSNS server. Error codes are
described in the following table:
Error Code Error Description
---------- -----------------
0 No Error
1 Unknown Error
2 Format Error
3 Invalid Registration
4 Scope Not Supported
5 Authentication Unknown
6 Authentication Absent
7 Authentication Failed
8 Entry Requested Not Found
9 Version Not Supported
10 Internal Bus Error
11 Busy Now
12 Option Not Understood
13 Invalid Update
14 Message Not Supported
15 Refresh Rejected
5.3 Message Authentication
iSNSP provides an optional message authentication capability.
Network interactions using iSNSP occur in short transactions, and
are generally not sesion based. The iSNS client connects to the
iSNS server only when information needs to be registered or
queried.
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
Gibbons, Tseng, Monia 14
iSNS October 2000
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 message. 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 | BLOCK STRUCTURE DESCRIPTOR | 2 Bytes
+----------------------------------+
2 | AUTHENTICATION BLOCK LENGTH | 2 Bytes
+----------------------------------+
4 | TIMESTAMP | 4 Bytes
+----------------------------------+
8 | SPI STRING LENGTH | 1 Byte
+----------------------------------+
9 | SPI STRING | N Bytes
+----------------------------------+
9 + N | STRUCTURED AUTHENTICATOR | M Bytes
+----------------------------------+
Total Length = 9 + N + M
BLOCK STRUCTURE DESCRIPTOR (BSD) - Defines the structure and
algorithm to use for the STRUCTURED AUTHENTICATOR. Currently, the
only defined value for BSD is 0x0002, which represents DSA with
SHA-1. Details on DSA can be found in [DSS]. BSD values from
0x0000 to 0x7FFF are assigned by IANA, while 0x8000 to 0x8FFF are
for private use. The BSD value 0x0002 is compatible with the X.509
PKI specification, allowing easy integration of the STRUCTURED
AUTHENTICATOR format with an existing PKI infrastructure.
AUTHENTICATION BLOCK LENGTH - Defines the length of the
authentication block, beginning with the BSD field and running
through the last byte of the STRUCTURED AUTHENTICATOR.
TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving
the number of seconds since midnight, January 1, 1970.
SPI STRING LENGTH - The length of the SPI STRING field.
Gibbons, Tseng, Monia 15
iSNS October 2000
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.
5.4 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:
Attribute Name Size(bytes) ID Reg Key Query Key
-------------- ----------- -- ------- ---------
Node Name (WWNN) 8 1 1 1,4, 9&10 or 18&19
Node Symbolic Name 0-255 2 1 1,4, 9&10 or 18&19
Management IP Address 16 3 1 1,4, 9&10 or 18&19
Port Name (WWPN) 8 4 1 1 or 9&10
FC Node IPA 8 5 1 1,4 or 9&10
FC Hard Address 3 6 1 1,4 or 9&10
Fabric Port Name (FWWN) 8 7 1 1,4 or 9&10
Node Type 2 8 1 1,4 or 9&10
IP Address 16 9 4 1,4 or 19
Port ID 3 10 4 4
Port Symbolic Name 0-255 11 4 4 or 9&10
Port Type 2 12 4 4 or 9&10
FC Class of Service 4 13 4 4 or 9&10
FC Port IP Address 16 14 4 4 or 9&10
FC-4 Types 32 15 4 4 or 9&10
Port Reg Timestamp 8 16 4 4 or 9&10
Transport Protocol 2 17 4 4 or 9&10
DNS Name 0-255 18 1 or 9 1,4 or 9&10
Path 0-255 19 1 or 9 1,4 or 9&10
Client Certificate variable 20 1 1,4, 9&10 or 18&19
Port Number 2 21 4 4 or 9&10
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.
ID - the value used to identify the attribute.
Gibbons, Tseng, Monia 16
iSNS October 2000
Registration Key - indicates the attribute ID that is the unique
key used for attribute registration. This attribute is also known
as the primary key for the iSNS directory database entry.
Query Key - indicates the attribute ID(s) that is (are) the unique
key used to query the iSNS directory database.
iSNS client attributes are defined below:
5.4.1 Node Name (WWNN)
Node Name is a 64-bit identifier that uniquely identifies the
device node in the network. This required field is provided by the
iSNS client entity. The format of the Node Name (WWNN) is as
defined in section 3.2.4.
5.4.2 Node Symbolic Name
This is a variable-length text-based description of up to 255
bytes, that is associated with the device node 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, a
network management application can update this field as required.
The Node Symbolic Name provides a user-readable description of the
device entry in the iSNS. The use of the Node Symbolic Name is
consistent with Fibre Channel.
5.4.3 Management IP Address
This optional field is provided by the iSNS client. It contains
the IP Address used to manage the node. 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.
5.4.4 Port Name (WWPN)
This 64-bit identifier uniquely defines the device port. This
required field is provided by the iSNS client entity. The format
of the Port Name (WWPN) is defined in section 3.2.4.
5.4.5 FC Node Initial Process Associator
This optional field is included for compatibility with Fibre
Channel, and is provided by the iSNS client entity. The initial
process associator can be used for communication between Fibre
Channel devices.
5.4.6 FC Hard Address
Gibbons, Tseng, Monia 17
iSNS October 2000
This optional is the 24-bit NL Port Identifier, included in the
iSNSP for compatibility with Fibre Channel Arbitrated Loop devices
and topologies.
5.4.7 Fabric Port Name (FWWN)
This 64-bit identifier uniquely defines the fabric port. If the
iSNS client is attached to a 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.
5.4.8 Node Type
This 16-bit field is a bitmap indicating the type of 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
2 Proxy
3 Switch
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".
5.4.9 IP Address
This is the IP address associated with a device port in the
network. 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.
5.4.10 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 only used for
native Fibre Channel storage devices, and is unused for native IP-
based storage devices.
5.4.11 Port Symbolic Name
A variable-length text-based description of up to 256 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
Gibbons, Tseng, Monia 18
iSNS October 2000
provided by the iSNS client during registration. However, network
management application can update this field as required. The use
of the Symbolic Name provides the user with a readable description
of the port entry in the iSNS directory database.
5.4.12 Port Type
Indicates the type of device port. This is provided by the iSNS
client entity. Encoded values for this field are listed in the
following table:
Type Description
---- -----------
0x0000 Unidentified/Null Entry
0x0001 Fibre Channel N_Port
0x0002 Fibre Channel NL_Port
0x0003 Fibre Channel F/NL_Port
0x0004-0080 RESERVED
0x0081 Fibre Channel F_Port
0x0082 Fibre Channel FL_Port
0x0083 RESERVED
0x0084 Fibre Channel E_Port
0x0085-00FF RESERVED
0xFF10 iSCSI Port
0xFF11 RESERVED (for mFCP Port*)
0xFF12 RESERVED (for iFCP Port*)
0xFF13-FFFF RESERVED
* To be defined later.
5.4.13 Class of Service (COS)
This is a 32-bit bit-map field that indicates the COS types that
are supported by the registered port. This required field is
provided by the 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
5.4.14 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.
Gibbons, Tseng, Monia 19
iSNS October 2000
5.4.15 FC-4 Types
An 8-word bit-map of the FC-4 protocol types supported by the
associated port. This required field is provided by the iSNS
client. This field can be used to support Fibre Channel devices.
5.4.16 Port Registration Timestamp
Indicates the time that the most recent device port registration
updates occurred. It is the time, in milliseconds, after the
standard base time of 00:00:00 GMT on january 1, 1970, that the
last update occurred. The timestamp is used to ensure the SNS
directory does not contain entries for non-existent port devices.
5.4.17 Transport Protocol
Contains a bit map that indicates the type of transport protocol
that the iSNS client supports for transport of storage traffic.
This bit map is indicated below:
Bit Field Transport Protocol Supported
--------- ----------------------------
0 UDP
1 TCP
2 SCTP
Others RESERVED
5.4.18 DNS Name
Identifies a node in the IP storage network. The DNS Name, along
with the Path, uniquely identify a Node Name (WWNN). It uses
existing naming conventions defined in RFC1035. Each DNS Name maps
to one IP-addressable node. A node having an IP Address may have
more than one storage device. For example, a host at a single IP
address may have several device controllers that can be
independently addressed by initiators. The Path attribute
distinguishes among multiple devices which may reside in an IP-
addressable node.
5.4.19 Path
Along with the DNS Name, the Path uniquely identifies a native IP-
based storage device. The Path distinguishes among multiple IP-
based storage entities which may reside at the same IP address.
Note that the Path is used only with native IP-based storage
devices, and native Fibre Channel devices do not need a Path. The
Path field is similar to that of the UNIX file format.
5.4.20 Client Certificate
Gibbons, Tseng, Monia 20
iSNS October 2000
This optional attribute MAY contain a X.509 certificate with the
public key of the iSNS client. This certificate is used by the
iSNS client to authenticate itself for storage transfers with other
storage entities. Initiators wishing to communicate with a target
storage device MAY retrieve the target's X.509 certificate from the
name server in order to encrypt a secret session key using the
target's public key contained in the certificate.
5.4.21 Port Number
Contains the TCP or UDP port number being used for communication
with the iSNS server by the iSNS client.
5.4 Zone Registration Attributes
iSNS clients can be placed into zoned areas of control. When an
iSNS client or Network Management System registers a zone, it
provides attribute values to describe the zone characteristics and
capabilities. The following table lists the iSNSP zone attributes:
Attribute Name Size(bytes) ID Reg Key Query Key
-------------- ----------- -- ------- ---------
Zone ID 2 101 101
Zone Tag 2 102 101 101
Zone Symbolic Name 1-64 103 101 101
Zone Member (WWN) 8 104 101 101
Zone Member (IP Addr) 16 105 101 101
Zone Member Priority 1 106 101,105,106 101,104,105
Zone ID - a unique identifier used in the iSNS directory database
to indicate the zone. This value is used as the key for any zone
attribute query.
Zone Tag - the tag used to identify the the zone in the network.
Zone Symbolic Name - an ASCII, variable-length string that is
NULL-terminated. This is an optional user-readable field that can
be used to assist a network administrator in tracking the zone
function.
Zone Member (WWPN) - the Port Name of an iSNS client that is a
member of the zone. The zone may have a list of 0 to n members.
Membership is represented by the Port Name of the iSNS client being
listed.
Zone Member (IP Addr) - the IP address of an iSNS client that is a
member of the zone. The zone 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 zone.
Gibbons, Tseng, Monia 21
iSNS October 2000
Zone Member Priority - the 802.1P/Q priority being used for this
zone member in the network. This value can range from 0 to 7, and
is based on valid 802.1P/Q priority tag values.
5.5 State Change Notification and Port Status Inquiry Flags
A State Change Notification (SCN) allows an iSNS client to be
notified of changes within a zone, 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 an SCN is sent is based on the flags
set in the EVENT TYPE FLAGS field. The EVENT TYPE FLAGS field is a
16-bit mask containing flags for different event types.
Port Status Inquiry (PSI) allows an iSNS server to verify that an
iSNS client port is still connected to the network. The PSI
message is sent to the iSNS client by the server to verify port
status. If enabled, the iSNS server will send a PSI to request a
Port Status Inquiry Update message from the SCE.
The following table displays the flags in the EVENT TYPE FLAGS
field used in SCNReg, SCN and PSI messages:
Bit Field Flag Description
--------- ----------------
0 CHANGE IN ZONE MEMBERSHIP
1 CHANGE IN NETWORK
2 CHANGE IN DEVICE REGISTRATION PARAMETERS
3 DEVICE ADDED
4 DEVICE REMOVED
5 PORT STATUS UPDATE REQUESTED (for PSI message)
CHANGE IN ZONE MEMBERSHIP - indicates a change has occurred in a
zone that the iSNS client is a member of. A client can be a member
of multiple zones. This flag indicates that a change in
registration parameters or membership has occured, either an
addition or deletion, to a zone 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 zones that the client is a
member of. This flag is used in conjunction with CHANGE IN ZONE
MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the change
Gibbons, Tseng, Monia 22
iSNS October 2000
in device registration occurred in a zone or the network. This
flag may be administratively enabled/disabled.
DEVICE ADDED - indicates a device addition has occurred in the
network or zone. This flag is used in conjunction with CHANGE IN
ZONE MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the
addition occurred in a zone or the network.
DEVICE REMOVED - indicates a device removal has occurred in the
network or zone. This flag is used in conjunction with CHANGE IN
ZONE MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the
removal occurred in a zone or the network.
6. iSNSP Message Descriptions
The message payload follows the iSNSP header described in section
5.1. The request message payload contains a list of attributes,
each in TLV format described in section 5.2.
The iSNSP request message payload contains a list of attributes,
and has the following format:
+----------------------------------------+
| Source Attribute |
+----------------------------------------+
| Key Attribute[1] |
+----------------------------------------+
| Key Attribute[2] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| Op Attribute[1] |
+----------------------------------------+
| Op Attribute[2] (if present) |
+----------------------------------------+
| Op Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
The source attribute is used to identify the iSNS client to the
iSNS server. The key attribute is used to identify the entry (or
entries) in the iSNS server for the request operation. Following
the key attribute is a list of one or more operating attributes
directly related to the actual iSNS request message. The number of
each attribute (key & operating) depends on the specific iSNSP
request or operation being performed. Some iSNSP messages may not
specify any attributes.
Gibbons, Tseng, Monia 23
iSNS October 2000
The response message contains a 4-byte ERROR CODE field, and
depending on the specific iSNSP request, may be followed by a list
of attributes.
The following table lists each iSNSP message, allowable source
attribute ID's, key attribute ID's, and operating attribute ID's.
Message Source/Dest Attr Key Attribute Operating Attr
------- ---------------- ------------- --------------
RegDevAttr 1,4,9 1,4,9,18&19 multiple[1-21]
RegDevRsp -- -- --
DevAttrQry 4,9 1,4,9,18&19 multiple[1-21]
DevAttrQryRsp -- -- multiple[1-21]
DevGetNext 4,9 1,4,9,18&19 --
DevGetNextRsp -- -- 1,4,9,18&19
DeregDev 4,9 1,4,9,18&19 --
DeregDevRsp -- -- --
SCNReg 4,9 1,4,9,18&19 --
SCNRegRsp -- -- --
SCN 4,9 (dest) -- --
RegZone 4,9 (dest) 101 multiple[101-106]
RegZoneRsp -- -- --
DeregZone 4,9 101 --
DeregZoneRsp -- -- --
RegDevZone 4,9 101 4,9
RegDevZoneRsp -- -- --
DeregDevZone 4,9 101 4,9
DeregDevZoneRsp -- -- --
PSI 4,9 (dest) -- --
PSIUpdate 4,9 -- --
Heartbeat -- -- --
The above table lists attribute ID's from section 5.4 that can be
used for each role (source, key, and operating attribute) in the
iSNSP message. The source attribute is that of the iSNS client,
used in the registration or query message. The key attribute is
the attribute used to look up the operating attribute in the iSNS
directory database. The operating attribute(s) is the attribute(s)
in the iSNS directory database which is to be added, modified,
deleted, or queried.
If more than one operating attribute can be used, "multiple" is
noted in the entry. A "--" entry indicates that the iSNSP message
does not use the attribute role (source/dest, key, or operating
attribute). Note that the SCN and PSI messages specify the
destination attribute in place of the source attribute.
6.1 Register Device Attribute Request (RegDevAttr)
The Register Device Attribute Request (RegDevAttr) message provides
an iSNS client with the means to register device attributes. The
Gibbons, Tseng, Monia 24
iSNS October 2000
iSNS client formulates a register attribute request by specifying a
source, query key(s), and list of attributes to register. All
values are in Tag Length Value format.
The source attribute of the request is the IP address or the 8-byte
Port Name (WWPN) of the iSNS client performing the query. The key
attribute(s) is based on the type of attributes being registered,
and is the IP Address, DNS Name & Path, Node Name (WWNN), or Port
Name (WWPN) of the client being registered. If the key attribute
matches an existing entry in the iSNS directory database, then the
attribute values corresponding to the key entry will be replaced
with new values sent in the message. Multiple attributes
associated with the one database key attribute can be registered.
The source attribute does not need to have been previously
registered for the registration to succeed. The use of a Port Name
(WWPN) as source does not automatically register it in the
database--it is registered by including the attribute as part of a
registration using a Node Name (WWNN) as a key. However, a Node
Name (WWNN) is registered the first time it is used as a key, so it
does not necessarily have to be listed among the attributes to be
registered.
The RegDevAttr request message payload includes the source
attribute (IP Address, Node Name, or Port Name), the key attribute
(IP Address, DNS Name & Path, Node Name or Port Name), and one or
more operating attributes.
6.2 Register Device Attribute Response (DevAttrRsp)
If device attributes are successfully addded to the iSNS directory
database as a result of DevAttrReg, then an acknowledgement with an
error code of NO ERROR (0) is returned to the iSNS client. If the
registration request is unsuccessful, the appropriate error code
will be returned.
6.3 Device Attribute Query Request (DevAttrQry)
Once iSNS client attributes have been registered in the name
service, queries can be made to obtain attributes related to a
specific key. The Device Attribute Query Request (DevAttrQry)
messages provide an iSNS client with the means to query the iSNS
server for device attributes.
The key attribute for the DevAttrQry is Node Name (WWNN), Port Name
(WWPN), or a key set consisting of DNS Name and Path. The
attribute list contains desired attributes. The length field for
each requested attribute shall be of length 0.
Gibbons, Tseng, Monia 25
iSNS October 2000
The iSNS server uses the key in the request message to query its
database, and then returns the corresponding entry or entries for
each requested attribute back to the client.
The DevAttrQry request message payload includes the source
attribute (IP Address or Port Name), the key attribute(s), and one
or more operating attributes.
6.4 Device Attribute Query Response (DevAttrQryRsp)
The iSNS server uses the DevAttrQryRsp message to send back the
attribute query results back to the iSNS client. A successful
query will result in attribute values and length fields in the
original TLV-formatted DevAttrQry request to be appropriately
filled in. A failed query as a result of an inappropriate source
and/or key attribute(s) will result in the message payload being
replaced with the 4-byte ERROR CODE field. If there is no entry
for queried attributes, the TLV-formatted attribute block will be
returned with the length field set to 0 or a negative value error
code.
In addition to the ERROR CODE field, the DevAttrQryRsp message
contains a list of operating attributes corresponding to the
original request message. The attribute values resulting from the
query are represented in the TLV format described in section 5.2.
6.5 Device Get Next Request (DevGetNext)
This message provides the iSNS client with the means to
sequentially retrieve IP Addresses, DNS Name & Paths, Node Names
and Port Names from devices in zones to which the client has
access. The source of the query is represented by the IP Address
or 8-byte Port Name (WWPN) of the client performing the query. The
key tag is the IP Address, DNS Name & Path, Node Name (WWNN), or
Port Name (WWPN). If the key length value entered is zero,
signifying an empty key value field, the first accessible IP
Address, DNS Name, Node Name, or Port Name instance shall be
returned to the client.
The DevGetNext request message payload contains a source attribute
(IP Address or Port Name) and a key attribute (IP Address, DNS Name
& Path, Node Name or Port Name).
6.6 Device Get Next Response (DevGetNextRsp)
The iSNS server uses the DevGetNextRsp to return the results of the
DevGetNext request message. If the DevGetNext query does not
identify an IP Address, DNS Name & Path, Node Name, or Port Name
following the key provided in the query, and the query completed
properly, the attribute value length field is set to zero.
Gibbons, Tseng, Monia 26
iSNS October 2000
The DevGetNextRsp response message payload returns the queried
attribute resulting from the original DevGetNext request (IP
Address, DNS Name & Path, Node Name, or Port Name).
6.7 Deregister Device Request (DeregDev)
An iSNS client port or device is removed from the iSNS directory
database by using the Deregister Device Request (DeregDev). Upon
receiving the DeregDev, the iSNS server removes all attributes
associated with the IP Address, DNS Name & Path, Node Name (WWNN)
or Port Name (WWPN) key, and sends state change notifications
(SCNs) to registered iSNS clients that are in the same Zone as the
removed device or port. After removing the port or device, the
iSNS server sends back an acknowledgement to the iSNS client.
The DeregDev request message payload contains a single source
attribute (IP Address or Port Name) and key attributes (IP Address,
DNS Name & Path, Node Name or Port Name).
6.8 Deregister Device Response (DeregDevRsp)
If device attributes are successfully removed from the iSNS
directory database as a result of a Deregister Device Request
(DeregDev), the DeregDevRsp message with error code of NO ERROR(0)
is returned to the original iSNS client. The DeregDevRsp response
message payload does not contain any attributes.
6.9 SCN Registration Request (SCNReg)
The State Change Notification Registration Request (SCNReg) message
allows an iSNS client to register an IP Address or Port Name (WWPN)
for State Change Notification (SCN) messages. SCN messages allow
an iSNS client to be notified of changes within the zone or network
(if adminstratively allowed) that the device port is a member of.
In place of the attribute list for other iSNSP message types, the
SCNReg has the 16-bit INTERESTED EVENT TYPE FLAGS field described
in section 5.5, which comes immediately after the key attribute.
The following displays the format of the SCNReg message payload:
Byte MSb LSb
Offset 7 6 5 4 3 2 1 0
+----------------------------------+
0 | source attribute | 12 Bytes
+----------------------------------+
12 | key attribute | 12 Bytes
+----------------------------------+
24 | EVENT TYPE FLAGS | 2 Bytes
+----------------------------------+
Total Length = 26
Gibbons, Tseng, Monia 27
iSNS October 2000
Section 5.5 describes each flag used in the EVENT TYPE FLAGS field.
6.10 SCN Registration Response (SCNRegRsp)
If the iSNS client successfully registered for state change
notifications, an acknowledgement with the ERROR CODE field set to
NO ERROR(0) is returned to the client. This message does not
contain any attributes.
6.11 State Change Notification (SCN)
The State Change Notification is a special message which allows a
registered iSNS client to be notified of changes within a zone,
network (if administratively allowed), or other device registration
parameters in the iSNS directory database. The notification is
indicated in the EVENT TYPE FLAGS field described in section 5.5.
A time stamp is included in this message following the EVENT TYPE
FLAGS field. This time stamp is a 4-byte unsigned, fixed-point
integer giving the number of seconds since midnight, January 1,
1970. The format of the message payload of the SCN message is as
follows:
Byte MSb LSb
Offset 7 6 5 4 3 2 1 0
+----------------------------------+
0 | destination attribute | 12 Bytes
+----------------------------------+
12 | EVENT TYPE FLAGS | 2 Bytes
+----------------------------------+
14 | TIME STAMP | 4 Bytes
+----------------------------------+
Total Length = 18
Destination attribute contains the IP Address or Port_Name in TLV
format of the iSNS client to receive the SCN message. There is no
response message to the SCN message by the iSNS client.
6.12 Register Zone (RegZone)
This message allows an iSNS client to create a new Zone to be
stored in the iSNS directory database. Once created, Port Names
can be added and deleted from the Zone.
Zones are defined using Zone IDs, Zone tags, and Symbolic Names.
Zone registration attributes are described in section 5.4.
The RegZone message payload contains the source attribute (IP
Address or Port Name), key attribute (Zone ID), and one or more
Zone attributes (Zone Tag, Zone Symbolic Name, Zone Member [IP
Address or WWPN], and Zone Member Priority).
Gibbons, Tseng, Monia 28
iSNS October 2000
6.13 Register Zone Response (RegZoneRsp)
The Register Zone Response (RegZoneRsp) message is used by the iSNS
server to acknowledge a RegZone message. If a Zone is successfully
created with the requested attributes, the RegZoneRsp is returned
to the client with an ERROR CODE of NO ERROR(0). The message
payload contains no attributes.
6.14 Deregister Zone (DeregZone)
This message allows an iSNS client to delete an existing Zone from
the iSNS directory database. A zone with non-zero membership
cannot be deleted. The DeregZone message payload contains the
source attribute (IP Address or Port Name) and key attribute (Zone
ID).
6.15 Deregister Zone Response (DeregZoneRsp)
This message is used by the iSNS server to acknowledge a DeregZone
request. If the zone was successfully deregistered, an
acknowledgement is sent with an ERROR CODE of NO ERROR(0). The
DeregZoneRsp message payload does not contain any attributes.
6.16 Register Device in Zone (RegDevZone)
Devices can be added to a zone by registering the port names of the
devices. Adding an IP Address or Port Name (WWPN) to the zone
provides access to all other device ports in the zone.
The RegDevZone message payload contains the source attribute (IP
Address or Port Name), key attribute (Zone ID), and one or more
Zone attributes (Zone Tag, Zone Symbolic Name, Zone Member [IP
Address or Port_Name], and Zone Member Priority).
6.17 Register Device in Zone Response (RegDevZoneRsp)
This message provides confirmation that the RegDevZone message was
received and processed by the iSNS server. If the device was
successfully registered in the zone, an acknowledgement is sent
with an ERROR CODE of NO ERROR(0). The RegDevZoneRsp message
payload does not contain any attributes.
6.18 Deregister Device in Zone (DeregDevZone)
Devices can be removed from a Zone by deleting their IP Address or
Port Names (WWPN) from the Zone. Deleting devices from a zone
removes access to that device from all other devices in that Zone.
The DeregDevZone request message payload contains the source
attribute (IP Address or Port Name), key attribute (Zone ID), and
Gibbons, Tseng, Monia 29
iSNS October 2000
the operating attribute (IP Address or Port Name) of the device
being deregistered.
6.19 Deregister Device in Zone Response (DeregDevZoneRsp)
This message provides confirmation that the DeregDevZone message
was received and processed by the iSNS server. If the device was
successfully deregistered from the zone, an acknowledgement is sent
with an ERROR CODE of NO ERROR(0). The DeregDevZoneRsp message
payload does not contain any attributes.
6.20 Port Status Inquiry (PSI)
The Port Status Inquiry (PSI) message provides the iSNS server with
the ability to verify that a registered iSNS client is still
accessible. The format of the PSI is similar to the SCN message,
and uses the same EVENT TYPE FLAGS field. The types of events and
flags are listed in section 5.5.
The PSI request message payload contains the attribute (IP Address
or Port Name) of the device being inquired for status.
6.21 Port Status Inquiry Update (PSIUpdate)
This message provides confirmation that the PSI message was
received and processed by the iSNS client. If the client is still
accessible by the iSNS server, then it will respond and confirm
accessibility through the PSIUpdate message.
The PSIUpdate response message payload contains the source
attribute (IP Address or Port Name) of the responding device.
6.22 Name Service Heartbeat (Heartbeat)
The iSNS server sends out a multicast heartbeat message. The
heartbeat can be used by iSNS clients to verify connectivity, as
well as to discover the iSNS server. The period of the heartbeat
is included in the message, with default period of 15 seconds.
There is no response to the Heartbeat message.
7. Security Considerations
7.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.
7.2 Security Model
Gibbons, Tseng, Monia 30
iSNS October 2000
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 with stateful inspection
technology can examine incoming traffic from the Public Internet,
and protect against active attacks.
8. References
[RFC1035] Domain Implentation and Specification
[STD0035] Domain Name System
[RFC2065] Domain Name System Security Extensions
[FC-GS-2] Fibre Channel Generic Services-2, ANSI NCITS 288
[FC-GS-3] Fibre Channel Generic Services-3, NCITS Working
Draft Rev 6.42, June 7, 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
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
9. 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
Gibbons, Tseng, Monia 31
iSNS October 2000
Full Copyright Statement
"Copyright (C) The Internet Society, September 18, 2000. 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 implmentation 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
Gibbons, Tseng, Monia 32
iSNS October 2000
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/