[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

iSCSI                                                        Mark Bakke
Internet Draft                                                    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



draft-voruganti-ips-iscsi-disc-reqts-00.txt              November, 2000
Expires May 2001

             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 except that the right to
   produce derivative works is not granted.

   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


Voruganti          Internet Draft Expires May 2001       1

                   iSCSI Naming and Discovery        November 2000


   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.


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



 Voruganti          Internet Draft Expires May 2001       2

                      iSCSI Naming and Discovery        November 2000


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:


  Voruganti          Internet Draft Expires May 2001       3

                      iSCSI Naming and Discovery        November 2000


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:



Voruganti            Internet Draft Expires May 2001       4

                      iSCSI Naming and Discovery        November 2000

 Internet Draft:  iSCSI Naming and Discovery        November 2000
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

Voruganti            Internet Draft Expires May 2001       5

                      iSCSI Naming and Discovery        November 2000






"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, Full Copyright Statement
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

Voruganti  iSCSI Naming and Discovery Draft Expires May 2001


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/