iSCSI Naming and Discovery Requirements Document

["Kaladhar Voruganti/Almaden/IBM" <kaladhar@us.ibm.com>]

Attached is the iSCSI Naming and Discovery requirements Internet Draft
document.
This document was produced by the iSCSI naming and discovery team.

Kaladhar Voruganti
IBM Almaden Research
San Jose,  CA

(See attached file: draft-Voruganti-ips-iscsi-disc-reqts-00.txt)

iSCSI
                                                            Mark Bakke
                                                                 Cisco

                                                              Joe Czap
                                                                   IBM

                                                            Jim Hafner
                                                                   IBM

                                                           Howard Hall
                                                                 Pirus

                                                          Jack Harwood
                                                                   EMC

                                                          John Hufferd
                                                                   IBM

                                                           Yaron Klein
                                                                Sanrad

                                                       Lawrence Lamers
                                                    San Valley Systems

                                                          Joshua Tseng
                                                                Nishan

                                                    Kaladhar Voruganti
                                                                   IBM
iSCSI
INTERNET DRAFT

Expires May 2001
draft-Voruganti-ips-iscsi-disc-reqts-00.txt
                                                       <November 2000> 




                         iSCSI Naming and Discovery Requirements


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 
kaladhar@us.ibm.com



1. Abstract

This document describes the  iSCSI [7] naming and discovery requirements. 
The requirements presented in this document have been agreed to by the 
members of the iSCSI naming and discovery team. The focus of this document 
is on iSCSI naming and discovery requirements and not on the details of 
the naming and discovery mechanisms. This document complements the iSCSI 
IETF draft. Flexibility is the key guiding principle behind this 
requirements document. That is, an effort has been made to satisfy the 
needs of both small isolated environments, as well as large environments 
requiring secure/scalable solutions.


2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [2].


3. Naming and Discovery Requirements
The following items represent iSCSI naming and discovery requirements:

1) There is a requirement to have the ability to generate world wide 
unique identifiers (WWUIs) for both iSCSI initiators and targets. However, 
it is not mandatory for the initiators and targets to use WWUIs because a 
globally unique identifier might not be required in some simple, isolated 
iSCSI configurations. WWUIs are useful because in some cases (e.g. when 
DHCP services [6] are used etc), the combination of IP address and port 
number [6] cannot uniquely identify an initiator or a target. The format 
of the the WWUIs and their generation process is yet to be resolved.

2) An iSCSI initiator needs to be able to identify a target's iSCSI 
service delivery port. The iSCSI service delivery port address is made up 
of IP address and  port number. The default port number is the canonical 
iSCSI port. A single  iSCSI service delivery port could be serving one or 
many targets. If the iSCSI service delivery port is serving a single iSCSI 
target, then the service delivery port address is enough to access the 
iSCSI target. If the iSCSI target device service delivery port serves 
multiple targets then the initiator has the following different options 
with respect to how it accesses a particular target:

a) The initiator passes the target WWUI as part of the iSCSI Login 
message. The WWUI is resolved to access a specific target.
b) The initiator passes the DNS domain name [1] and a path string in the 
iSCSI Login message. A path string is a text string that contains
additional information about the target (e.g., a URL [3]). The exact 
format of this string is to be determined. The path string may be used for 
additional address resolution of the target, for example, by a transparent 
proxy. 

These options provide iSCSI with the necessary flexibility to operate with 
different types of intermediaries (proxies, gateways,
firewalls [4]).

If the target WWUI supplied in Login does not match or cannot be resolved 
by the target, then the Login should be rejected by the target.

3) It is not mandatory for the initiator to fill the initiator WWUI field 
in the Login message. The initiator WWUI field can be used for 
authentication purposes.

Thus, the iSCSI Login message optionally contains any of the following:
initiator WWUI, target WWUI, DNS domain name, and target path string 
fields.

4) The initiator can send the initial iSCSI Login
message to:

a) A canonical, well known iSCSI service delivery port.
b) A non-canonical, iSCSI service delivery port with the same 
functionality as in the canonical iSCSI port (no additional restrictions).

5) The initiator may Login to an iSCSI device and request from that device 
a list of targets and/or alternate IP addresses:Ports that may be 
available in the same device. The returned data SHALL contain a list of 
tuples, where each tuple consists of a target WWUI, an IP address:Port and 
optionally a Path string. 

6) The initiator can get the target address information in the following 
different ways:

a) Information is hard-coded at the initiator.
b) Initiator queries name servers.
c) Initiator queries a known service delivery port for a list of targets.

The initiator can access the target using the following:
 i) IP name or IP address
        +
 ii) TCP port number
        +
 iii) [Target WWUI  or (Target WWUI and path)]

Point ii) is implied if a canonical port number is used.
Point iii) is not mandatory.

Now, the initiator can either hard-code the above information, or it can 
obtain it from either DNS or storage director servers (like iSNS server 
[8]). The storage director is a server which stores discovery data. The 
storage director can also potentially store access control, zoning and 
other storage management information but this group's current focus is on 
storing discovery information.

If the initiators are not hard-coding the address information then they 
have to explicitly query the DNS/storage director servers. That is, this 
information is not presented to the initiators via upcalls from the DNS or 
storage director servers.

7) The information about the targets can be registered at the storage 
director in the following different ways:
a) The targets can register this information at the storage director 
automatically via upcalls.
b) The target information is registered manually at the storage director.
c) The target information is registered manually in DNS servers.

8) The interaction between the initiators and the storage director/DNS 
servers, and between the targets and the storage director/DNS servers can 
be either secure or insecure. The details of the secure interaction still 
need to be worked out.


4. Outstanding Work Items

The naming and discovery team will be working on the following outstanding 
work items:

1) Initiator WWUIs and target WWUIs design. Goal is to try and build upon 
existing naming mechanisms [1,5].
2) The "path" format design.
3) Impact of naming and discovery on iSCSI Login command.
4) Details of initiator APIs to interact with the storage director.
5) Details of the target APIs for interacting with the storage director.
6) Core schema design for the storage director.
7) Secure interaction between the storage director and the initiators and 
the targets.



5. References
[1] Mockapetris, P., "Domain Names -- Implentation and Specification", RFC 
1035, November 1987 

[2] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, 
March 1994.

[3] Berners-Lee, T., Masinter, L., and McCahill, M., Uniform Resource 
Locators (URL), RFC 1738, December 1994.

[4] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 
2979, October 2000.

[5] ANSI/IEEE Std 802-1990, Name: IEEE Standards for Local and 
Metropolitan Area Networks: Overview and Architecture

[6] Kessler, G. and Shepard, S., "A Primer On Internet and TCP/IP Tools 
and Utilities", RFC 2151, June 1997. 

[7] Satran, J., Sapuntzakis, C., Wakeley, M., Von Stamwitz, P., Haagens, 
R., Zeidner, E., Dalle Ore, L., Klein, Y., "iSCSI", 
draft-ietf-ips-iscsi-00.txt, November, 2000. 

[8] Gibbons, K., Tseng, J. and Monia, C., "iSNS Internet Storage Name 
Service", draft-tseng-ips-isns-00.txt, October 2000.

6. Contact Author
Kaladhar Voruganti
650 Harry Road
IBM Almaden Research
San Jose, CA
USA
Email: kaladhar@us.ibm.com





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 
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 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"


Expires May 2001