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