rfc3783.txt

一个学习iSCSI协议的文档

         CONDITION, and the ASC/ASCQ value of 47h/7Fh ("SOME COMMANDS
         CLEARED BY ISCSI PROTOCOL EVENT").

6.  Command Ordering System Considerations

   In general, command ordering is automatically enforced if targets and
   initiators comply with the iSCSI specification.  However, listed
   below are certain additional related implementation considerations
   for the iSCSI initiators and targets to take note of.

      a) Even when all iSCSI and SCSI command ordering considerations
         earlier noted in this document were applied, it is beneficial
         for iSCSI initiators to proactively avoid scenarios that would
         otherwise lead to out-of-order command execution.  This is
         simply because the SCSI command ordering features such as UA
         interlock are likely to be costlier in performance when they
         are allowed to be triggered.  [iSCSI] provides enough guidance
         on how to implement this proactive detection of PDU ordering
         errors.

      b) The whole notion of command streaming does of course assume
         that the target in question supports command queueing.  An
         iSCSI target desirous of supporting command ordering solutions
         should ensure that the SCSI layer on the target supports
         command queuing.  The remote backup (tape vaulting)
         applications that iSCSI enables make an especially compelling
         case that tape devices should give a very serious consideration
         to supporting command queuing, at least when used in
         conjunction with iSCSI.





Chadalapaka & Elliott        Informational                     [Page 10]

RFC 3783                    Command Ordering                    May 2004


      c) An iSCSI target desirous of supporting high-performance command
         ordering solutions that involve specifying a description of
         execution schema should ensure that the SCSI layer on the
         target in fact does support the ORDERED and SIMPLE task
         attributes.

      d) There is some consideration of expanding the scope of UA
         interlock to encompass CHECK CONDITION status, and thus make it
         the only required command ordering functionality of
         implementations to build command ordering solutions.  Until
         this is resolved in T10, the currently defined semantics of UA
         interlock and ACA warrant implementing both features by iSCSI
         targets desirous of supporting command ordering solutions.

7.  Reservation Considerations

   [iSCSI] describes a "principle of conservative reuse" that encourages
   iSCSI initiators to reuse the same ISIDs (see section 3.2) to various
   SCSI target ports, in order to present the same SCSI initiator port
   name to those target ports.  This is in fact a very crucial
   implementation consideration that must be complied with.  [SPC3]
   mandates the SCSI targets to associate persistent reservations and
   the related registrations with the SCSI initiator port names whenever
   they are required by the SCSI transport protocol.  Since [iSCSI]
   requires the mandatory SCSI initiator port names based on ISIDs,
   iSCSI targets are required to work off the SCSI initiator port names,
   and thus indirectly the ISIDs, in enforcing the persistent
   reservations.

   This fact has the following implications for the implementations:

      a) If a persistent reservation/registration is intended to be used
         across multiple SCSI ports of a SCSI device, the initiator
         iSCSI implementation must use the same ISID across associated
         iSCSI sessions connecting to different iSCSI target portal
         groups of the SCSI device.

      b) If a persistent reservation/registration is intended to be used
         across the power loss of a SCSI target, the initiator iSCSI
         implementation must use the same ISIDs as before in
         re-establishing the associated iSCSI sessions upon subsequent
         reboot in order to rely on the persist through power loss
         capability.








Chadalapaka & Elliott        Informational                     [Page 11]

RFC 3783                    Command Ordering                    May 2004


8.  Security Considerations

   For security considerations in using the iSCSI protocol, refer to the
   Security Considerations section in [iSCSI].  This document does not
   introduce any additional security considerations other than those
   already discussed in [iSCSI].

9.  References

9.1.  Normative References

   [iSCSI]   Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M. and
             E. Zeidner, "Internet Small Computer Systems Inferface
             (iSCSI)", RFC 3720, May 2004.

   [SAM2]    ANSI INCITS.366:2003 SCSI Architecture Model - 2 (SAM-2).

9.2.  Informative References

   [RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

   [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3347] Krueger, M. and R. Haagens, "iSCSI Requirements and Design
             Considerations", RFC 3347, July 2002.

   [SPC3]    INCITS T10/1416-D, SCSI Primary Commands-3 (SPC-3).

10.  Acknowledgments

   We are grateful to the IPS working group whose work defined the iSCSI
   protocol.  Thanks also to David Black (EMC) who encouraged the
   publication of this document.  Special thanks to Randy Haagens (HP)
   for his insights on the topic of command ordering.  Thanks are also
   due to Elizabeth Rodriguez for carefully reviewing this document.














Chadalapaka & Elliott        Informational                     [Page 12]

RFC 3783                    Command Ordering                    May 2004


11.  Authors' Addresses

   Mallikarjun Chadalapaka
   Hewlett-Packard Company
   8000 Foothills Blvd.
   Roseville, CA 95747-5668, USA

   Phone: [phone]
   EMail: [e-mail]


   Rob Elliott
   Hewlett-Packard Company
   MC140801
   PO Box 692000
   Houston, TX 77269-2000  USA

   Phone: [phone]
   EMail: [e-mail]
































Chadalapaka & Elliott        Informational                     [Page 13]

RFC 3783                    Command Ordering                    May 2004


12.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









Chadalapaka & Elliott        Informational                     [Page 14]