rfc4173.txt

一个学习iSCSI协议的文档

Network Working Group                                          P. Sarkar
Request for Comments: 4173                                           IBM
Category: Standards Track                                    D. Missimer
                                                 Hewlett-Packard Company
                                                          C. Sapuntzakis
                                                     Stanford University
                                                          September 2005


                      Bootstrapping Clients using
     the Internet Small Computer System Interface (iSCSI) Protocol

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Internet Small Computer System Interface (iSCSI) is a proposed
   transport protocol for Small Computer Systems Interface (SCSI) that
   operates on top of TCP.  This memo describes a standard mechanism for
   enabling clients to bootstrap themselves using the iSCSI protocol.
   The goal of this standard is to enable iSCSI boot clients to obtain
   the information to open an iSCSI session with the iSCSI boot server.

1.  Introduction

   The Small Computer Systems Interface (SCSI) is a popular family of
   protocols for communicating with I/O devices, especially storage
   devices.  SCSI can be characterized as a request/response messaging
   protocol with a standard architecture and componentized command sets
   for different device classes.

   iSCSI is a proposed transport protocol for SCSI that operates on top
   of TCP.  The role of iSCSI is necessitated by the evolution of the
   system interconnect from a shared bus to a switched network.  IP
   networks meet the architectural and performance requirements of
   transporting SCSI, paving the way for the iSCSI protocol.





Sarkar, et al.              Standards Track                     [Page 1]

RFC 4173                  iSCSI Bootstrapping             September 2005


   Many diskless clients sometimes bootstrap off remote SCSI devices.
   Such diskless entities are lightweight, space efficient, and power-
   conserving and are increasingly popular in various environments.

   This memo describes a standard mechanism for enabling clients to
   bootstrap themselves using the iSCSI protocol.  The goal of this
   standard is to enable iSCSI boot clients to obtain the information to
   open an iSCSI session with the iSCSI boot server.  It is possible
   that all the information is not available at the very outset, so the
   memo describes steps to obtain the information required to bootstrap
   clients off an iSCSI boot server.

1.1.  Keywords

   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 [Bradner97].

2.  Requirements

   1. There must be no restriction of network topology between the iSCSI
      boot client and the boot server other than that in effect for
      establishing the iSCSI session.  Consequently, it is possible for
      an iSCSI boot client to boot from an iSCSI boot server behind
      gateways or firewalls as long as it is possible to establish an
      iSCSI session between the client and the server.

   2. The following represent the minimum information required for an
      iSCSI boot client to contact an iSCSI boot server: (a) the
      client's IP address (IPv6 or IPv4); (b) the server's iSCSI Target
      Name; and (c) mandatory iSCSI initiator capability.

   The above assume that the default LUN for the boot process is 0 and
   that the default port for the iSCSI boot server is the well-known
   iSCSI port [Satran02].  However, both may be overridden at the time
   of configuration.

   Additional information may be required at each stage of the boot
   process.

   3. It is possible for the iSCSI boot client to have none of the above
      information or capability on starting.

   4. The client should be able to complete boot without user
      intervention (for boots that occur during an unattended power-up).
      However, there should be a mechanism for the user to input values
      so as to bypass stages of the boot protocol.




Sarkar, et al.              Standards Track                     [Page 2]

RFC 4173                  iSCSI Bootstrapping             September 2005


   5. Additional protocol software (for example, BOOTP or DHCP) may be
      necessary if the minimum information required for an iSCSI session
      is not provided.

3.  Related Work

   The Reverse Address Resolution Protocol (RARP) [Finlayson84] through
   the extensions defined in the Dynamic RARP (DRARP) [Brownell96]
   explicitly addresses the problem of network address discovery, and
   includes an automatic IP address assignment mechanism.  The Trivial
   File Transfer Protocol (TFTP) [Sollins81] provides for transport of a
   boot image from a boot server.  BOOTP [Croft85, Reynolds93, Wimer93]
   is a transport mechanism for a collection of configuration
   information.  BOOTP is also extensible, and official extensions have
   been defined for several configuration parameters.  DHCPv4 [Droms97,
   Droms93] and DHCPv6 [Droms02] are standards by which hosts are to be
   dynamically configured in an IP network.  The Service Location
   Protocol (SLP) provides for location of higher-level services
   [Guttman99].

4.  Software Stage

   Some iSCSI boot clients may lack the resources to boot up with the
   mandatory iSCSI initiator capability.  Such boot clients may choose
   to obtain iSCSI initiator software from a boot server.  Currently,
   many established protocols allow such a service in order to enable
   clients to load software images.  For example, BOOTP and DHCP servers
   have the capability to provide the locations of servers that can
   serve software images on requests from boot clients.

   Note that this document does not recommend any of the above
   protocols, and the final decision of which boot protocol is to be
   used to load iSCSI initiator software is left to the discretion of
   the implementor.

5.  DHCP Stage

   In order to use an iSCSI boot server, the following pieces of
   information are required for an ISCSI boot client.

   - The IP address of the iSCSI boot client (IPv4 or IPv6)

   - The IP transport endpoint for the iSCSI Target Port for the iSCSI
     boot server.  If the transport is TCP, for example, this has to
     resolve to an IP address and a TCP port number.  TCP is currently
     the only transport approved for iSCSI.





Sarkar, et al.              Standards Track                     [Page 3]

RFC 4173                  iSCSI Bootstrapping             September 2005


   - The eight-byte LUN structure identifying the Logical Unit within
     the iSCSI boot server.

   At boot time, all or none of this information may be stored in the
   iSCSI boot client.  This section describes techniques for obtaining
   the required information via the DHCP stage.  Otherwise, if the iSCSI
   boot client has all the information, the boot client may proceed
   directly to the Boot stage.

   An iSCSI boot client that does not know its IP address at power-on
   may acquire it via BOOTP or DHCP (v4 or v6), or via IPv6 address
   autoconfiguration.  Please note that DHCP settings (such as the RA
   settings in DHCPv6) may prohibit the use of DHCP in distributing
   iSCSI boot information; in this case, the DHCP stage cannot be used.

   Unless specified otherwise here, BOOTP or DHCP fields such as the
   client ID and gateway information are used in an identical way as
   applications other than iSCSI.

   A BOOTP or DHCP server (v4 or v6) MAY instruct an iSCSI client how to
   reach its boot device.  This is done using the variable-length option
   named Root Path [Alexander93, Reynolds93].  The use of the option
   field is reserved for iSCSI boot use by prefacing the string with
   "iscsi:".  The Root Path option is not currently defined for DHCPv6;
   if the option is defined for DHCPv6 in the future, the use of the
   option as defined for iSCSI boot will apply.

   The option field consists of an UTF-8 [Yergeau98] string.  The string
   has the following composition:

   "iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname>

   The fields "servername", "port", "protocol", and "LUN" are OPTIONAL
   and should be left blank if there are no corresponding values.  The
   "targetname" field is not optional and MUST be provided.

   The "servername" is the name of iSCSI server and contains either a
   valid domain name, a literal IPv4 address, or a literal IPv6 address.
   The servername must follow the specifications outlined in Section
   3.2.2 of the URI Specification [Lee98] [Hinden99].  The characters
   allowed must also conform to Section 2.2 of the same specification.
   Servername compression MUST NOT be used in this field.

   The "protocol" field is the decimal representation of the IANA-
   approved string for the transport protocol to be used for iSCSI.  If
   the protocol field is left bank, the default value is assumed to be





Sarkar, et al.              Standards Track                     [Page 4]

RFC 4173                  iSCSI Bootstrapping             September 2005


   "6" for TCP.  The transport protocol MUST have been approved for use
   in iSCSI; currently, the only approved protocol is TCP.

   The "port" is the decimal representation of the port on which the
   iSCSI boot server is listening.  If not specified, the port defaults
   to the well-known iSCSI port [Satran02].

   The "LUN" field is a hexadecimal representation of the LU number.  If
   the LUN field is blank, then LUN 0 is assumed.  If the LUN field is
   not blank, the representation MUST be divided into four groups of
   four hexadecimal digits, separated by "-".  Digits above 9 may be
   either lower or upper case.  An example of such a representation
   would be 4752-3A4F-6b7e-2F99.  For the sake of brevity, at most three
   leading zero ("0") digits MAY be omitted in any group of hexadecimal
   digits.  Thus, the "LUN" representation 6734-9-156f-127 is equivalent
   to 6734-0009-156f-0127.  Furthermore, trailing groups containing only
   the "0" digit MAY be omitted along with the preceding "-".  So, the
   "LUN" representation 4186-9 is equivalent to 4186-0009-0000-0000.
   Other concise representations of the LUN field MUST NOT be used.

   Note that SCSI targets are allowed to present different LU numberings
   for different SCSI initiators, so to our knowledge nothing precludes
   a SCSI target from exporting several different LUs to several
   different SCSI initiators as their respective LUN 0s.

   The "targetname" field is an iSCSI Name that is defined by the iSCSI
   standard [Satran02] to uniquely identify an iSCSI target.  The
   approved characters in the targetname field are stated in the iSCSI
   String Profile document[Bakke04].

   If the "servername" field is provided by BOOTP or DHCP, then that
   field is used in conjunction with other associated fields to contact
   the boot server in the Boot stage (Section 7).  However, if the
   "servername" field is not provided, then the "targetname" field is
   then used in the Discovery Service stage in conjunction with other
   associated fields (Section 6).

6.  Discovery Service Stage

   This stage is required if the BOOTP or DHCP server (v4 or v6) is
   unaware of any iSCSI boot servers or if the BOOTP or DHCP server is
   unable to provide the minimum information required to connect to the
   iSCSI boot server, other than the targetname.

   The Discovery Service may be based on the SLP protocol [Guttman99,
   Bakke02] and is an instantiation of the SLP Service or Directory
   Agent.  Alternatively, the Discovery Service may be based on the iSNS
   protocol [Tseng03] and is an instantiation of the iSNS Server.



Sarkar, et al.              Standards Track                     [Page 5]

RFC 4173                  iSCSI Bootstrapping             September 2005


   The iSCSI boot client may have obtained the targetname of the iSCSI
   boot server in the DHCP stage (Section 5).  In that case, the iSCSI
   boot client queries the SLP Discovery Service using query string 1 of
   the iSCSI Target Concrete Service Type Template, as specified in
   Section 6.2 of the iSCSI SLP interaction document [Bakke02], to
   resolve the targetname to an IP address and port number.
   Alternatively, the iSCSI boot client may query the iSNS Discovery
   Service with a Device Attribute Query with the targetname as the
   query parameter [Tseng03].  Once this is obtained, the iSCSI boot
   client proceeds to the Boot stage (Section 7).

   It is possible that the port number obtained from the Discovery
   Service may conflict with the one obtained from the DHCP stage.  In
   such a case, the implementor has the option to try both port numbers
   in the Boot stage.

   If the iSCSI boot client does not have any targetname information,
   the iSCSI boot client may then query the SLP Discovery Service with
   query string 4 of the iSCSI Target Concrete Service Type Template, as
   specified in Section 6.2 of the iSCSI SLP interaction document
   [Bakke02].  In response to this query, the SLP Discovery Service
   provides the boot client with a list of iSCSI boot servers the boot
   client is allowed to access.  Alternatively, the iSCSI boot client
   can query the iSNS Discovery Service to verify if the targets in
   particular Discovery Domain are bootable [Tseng03].

   If the list of iSCSI boot servers is empty, subsequent actions are
   left to the discretion of the implementor.  Otherwise, the iSCSI boot
   client may contact any iSCSI boot server in the list.  Moreover, the
   order in which iSCSI boot servers are contacted is also left to the
   discretion of the implementor.

7.  Boot Stage

   Once the iSCSI boot client has obtained the minimum information to
   open an iSCSI session with the iSCSI boot server, the actual booting
   process can start.

   The actual sequence of iSCSI commands that are needed to complete the
   boot process is left to the implementor.  This was done because of
   varying requirements from different vendors and equipment, making it
   difficult to specify a common subset of the iSCSI standard that would
   be acceptable to everybody.

   The iSCSI session established for boot may be taken over by the
   booted software in the iSCSI boot client.





Sarkar, et al.              Standards Track                     [Page 6]