SNS Requirements

[Joshua Tseng <jtseng@NishanSystems.com>]

Folks,

To complete my action item from the Nashua Meeting,
the following is the updated requirements text for SNS for
the NDT document.  Please send comments on these
requirements to the reflector.

Thanks,
Josh Tseng

-----------------------------------

5.  Storage Name Server (SNS) 
          
The following section describes a set of generic requirements for any
protocol or application used in the name service role to support iSCSI.
This application or protocol is hereafter generically refered to as the SNS.
An example of a Storage Name Server is the iSNS protocol described in the
draft document draft-ietf-ips-iSNS-02.txt [8]. 

5.1  Overview 

The SNS shall be architected using a client-server paradigm, with the SNS
server acting as the information repository. SNS clients actively register
and manipulate entity objects and their attributes in the SNS server.  The
SNS server SHALL be able to send asynchronous state change notifications to
registered clients, and SHALL be able to send polling messages to monitor
the availability of clients.  Examples of SNS clients include initiators,
targets, management stations, and switches.  The SNS server can be hosted on
a target, switch, or stand-alone server. 

5.2  Login Control and Discovery Domains (DD's)

The SNS MUST support Discovery Domains and Login control.  The SNS must
provide SNS clients with the ability to enforce DD configurations which may
exist on the SNS server.  Targets and management stations shall be able to
register (i.e., 
upload) Login Control and Zoning configurations to the iSNS if authorized by
the end user. DD and Login control supports two separate purposes: 

5.2.1  Discovery Domain (DD) Partitions

The SNS SHALL support the ability to partition the storage network into
separate "Discovery Domains".  The SNS shall not provide information if the
SNS client performing the query is not in a common Discovery Domain as the
SNS client that is the subject of the request.  This capability prevents an
initiator from attempting an iSCSI login to every single target in a large
enterprise network, and is the iSCSI equivalent of "Soft" zoning. 

5.2.2  Login Control

To support login access security which is specified in the current iSCSI
draft (Appendix A) [7] and MAY be implemented by the iSCSI target.  The SNS
SHALL support login control by storing a mapping of initiators that are
permitted to access each target.  Targets shall be able to query the SNS for
a list of initiators that are allowed login access.  This list shall include
the key attribute (e.g., iSCSI Name) used to identify the initiator.  This
capability is the iSCSI equivalent of "Hard zoning". 

5.3    Object Model 

The SNS MUST store the following objects and attributes: 
          
             Network Entity: 
               -  Entity Identifier 
               -  Management IP Address 
               -  Entity Type (iSCSI) 
          
             Portal: 
               -  Portal Index 
               -  IP Address 
               -  TCP Port Number 
          
             Storage Node: 
               -  iSCSI Name 
               -  Alias 
               -  Node Type (target or initiator or both) 
          
             Discovery Domain: 
               -  DD symbolic name 
               -  DD ID 
               -  DD Member:  iSCSI Name 
              
A diagram of how the above objects are related is shown below. 
          
+----------------------------------------------------------------+ 
|                         IP Network                             | 
+------------+--------------------------------------+------------+ 
             |                                      | 
             |                                      | 
+-----+------+------+-----+            +-----+------+------+-----+ 
|     | PORTAL      |     |            |     | PORTAL      |     | 
|     | -IP Addr 1  |     |            |     | -IP Addr 2  |     | 
|     | -TCP Port 1 |     |            |     | -TCP Port 2 |     | 
|     +-----+ +-----+     |            |     +-----+ +-----+     | 
|           | |           |            |           | |           | 
|           | |           |            |           | |           | 
|  +--------+ +--------+  |            |   +-------+ +--------+  | 
|  |                   |  |            |   |                  |  | 
|  |  STORAGE NODE     |  |            |   |  STORAGE NODE    |  | 
|  |  -iSCSI Name      |  |            |   |   -iSCSI Name    |  | 
|  |  -Alias: "server1"|  |            |   |   -Alias: "disk1"|  | 
|  |  -Type: initiator |  |            |   |   -Type: target  |  | 
|  |                   |  |            |   |                  |  | 
|  +-------------------+  |            |   +------------------+  | 
|                         |            |                         | 
|    NETWORK ENTITY       |            |    NETWORK ENTITY       | 
|   -Entity ID (DNS):     |            |   -Entity ID (DNS):     | 
|    "strg1.foo.com"      |            |    "strg2.bar.com"      | 
|   -Type: iSCSI          |            |   -Type: iSCSI          | 
|                         |            |                         | 
+-------------------------+            +-------------------------+


5.4  SNS Authentication Requirements

The SNS SHALL include authentication of SNS protocol messages between SNS
clients and the SNS server. The authentication mechanism will allow for
authentication of both client and server. 

5.5 SNS Query and Registration Services Requirements 

The SNS SHALL allow SNS clients (initiators and targets) to register
themselves with the SNS server. Initiators and targets also SHALL be able to
query the SNS server for information.

During registration, the initiators and the targets MUST be able to provide
the following information: 
a) Storage Entity ID 
b) Portal object address (IP address and Port Number) 
c) iSCSI Name 
d) Storage node type 

They could optionally also provide other information such as: 
a) Alias string information 

When querying address information in order to establish an iSCSI connection,
the query, as a minimum, should return the following information: 
a) PORTAL IP address(es) 

In the absence of SNS, the iSCSI Name and IP address(es) of the target
device can be queried by issuing the SendTargets command to the default
canonical iSCSI target present at the IP address and port number.

5.6  State Change Notification Requirements

The SNS server MUST be able to inform SNS clients of changes to its
database, including the availability of new SNS clients as a result of
changes or modifications to DD policies.  These changes may occur as a
result of various events, including an SNS client actively manipulating the
SNS database, response or non-response to an SNS monitoring message, or a
hardware interrupt delivered by the SNS host platform (such as a switch).
Asynchronous notification shall be delivered only to SNS clients that
register for the notification, and only for SNS clients that are in the same
DD as the event.

5.7  Monitoring Messages

The SNS server MUST be able to poll client devices to monitor their
availability on an ongoing basis.  If a client fails to respond to
monitoring messages, the SNS server shall take appropriate action, including
sending state change notifications to other clients to inform them of the
change in status.

5.8  Lightweight Protocol

The SNS protocol SHALL be a lightweight protocol that can be scaled down for
embedded implementation on switches and targets, or scaled up for
implementation on servers. 

5.9  The SNS SHALL meet the iSCSI boot requirements (see
draft-ietf-ips-iscsi-boot-00.txt).