Internet Engineering Task Force (IETF)                    M. Chadalapaka
Request for Comments: 7143                                     Microsoft
Obsoletes: 3720, 3980, 4850, 5048                              J. Satran
Updates: 3721                                             Infinidat Ltd.
Category: Standards Track                                        K. Meth
ISSN: 2070-1721                                                      IBM
                                                                D. Black
                                                                     EMC
                                                              April 2014
        
Internet Engineering Task Force (IETF)                    M. Chadalapaka
Request for Comments: 7143                                     Microsoft
Obsoletes: 3720, 3980, 4850, 5048                              J. Satran
Updates: 3721                                             Infinidat Ltd.
Category: Standards Track                                        K. Meth
ISSN: 2070-1721                                                      IBM
                                                                D. Black
                                                                     EMC
                                                              April 2014
        

Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)

Internet小型计算机系统接口(iSCSI)协议(整合)

Abstract

摘要

This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as a few improvements and corrections to the original iSCSI protocol.

本文档描述了在TCP之上工作的SCSI传输协议。iSCSI协议旨在完全符合标准化SCSI体系结构模型(SAM-2)。RFC 3720定义了原始iSCSI协议。RFC 3721讨论了iSCSI命名示例和发现技术。随后,RFC 3980向iSCSI协议添加了一种附加的命名格式。RFC 4850随后向iSCSI添加了一个新的公共扩展密钥。RFC 5048对原始iSCSI协议进行了许多澄清,并进行了一些改进和更正。

This document obsoletes RFCs 3720, 3980, 4850, and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics.

本文档通过将RFC 3720、3980、4850和5048合并为一个文档并对合并规范进行额外更新,从而淘汰了RFC 3720、3980、4850和5048。本文件还更新了RFC 3721。因此,如果语义上存在差异,本文件中的文本将取代所有注释RFC中的文本。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7143.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7143.

Copyright Notice

版权公告

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2014 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1. Introduction ...................................................11
   2. Acronyms, Definitions, and Document Summary ....................11
      2.1. Acronyms ..................................................11
      2.2. Definitions ...............................................13
      2.3. Summary of Changes ........................................19
      2.4. Conventions ...............................................20
   3. UML Conventions ................................................20
      3.1. UML Conventions Overview ..................................20
      3.2. Multiplicity Notion .......................................21
      3.3. Class Diagram Conventions .................................22
      3.4. Class Diagram Notation for Associations ...................23
      3.5. Class Diagram Notation for Aggregations ...................24
      3.6. Class Diagram Notation for Generalizations ................25
   4. Overview .......................................................25
      4.1. SCSI Concepts .............................................25
      4.2. iSCSI Concepts and Functional Overview ....................26
           4.2.1. Layers and Sessions ................................27
           4.2.2. Ordering and iSCSI Numbering .......................28
                  4.2.2.1. Command Numbering and Acknowledging .......28
                  4.2.2.2. Response/Status Numbering and
                           Acknowledging .............................32
                  4.2.2.3. Response Ordering .........................32
                           4.2.2.3.1. Need for Response Ordering .....32
                           4.2.2.3.2. Response Ordering Model
                                      Description ....................33
                           4.2.2.3.3. iSCSI Semantics with
                                      the Interface Model ............33
                           4.2.2.3.4. Current List of Fenced
                                      Response Use Cases .............34
                  4.2.2.4. Data Sequencing ...........................35
        
   1. Introduction ...................................................11
   2. Acronyms, Definitions, and Document Summary ....................11
      2.1. Acronyms ..................................................11
      2.2. Definitions ...............................................13
      2.3. Summary of Changes ........................................19
      2.4. Conventions ...............................................20
   3. UML Conventions ................................................20
      3.1. UML Conventions Overview ..................................20
      3.2. Multiplicity Notion .......................................21
      3.3. Class Diagram Conventions .................................22
      3.4. Class Diagram Notation for Associations ...................23
      3.5. Class Diagram Notation for Aggregations ...................24
      3.6. Class Diagram Notation for Generalizations ................25
   4. Overview .......................................................25
      4.1. SCSI Concepts .............................................25
      4.2. iSCSI Concepts and Functional Overview ....................26
           4.2.1. Layers and Sessions ................................27
           4.2.2. Ordering and iSCSI Numbering .......................28
                  4.2.2.1. Command Numbering and Acknowledging .......28
                  4.2.2.2. Response/Status Numbering and
                           Acknowledging .............................32
                  4.2.2.3. Response Ordering .........................32
                           4.2.2.3.1. Need for Response Ordering .....32
                           4.2.2.3.2. Response Ordering Model
                                      Description ....................33
                           4.2.2.3.3. iSCSI Semantics with
                                      the Interface Model ............33
                           4.2.2.3.4. Current List of Fenced
                                      Response Use Cases .............34
                  4.2.2.4. Data Sequencing ...........................35
        
           4.2.3. iSCSI Task Management ..............................36
                  4.2.3.1. Task Management Overview ..................36
                  4.2.3.2. Notion of Affected Tasks ..................36
                  4.2.3.3. Standard Multi-Task Abort Semantics .......37
                  4.2.3.4. FastAbort Multi-Task Abort Semantics ......38
                  4.2.3.5. Affected Tasks Shared across
                           Standard and FastAbort Sessions ...........40
                  4.2.3.6. Rationale behind the FastAbort Semantics ..41
           4.2.4. iSCSI Login ........................................42
           4.2.5. iSCSI Full Feature Phase ...........................44
                  4.2.5.1. Command Connection Allegiance .............44
                  4.2.5.2. Data Transfer Overview ....................45
                  4.2.5.3. Tags and Integrity Checks .................46
                  4.2.5.4. SCSI Task Management during iSCSI
                           Full Feature Phase ........................47
           4.2.6. iSCSI Connection Termination .......................47
           4.2.7. iSCSI Names ........................................47
                  4.2.7.1. iSCSI Name Properties .....................48
                  4.2.7.2. iSCSI Name Encoding .......................50
                  4.2.7.3. iSCSI Name Structure ......................51
                  4.2.7.4. Type "iqn." (iSCSI Qualified Name) ........52
                  4.2.7.5. Type "eui." (IEEE EUI-64 Format) ..........53
                  4.2.7.6. Type "naa." (Network Address Authority) ...54
           4.2.8. Persistent State ...................................55
           4.2.9. Message Synchronization and Steering ...............55
                  4.2.9.1. Sync/Steering and iSCSI PDU Length ........56
      4.3. iSCSI Session Types .......................................56
      4.4. SCSI-to-iSCSI Concepts Mapping Model ......................57
           4.4.1. iSCSI Architecture Model ...........................58
           4.4.2. SCSI Architecture Model ............................59
           4.4.3. Consequences of the Model ..........................61
                  4.4.3.1. I_T Nexus State ...........................62
                  4.4.3.2. Reservations ..............................63
      4.5. iSCSI UML Model ...........................................64
      4.6. Request/Response Summary ..................................66
           4.6.1. Request/Response Types Carrying SCSI Payload .......66
                  4.6.1.1. SCSI Command ..............................66
                  4.6.1.2. SCSI Response .............................66
                  4.6.1.3. Task Management Function Request ..........67
                  4.6.1.4. Task Management Function Response .........68
                  4.6.1.5. SCSI Data-Out and SCSI Data-In ............68
                  4.6.1.6. Ready To Transfer (R2T) ...................69
           4.6.2. Requests/Responses Carrying SCSI and iSCSI
                  Payload ............................................69
                  4.6.2.1. Asynchronous Message ......................69
        
           4.2.3. iSCSI Task Management ..............................36
                  4.2.3.1. Task Management Overview ..................36
                  4.2.3.2. Notion of Affected Tasks ..................36
                  4.2.3.3. Standard Multi-Task Abort Semantics .......37
                  4.2.3.4. FastAbort Multi-Task Abort Semantics ......38
                  4.2.3.5. Affected Tasks Shared across
                           Standard and FastAbort Sessions ...........40
                  4.2.3.6. Rationale behind the FastAbort Semantics ..41
           4.2.4. iSCSI Login ........................................42
           4.2.5. iSCSI Full Feature Phase ...........................44
                  4.2.5.1. Command Connection Allegiance .............44
                  4.2.5.2. Data Transfer Overview ....................45
                  4.2.5.3. Tags and Integrity Checks .................46
                  4.2.5.4. SCSI Task Management during iSCSI
                           Full Feature Phase ........................47
           4.2.6. iSCSI Connection Termination .......................47
           4.2.7. iSCSI Names ........................................47
                  4.2.7.1. iSCSI Name Properties .....................48
                  4.2.7.2. iSCSI Name Encoding .......................50
                  4.2.7.3. iSCSI Name Structure ......................51
                  4.2.7.4. Type "iqn." (iSCSI Qualified Name) ........52
                  4.2.7.5. Type "eui." (IEEE EUI-64 Format) ..........53
                  4.2.7.6. Type "naa." (Network Address Authority) ...54
           4.2.8. Persistent State ...................................55
           4.2.9. Message Synchronization and Steering ...............55
                  4.2.9.1. Sync/Steering and iSCSI PDU Length ........56
      4.3. iSCSI Session Types .......................................56
      4.4. SCSI-to-iSCSI Concepts Mapping Model ......................57
           4.4.1. iSCSI Architecture Model ...........................58
           4.4.2. SCSI Architecture Model ............................59
           4.4.3. Consequences of the Model ..........................61
                  4.4.3.1. I_T Nexus State ...........................62
                  4.4.3.2. Reservations ..............................63
      4.5. iSCSI UML Model ...........................................64
      4.6. Request/Response Summary ..................................66
           4.6.1. Request/Response Types Carrying SCSI Payload .......66
                  4.6.1.1. SCSI Command ..............................66
                  4.6.1.2. SCSI Response .............................66
                  4.6.1.3. Task Management Function Request ..........67
                  4.6.1.4. Task Management Function Response .........68
                  4.6.1.5. SCSI Data-Out and SCSI Data-In ............68
                  4.6.1.6. Ready To Transfer (R2T) ...................69
           4.6.2. Requests/Responses Carrying SCSI and iSCSI
                  Payload ............................................69
                  4.6.2.1. Asynchronous Message ......................69
        
           4.6.3. Requests/Responses Carrying iSCSI-Only Payload .....69
                  4.6.3.1. Text Requests and Text Responses ..........69
                  4.6.3.2. Login Requests and Login Responses ........70
                  4.6.3.3. Logout Requests and Logout Responses ......71
                  4.6.3.4. SNACK Request .............................71
                  4.6.3.5. Reject ....................................71
                  4.6.3.6. NOP-Out Request and NOP-In Response .......71
   5. SCSI Mode Parameters for iSCSI .................................72
   6. Login and Full Feature Phase Negotiation .......................72
      6.1. Text Format ...............................................73
      6.2. Text Mode Negotiation .....................................76
           6.2.1. List Negotiations ..................................80
           6.2.2. Simple-Value Negotiations ..........................80
      6.3. Login Phase ...............................................81
           6.3.1. Login Phase Start ..................................84
           6.3.2. iSCSI Security Negotiation .........................87
           6.3.3. Operational Parameter Negotiation during
                  the Login Phase ....................................87
           6.3.4. Connection Reinstatement ...........................88
           6.3.5. Session Reinstatement, Closure, and Timeout ........89
                  6.3.5.1. Loss of Nexus Notification ................90
           6.3.6. Session Continuation and Failure ...................90
      6.4. Operational Parameter Negotiation outside the
           Login Phase ...............................................90
   7. iSCSI Error Handling and Recovery ..............................92
      7.1. Overview ..................................................92
           7.1.1. Background .........................................92
           7.1.2. Goals ..............................................92
           7.1.3. Protocol Features and State Expectations ...........93
           7.1.4. Recovery Classes ...................................94
                  7.1.4.1. Recovery Within-command ...................95
                  7.1.4.2. Recovery Within-connection ................96
                  7.1.4.3. Connection Recovery .......................96
                  7.1.4.4. Session Recovery ..........................97
           7.1.5. Error Recovery Hierarchy ...........................97
      7.2. Retry and Reassign in Recovery ............................99
           7.2.1. Usage of Retry .....................................99
           7.2.2. Allegiance Reassignment ...........................100
      7.3. Usage of Reject PDU in Recovery ..........................101
      7.4. Error Recovery Considerations for Discovery Sessions .....102
           7.4.1. ErrorRecoveryLevel for Discovery Sessions .........102
           7.4.2. Reinstatement Semantics for Discovery Sessions ....102
                  7.4.2.1. Unnamed Discovery Sessions ...............103
                  7.4.2.2. Named Discovery Sessions .................103
           7.4.3. Target PDUs during Discovery ......................103
        
           4.6.3. Requests/Responses Carrying iSCSI-Only Payload .....69
                  4.6.3.1. Text Requests and Text Responses ..........69
                  4.6.3.2. Login Requests and Login Responses ........70
                  4.6.3.3. Logout Requests and Logout Responses ......71
                  4.6.3.4. SNACK Request .............................71
                  4.6.3.5. Reject ....................................71
                  4.6.3.6. NOP-Out Request and NOP-In Response .......71
   5. SCSI Mode Parameters for iSCSI .................................72
   6. Login and Full Feature Phase Negotiation .......................72
      6.1. Text Format ...............................................73
      6.2. Text Mode Negotiation .....................................76
           6.2.1. List Negotiations ..................................80
           6.2.2. Simple-Value Negotiations ..........................80
      6.3. Login Phase ...............................................81
           6.3.1. Login Phase Start ..................................84
           6.3.2. iSCSI Security Negotiation .........................87
           6.3.3. Operational Parameter Negotiation during
                  the Login Phase ....................................87
           6.3.4. Connection Reinstatement ...........................88
           6.3.5. Session Reinstatement, Closure, and Timeout ........89
                  6.3.5.1. Loss of Nexus Notification ................90
           6.3.6. Session Continuation and Failure ...................90
      6.4. Operational Parameter Negotiation outside the
           Login Phase ...............................................90
   7. iSCSI Error Handling and Recovery ..............................92
      7.1. Overview ..................................................92
           7.1.1. Background .........................................92
           7.1.2. Goals ..............................................92
           7.1.3. Protocol Features and State Expectations ...........93
           7.1.4. Recovery Classes ...................................94
                  7.1.4.1. Recovery Within-command ...................95
                  7.1.4.2. Recovery Within-connection ................96
                  7.1.4.3. Connection Recovery .......................96
                  7.1.4.4. Session Recovery ..........................97
           7.1.5. Error Recovery Hierarchy ...........................97
      7.2. Retry and Reassign in Recovery ............................99
           7.2.1. Usage of Retry .....................................99
           7.2.2. Allegiance Reassignment ...........................100
      7.3. Usage of Reject PDU in Recovery ..........................101
      7.4. Error Recovery Considerations for Discovery Sessions .....102
           7.4.1. ErrorRecoveryLevel for Discovery Sessions .........102
           7.4.2. Reinstatement Semantics for Discovery Sessions ....102
                  7.4.2.1. Unnamed Discovery Sessions ...............103
                  7.4.2.2. Named Discovery Sessions .................103
           7.4.3. Target PDUs during Discovery ......................103
        
      7.5. Connection Timeout Management ............................104
           7.5.1. Timeouts on Transport Exception Events ............104
           7.5.2. Timeouts on Planned Decommissioning ...............104
      7.6. Implicit Termination of Tasks ............................104
      7.7. Format Errors ............................................105
      7.8. Digest Errors ............................................106
      7.9. Sequence Errors ..........................................107
      7.10. Message Error Checking ..................................108
      7.11. SCSI Timeouts ...........................................108
      7.12. Negotiation Failures ....................................109
      7.13. Protocol Errors .........................................110
      7.14. Connection Failures .....................................110
      7.15. Session Errors ..........................................111
   8. State Transitions .............................................112
      8.1. Standard Connection State Diagrams .......................112
           8.1.1. State Descriptions for Initiators and Targets .....112
           8.1.2. State Transition Descriptions for
                  Initiators and Targets ............................114
           8.1.3. Standard Connection State Diagram for an
                  Initiator .........................................118
           8.1.4. Standard Connection State Diagram for a Target ....120
      8.2. Connection Cleanup State Diagram for Initiators
           and Targets ..............................................122
           8.2.1. State Descriptions for Initiators and Targets .....124
           8.2.2. State Transition Descriptions for
                  Initiators and Targets ............................124
      8.3. Session State Diagrams ...................................126
           8.3.1. Session State Diagram for an Initiator ............126
           8.3.2. Session State Diagram for a Target ................127
           8.3.3. State Descriptions for Initiators and Targets .....129
           8.3.4. State Transition Descriptions for
                  Initiators and Targets ............................129
   9. Security Considerations .......................................131
      9.1. iSCSI Security Mechanisms ................................132
      9.2. In-Band Initiator-Target Authentication ..................132
           9.2.1. CHAP Considerations ...............................134
           9.2.2. SRP Considerations ................................136
           9.2.3. Kerberos Considerations ...........................136
      9.3. IPsec ....................................................137
           9.3.1. Data Authentication and Integrity .................137
           9.3.2. Confidentiality ...................................138
           9.3.3. Policy, Security Associations, and
                  Cryptographic Key Management ......................139
      9.4. Security Considerations for the X#NodeArchitecture Key ...141
      9.5. SCSI Access Control Considerations .......................143
        
      7.5. Connection Timeout Management ............................104
           7.5.1. Timeouts on Transport Exception Events ............104
           7.5.2. Timeouts on Planned Decommissioning ...............104
      7.6. Implicit Termination of Tasks ............................104
      7.7. Format Errors ............................................105
      7.8. Digest Errors ............................................106
      7.9. Sequence Errors ..........................................107
      7.10. Message Error Checking ..................................108
      7.11. SCSI Timeouts ...........................................108
      7.12. Negotiation Failures ....................................109
      7.13. Protocol Errors .........................................110
      7.14. Connection Failures .....................................110
      7.15. Session Errors ..........................................111
   8. State Transitions .............................................112
      8.1. Standard Connection State Diagrams .......................112
           8.1.1. State Descriptions for Initiators and Targets .....112
           8.1.2. State Transition Descriptions for
                  Initiators and Targets ............................114
           8.1.3. Standard Connection State Diagram for an
                  Initiator .........................................118
           8.1.4. Standard Connection State Diagram for a Target ....120
      8.2. Connection Cleanup State Diagram for Initiators
           and Targets ..............................................122
           8.2.1. State Descriptions for Initiators and Targets .....124
           8.2.2. State Transition Descriptions for
                  Initiators and Targets ............................124
      8.3. Session State Diagrams ...................................126
           8.3.1. Session State Diagram for an Initiator ............126
           8.3.2. Session State Diagram for a Target ................127
           8.3.3. State Descriptions for Initiators and Targets .....129
           8.3.4. State Transition Descriptions for
                  Initiators and Targets ............................129
   9. Security Considerations .......................................131
      9.1. iSCSI Security Mechanisms ................................132
      9.2. In-Band Initiator-Target Authentication ..................132
           9.2.1. CHAP Considerations ...............................134
           9.2.2. SRP Considerations ................................136
           9.2.3. Kerberos Considerations ...........................136
      9.3. IPsec ....................................................137
           9.3.1. Data Authentication and Integrity .................137
           9.3.2. Confidentiality ...................................138
           9.3.3. Policy, Security Associations, and
                  Cryptographic Key Management ......................139
      9.4. Security Considerations for the X#NodeArchitecture Key ...141
      9.5. SCSI Access Control Considerations .......................143
        
   10. Notes to Implementers ........................................143
      10.1. Multiple Network Adapters ...............................143
           10.1.1. Conservative Reuse of ISIDs ......................143
           10.1.2. iSCSI Name, ISID, and TPGT Use ...................144
      10.2. Autosense and Auto Contingent Allegiance (ACA) ..........146
      10.3. iSCSI Timeouts ..........................................146
      10.4. Command Retry and Cleaning Old Command Instances ........147
      10.5. Sync and Steering Layer, and Performance ................147
      10.6. Considerations for State-Dependent Devices and
            Long-Lasting SCSI Operations ............................147
           10.6.1. Determining the Proper ErrorRecoveryLevel ........148
      10.7. Multi-Task Abort Implementation Considerations ..........149
   11. iSCSI PDU Formats ............................................150
      11.1. iSCSI PDU Length and Padding ............................150
      11.2. PDU Template, Header, and Opcodes .......................150
           11.2.1. Basic Header Segment (BHS) .......................152
                  11.2.1.1. I (Immediate) Bit .......................152
                  11.2.1.2. Opcode ..................................152
                  11.2.1.3. F (Final) Bit ...........................154
                  11.2.1.4. Opcode-Specific Fields ..................154
                  11.2.1.5. TotalAHSLength ..........................154
                  11.2.1.6. DataSegmentLength .......................154
                  11.2.1.7. LUN .....................................154
                  11.2.1.8. Initiator Task Tag ......................154
           11.2.2. Additional Header Segment (AHS) ..................155
                  11.2.2.1. AHSType .................................155
                  11.2.2.2. AHSLength ...............................155
                  11.2.2.3. Extended CDB AHS ........................156
                  11.2.2.4. Bidirectional Read Expected Data
                            Transfer Length AHS .....................156
           11.2.3. Header Digest and Data Digest ....................156
           11.2.4. Data Segment .....................................157
      11.3. SCSI Command ............................................158
           11.3.1. Flags and Task Attributes (Byte 1) ...............159
           11.3.2. CmdSN - Command Sequence Number ..................159
           11.3.3. ExpStatSN ........................................160
           11.3.4. Expected Data Transfer Length ....................160
           11.3.5. CDB - SCSI Command Descriptor Block ..............160
           11.3.6. Data Segment - Command Data ......................161
      11.4. SCSI Response ...........................................161
           11.4.1. Flags (Byte 1) ...................................162
           11.4.2. Status ...........................................163
           11.4.3. Response .........................................163
           11.4.4. SNACK Tag ........................................164
        
   10. Notes to Implementers ........................................143
      10.1. Multiple Network Adapters ...............................143
           10.1.1. Conservative Reuse of ISIDs ......................143
           10.1.2. iSCSI Name, ISID, and TPGT Use ...................144
      10.2. Autosense and Auto Contingent Allegiance (ACA) ..........146
      10.3. iSCSI Timeouts ..........................................146
      10.4. Command Retry and Cleaning Old Command Instances ........147
      10.5. Sync and Steering Layer, and Performance ................147
      10.6. Considerations for State-Dependent Devices and
            Long-Lasting SCSI Operations ............................147
           10.6.1. Determining the Proper ErrorRecoveryLevel ........148
      10.7. Multi-Task Abort Implementation Considerations ..........149
   11. iSCSI PDU Formats ............................................150
      11.1. iSCSI PDU Length and Padding ............................150
      11.2. PDU Template, Header, and Opcodes .......................150
           11.2.1. Basic Header Segment (BHS) .......................152
                  11.2.1.1. I (Immediate) Bit .......................152
                  11.2.1.2. Opcode ..................................152
                  11.2.1.3. F (Final) Bit ...........................154
                  11.2.1.4. Opcode-Specific Fields ..................154
                  11.2.1.5. TotalAHSLength ..........................154
                  11.2.1.6. DataSegmentLength .......................154
                  11.2.1.7. LUN .....................................154
                  11.2.1.8. Initiator Task Tag ......................154
           11.2.2. Additional Header Segment (AHS) ..................155
                  11.2.2.1. AHSType .................................155
                  11.2.2.2. AHSLength ...............................155
                  11.2.2.3. Extended CDB AHS ........................156
                  11.2.2.4. Bidirectional Read Expected Data
                            Transfer Length AHS .....................156
           11.2.3. Header Digest and Data Digest ....................156
           11.2.4. Data Segment .....................................157
      11.3. SCSI Command ............................................158
           11.3.1. Flags and Task Attributes (Byte 1) ...............159
           11.3.2. CmdSN - Command Sequence Number ..................159
           11.3.3. ExpStatSN ........................................160
           11.3.4. Expected Data Transfer Length ....................160
           11.3.5. CDB - SCSI Command Descriptor Block ..............160
           11.3.6. Data Segment - Command Data ......................161
      11.4. SCSI Response ...........................................161
           11.4.1. Flags (Byte 1) ...................................162
           11.4.2. Status ...........................................163
           11.4.3. Response .........................................163
           11.4.4. SNACK Tag ........................................164
        
           11.4.5. Residual Count ...................................164
                  11.4.5.1. Field Semantics .........................164
                  11.4.5.2. Residuals Concepts Overview .............164
                  11.4.5.3. SCSI REPORT LUNS Command and
                            Residual Overflow .......................165
           11.4.6. Bidirectional Read Residual Count ................166
           11.4.7. Data Segment - Sense and Response Data Segment ...167
                  11.4.7.1. SenseLength .............................167
                  11.4.7.2. Sense Data ..............................168
           11.4.8. ExpDataSN ........................................168
           11.4.9. StatSN - Status Sequence Number ..................168
           11.4.10. ExpCmdSN - Next Expected CmdSN from This
                    Initiator .......................................169
           11.4.11. MaxCmdSN - Maximum CmdSN from This Initiator ....169
      11.5. Task Management Function Request ........................170
           11.5.1. Function .........................................170
           11.5.2. TotalAHSLength and DataSegmentLength .............173
           11.5.3. LUN ..............................................173
           11.5.4. Referenced Task Tag ..............................173
           11.5.5. RefCmdSN .........................................174
           11.5.6. ExpDataSN ........................................174
      11.6. Task Management Function Response .......................175
           11.6.1. Response .........................................176
           11.6.2. TotalAHSLength and DataSegmentLength .............177
      11.7. SCSI Data-Out and SCSI Data-In ..........................178
           11.7.1. F (Final) Bit ....................................180
           11.7.2. A (Acknowledge) Bit ..............................180
           11.7.3. Flags (Byte 1) ...................................181
           11.7.4. Target Transfer Tag and LUN ......................181
           11.7.5. DataSN ...........................................182
           11.7.6. Buffer Offset ....................................182
           11.7.7. DataSegmentLength ................................182
      11.8. Ready To Transfer (R2T) .................................183
           11.8.1. TotalAHSLength and DataSegmentLength .............184
           11.8.2. R2TSN ............................................184
           11.8.3. StatSN ...........................................185
           11.8.4. Desired Data Transfer Length and Buffer Offset ...185
           11.8.5. Target Transfer Tag ..............................185
      11.9. Asynchronous Message ....................................186
           11.9.1. AsyncEvent .......................................187
           11.9.2. AsyncVCode .......................................189
           11.9.3. LUN ..............................................189
           11.9.4. Sense Data and iSCSI Event Data ..................190
                  11.9.4.1. SenseLength .............................190
        
           11.4.5. Residual Count ...................................164
                  11.4.5.1. Field Semantics .........................164
                  11.4.5.2. Residuals Concepts Overview .............164
                  11.4.5.3. SCSI REPORT LUNS Command and
                            Residual Overflow .......................165
           11.4.6. Bidirectional Read Residual Count ................166
           11.4.7. Data Segment - Sense and Response Data Segment ...167
                  11.4.7.1. SenseLength .............................167
                  11.4.7.2. Sense Data ..............................168
           11.4.8. ExpDataSN ........................................168
           11.4.9. StatSN - Status Sequence Number ..................168
           11.4.10. ExpCmdSN - Next Expected CmdSN from This
                    Initiator .......................................169
           11.4.11. MaxCmdSN - Maximum CmdSN from This Initiator ....169
      11.5. Task Management Function Request ........................170
           11.5.1. Function .........................................170
           11.5.2. TotalAHSLength and DataSegmentLength .............173
           11.5.3. LUN ..............................................173
           11.5.4. Referenced Task Tag ..............................173
           11.5.5. RefCmdSN .........................................174
           11.5.6. ExpDataSN ........................................174
      11.6. Task Management Function Response .......................175
           11.6.1. Response .........................................176
           11.6.2. TotalAHSLength and DataSegmentLength .............177
      11.7. SCSI Data-Out and SCSI Data-In ..........................178
           11.7.1. F (Final) Bit ....................................180
           11.7.2. A (Acknowledge) Bit ..............................180
           11.7.3. Flags (Byte 1) ...................................181
           11.7.4. Target Transfer Tag and LUN ......................181
           11.7.5. DataSN ...........................................182
           11.7.6. Buffer Offset ....................................182
           11.7.7. DataSegmentLength ................................182
      11.8. Ready To Transfer (R2T) .................................183
           11.8.1. TotalAHSLength and DataSegmentLength .............184
           11.8.2. R2TSN ............................................184
           11.8.3. StatSN ...........................................185
           11.8.4. Desired Data Transfer Length and Buffer Offset ...185
           11.8.5. Target Transfer Tag ..............................185
      11.9. Asynchronous Message ....................................186
           11.9.1. AsyncEvent .......................................187
           11.9.2. AsyncVCode .......................................189
           11.9.3. LUN ..............................................189
           11.9.4. Sense Data and iSCSI Event Data ..................190
                  11.9.4.1. SenseLength .............................190
        
      11.10. Text Request ...........................................191
           11.10.1. F (Final) Bit ...................................192
           11.10.2. C (Continue) Bit ................................192
           11.10.3. Initiator Task Tag ..............................192
           11.10.4. Target Transfer Tag .............................192
           11.10.5. Text ............................................193
      11.11. Text Response ..........................................194
           11.11.1. F (Final) Bit ...................................194
           11.11.2. C (Continue) Bit ................................195
           11.11.3. Initiator Task Tag ..............................195
           11.11.4. Target Transfer Tag .............................195
           11.11.5. StatSN ..........................................196
           11.11.6. Text Response Data ..............................196
      11.12. Login Request ..........................................196
           11.12.1. T (Transit) Bit .................................197
           11.12.2. C (Continue) Bit ................................197
           11.12.3. CSG and NSG .....................................198
           11.12.4. Version .........................................198
                  11.12.4.1. Version-max ............................198
                  11.12.4.2. Version-min ............................198
           11.12.5. ISID ............................................199
           11.12.6. TSIH ............................................200
           11.12.7. Connection ID (CID) .............................200
           11.12.8. CmdSN ...........................................201
           11.12.9. ExpStatSN .......................................201
           11.12.10. Login Parameters ...............................201
      11.13. Login Response .........................................202
           11.13.1. Version-max .....................................202
           11.13.2. Version-active ..................................203
           11.13.3. TSIH ............................................203
           11.13.4. StatSN ..........................................203
           11.13.5. Status-Class and Status-Detail ..................203
           11.13.6. T (Transit) Bit .................................206
           11.13.7. C (Continue) Bit ................................206
           11.13.8. Login Parameters ................................207
      11.14. Logout Request .........................................207
           11.14.1. Reason Code .....................................209
           11.14.2. TotalAHSLength and DataSegmentLength ............209
           11.14.3. CID .............................................210
           11.14.4. ExpStatSN .......................................210
           11.14.5. Implicit Termination of Tasks ...................210
      11.15. Logout Response ........................................211
           11.15.1. Response ........................................212
           11.15.2. TotalAHSLength and DataSegmentLength ............212
           11.15.3. Time2Wait .......................................212
           11.15.4. Time2Retain .....................................212
        
      11.10. Text Request ...........................................191
           11.10.1. F (Final) Bit ...................................192
           11.10.2. C (Continue) Bit ................................192
           11.10.3. Initiator Task Tag ..............................192
           11.10.4. Target Transfer Tag .............................192
           11.10.5. Text ............................................193
      11.11. Text Response ..........................................194
           11.11.1. F (Final) Bit ...................................194
           11.11.2. C (Continue) Bit ................................195
           11.11.3. Initiator Task Tag ..............................195
           11.11.4. Target Transfer Tag .............................195
           11.11.5. StatSN ..........................................196
           11.11.6. Text Response Data ..............................196
      11.12. Login Request ..........................................196
           11.12.1. T (Transit) Bit .................................197
           11.12.2. C (Continue) Bit ................................197
           11.12.3. CSG and NSG .....................................198
           11.12.4. Version .........................................198
                  11.12.4.1. Version-max ............................198
                  11.12.4.2. Version-min ............................198
           11.12.5. ISID ............................................199
           11.12.6. TSIH ............................................200
           11.12.7. Connection ID (CID) .............................200
           11.12.8. CmdSN ...........................................201
           11.12.9. ExpStatSN .......................................201
           11.12.10. Login Parameters ...............................201
      11.13. Login Response .........................................202
           11.13.1. Version-max .....................................202
           11.13.2. Version-active ..................................203
           11.13.3. TSIH ............................................203
           11.13.4. StatSN ..........................................203
           11.13.5. Status-Class and Status-Detail ..................203
           11.13.6. T (Transit) Bit .................................206
           11.13.7. C (Continue) Bit ................................206
           11.13.8. Login Parameters ................................207
      11.14. Logout Request .........................................207
           11.14.1. Reason Code .....................................209
           11.14.2. TotalAHSLength and DataSegmentLength ............209
           11.14.3. CID .............................................210
           11.14.4. ExpStatSN .......................................210
           11.14.5. Implicit Termination of Tasks ...................210
      11.15. Logout Response ........................................211
           11.15.1. Response ........................................212
           11.15.2. TotalAHSLength and DataSegmentLength ............212
           11.15.3. Time2Wait .......................................212
           11.15.4. Time2Retain .....................................212
        
      11.16. SNACK Request ..........................................213
           11.16.1. Type ............................................214
           11.16.2. Data Acknowledgment .............................215
           11.16.3. Resegmentation ..................................215
           11.16.4. Initiator Task Tag ..............................216
           11.16.5. Target Transfer Tag or SNACK Tag ................216
           11.16.6. BegRun ..........................................216
           11.16.7. RunLength .......................................216
      11.17. Reject .................................................217
           11.17.1. Reason ..........................................218
           11.17.2. DataSN/R2TSN ....................................219
           11.17.3. StatSN, ExpCmdSN, and MaxCmdSN ..................219
           11.17.4. Complete Header of Bad PDU ......................219
      11.18. NOP-Out ................................................220
           11.18.1. Initiator Task Tag ..............................221
           11.18.2. Target Transfer Tag .............................221
           11.18.3. Ping Data .......................................221
      11.19. NOP-In .................................................222
           11.19.1. Target Transfer Tag .............................223
           11.19.2. StatSN ..........................................223
           11.19.3. LUN .............................................223
   12. iSCSI Security Text Keys and Authentication Methods ..........223
      12.1. AuthMethod ..............................................224
           12.1.1. Kerberos .........................................226
           12.1.2. Secure Remote Password (SRP) .....................226
           12.1.3. Challenge Handshake Authentication
                   Protocol (CHAP) ..................................228
   13. Login/Text Operational Text Keys .............................229
      13.1. HeaderDigest and DataDigest .............................230
      13.2. MaxConnections ..........................................232
      13.3. SendTargets .............................................232
      13.4. TargetName ..............................................232
      13.5. InitiatorName ...........................................233
      13.6. TargetAlias .............................................233
      13.7. InitiatorAlias ..........................................234
      13.8. TargetAddress ...........................................234
      13.9. TargetPortalGroupTag ....................................235
      13.10. InitialR2T .............................................236
      13.11. ImmediateData ..........................................236
      13.12. MaxRecvDataSegmentLength ...............................237
      13.13. MaxBurstLength .........................................238
      13.14. FirstBurstLength .......................................238
      13.15. DefaultTime2Wait .......................................239
      13.16. DefaultTime2Retain .....................................239
      13.17. MaxOutstandingR2T ......................................239
      13.18. DataPDUInOrder .........................................240
      13.19. DataSequenceInOrder ....................................240
      13.20. ErrorRecoveryLevel .....................................241
        
      11.16. SNACK Request ..........................................213
           11.16.1. Type ............................................214
           11.16.2. Data Acknowledgment .............................215
           11.16.3. Resegmentation ..................................215
           11.16.4. Initiator Task Tag ..............................216
           11.16.5. Target Transfer Tag or SNACK Tag ................216
           11.16.6. BegRun ..........................................216
           11.16.7. RunLength .......................................216
      11.17. Reject .................................................217
           11.17.1. Reason ..........................................218
           11.17.2. DataSN/R2TSN ....................................219
           11.17.3. StatSN, ExpCmdSN, and MaxCmdSN ..................219
           11.17.4. Complete Header of Bad PDU ......................219
      11.18. NOP-Out ................................................220
           11.18.1. Initiator Task Tag ..............................221
           11.18.2. Target Transfer Tag .............................221
           11.18.3. Ping Data .......................................221
      11.19. NOP-In .................................................222
           11.19.1. Target Transfer Tag .............................223
           11.19.2. StatSN ..........................................223
           11.19.3. LUN .............................................223
   12. iSCSI Security Text Keys and Authentication Methods ..........223
      12.1. AuthMethod ..............................................224
           12.1.1. Kerberos .........................................226
           12.1.2. Secure Remote Password (SRP) .....................226
           12.1.3. Challenge Handshake Authentication
                   Protocol (CHAP) ..................................228
   13. Login/Text Operational Text Keys .............................229
      13.1. HeaderDigest and DataDigest .............................230
      13.2. MaxConnections ..........................................232
      13.3. SendTargets .............................................232
      13.4. TargetName ..............................................232
      13.5. InitiatorName ...........................................233
      13.6. TargetAlias .............................................233
      13.7. InitiatorAlias ..........................................234
      13.8. TargetAddress ...........................................234
      13.9. TargetPortalGroupTag ....................................235
      13.10. InitialR2T .............................................236
      13.11. ImmediateData ..........................................236
      13.12. MaxRecvDataSegmentLength ...............................237
      13.13. MaxBurstLength .........................................238
      13.14. FirstBurstLength .......................................238
      13.15. DefaultTime2Wait .......................................239
      13.16. DefaultTime2Retain .....................................239
      13.17. MaxOutstandingR2T ......................................239
      13.18. DataPDUInOrder .........................................240
      13.19. DataSequenceInOrder ....................................240
      13.20. ErrorRecoveryLevel .....................................241
        
      13.21. SessionType ............................................241
      13.22. The Private Extension Key Format .......................242
      13.23. TaskReporting ..........................................242
      13.24. iSCSIProtocolLevel Negotiation .........................243
      13.25. Obsoleted Keys .........................................243
      13.26. X#NodeArchitecture .....................................244
           13.26.1. Definition ......................................244
           13.26.2. Implementation Requirements .....................244
   14. Rationale for Revised IANA Considerations ....................245
   15. IANA Considerations ..........................................246
   16. References ...................................................248
      16.1. Normative References ....................................248
      16.2. Informative References ..................................251
   Appendix A. Examples .............................................254
     A.1. Read Operation Example ....................................254
     A.2. Write Operation Example ...................................255
     A.3. R2TSN/DataSN Use Examples .................................256
          A.3.1. Output (Write) Data DataSN/R2TSN Example ...........256
          A.3.2. Input (Read) Data DataSN Example ...................257
          A.3.3. Bidirectional DataSN Example .......................258
          A.3.4. Unsolicited and Immediate Output (Write) Data
                 with DataSN Example ................................259
     A.4. CRC Examples ..............................................259
   Appendix B. Login Phase Examples .................................261
   Appendix C. SendTargets Operation ................................268
   Appendix D. Algorithmic Presentation of Error Recovery
               Classes ..............................................272
     D.1. General Data Structure and Procedure Description ..........273
     D.2. Within-command Error Recovery Algorithms ..................274
          D.2.1. Procedure Descriptions .............................274
          D.2.2. Initiator Algorithms ...............................275
          D.2.3. Target Algorithms ..................................277
     D.3. Within-connection Recovery Algorithms .....................279
          D.3.1. Procedure Descriptions .............................279
          D.3.2. Initiator Algorithms ...............................280
          D.3.3. Target Algorithms ..................................283
     D.4. Connection Recovery Algorithms ............................283
          D.4.1. Procedure Descriptions .............................283
          D.4.2. Initiator Algorithms ...............................284
          D.4.3. Target Algorithms ..................................286
   Appendix E. Clearing Effects of Various Events on Targets ........288
     E.1. Clearing Effects on iSCSI Objects .........................288
     E.2. Clearing Effects on SCSI Objects ..........................293
   Acknowledgments ..................................................294
        
      13.21. SessionType ............................................241
      13.22. The Private Extension Key Format .......................242
      13.23. TaskReporting ..........................................242
      13.24. iSCSIProtocolLevel Negotiation .........................243
      13.25. Obsoleted Keys .........................................243
      13.26. X#NodeArchitecture .....................................244
           13.26.1. Definition ......................................244
           13.26.2. Implementation Requirements .....................244
   14. Rationale for Revised IANA Considerations ....................245
   15. IANA Considerations ..........................................246
   16. References ...................................................248
      16.1. Normative References ....................................248
      16.2. Informative References ..................................251
   Appendix A. Examples .............................................254
     A.1. Read Operation Example ....................................254
     A.2. Write Operation Example ...................................255
     A.3. R2TSN/DataSN Use Examples .................................256
          A.3.1. Output (Write) Data DataSN/R2TSN Example ...........256
          A.3.2. Input (Read) Data DataSN Example ...................257
          A.3.3. Bidirectional DataSN Example .......................258
          A.3.4. Unsolicited and Immediate Output (Write) Data
                 with DataSN Example ................................259
     A.4. CRC Examples ..............................................259
   Appendix B. Login Phase Examples .................................261
   Appendix C. SendTargets Operation ................................268
   Appendix D. Algorithmic Presentation of Error Recovery
               Classes ..............................................272
     D.1. General Data Structure and Procedure Description ..........273
     D.2. Within-command Error Recovery Algorithms ..................274
          D.2.1. Procedure Descriptions .............................274
          D.2.2. Initiator Algorithms ...............................275
          D.2.3. Target Algorithms ..................................277
     D.3. Within-connection Recovery Algorithms .....................279
          D.3.1. Procedure Descriptions .............................279
          D.3.2. Initiator Algorithms ...............................280
          D.3.3. Target Algorithms ..................................283
     D.4. Connection Recovery Algorithms ............................283
          D.4.1. Procedure Descriptions .............................283
          D.4.2. Initiator Algorithms ...............................284
          D.4.3. Target Algorithms ..................................286
   Appendix E. Clearing Effects of Various Events on Targets ........288
     E.1. Clearing Effects on iSCSI Objects .........................288
     E.2. Clearing Effects on SCSI Objects ..........................293
   Acknowledgments ..................................................294
        
1. Introduction
1. 介绍

The Small Computer System Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. SCSI is a client-server architecture. Clients of a SCSI interface are called "initiators". Initiators issue SCSI "commands" to request services from components -- logical units of a server known as a "target". A "SCSI transport" maps the client-server SCSI protocol to a specific interconnect. An initiator is one endpoint of a SCSI transport, and a target is the other endpoint.

小型计算机系统接口(SCSI)是与I/O设备(尤其是存储设备)通信的一个流行协议系列。SCSI是一种客户机-服务器体系结构。SCSI接口的客户端称为“启动器”。启动器发出SCSI“命令”从组件请求服务——服务器的逻辑单元称为“目标”。“SCSI传输”将客户机-服务器SCSI协议映射到特定的互连。启动器是SCSI传输的一个端点,目标是另一个端点。

The SCSI protocol has been mapped over various transports, including Parallel SCSI, Intelligent Peripheral Interface (IPI), IEEE 1394 (FireWire), and Fibre Channel. These transports are I/O-specific and have limited distance capabilities.

SCSI协议已映射到各种传输,包括并行SCSI、智能外围接口(IPI)、IEEE 1394(火线)和光纤通道。这些传输是特定于I/O的,并且具有有限的距离能力。

The iSCSI protocol defined in this document describes a means of transporting SCSI packets over TCP/IP, providing for an interoperable solution that can take advantage of existing Internet infrastructure, Internet management facilities, and address distance limitations.

本文档中定义的iSCSI协议描述了通过TCP/IP传输SCSI数据包的方法,提供了一个可互操作的解决方案,该解决方案可以利用现有的Internet基础架构、Internet管理设施和解决距离限制。

2. Acronyms, Definitions, and Document Summary
2. 缩略语、定义和文档摘要
2.1. Acronyms
2.1. 缩略词
   Acronym     Definition
   --------------------------------------------------------------
   3DES        Triple Data Encryption Standard
   ACA         Auto Contingent Allegiance
   AEN         Asynchronous Event Notification
   AES         Advanced Encryption Standard
   AH          Additional Header (not the IPsec AH!)
   AHS         Additional Header Segment
   API         Application Programming Interface
   ASC         Additional Sense Code
   ASCII       American Standard Code for Information Interchange
   ASCQ        Additional Sense Code Qualifier
   ATA         AT Attachment
   BHS         Basic Header Segment
   CBC         Cipher Block Chaining
   CD          Compact Disk
   CDB         Command Descriptor Block
   CHAP        Challenge Handshake Authentication Protocol
   CID         Connection ID
   CO          Connection Only
   CRC         Cyclic Redundancy Check
   CRL         Certificate Revocation List
   CSG         Current Stage
        
   Acronym     Definition
   --------------------------------------------------------------
   3DES        Triple Data Encryption Standard
   ACA         Auto Contingent Allegiance
   AEN         Asynchronous Event Notification
   AES         Advanced Encryption Standard
   AH          Additional Header (not the IPsec AH!)
   AHS         Additional Header Segment
   API         Application Programming Interface
   ASC         Additional Sense Code
   ASCII       American Standard Code for Information Interchange
   ASCQ        Additional Sense Code Qualifier
   ATA         AT Attachment
   BHS         Basic Header Segment
   CBC         Cipher Block Chaining
   CD          Compact Disk
   CDB         Command Descriptor Block
   CHAP        Challenge Handshake Authentication Protocol
   CID         Connection ID
   CO          Connection Only
   CRC         Cyclic Redundancy Check
   CRL         Certificate Revocation List
   CSG         Current Stage
        

CSM Connection State Machine DES Data Encryption Standard DNS Domain Name Server DOI Domain of Interpretation DVD Digital Versatile Disk EDTL Expected Data Transfer Length ESP Encapsulating Security Payload EUI Extended Unique Identifier FFP Full Feature Phase FFPO Full Feature Phase Only HBA Host Bus Adapter HMAC Hashed Message Authentication Code I_T Initiator_Target I_T_L Initiator_Target_LUN IANA Internet Assigned Numbers Authority IB InfiniBand ID Identifier IDN Internationalized Domain Name IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IKE Internet Key Exchange I/O Input-Output IO Initialize Only IP Internet Protocol IPsec Internet Protocol Security IPv4 Internet Protocol Version 4 IPv6 Internet Protocol Version 6 IQN iSCSI Qualified Name iSCSI Internet SCSI iSER iSCSI Extensions for RDMA (see [RFC7145]) ISID Initiator Session ID iSNS Internet Storage Name Service (see [RFC4171]) ITN iSCSI Target Name ITT Initiator Task Tag KRB5 Kerberos V5 LFL Lower Functional Layer LTDS Logical-Text-Data-Segment LO Leading Only LU Logical Unit LUN Logical Unit Number MAC Message Authentication Code NA Not Applicable NAA Network Address Authority NIC Network Interface Card NOP No Operation NSG Next Stage OCSP Online Certificate Status Protocol OS Operating System

CSM连接状态机DES数据加密标准DNS域名服务器DOI解释域DVD数字多功能磁盘EDTL预期数据传输长度ESP封装安全有效负载EUI扩展唯一标识符FFP全功能阶段FFPO全功能阶段仅HBA主机总线适配器HMAC哈希消息身份验证代码I_T启动器I_T_L启动器I_T_L启动器I_T_LUN IANA Internet分配号码管理局IB InfiniBand ID标识符IDN国际化域名IEEE电气和电子工程师协会IETF Internet工程任务组IKE Internet密钥交换I/O输入输出IO仅初始化IP Internet协议IPsec Internet协议安全IPv4 Internet协议版本4 IPv6 Internet协议版本6 IQN iSCSI限定名称用于RDMA的iSCSI Internet SCSI iSER iSCSI扩展(请参阅[RFC7145])ISID启动器会话ID iSNS Internet存储名称服务(请参阅[RFC4171])ITN iSCSI目标名称ITT启动器任务标记KRB5 Kerberos V5 LFL较低功能层LTDS逻辑文本数据段LO仅前导LU逻辑单元LUN逻辑单元编号MAC消息身份验证代码NA不适用NAA网络地址管理机构NIC网络接口卡NOP无操作NSG下一阶段OCSP联机证书状态协议操作系统

PDU Protocol Data Unit PKI Public Key Infrastructure R2T Ready To Transfer R2TSN Ready To Transfer Sequence Number RDMA Remote Direct Memory Access RFC Request For Comments SA Security Association SAM SCSI Architecture Model SAM-2 SCSI Architecture Model - 2 SAN Storage Area Network SAS Serial Attached SCSI SATA Serial AT Attachment SCSI Small Computer System Interface SLP Service Location Protocol SN Sequence Number SNACK Selective Negative Acknowledgment - also Sequence Number Acknowledgement for data SPDTL SCSI-Presented Data Transfer Length SPKM Simple Public-Key Mechanism SRP Secure Remote Password SSID Session ID SW Session-Wide TCB Task Control Block TCP Transmission Control Protocol TMF Task Management Function TPGT Target Portal Group Tag TSIH Target Session Identifying Handle TTT Target Transfer Tag UA Unit Attention UFL Upper Functional Layer ULP Upper Level Protocol URN Uniform Resource Name UTF Universal Transformation Format WG Working Group

PDU协议数据单元PKI公钥基础设施R2T准备传输R2TSN准备传输序列号RDMA远程直接内存访问RFC征求意见SA安全协会SAM SCSI体系结构模型SAM-2 SCSI体系结构模型-2 SAN存储区域网络SAS串行连接SCSI SATA串行连接SCSI小型连接计算机系统接口SLP服务位置协议SN序列号SNAK选择性否定确认-数据序列号确认SPDTL SCSI表示的数据传输长度SPKM简单公钥机制SRP安全远程密码SSID会话ID SW会话范围TCB任务控制块TCP传输控制协议TMF任务管理功能TPGT目标门户组标记TSIH目标会话标识句柄TTT目标传输标记UA单元注意UFL上层功能层ULP上层协议URN统一资源名称UTF通用转换格式WG工作组

2.2. Definitions
2.2. 定义

- Alias: An alias string can also be associated with an iSCSI node. The alias allows an organization to associate a user-friendly string with the iSCSI name. However, the alias string is not a substitute for the iSCSI name.

- 别名:别名字符串也可以与iSCSI节点关联。别名允许组织将用户友好的字符串与iSCSI名称关联。但是,别名字符串不能替代iSCSI名称。

- CID (connection ID): Connections within a session are identified by a connection ID. It is a unique ID for this connection within the session for the initiator. It is generated by the initiator and presented to the target during Login Requests and during logouts that close connections.

- CID(连接ID):会话中的连接由连接ID标识。它是启动器会话中此连接的唯一ID。它由启动器生成,并在登录请求和关闭连接的注销期间呈现给目标。

- Connection: A connection is a TCP connection. Communication between the initiator and target occurs over one or more TCP connections. The TCP connections carry control messages, SCSI commands, parameters, and data within iSCSI Protocol Data Units (iSCSI PDUs).

- 连接:连接是TCP连接。启动器和目标之间的通信通过一个或多个TCP连接进行。TCP连接在iSCSI协议数据单元(iSCSI PDU)中承载控制消息、SCSI命令、参数和数据。

- I/O Buffer: An I/O Buffer is a buffer that is used in a SCSI read or write operation so SCSI data may be sent from or received into that buffer. For a read or write data transfer to take place for a task, an I/O Buffer is required on the initiator and at least one is required on the target.

- I/O缓冲区:I/O缓冲区是SCSI读写操作中使用的缓冲区,因此SCSI数据可以从该缓冲区发送或接收。要对任务进行读或写数据传输,启动器上需要一个I/O缓冲区,目标上至少需要一个I/O缓冲区。

- INCITS: "INCITS" stands for InterNational Committee for Information Technology Standards. The INCITS has a broad standardization scope within the field of Information and Communications Technologies (ICT), encompassing storage, processing, transfer, display, management, organization, and retrieval of information. INCITS serves as ANSI's Technical Advisory Group for the ISO/IEC Joint Technical Committee 1 (JTC 1). See <http://www.incits.org>.

- INCITS:“INCITS”代表国际信息技术标准委员会。INCITS在信息和通信技术(ICT)领域具有广泛的标准化范围,包括信息的存储、处理、传输、显示、管理、组织和检索。INCITS作为ANSI的ISO/IEC联合技术委员会1(JTC 1)技术咨询小组。看<http://www.incits.org>.

- InfiniBand: InfiniBand is an I/O architecture originally intended to replace Peripheral Component Interconnect (PCI) and address high-performance server interconnectivity [IB].

- InfiniBand:InfiniBand是一种I/O体系结构,最初旨在取代外围组件互连(PCI)并解决高性能服务器互连[IB]。

- iSCSI Device: An iSCSI device is a SCSI device using an iSCSI service delivery subsystem. The Service Delivery Subsystem is defined by [SAM2] as a transport mechanism for SCSI commands and responses.

- iSCSI设备:iSCSI设备是使用iSCSI服务提供子系统的SCSI设备。[SAM2]将服务交付子系统定义为SCSI命令和响应的传输机制。

- iSCSI Initiator Name: The iSCSI Initiator Name specifies the worldwide unique name of the initiator.

- iSCSI启动器名称:iSCSI启动器名称指定启动器的全球唯一名称。

- iSCSI Initiator Node: An iSCSI initiator node is the "initiator" device. The word "initiator" has been appropriately qualified as either a port or a device in the rest of the document when the context is ambiguous. All unqualified usages of "initiator" refer to an initiator port (or device), depending on the context.

- iSCSI启动器节点:iSCSI启动器节点是“启动器”设备。当上下文不明确时,“启动器”一词在文档的其余部分被适当地限定为端口或设备。“启动器”的所有非限定用法均指启动器端口(或设备),具体取决于上下文。

- iSCSI Layer: This layer builds/receives iSCSI PDUs and relays/receives them to/from one or more TCP connections that form an initiator-target "session".

- iSCSI层:该层构建/接收iSCSI PDU,并将其中继/接收到形成启动器目标“会话”的一个或多个TCP连接。

- iSCSI Name: This is the name of an iSCSI initiator or iSCSI target.

- iSCSI名称:这是iSCSI启动器或iSCSI目标的名称。

- iSCSI Node: The iSCSI node represents a single iSCSI initiator or iSCSI target, or a single instance of each. There are one or more iSCSI nodes within a Network Entity. The iSCSI node is accessible via one or more Network Portals. An iSCSI node is identified by

- iSCSI节点:iSCSI节点表示单个iSCSI启动器或iSCSI目标,或每个iSCSI启动器或目标的单个实例。网络实体中有一个或多个iSCSI节点。iSCSI节点可通过一个或多个网络入口访问。iSCSI节点由以下项标识:

its iSCSI name. The separation of the iSCSI name from the addresses used by and for the iSCSI node allows multiple iSCSI nodes to use the same address and the same iSCSI node to use multiple addresses.

它的iSCSI名称。将iSCSI名称与iSCSI节点使用的地址分离,允许多个iSCSI节点使用同一地址,而同一iSCSI节点使用多个地址。

- iSCSI Target Name: The iSCSI Target Name specifies the worldwide unique name of the target.

- iSCSI目标名称:iSCSI目标名称指定目标的全球唯一名称。

- iSCSI Target Node: The iSCSI target node is the "target" device. The word "target" has been appropriately qualified as either a port or a device in the rest of the document when the context is ambiguous. All unqualified usages of "target" refer to a target port (or device), depending on the context.

- iSCSI目标节点:iSCSI目标节点是“目标”设备。当上下文不明确时,“target”一词在文档的其余部分被适当地限定为端口或设备。“target”的所有非限定用法均指目标端口(或设备),具体取决于上下文。

- iSCSI Task: An iSCSI task is an iSCSI request for which a response is expected.

- iSCSI任务:iSCSI任务是预期响应的iSCSI请求。

- iSCSI Transfer Direction: The iSCSI transfer direction is defined with regard to the initiator. Outbound or outgoing transfers are transfers from the initiator to the target, while inbound or incoming transfers are from the target to the initiator.

- iSCSI传输方向:iSCSI传输方向是针对启动器定义的。出站或传出传输是从启动器到目标的传输,而入站或传入传输是从目标到启动器的传输。

- ISID: The ISID is the initiator part of the session identifier. It is explicitly specified by the initiator during login.

- ISID:ISID是会话标识符的发起方部分。它由启动器在登录期间显式指定。

- I_T Nexus: According to [SAM2], the I_T nexus is a relationship between a SCSI initiator port and a SCSI target port. For iSCSI, this relationship is a session, defined as a relationship between an iSCSI initiator's end of the session (SCSI initiator port) and the iSCSI target's portal group. The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + ',i,' + ISID, iSCSI Target Name + ',t,' + Target Portal Group Tag).

- I_T Nexus:根据[SAM2],I_T Nexus是SCSI启动器端口和SCSI目标端口之间的关系。对于iSCSI,此关系是一个会话,定义为iSCSI启动器的会话结束(SCSI启动器端口)与iSCSI目标的入口组之间的关系。I_T nexus可以通过连接SCSI端口名来识别;也就是说,I_T nexus标识符是元组(iSCSI启动器名称+”,I,“+ISID,iSCSI目标名称+”,T,“+目标门户组标记)。

- I_T_L Nexus: An I_T_L nexus is a SCSI concept and is defined as the relationship between a SCSI initiator port, a SCSI target port, and a Logical Unit (LU).

- I_T_L Nexus:I_T_L Nexus是一个SCSI概念,定义为SCSI启动器端口、SCSI目标端口和逻辑单元(LU)之间的关系。

- NAA: "NAA" refers to Network Address Authority, a naming format defined by the INCITS T11 Fibre Channel protocols [FC-FS3].

- NAA:“NAA”指网络地址授权,是由INCITS T11光纤通道协议[FC-FS3]定义的命名格式。

- Network Entity: The Network Entity represents a device or gateway that is accessible from the IP network. A Network Entity must have one or more Network Portals, each of which can be used to gain access to the IP network by some iSCSI nodes contained in that Network Entity.

- 网络实体:网络实体表示可从IP网络访问的设备或网关。一个网络实体必须有一个或多个网络入口,每个入口都可用于通过该网络实体中包含的某些iSCSI节点访问IP网络。

- Network Portal: The Network Portal is a component of a Network Entity that has a TCP/IP network address and that may be used by an iSCSI node within that Network Entity for the connection(s) within one of its iSCSI sessions. A Network Portal in an initiator is identified by its IP address. A Network Portal in a target is identified by its IP address and its listening TCP port.

- 网络入口:网络入口是具有TCP/IP网络地址的网络实体的一个组件,该网络实体内的iSCSI节点可使用该网络实体的一个iSCSI会话内的连接。启动器中的网络入口由其IP地址标识。目标中的网络入口由其IP地址和侦听TCP端口标识。

- Originator: In a negotiation or exchange, the originator is the party that initiates the negotiation or exchange.

- 发起人:在谈判或交换中,发起人是发起谈判或交换的一方。

- PDU (Protocol Data Unit): The initiator and target divide their communications into messages. The term "iSCSI Protocol Data Unit" (iSCSI PDU) is used for these messages.

- PDU(协议数据单元):发起方和目标方将其通信划分为消息。术语“iSCSI协议数据单元”(iSCSI PDU)用于这些消息。

- Portal Groups: iSCSI supports multiple connections within the same session; some implementations will have the ability to combine connections in a session across multiple Network Portals. A portal group defines a set of Network Portals within an iSCSI Network Entity that collectively supports the capability of coordinating a session with connections spanning these portals. Not all Network Portals within a portal group need participate in every session connected through that portal group. One or more portal groups may provide access to an iSCSI node. Each Network Portal, as utilized by a given iSCSI node, belongs to exactly one portal group within that node.

- 门户组:iSCSI支持同一会话中的多个连接;一些实现将能够在跨多个网络门户的会话中组合连接。门户组定义了iSCSI网络实体内的一组网络门户,这些门户共同支持通过跨这些门户的连接协调会话的功能。并非门户组中的所有网络门户都需要参与通过该门户组连接的每个会话。一个或多个门户组可以提供对iSCSI节点的访问。给定iSCSI节点使用的每个网络入口都只属于该节点内的一个入口组。

- Portal Group Tag: This 16-bit quantity identifies a portal group within an iSCSI node. All Network Portals with the same Portal Group Tag in the context of a given iSCSI node are in the same portal group.

- 门户组标记:此16位数量标识iSCSI节点内的门户组。给定iSCSI节点上下文中具有相同门户组标记的所有网络门户都位于同一门户组中。

- Recovery R2T: A recovery R2T is an R2T generated by a target upon detecting the loss of one or more Data-Out PDUs through one of the following means: a digest error, a sequence error, or a sequence reception timeout. A recovery R2T carries the next unused R2TSN but requests all or part of the data burst that an earlier R2T (with a lower R2TSN) had already requested.

- 恢复R2T:恢复R2T是目标通过以下方式之一检测到一个或多个数据输出PDU丢失时生成的R2T:摘要错误、序列错误或序列接收超时。恢复R2T携带下一个未使用的R2TSN,但请求早期R2T(具有较低R2TSN)已请求的全部或部分数据突发。

- Responder: In a negotiation or exchange, the responder is the party that responds to the originator of the negotiation or exchange.

- 响应者:在谈判或交换中,响应者是响应谈判或交换发起人的一方。

- SAS: The Serial Attached SCSI (SAS) standard contains both a physical layer compatible with Serial ATA, and protocols for transporting SCSI commands to SAS devices and ATA commands to SATA devices [SAS] [SPL].

- SAS:串行连接SCSI(SAS)标准包含与串行ATA兼容的物理层,以及用于将SCSI命令传输到SAS设备和ATA命令传输到SATA设备的协议[SAS][SPL]。

- SCSI Device: This is the SAM-2 term for an entity that contains one or more SCSI ports that are connected to a service delivery subsystem and supports a SCSI application protocol. For example, a SCSI initiator device contains one or more SCSI initiator ports and zero or more application clients. A target device contains one or more SCSI target ports and one or more device servers and associated LUs. For iSCSI, the SCSI device is the component within an iSCSI node that provides the SCSI functionality. As such, there can be at most one SCSI device within a given iSCSI node. Access to the SCSI device can only be achieved in an iSCSI Normal operational session. The SCSI device name is defined to be the iSCSI name of the node.

- SCSI设备:这是SAM-2术语,表示包含一个或多个连接到服务交付子系统并支持SCSI应用程序协议的SCSI端口的实体。例如,SCSI启动器设备包含一个或多个SCSI启动器端口和零个或多个应用程序客户端。目标设备包含一个或多个SCSI目标端口、一个或多个设备服务器和关联的LU。对于iSCSI,SCSI设备是iSCSI节点中提供SCSI功能的组件。因此,给定iSCSI节点中最多可以有一个SCSI设备。只能在iSCSI正常操作会话中访问SCSI设备。SCSI设备名称定义为节点的iSCSI名称。

- SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor Blocks) and relays/receives them with the remaining Execute Command [SAM2] parameters to/from the iSCSI Layer.

- SCSI层:该层构建/接收SCSI CDB(命令描述符块),并将它们与剩余的Execute Command[SAM2]参数一起中继/接收到iSCSI层。

- Session: The group of TCP connections that link an initiator with a target form a session (loosely equivalent to a SCSI I_T nexus). TCP connections can be added and removed from a session. Across all connections within a session, an initiator sees one and the same target.

- 会话:连接发起方和目标的TCP连接组,形成会话(大致相当于SCSI I_T nexus)。可以在会话中添加和删除TCP连接。在会话中的所有连接中,启动器都会看到同一个目标。

- SCSI Port: This is the SAM-2 term for an entity in a SCSI device that provides the SCSI functionality to interface with a service delivery subsystem. For iSCSI, the definitions of the SCSI initiator port and the SCSI target port are different.

- SCSI端口:这是SAM-2术语,表示SCSI设备中提供SCSI功能以与服务交付子系统接口的实体。对于iSCSI,SCSI启动器端口和SCSI目标端口的定义不同。

- SCSI Initiator Port: This maps to the endpoint of an iSCSI Normal operational session. An iSCSI Normal operational session is negotiated through the login process between an iSCSI initiator node and an iSCSI target node. At successful completion of this process, a SCSI initiator port is created within the SCSI initiator device. The SCSI initiator port name and SCSI initiator port identifier are both defined to be the iSCSI Initiator Name together with (a) a label that identifies it as an initiator port name/identifier and (b) the ISID portion of the session identifier.

- SCSI启动器端口:该端口映射到iSCSI正常操作会话的端点。iSCSI正常操作会话通过iSCSI启动器节点和iSCSI目标节点之间的登录过程进行协商。成功完成此过程后,将在SCSI启动器设备中创建SCSI启动器端口。SCSI启动器端口名称和SCSI启动器端口标识符都定义为iSCSI启动器名称,以及(a)将其标识为启动器端口名称/标识符的标签和(b)会话标识符的ISID部分。

- SCSI Port Name: This is a name consisting of UTF-8 [RFC3629] encoding of Unicode [UNICODE] characters and includes the iSCSI name + 'i' or 't' + ISID or Target Portal Group Tag.

- SCSI端口名:此名称由Unicode[Unicode]字符的UTF-8[RFC3629]编码组成,包括iSCSI名称+“i”或“t”+ISID或目标门户组标记。

- SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the aggregate data length of the data that the SCSI layer logically "presents" to the iSCSI layer for a Data-In or Data-Out transfer in the context of a SCSI task. For a bidirectional task, there are two SPDTL values -- one for Data-In and one for Data-Out. Note that the notion of "presenting" includes immediate data per the data

- SCSI呈现数据传输长度(SPDTL):SPDTL是SCSI层在SCSI任务上下文中为数据输入或数据输出传输逻辑“呈现”给iSCSI层的数据的聚合数据长度。对于双向任务,有两个SPDTL值——一个用于数据输入,一个用于数据输出。请注意,“呈现”的概念包括每个数据的即时数据

transfer model in [SAM2] and excludes overlapping data transfers, if any, requested by the SCSI layer.

[SAM2]中的传输模型,并排除SCSI层请求的重叠数据传输(如果有)。

- SCSI Target Port: This maps to an iSCSI target portal group.

- SCSI目标端口:此端口映射到iSCSI目标门户组。

- SCSI Target Port Name and SCSI Target Port Identifier: These are both defined to be the iSCSI Target Name together with (a) a label that identifies it as a target port name/identifier and (b) the Target Portal Group Tag.

- SCSI目标端口名称和SCSI目标端口标识符:它们都被定义为iSCSI目标名称以及(a)将其标识为目标端口名称/标识符的标签和(b)目标门户组标记。

- SSID (Session ID): A session between an iSCSI initiator and an iSCSI target is defined by a session ID that is a tuple composed of an initiator part (ISID) and a target part (Target Portal Group Tag). The ISID is explicitly specified by the initiator at session establishment. The Target Portal Group Tag is implied by the initiator through the selection of the TCP endpoint at connection establishment. The TargetPortalGroupTag key must also be returned by the target as a confirmation during connection establishment.

- SSID(会话ID):iSCSI启动器和iSCSI目标之间的会话由会话ID定义,会话ID是由启动器部分(ISID)和目标部分(目标门户组标记)组成的元组。ISID由发起方在会话建立时明确指定。发起方通过在连接建立时选择TCP端点来暗示目标门户组标记。在建立连接期间,目标还必须返回TargetPortalGroupTag密钥作为确认。

- T10: T10 is a technical committee within INCITS that develops standards and technical reports on I/O interfaces, particularly the series of SCSI (Small Computer System Interface) standards. See <http://www.t10.org>.

- T10:T10是INCITS内部的一个技术委员会,负责制定I/O接口的标准和技术报告,特别是SCSI(小型计算机系统接口)系列标准。看<http://www.t10.org>.

- T11: T11 is a technical committee within INCITS responsible for standards development in the areas of Intelligent Peripheral Interface (IPI), High-Performance Parallel Interface (HIPPI), and Fibre Channel (FC). See <http://www.t11.org>.

- T11:T11是INCITS内部的一个技术委员会,负责智能外围接口(IPI)、高性能并行接口(HIPPI)和光纤通道(FC)领域的标准开发。看<http://www.t11.org>.

- Target Portal Group Tag: This is a numerical identifier (16-bit) for an iSCSI target portal group.

- 目标门户组标记:这是iSCSI目标门户组的数字标识符(16位)。

- Target Transfer Tag (TTT): The TTT is an iSCSI protocol field used in a few iSCSI PDUs (e.g., R2T, NOP-In) that is always sent from the target to the initiator first and then quoted as a reference in initiator-sent PDUs back to the target relating to the same task/exchange. Therefore, the TTT effectively acts as an opaque handle to an existing task/exchange to help the target associate the incoming PDUs from the initiator to the proper execution context.

- 目标传输标签(TTT):TTT是几个iSCSI PDU(例如R2T、NOP in)中使用的iSCSI协议字段,总是先从目标发送到启动器,然后在启动器发送的PDU中引用为与同一任务/交换相关的目标。因此,TTT有效地充当现有任务/交换的不透明句柄,以帮助目标将来自启动器的传入PDU关联到适当的执行上下文。

- Third-party: This term is used in this document as a qualifier to nexus objects (I_T or I_T_L) and iSCSI sessions, to indicate that these objects and sessions reap the side effects of actions that take place in the context of a separate iSCSI session. One example of a third-party session is an iSCSI session discovering that its I_T_L nexus to a LU got reset due to a LU reset operation orchestrated via a separate I_T nexus.

- 第三方:此术语在本文档中用作nexus对象(I_T或I_T_L)和iSCSI会话的限定词,以表示这些对象和会话获得在单独iSCSI会话上下文中发生的操作的副作用。第三方会话的一个示例是iSCSI会话,该会话发现其与LU的I__L连接由于通过单独的I_T连接进行的LU重置操作而被重置。

- TSIH (Target Session Identifying Handle): This is a target-assigned tag for a session with a specific named initiator. The target generates it during session establishment. Other than defining it as a 16-bit binary string, its internal format and content are not defined by this protocol but for the value with all bits set to 0 that is reserved and used by the initiator to indicate a new session. It is given to the target during additional connection establishment for the same session.

- TSIH(目标会话标识句柄):这是为具有特定命名启动器的会话分配的目标标记。目标在会话建立期间生成它。除了将其定义为16位二进制字符串外,其内部格式和内容不由本协议定义,而是针对所有位均设置为0的值,该值由启动器保留并用于指示新会话。在同一会话的附加连接建立过程中,会将其提供给目标。

2.3. Summary of Changes
2.3. 更改摘要

1) Consolidated RFCs 3720, 3980, 4850, and 5048, and made the necessary editorial changes.

1) 合并了RFC 3720、3980、4850和5048,并进行了必要的编辑更改。

2) Specified iSCSIProtocolLevel as "1" in Section 13.24 and added a related normative reference to [RFC7144].

2) 在第13.24节中将iSCSIProtocolLevel指定为“1”,并在[RFC7144]中添加了相关的规范性参考。

3) Removed markers and related keys.

3) 删除标记和相关键。

4) Removed SPKM authentication and related keys.

4) 已删除SPKM身份验证和相关密钥。

5) Added a new Section 13.25 on responding to obsoleted keys.

5) 新增第13.25节“对废弃钥匙的响应”。

6) Have explicitly allowed initiator+target implementations throughout the text.

6) 在全文中明确允许启动器+目标实现。

7) Clarified in Section 4.2.7 that implementations SHOULD NOT rely on SLP-based discovery.

7) 在第4.2.7节中阐明,实现不应依赖于基于SLP的发现。

8) Added Unified Modeling Language (UML) diagrams and related conventions in Section 3.

8) 在第3节中添加了统一建模语言(UML)图和相关约定。

9) Made FastAbort implementation a "SHOULD" requirement in Section 4.2.3.4, rather than the previous "MUST" requirement.

9) 使FastAbort实施成为第4.2.3.4节中的“应该”要求,而不是之前的“必须”要求。

10) Required in Section 4.2.7.1 that iSCSI Target Name be the same as iSCSI Initiator Name for SCSI (composite) devices with both roles.

10) 第4.2.7.1节要求iSCSI目标名称与具有两个角色的SCSI(复合)设备的iSCSI启动器名称相同。

11) Changed the "MUST NOT" to "should be avoided" in Section 4.2.7.2 regarding usage of characters such as punctuation marks in iSCSI names.

11) 将第4.2.7.2节中有关iSCSI名称中标点符号等字符用法的“不得”更改为“应避免”。

12) Updated Section 9.3 to require the following: MUST implement IPsec, 2400-series RFCs (IPsec v2, IKEv1); and SHOULD implement IPsec, 4300-series RFCs (IPsec v3, IKEv2).

12) 更新了第9.3节,要求如下:必须实施IPsec,2400系列RFC(IPsec v2,IKEv1);并且应该实现IPsec,4300系列RFC(IPSecv3,IKEv2)。

13) Clarified in Section 10.2 that ACA is a "SHOULD" only for iSCSI targets.

13) 在第10.2节中阐明,ACA仅适用于iSCSI目标。

14) Prohibited usage of X# name prefix for new public keys in Section 6.2.

14) 第6.2节禁止为新公钥使用X#名称前缀。

15) Prohibited usage of Y# name prefix for new digest extensions in Section 13.1 and Z# name prefix for new authentication method extensions in Section 12.1.

15) 禁止在第13.1节中为新摘要扩展使用Y#名称前缀,在第12.1节中为新身份验证方法扩展使用Z#名称前缀。

16) Added a "SHOULD" in Section 6.2 that initiators and targets support at least six (6) exchanges during text negotiation.

16) 在第6.2节中增加了一个“应该”,即发起人和目标人在文本协商期间至少支持六(6)次交换。

17) Added a clarification that Appendix C is normative.

17) 增加了附录C为规范性附录的澄清。

18) Added a normative requirement on [RFC7146] and made a few related changes in Section 9.3 to align the text in this document with that of [RFC7146].

18) 增加了[RFC7146]的规范性要求,并在第9.3节中进行了一些相关更改,以使本文件中的文本与[RFC7146]的文本保持一致。

19) Added a new Section 9.2.3 covering Kerberos authentication considerations.

19) 添加了一个新的第9.2.3节,涵盖Kerberos身份验证注意事项。

20) Added text in Section 9.3.3 noting that OCSP is now allowed for checking certificates used with IPsec in addition to the use of CRLs.

20) 在第9.3.3节中添加了文本,指出除了使用CRL之外,OCSP现在还允许检查与IPsec一起使用的证书。

21) Added text in Section 9.3.1 specifying that extended sequence numbers (ESNs) are now required for ESPv2 (part of IPsec v2).

21)在第9.3.1节中添加了文本,规定ESPv2(IPsec v2的一部分)现在需要扩展序列号(ESN)。

2.4. Conventions
2.4. 习俗

In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator and target, respectively.

在示例中,“I->”和“T->”分别显示启动器和目标发送的iSCSI PDU。

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

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。

3. UML Conventions
3. UML约定
3.1. UML Conventions Overview
3.1. UML约定概述

The SCSI Architecture Model (SAM) uses class diagrams and object diagrams with notation that is based on the Unified Modeling Language [UML]. Therefore, this document also uses UML to model the relationships for SCSI and iSCSI objects.

SCSI体系结构模型(SAM)使用基于统一建模语言[UML]的带有符号的类图和对象图。因此,本文档还使用UML为SCSI和iSCSI对象的关系建模。

A treatise on the graphical notation used in UML is beyond the scope of this document. However, given the use of ASCII drawing for UML static class diagrams, a description of the notational conventions used in this document is included in the remainder of this section.

关于UML中使用的图形符号的论述超出了本文档的范围。然而,鉴于UML静态类图使用ASCII绘图,本节的其余部分将介绍本文档中使用的符号约定。

3.2. Multiplicity Notion
3.2. 多重性概念

Not specified The number of instances of an attribute is not specified.

未指定未指定属性的实例数。

1 One instance of the class or attribute exists.

1该类或属性存在一个实例。

0..* Zero or more instances of the class or attribute exist.

0..*存在零个或多个类或属性实例。

1..* One or more instances of the class or attribute exist.

1..*存在类或属性的一个或多个实例。

0..1 Zero or one instance of the class or attribute exists.

0..1存在零个或一个类或属性实例。

n..m n to m instances of the class or attribute exist (e.g., 2..8).

n、 .m存在类或属性的n到m个实例(例如,2..8)。

x, n..m Multiple disjoint instances of the class or attribute exist (e.g., 2, 8..15).

x、 n..m类或属性存在多个不相交的实例(例如,2、8..15)。

3.3. Class Diagram Conventions
3.3. 类图约定
     +--------------+    +--------------+       +--------------+
     |  Class Name  |    |  Class Name  |       |  Class Name  |
     +--------------+    +--------------+       +--------------+
     |              |    |              |
     +--------------+    +--------------+
     |              |
     +--------------+
        
     +--------------+    +--------------+       +--------------+
     |  Class Name  |    |  Class Name  |       |  Class Name  |
     +--------------+    +--------------+       +--------------+
     |              |    |              |
     +--------------+    +--------------+
     |              |
     +--------------+
        

The previous three diagrams are examples of a class with no attributes and with no operations.

前三个图是没有属性和操作的类的示例。

     +-------------------+    +-------------------+
     |    Class Name     |    |    Class Name     |
     +-------------------+    +-------------------+
     | attribute 01[1]   |    |   attribute 01[1] |
     | attribute 02[1]   |    |   attribute 02[1] |
     +-------------------+    +-------------------+
     |                   |
     +-------------------+
        
     +-------------------+    +-------------------+
     |    Class Name     |    |    Class Name     |
     +-------------------+    +-------------------+
     | attribute 01[1]   |    |   attribute 01[1] |
     | attribute 02[1]   |    |   attribute 02[1] |
     +-------------------+    +-------------------+
     |                   |
     +-------------------+
        

The preceding two diagrams are examples of a class with attributes and with no operations.

前面的两个图是具有属性但没有操作的类的示例。

     +------------------------+
     |      Class Name        |
     +------------------------+
     |    attribute 01[1..*]  |
     |    attribute 02[1]     |
     +------------------------+
     |    operation 01()      |
     |    operation 02()      |
     +------------------------+
        
     +------------------------+
     |      Class Name        |
     +------------------------+
     |    attribute 01[1..*]  |
     |    attribute 02[1]     |
     +------------------------+
     |    operation 01()      |
     |    operation 02()      |
     +------------------------+
        

The preceding diagram is an example of a class with attributes that have a specified multiplicity and operations.

上图是一个类的示例,该类的属性具有指定的多重性和操作。

3.4. Class Diagram Notation for Associations
3.4. 关联的类图表示法
     +-----------------+
     |     Class A     |
     +-----------------+ association_name   +-----------------+
     | attribute 01[1] |<------------------>|     Class B     |
     | attribute 02[1] | 1..*          0..1 +-----------------+
     +-----------------+                    | attribute 03[1] |
     | operation 1()   |                    +-----------------+
     +-----------------+
        
     +-----------------+
     |     Class A     |
     +-----------------+ association_name   +-----------------+
     | attribute 01[1] |<------------------>|     Class B     |
     | attribute 02[1] | 1..*          0..1 +-----------------+
     +-----------------+                    | attribute 03[1] |
     | operation 1()   |                    +-----------------+
     +-----------------+
        

The preceding diagram is an example where Class A knows about Class B (i.e., read as "Class A association_name Class B") and Class B knows about Class A (i.e., read as "Class B association_name Class A"). The use of association_name is optional. The multiplicity notation (1..* and 0..1) indicates the number of instances of the object.

上图是一个示例,其中类别A了解类别B(即,读作“类别A关联\名称类别B”),类别B了解类别A(即,读作“类别B关联\名称类别A”)。关联名称的使用是可选的。多重性表示法(1..*和0..1)表示对象的实例数。

     +--------------------+
     |      Class A       |
     +--------------------+              +--------------------+
     | attribute 01[1]    |<-------------|      Class B       |
     | attribute 02[1]    | 1      0..1  +--------------------+
     +--------------------+              | attribute 03[1]    |
     | operation 1()      |              +--------------------+
     +--------------------+
        
     +--------------------+
     |      Class A       |
     +--------------------+              +--------------------+
     | attribute 01[1]    |<-------------|      Class B       |
     | attribute 02[1]    | 1      0..1  +--------------------+
     +--------------------+              | attribute 03[1]    |
     | operation 1()      |              +--------------------+
     +--------------------+
        

The preceding diagram is an example where Class B knows about Class A (i.e., read as "Class B knows about Class A") but Class A does not know about Class B.

上图是一个示例,其中B类知道A类(即,读作“B类知道A类”),但A类不知道B类。

     +----------------------+
     |       Class A        |
     +----------------------+            +--------------------+
     |   attribute 01[1]    |----------->|      Class B       |
     |   attribute 02[1]    | 0..*     1 +--------------------+
     +----------------------+            | attribute 03[1]    |
     |    operation 1()     |            +--------------------+
     +----------------------+
        
     +----------------------+
     |       Class A        |
     +----------------------+            +--------------------+
     |   attribute 01[1]    |----------->|      Class B       |
     |   attribute 02[1]    | 0..*     1 +--------------------+
     +----------------------+            | attribute 03[1]    |
     |    operation 1()     |            +--------------------+
     +----------------------+
        

The preceding diagram is an example where Class A knows about Class B (i.e., read as "Class A knows about Class B") but Class B does not know about Class A.

上图是一个示例,其中A类了解B类(即,读作“A类了解B类”),但B类不了解A类。

3.5. Class Diagram Notation for Aggregations
3.5. 聚合的类图表示法
     +---------------+             +--------------+
     |  Class whole  |o------------|  Class part  |
     +---------------+             +--------------+
        
     +---------------+             +--------------+
     |  Class whole  |o------------|  Class part  |
     +---------------+             +--------------+
        

The preceding diagram is an example where Class whole is an aggregate that contains Class part and where Class part may continue to exist even if Class whole is removed (i.e., read as "the whole contains the part").

前面的图表是一个示例,其中类整体是包含类部分的聚合,并且即使删除了类整体(即,读作“整体包含部分”),类部分也可能继续存在。

     +---------------+             +--------------+
     |  Class whole  |@------------|  Class part  |
     +---------------+             +--------------+
        
     +---------------+             +--------------+
     |  Class whole  |@------------|  Class part  |
     +---------------+             +--------------+
        

The preceding diagram is an example where Class whole is an aggregate that contains Class part where Class part only belongs to one Class whole, and the Class part does not continue to exist if the Class whole is removed (i.e., read as "the whole contains the part").

上图是一个示例,其中类整体是一个包含类部分的聚合,其中类部分仅属于一个类整体,如果类整体被删除(即,读作“整体包含部分”),则类部分不会继续存在。

     +-------------+
     |             |
     +-------------+
        |       |
        + =(a)= +
        |       |
        
     +-------------+
     |             |
     +-------------+
        |       |
        + =(a)= +
        |       |
        

The preceding diagram is an example where there is a constraint between the associations, where the (a) footnote describes the constraint.

上图是关联之间存在约束的示例,(a)脚注描述了约束。

3.6. Class Diagram Notation for Generalizations
3.6. 用于泛化的类图表示法
     +---------------+
     |  Superclass   |
     +-------^-------+
            /_\
             |
     +---------------+
     |    Subclass   |
     +---------------+
        
     +---------------+
     |  Superclass   |
     +-------^-------+
            /_\
             |
     +---------------+
     |    Subclass   |
     +---------------+
        

The preceding diagram is an example where the subclass is a kind of superclass. A subclass shares all the attributes and operations of the superclass (i.e., the subclass inherits from the superclass).

上图是一个例子,其中子类是一种超类。子类共享超类的所有属性和操作(即,子类继承自超类)。

4. Overview
4. 概述
4.1. SCSI Concepts
4.1. SCSI概念

The SCSI Architecture Model - 2 [SAM2] describes in detail the architecture of the SCSI family of I/O protocols. This section provides a brief background of the SCSI architecture and is intended to familiarize readers with its terminology.

SCSI体系结构模型-2[SAM2]详细描述了SCSI系列I/O协议的体系结构。本节简要介绍SCSI体系结构的背景知识,旨在使读者熟悉其术语。

At the highest level, SCSI is a family of interfaces for requesting services from I/O devices, including hard drives, tape drives, CD and DVD drives, printers, and scanners. In SCSI terminology, an individual I/O device is called a "logical unit" (LU).

在最高级别,SCSI是一系列接口,用于从I/O设备(包括硬盘驱动器、磁带驱动器、CD和DVD驱动器、打印机和扫描仪)请求服务。在SCSI术语中,单个I/O设备称为“逻辑单元”(LU)。

SCSI is a client-server architecture. Clients of a SCSI interface are called "initiators". Initiators issue SCSI "commands" to request services from components -- LUs of a server known as a "target". The "device server" on the LU accepts SCSI commands and processes them.

SCSI是一种客户机-服务器体系结构。SCSI接口的客户端称为“启动器”。启动器发出SCSI“命令”以请求来自组件的服务,这些组件是服务器的LU,称为“目标”。LU上的“设备服务器”接受SCSI命令并对其进行处理。

A "SCSI transport" maps the client-server SCSI protocol to a specific interconnect. The initiator is one endpoint of a SCSI transport. The "target" is the other endpoint. A target can contain multiple LUs. Each LU has an address within a target called a Logical Unit Number (LUN).

“SCSI传输”将客户机-服务器SCSI协议映射到特定的互连。启动器是SCSI传输的一个端点。“目标”是另一个端点。一个目标可以包含多个逻辑单元。每个LU在目标中都有一个称为逻辑单元号(LUN)的地址。

A SCSI task is a SCSI command or possibly a linked set of SCSI commands. Some LUs support multiple pending (queued) tasks, but the queue of tasks is managed by the LU. The target uses an initiator-provided "task tag" to distinguish between tasks. Only one command in a task can be outstanding at any given time.

SCSI任务是一个SCSI命令,也可能是一组链接的SCSI命令。某些LU支持多个挂起(排队)任务,但任务队列由LU管理。目标使用启动器提供的“任务标记”来区分任务。在任何给定时间,任务中只能有一条命令处于未完成状态。

Each SCSI command results in an optional data phase and a required response phase. In the data phase, information can travel from the initiator to the target (e.g., write), from the target to the initiator (e.g., read), or in both directions. In the response phase, the target returns the final status of the operation, including any errors.

每个SCSI命令都会导致可选的数据阶段和所需的响应阶段。在数据阶段,信息可以从启动器传输到目标(例如写入),从目标传输到启动器(例如读取),或者双向传输。在响应阶段,目标返回操作的最终状态,包括任何错误。

Command Descriptor Blocks (CDBs) are the data structures used to contain the command parameters that an initiator sends to a target. The CDB content and structure are defined by [SAM2] and device-type specific SCSI standards.

命令描述符块(CDB)是用于包含启动器发送到目标的命令参数的数据结构。CDB内容和结构由[SAM2]和特定于设备类型的SCSI标准定义。

4.2. iSCSI Concepts and Functional Overview
4.2. iSCSI概念和功能概述

The iSCSI protocol is a mapping of the SCSI command, event, and task management model (see [SAM2]) over the TCP protocol. SCSI commands are carried by iSCSI requests, and SCSI responses and status are carried by iSCSI responses. iSCSI also uses the request-response mechanism for iSCSI protocol mechanisms.

iSCSI协议是SCSI命令、事件和任务管理模型(请参见[SAM2])在TCP协议上的映射。SCSI命令由iSCSI请求承载,SCSI响应和状态由iSCSI响应承载。iSCSI还将请求-响应机制用于iSCSI协议机制。

For the remainder of this document, the terms "initiator" and "target" refer to "iSCSI initiator node" and "iSCSI target node", respectively (see iSCSI), unless otherwise qualified.

在本文档的其余部分中,术语“启动器”和“目标”分别指“iSCSI启动器节点”和“iSCSI目标节点”(请参阅iSCSI),除非另有限定。

As its title suggests, Section 4 presents an overview of the iSCSI concepts, and later sections in the rest of the specification contain the normative requirements -- in many cases covering the same concepts discussed in Section 4. Such normative requirements text overrides the overview text in Section 4 if there is a disagreement between the two.

正如其标题所示,第4节概述了iSCSI概念,本规范其余部分的后续章节包含了规范性要求——在许多情况下涵盖了第4节中讨论的相同概念。如果第4节中的概述文本与规范性要求文本之间存在分歧,则此类规范性要求文本优先于概述文本。

In keeping with similar protocols, the initiator and target divide their communications into messages. This document uses the term "iSCSI Protocol Data Unit" (iSCSI PDU) for these messages.

按照类似的协议,发起方和目标方将其通信划分为消息。本文档对这些消息使用术语“iSCSI协议数据单元”(iSCSI PDU)。

For performance reasons, iSCSI allows a "phase-collapse". A command and its associated data may be shipped together from initiator to target, and data and responses may be shipped together from targets.

出于性能原因,iSCSI允许“阶段崩溃”。命令及其相关数据可以从启动器一起发送到目标,数据和响应可以从目标一起发送。

The iSCSI transfer direction is defined with respect to the initiator. Outbound or outgoing transfers are transfers from an initiator to a target, while inbound or incoming transfers are from a target to an initiator.

iSCSI传输方向是针对启动器定义的。出站或传出传输是从启动器到目标的传输,而入站或传入传输是从目标到启动器的传输。

An iSCSI task is an iSCSI request for which a response is expected.

iSCSI任务是需要响应的iSCSI请求。

In this document, "iSCSI request", "iSCSI command", request, or (unqualified) command have the same meaning. Also, unless otherwise specified, status, response, or numbered response have the same meaning.

在本文档中,“iSCSI请求”、“iSCSI命令”、“请求”或(不合格)命令具有相同的含义。此外,除非另有规定,否则状态、响应或编号响应具有相同的含义。

4.2.1. Layers and Sessions
4.2.1. 层和会话

The following conceptual layering model is used to specify initiator and target actions and the way in which they relate to transmitted and received Protocol Data Units:

以下概念分层模型用于指定启动器和目标操作,以及它们与传输和接收的协议数据单元的关联方式:

- The SCSI layer builds/receives SCSI CDBs (Command Descriptor Blocks) and passes/receives them with the remaining Execute Command [SAM2] parameters to/from

- SCSI层构建/接收SCSI CDB(命令描述符块),并将它们与剩余的Execute Command[SAM2]参数一起传递/接收到/从中传递

- the iSCSI layer that builds/receives iSCSI PDUs and relays/receives them to/from one or more TCP connections; the group of connections form an initiator-target "session".

- iSCSI层,用于构建/接收iSCSI PDU,并将其中继/接收到一个或多个TCP连接;连接组形成一个启动器目标“会话”。

Communication between the initiator and target occurs over one or more TCP connections. The TCP connections carry control messages, SCSI commands, parameters, and data within iSCSI Protocol Data Units (iSCSI PDUs). The group of TCP connections that link an initiator with a target form a session (equivalent to a SCSI I_T nexus; see Section 4.4.2). A session is defined by a session ID that is composed of an initiator part and a target part. TCP connections can be added and removed from a session. Each connection within a session is identified by a connection ID (CID).

启动器和目标之间的通信通过一个或多个TCP连接进行。TCP连接在iSCSI协议数据单元(iSCSI PDU)中承载控制消息、SCSI命令、参数和数据。连接启动器和目标的TCP连接组构成会话(相当于SCSI I_T nexus;参见第4.4.2节)。会话由会话ID定义,会话ID由启动器部分和目标部分组成。可以在会话中添加和删除TCP连接。会话中的每个连接都由连接ID(CID)标识。

Across all connections within a session, an initiator sees one "target image". All target-identifying elements, such as a LUN, are the same. A target also sees one "initiator image" across all connections within a session. Initiator-identifying elements, such as the Initiator Task Tag, are global across the session, regardless of the connection on which they are sent or received.

在会话中的所有连接中,启动器都会看到一个“目标映像”。所有目标标识元素(如LUN)都是相同的。目标还可以在会话中的所有连接中看到一个“启动器映像”。启动器标识元素(如启动器任务标记)在整个会话中都是全局的,而不管它们在哪个连接上发送或接收。

iSCSI targets and initiators MUST support at least one TCP connection and MAY support several connections in a session. For error recovery purposes, targets and initiators that support a single active connection in a session SHOULD support two connections during recovery.

iSCSI目标和启动器必须至少支持一个TCP连接,并且可以在一个会话中支持多个连接。出于错误恢复目的,支持会话中单个活动连接的目标和启动器在恢复期间应支持两个连接。

4.2.2. Ordering and iSCSI Numbering
4.2.2. 订购和iSCSI编号

iSCSI uses command and status numbering schemes and a data sequencing scheme.

iSCSI使用命令和状态编号方案以及数据排序方案。

Command numbering is session-wide and is used for ordered command delivery over multiple connections. It can also be used as a mechanism for command flow control over a session.

命令编号是会话范围的,用于通过多个连接按顺序传递命令。它还可以用作会话上的命令流控制机制。

Status numbering is per connection and is used to enable missing status detection and recovery in the presence of transient or permanent communication errors.

状态编号是每个连接的编号,用于在出现瞬时或永久通信错误时启用缺失状态检测和恢复。

Data sequencing is per command or part of a command (R2T-triggered sequence) and is used to detect missing data and/or R2T PDUs due to header digest errors.

数据排序是每个命令或命令的一部分(R2T触发序列),用于检测由于报头摘要错误而丢失的数据和/或R2T PDU。

Typically, fields in the iSCSI PDUs communicate the sequence numbers between the initiator and target. During periods when traffic on a connection is unidirectional, iSCSI NOP-Out/NOP-In PDUs may be utilized to synchronize the command and status ordering counters of the target and initiator.

通常,iSCSI PDU中的字段在启动器和目标之间传递序列号。在连接上的通信量是单向的期间,可以利用iSCSI NOP Out/NOP In PDU来同步目标和启动器的命令和状态排序计数器。

The iSCSI session abstraction is equivalent to the SCSI I_T nexus, and the iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. For detailed design considerations that led to the iSCSI session model as it is defined here and how it relates the SCSI command ordering features defined in SCSI specifications to the iSCSI concepts, see [RFC3783].

iSCSI会话抽象相当于SCSI I_T nexus,iSCSI会话提供从SCSI启动器到SCSI目标的有序命令传递。有关导致此处定义的iSCSI会话模型的详细设计考虑事项,以及如何将SCSI规范中定义的SCSI命令排序功能与iSCSI概念相关联,请参阅[RFC3783]。

4.2.2.1. Command Numbering and Acknowledging
4.2.2.1. 命令编号和确认

iSCSI performs ordered command delivery within a session. All commands (initiator-to-target PDUs) in transit from the initiator to the target are numbered.

iSCSI在会话中执行有序的命令传递。从启动器传输到目标的所有命令(启动器到目标PDU)都已编号。

iSCSI considers a task to be instantiated on the target in response to every request issued by the initiator. A set of task management operations, including abort and reassign (see Section 11.5), may be performed on an iSCSI task; however, an abort operation cannot be performed on a task management operation, and usage of reassign operations has certain constraints. See Section 11.5.1 for details.

iSCSI考虑在目标上实例化一个任务,以响应启动器发出的每个请求。可以对iSCSI任务执行一组任务管理操作,包括中止和重新分配(参见第11.5节);但是,不能对任务管理操作执行中止操作,并且重新分配操作的使用有一定的限制。详见第11.5.1节。

Some iSCSI tasks are SCSI tasks, and many SCSI activities are related to a SCSI task ([SAM2]). In all cases, the task is identified by the Initiator Task Tag for the life of the task.

某些iSCSI任务是SCSI任务,许多SCSI活动与SCSI任务([SAM2])相关。在所有情况下,任务都由任务生命周期内的启动器任务标记标识。

The command number is carried by the iSCSI PDU as the CmdSN (command sequence number). The numbering is session-wide. Outgoing iSCSI PDUs carry this number. The iSCSI initiator allocates CmdSNs with a 32-bit unsigned counter (modulo 2**32). Comparisons and arithmetic on CmdSNs use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.

iSCSI PDU将命令号作为CmdSN(命令序列号)携带。编号是会话范围内的。传出的iSCSI PDU携带此号码。iSCSI启动器使用32位无符号计数器(模2**32)分配CMDSN。CMDSN上的比较和算法使用[RFC1982]中定义的序列号算法,其中序列位=32。

Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. The CmdSN MUST NOT advance after a command marked for immediate delivery is sent.

用于立即交付的命令标有立即交付标志;它们还必须携带当前的CmdSN。发送标记为立即传递的命令后,CmdSN不得前进。

Command numbering starts with the first Login Request on the first connection of a session (the leading login on the leading connection), and the CmdSN MUST be incremented by 1 in a Serial Number Arithmetic sense, as defined in [RFC1982], for every non-immediate command issued afterwards.

命令编号从会话的第一个连接上的第一个登录请求开始(前导连接上的前导登录),对于随后发出的每个非立即命令,CmdSN必须在序列号算术意义上递增1,如[RFC1982]中所定义。

If immediate delivery is used with task management commands, these commands may reach the target before the tasks on which they are supposed to act. However, their CmdSN serves as a marker of their position in the stream of commands. The initiator and target MUST ensure that the SCSI task management functions specified in [SAM2] act in accordance with the [SAM2] specification. For example, both commands and responses appear as if delivered in order. Whenever the CmdSN for an outgoing PDU is not specified by an explicit rule, the CmdSN will carry the current value of the local CmdSN variable (see later in this section).

如果即时交付与任务管理命令一起使用,则这些命令可能会在其应执行的任务之前到达目标。但是,它们的CmdSN用作它们在命令流中位置的标记。发起方和目标方必须确保[SAM2]中指定的SCSI任务管理功能符合[SAM2]规范。例如,命令和响应似乎都是按顺序传递的。当传出PDU的CmdSN未由显式规则指定时,CmdSN将携带本地CmdSN变量的当前值(请参阅本节后面的内容)。

The means by which an implementation decides to mark a PDU for immediate delivery or by which iSCSI decides by itself to mark a PDU for immediate delivery are beyond the scope of this document.

实现决定将PDU标记为立即交付或iSCSI决定将PDU标记为立即交付的方式超出了本文档的范围。

The number of commands used for immediate delivery is not limited, and their delivery to execution is not acknowledged through the numbering scheme. An iSCSI target MAY reject immediate commands, e.g., due to lack of resources to accommodate additional commands. An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI command per connection at any time.

用于立即传递的命令的数量不受限制,并且不会通过编号方案确认其传递到执行。iSCSI目标可能会拒绝即时命令,例如,由于缺乏资源来容纳其他命令。iSCSI目标必须能够在任何时候处理每个连接至少一个即时任务管理命令和一个即时非任务管理iSCSI命令。

In this document, delivery for execution means delivery to the SCSI execution engine or an iSCSI protocol-specific execution engine (e.g., for Text Requests with public or private extension keys involving an execution component). With the exception of the commands marked for immediate delivery, the iSCSI target layer MUST deliver the commands for execution in the order specified by the CmdSN. Commands marked for immediate delivery may be delivered by

在本文档中,交付执行是指交付到SCSI执行引擎或特定于iSCSI协议的执行引擎(例如,对于具有涉及执行组件的公共或私有扩展密钥的文本请求)。除标记为立即传递的命令外,iSCSI目标层必须按照CmdSN指定的顺序传递要执行的命令。标记为立即交付的命令可以通过

the iSCSI target layer for execution as soon as detected. iSCSI may avoid delivering some commands to the SCSI target layer if required by a prior SCSI or iSCSI action (e.g., a CLEAR TASK SET task management request received before all the commands on which it was supposed to act).

一旦检测到,iSCSI目标层将立即执行。如果先前的SCSI或iSCSI操作需要,iSCSI可能会避免将某些命令传递到SCSI目标层(例如,在其应执行的所有命令之前收到的清除任务集任务管理请求)。

On any connection, the iSCSI initiator MUST send the commands in increasing order of CmdSN, except for commands that are retransmitted due to digest error recovery and connection recovery.

在任何连接上,iSCSI启动器都必须按CmdSN的递增顺序发送命令,但由于摘要错误恢复和连接恢复而重新传输的命令除外。

For the numbering mechanism, the initiator and target maintain the following three variables for each session:

对于编号机制,启动器和目标为每个会话维护以下三个变量:

- CmdSN: the current command sequence number, advanced by 1 on each command shipped except for commands marked for immediate delivery as discussed above. The CmdSN always contains the number to be assigned to the next command PDU.

- CmdSN:当前命令序列号,在每个已发出的命令上增加1,上面讨论的标记为立即传递的命令除外。CmdSN始终包含要分配给下一个命令PDU的编号。

- ExpCmdSN: the next expected command by the target. The target acknowledges all commands up to, but not including, this number. The initiator treats all commands with a CmdSN less than the ExpCmdSN as acknowledged. The target iSCSI layer sets the ExpCmdSN to the largest non-immediate CmdSN that it can deliver for execution "plus 1" per [RFC1982]. There MUST NOT be any holes in the acknowledged CmdSN sequence.

- ExpCmdSN:目标所需的下一个命令。目标确认所有达到但不包括此数字的命令。启动器将CmdSN小于ExpCmdSN的所有命令视为已确认。目标iSCSI层将ExpCmdSN设置为最大的非即时CmdSN,该CmdSN可根据[RFC1982]交付执行“加1”。已确认的CmdSN序列中不得有任何孔。

- MaxCmdSN: the maximum number to be shipped. The queuing capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1.

- MaxCmdSN:要装运的最大数量。接收iSCSI层的队列容量为MaxCmdSN-ExpCmdSN+1。

The initiator's ExpCmdSN and MaxCmdSN are derived from target-to-initiator PDU fields. Comparisons and arithmetic on the ExpCmdSN and MaxCmdSN MUST use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.

启动器的ExpCmdSN和MaxCmdSN是从目标到启动器PDU字段派生的。ExpCmdSN和MaxCmdSN上的比较和运算必须使用[RFC1982]中定义的序列号运算,其中序列位=32。

The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN - 1. For non-immediate commands, the CmdSN field can take any value from the ExpCmdSN to the MaxCmdSN inclusive. The target MUST silently ignore any non-immediate command outside of this range or non-immediate duplicates within the range. The CmdSN carried by immediate commands may lie outside the ExpCmdSN-to-MaxCmdSN range. For example, if the initiator has previously sent a non-immediate command carrying the CmdSN equal to the MaxCmdSN, the target window is closed. For group task management commands issued as immediate commands, the CmdSN indicates the scope of the group action (e.g., an ABORT TASK SET indicates which commands are to be aborted).

目标不能传输小于ExpCmdSN-1的MaxCmdSN。对于非立即命令,CmdSN字段可以采用ExpCmdSN到MaxCmdSN(包括ExpCmdSN)之间的任何值。目标必须以静默方式忽略此范围之外的任何非即时命令或该范围内的非即时重复命令。即时命令携带的CmdSN可能位于ExpCmdSN到MaxCmdSN范围之外。例如,如果启动器先前发送了一个非即时命令,其中包含与MaxCmdSN相同的CmdSN,则目标窗口将关闭。对于作为即时命令发出的组任务管理命令,CmdSN指示组操作的范围(例如,中止任务集指示要中止的命令)。

MaxCmdSN and ExpCmdSN fields are processed by the initiator as follows:

MaxCmdSN和ExpCmdSN字段由启动器处理,如下所示:

- If the PDU MaxCmdSN is less than the PDU ExpCmdSN - 1 (in a Serial Number Arithmetic sense), they are both ignored.

- 如果PDU MaxCmdSN小于PDU ExpCmdSN-1(在序列号算术意义上),则它们都将被忽略。

- If the PDU MaxCmdSN is greater than the local MaxCmdSN (in a Serial Number Arithmetic sense), it updates the local MaxCmdSN; otherwise, it is ignored.

- 如果PDU MaxCmdSN大于本地MaxCmdSN(在序列号算术意义上),则更新本地MaxCmdSN;否则,它将被忽略。

- If the PDU ExpCmdSN is greater than the local ExpCmdSN (in a Serial Number Arithmetic sense), it updates the local ExpCmdSN; otherwise, it is ignored.

- 如果PDU ExpCmdSN大于本地ExpCmdSN(在序列号算术意义上),则更新本地ExpCmdSN;否则,它将被忽略。

This sequence is required because updates may arrive out of order (e.g., the updates are sent on different TCP connections).

此顺序是必需的,因为更新可能会无序到达(例如,更新在不同的TCP连接上发送)。

iSCSI initiators and targets MUST support the command numbering scheme.

iSCSI启动器和目标必须支持命令编号方案。

A numbered iSCSI request will not change its allocated CmdSN, regardless of the number of times and circumstances in which it is reissued (see Section 7.2.1). At the target, the CmdSN is only relevant while the command has not created any state related to its execution (execution state); afterwards, the CmdSN becomes irrelevant. Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target. If no execution state is found, it is followed by ordering and delivery. If an execution state is found, it is followed by delivery if it has not already been delivered.

编号的iSCSI请求不会更改其分配的CmdSN,无论其重新发布的次数和环境如何(请参阅第7.2.1节)。在目标位置,CmdSN仅在命令未创建与其执行相关的任何状态(执行状态)时才相关;之后,CmdSN变得无关紧要。测试执行状态(通过标识启动器任务标记表示)必须先于目标上的任何其他操作。如果未找到执行状态,则随后是订购和交付。如果找到一个执行状态,如果它还没有被传递,那么它后面会有传递。

If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN value is Q, it MUST NOT advance the CmdSN past R + 2**31 - 1 unless

如果当会话CmdSN值为Q时,发起程序在连接上发出命令重试命令,则除非

- the connection is no longer operational (i.e., it has returned to the FREE state; see Section 8.1.3),

- 连接不再运行(即,它已返回自由状态;见第8.1.3节),

- the connection has been reinstated (see Section 6.3.4), or

- 已恢复连接(见第6.3.4节),或

- a non-immediate command with a CmdSN equal to or greater than Q was issued subsequent to the command retry on the same connection and the reception of that command is acknowledged by the target (see Section 10.4).

- 在同一连接上重试命令后,发出了CmdSN等于或大于Q的非立即命令,目标系统确认收到该命令(见第10.4节)。

A target command response or Data-In PDU with status MUST NOT precede the command acknowledgment. However, the acknowledgment MAY be included in the response or the Data-In PDU.

目标命令响应或PDU中状态为的数据不得位于命令确认之前。然而,应答可以包括在响应中或PDU中的数据中。

4.2.2.2. Response/Status Numbering and Acknowledging
4.2.2.2. 响应/状态编号和确认

Responses in transit from the target to the initiator are numbered. The StatSN (status sequence number) is used for this purpose. The StatSN is a counter maintained per connection. The ExpStatSN is used by the initiator to acknowledge status. The status sequence number space is 32-bit unsigned integers, and the arithmetic operations are the regular mod(2**32) arithmetic.

从目标传输到启动器的响应将被编号。StatSN(状态序列号)用于此目的。StatSN是每个连接维护的计数器。启动器使用ExpStatSN确认状态。状态序列号空间为32位无符号整数,算术运算为常规mod(2**32)算术运算。

Status numbering starts with the Login Response to the first Login Request of the connection. The Login Response includes an initial value for status numbering (any initial value is valid).

状态编号从对连接的第一个登录请求的登录响应开始。登录响应包括状态编号的初始值(任何初始值都有效)。

To enable command recovery, the target MAY maintain enough state information for data and status recovery after a connection failure. A target doing so can safely discard all of the state information maintained for recovery of a command after the delivery of the status for the command (numbered StatSN) is acknowledged through the ExpStatSN.

要启用命令恢复,目标可能会保留足够的状态信息,以便在连接失败后恢复数据和状态。在通过ExpStatSN确认命令(编号为StatSN)的状态传递后,这样做的目标可以安全地放弃为恢复命令而维护的所有状态信息。

A large absolute difference between the StatSN and the ExpStatSN may indicate a failed connection. Initiators MUST undertake recovery actions if the difference is greater than an implementation-defined constant that MUST NOT exceed 2**31 - 1.

StatSN和ExpStatSN之间的绝对差值较大可能表示连接失败。如果差异大于实现定义的常量,则启动器必须执行恢复操作,该常量不得超过2**31-1。

Initiators and targets MUST support the response-numbering scheme.

启动器和目标必须支持响应编号方案。

4.2.2.3. Response Ordering
4.2.2.3. 响应顺序
4.2.2.3.1. Need for Response Ordering
4.2.2.3.1. 响应顺序的需要

Whenever an iSCSI session is composed of multiple connections, the Response PDUs (task responses or TMF Responses) originating in the target SCSI layer are distributed onto the multiple connections by the target iSCSI layer according to iSCSI connection allegiance rules. This process generally may not preserve the ordering of the responses by the time they are delivered to the initiator SCSI layer.

每当iSCSI会话由多个连接组成时,源于目标SCSI层的响应PDU(任务响应或TMF响应)将由目标iSCSI层根据iSCSI连接忠诚规则分布到多个连接上。此过程通常不会在响应传递到启动器SCSI层时保留响应的顺序。

Since ordering is not expected across SCSI Response PDUs anyway, this approach works fine in the general case. However, to address the special cases where some ordering is desired by the SCSI layer, we introduce the notion of a "Response Fence": a Response Fence is logically the attribute/property of a SCSI response message handed off to a target iSCSI layer that indicates that there are special SCSI-level ordering considerations associated with this particular response message. Whenever a Response Fence is set or required on a

由于SCSI响应PDU之间不需要排序,因此这种方法在一般情况下工作良好。然而,为了解决SCSI层需要某种排序的特殊情况,我们引入了“响应围栏”的概念:响应围栏在逻辑上是传递给目标iSCSI层的SCSI响应消息的属性/属性,表示与此特定响应消息相关的特殊SCSI级别排序注意事项。无论何时设置或要求在一条线路上设置响应围栏

SCSI response message, we define the semantics in Section 4.2.2.3.2 with respect to the target iSCSI layer's handling of such SCSI response messages.

SCSI响应消息,我们在第4.2.2.3.2节中定义了目标iSCSI层处理此类SCSI响应消息的语义。

4.2.2.3.2. Response Ordering Model Description
4.2.2.3.2. 响应排序模型描述

The target SCSI protocol layer hands off the SCSI response messages to the target iSCSI layer by invoking the "Send Command Complete" protocol data service ([SAM2], Clause 5.4.2) and "Task Management Function Executed" ([SAM2], Clause 6.9) service. On receiving the SCSI response message, the iSCSI layer exhibits the Response Fence behavior for certain SCSI response messages (Section 4.2.2.3.4 describes the specific instances where the semantics must be realized).

目标SCSI协议层通过调用“发送命令完成”协议数据服务([SAM2],第5.4.2条)和“已执行任务管理功能”([SAM2],第6.9条)服务,将SCSI响应消息传递给目标iSCSI层。在接收SCSI响应消息时,iSCSI层显示特定SCSI响应消息的响应围栏行为(第4.2.2.3.4节描述了必须实现语义的特定实例)。

Whenever the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST ensure that the following conditions are met in delivering the response message to the initiator iSCSI layer:

每当SCSI响应消息需要响应围栏行为时,目标iSCSI层必须确保在将响应消息传递到启动器iSCSI层时满足以下条件:

- A response with a Response Fence MUST be delivered chronologically after all the "preceding" responses on the I_T_L nexus, if the preceding responses are delivered at all, to the initiator iSCSI layer.

- 带有响应围栏的响应必须按时间顺序在I_T_L nexus上的所有“先前”响应之后交付,如果之前的响应都已交付到启动器iSCSI层。

- A response with a Response Fence MUST be delivered chronologically prior to all the "following" responses on the I_T_L nexus.

- 带有响应围栏的响应必须在I_T_L nexus上的所有“以下”响应之前按时间顺序提交。

The notions of "preceding" and "following" refer to the order of handoff of a response message from the target SCSI protocol layer to the target iSCSI layer.

“之前”和“之后”的概念是指响应消息从目标SCSI协议层切换到目标iSCSI层的顺序。

4.2.2.3.3. iSCSI Semantics with the Interface Model
4.2.2.3.3. iSCSI语义与接口模型

Whenever the TaskReporting key (Section 13.23) is negotiated to ResponseFence or FastAbort for an iSCSI session and the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST perform the actions described in this section for that session.

每当针对iSCSI会话将TaskReporting密钥(第13.23节)协商为ResponseFence或FastAbort,并且SCSI响应消息需要响应围栏行为时,目标iSCSI层必须针对该会话执行本节中描述的操作。

a) If it is a single-connection session, no special processing is required. The standard SCSI Response PDU build and dispatch process happens.

a) 如果是单个连接会话,则不需要特殊处理。标准SCSI响应PDU生成和分派过程会发生。

b) If it is a multi-connection session, the target iSCSI layer takes note of the last-sent and unacknowledged StatSN on each of the connections in the iSCSI session, and waits for an

b) 如果是多连接会话,目标iSCSI层会记录iSCSI会话中每个连接上最后发送和未确认的StatSN,并等待

acknowledgment (NOP-In PDUs MAY be used to solicit acknowledgments as needed in order to accelerate this process) of each such StatSN to clear the fence. The SCSI Response PDU requiring the Response Fence behavior MUST NOT be sent to the initiator before acknowledgments are received for each of the unacknowledged StatSNs.

每个此类StatSN的确认(PDU中的NOP可用于根据需要请求确认,以加速此过程),以清除围栏。在收到每个未确认STATSN的确认之前,不得将需要响应围栏行为的SCSI响应PDU发送给启动器。

c) The target iSCSI layer must wait for an acknowledgment of the SCSI Response PDU that carried the SCSI response requiring the Response Fence behavior. The fence MUST be considered cleared only after receiving the acknowledgment.

c) 目标iSCSI层必须等待SCSI响应PDU的确认,该PDU承载需要响应围栏行为的SCSI响应。只有在收到确认后,才能认为围栏已清除。

d) All further status processing for the LU is resumed only after clearing the fence. If any new responses for the I_T_L nexus are received from the SCSI layer before the fence is cleared, those Response PDUs MUST be held and queued at the iSCSI layer until the fence is cleared.

d) 只有在清除围栏后,LU的所有进一步状态处理才会恢复。如果在清除隔离之前从SCSI层接收到I_T_L nexus的任何新响应,则必须保留这些响应PDU并在iSCSI层排队,直到清除隔离。

4.2.2.3.4. Current List of Fenced Response Use Cases
4.2.2.3.4. 防护响应用例的当前列表

This section lists the situations in which fenced response behavior is REQUIRED in iSCSI target implementations. Note that the following list is an exhaustive enumeration as currently identified -- it is expected that as SCSI protocol specifications evolve, the specifications will enumerate when response fencing is required on a case-by-case basis.

本节列出了iSCSI目标实现中需要防护响应行为的情况。请注意,下面的列表是目前确定的一个详尽的枚举——随着SCSI协议规范的发展,预计在需要响应隔离时,这些规范将逐个枚举。

Whenever the TaskReporting key (Section 13.23) is negotiated to ResponseFence or FastAbort for an iSCSI session, the target iSCSI layer MUST assume that the Response Fence is required for the following SCSI completion messages:

每当将TaskReporting密钥(第13.23节)协商为iSCSI会话的ResponseFence或FastAbort时,目标iSCSI层必须假定以下SCSI完成消息需要响应围栏:

a) The first completion message carrying the UA after the multi-task abort on issuing and third-party sessions. See Section 4.2.3.2 for related TMF discussion.

a) 在发布和第三方会话的多任务中止后,承载UA的第一条完成消息。有关TMF的讨论,请参见第4.2.3.2节。

b) The TMF Response carrying the multi-task TMF Response on the issuing session.

b) 在发布会话上承载多任务TMF响应的TMF响应。

c) The completion message indicating ACA establishment on the issuing session.

c) 在发布会话上指示ACA建立的完成消息。

d) The first completion message carrying the ACA ACTIVE status after ACA establishment on issuing and third-party sessions.

d) 在发行和第三方会议上建立ACA后,第一条完成消息携带ACA活动状态。

e) The TMF Response carrying the CLEAR ACA response on the issuing session.

e) TMF响应在发布会议上包含明确的ACA响应。

f) The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT command.

f) 对持久保留输出/抢占和中止命令的响应。

Notes:

笔记:

- Due to the absence of ACA-related fencing requirements in [RFC3720], initiator implementations SHOULD NOT use ACA on multi-connection iSCSI sessions with targets complying only with [RFC3720]. This can be determined via TaskReporting key (Section 13.23) negotiation -- when the negotiation results in either "RFC3720" or "NotUnderstood".

- 由于[RFC3720]中没有与ACA相关的防护要求,启动器实施不应在目标仅符合[RFC3720]的多连接iSCSI会话上使用ACA。这可以通过任务报告键(第13.23节)协商确定——协商结果为“RFC3720”或“未理解”。

- Initiators that want to employ ACA on multi-connection iSCSI sessions SHOULD first assess response-fencing behavior via negotiating for the "ResponseFence" or "FastAbort" value for the TaskReporting (Section 13.23) key.

- 希望在多连接iSCSI会话上使用ACA的启动器应首先通过协商TaskReporting(第13.23节)键的“ResponseFence”或“FastAbort”值来评估响应防护行为。

4.2.2.4. Data Sequencing
4.2.2.4. 数据排序

Data and R2T PDUs transferred as part of some command execution MUST be sequenced. The DataSN field is used for data sequencing. For input (read) data PDUs, the DataSN starts with 0 for the first data PDU of an input command and advances by 1 for each subsequent data PDU. For output data PDUs, the DataSN starts with 0 for the first data PDU of a sequence (the initial unsolicited sequence or any data PDU sequence issued to satisfy an R2T) and advances by 1 for each subsequent data PDU. R2Ts are also sequenced per command. For example, the first R2T has an R2TSN of 0 and advances by 1 for each subsequent R2T. For bidirectional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated). Unlike command and status, data PDUs and R2Ts are not acknowledged by a field in regular outgoing PDUs. Data-In PDUs can be acknowledged on demand by a special form of the SNACK PDU. Data and R2T PDUs are implicitly acknowledged by status for the command. The DataSN/R2TSN field enables the initiator to detect missing data or R2T PDUs.

作为某些命令执行的一部分传输的数据和R2T PDU必须按顺序排列。DataSN字段用于数据排序。对于输入(读取)数据PDU,对于输入命令的第一个数据PDU,DataSN从0开始,对于每个后续数据PDU,DataSN前进1。对于输出数据PDU,对于序列的第一个数据PDU(初始未经请求的序列或为满足R2T而发布的任何数据PDU序列),DataSN从0开始,对于每个后续数据PDU,提前1。R2T也按命令排序。例如,第一个R2T的R2TSN为0,并且每个后续R2T的R2TSN均提前1。对于双向命令,目标使用DataSN/R2TSN在一个连续序列(未区分)中对数据和R2T PDU进行排序。与命令和状态不同,数据PDU和R2T不会被常规传出PDU中的字段确认。PDU中的数据可以通过特殊形式的PDU按需确认。数据和R2T PDU由命令的状态隐式确认。DataSN/R2TSN字段使启动器能够检测丢失的数据或R2T PDU。

For any read or bidirectional command, a target MUST issue less than 2**32 combined R2T and Data-In PDUs. Any output data sequence MUST contain less than 2**32 Data-Out PDUs.

对于任何读取或双向命令,目标必须在PDU中发出少于2**32组合R2T和数据。任何输出数据序列必须包含少于2**32个数据输出PDU。

4.2.3. iSCSI Task Management
4.2.3. iSCSI任务管理
4.2.3.1. Task Management Overview
4.2.3.1. 任务管理概述

iSCSI task management features allow an initiator to control the active iSCSI tasks on an operational iSCSI session that it has with an iSCSI target. Section 11.5 defines the task management function types that this specification defines -- ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, TARGET COLD RESET, and TASK REASSIGN.

iSCSI任务管理功能允许启动器在与iSCSI目标的可操作iSCSI会话上控制活动iSCSI任务。第11.5节定义了本规范定义的任务管理功能类型——中止任务、中止任务集、清除ACA、清除任务集、逻辑单元重置、目标热重置、目标冷重置和任务重新分配。

Out of these function types, ABORT TASK and TASK REASSIGN functions manage a single active task, whereas ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET functions can each potentially affect multiple active tasks.

在这些功能类型中,中止任务和任务重新分配功能管理单个活动任务,而中止任务集、清除任务集、逻辑单元重置、目标热重置和目标冷重置功能都可能影响多个活动任务。

4.2.3.2. Notion of Affected Tasks
4.2.3.2. 受影响任务的概念

This section defines the notion of "affected tasks" in multi-task abort scenarios. Scope definitions in this section apply to both the standard multi-task abort semantics (Section 4.2.3.3) and the FastAbort multi-task abort semantics behavior (Section 4.2.3.4).

本节定义了多任务中止场景中“受影响任务”的概念。本节中的范围定义适用于标准多任务中止语义(第4.2.3.3节)和FastAbort多任务中止语义行为(第4.2.3.4节)。

ABORT TASK SET: All outstanding tasks for the I_T_L nexus identified by the LUN field in the ABORT TASK SET TMF Request PDU.

中止任务集:由中止任务集TMF Request PDU中的LUN字段标识的I_T_L连接的所有未完成任务。

CLEAR TASK SET: All outstanding tasks in the task set for the LU identified by the LUN field in the CLEAR TASK SET TMF Request PDU. See [SPC3] for the definition of a "task set".

清除任务集:清除任务集TMF请求PDU中LUN字段标识的LU任务集中所有未完成的任务。有关“任务集”的定义,请参见[SPC3]。

LOGICAL UNIT RESET: All outstanding tasks from all initiators for the LU identified by the LUN field in the LOGICAL UNIT RESET Request PDU.

逻辑单元重置:逻辑单元重置请求PDU中LUN字段标识的LU所有启动器的所有未完成任务。

TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from all initiators across all LUs to which the TMF-issuing session has access on the SCSI target device hosting the iSCSI session.

目标热重设/目标冷重设:在托管iSCSI会话的SCSI目标设备上,TMF发出会话有权访问的所有LU中所有启动器的所有未完成任务。

Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text is an iSCSI TMF Request PDU with the "Function" field set to "ABORT TASK SET" as defined in Section 11.5. Similar usage is employed for other scope descriptions.

用法:前文中的“中止任务集TMF请求PDU”是iSCSI TMF请求PDU,其“功能”字段设置为第11.5节中定义的“中止任务集”。其他范围描述也采用类似用法。

4.2.3.3. Standard Multi-Task Abort Semantics
4.2.3.3. 标准多任务中止语义

All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.

所有iSCSI实施都必须支持本节中定义为默认行为的协议行为。中止任务集、清除任务集、逻辑单元重置、目标热重置和目标冷重置TMF请求的执行包括在指定方上按指定顺序执行以下操作序列。

The initiator iSCSI layer:

启动器iSCSI层:

a) MUST continue to respond to each TTT received for the affected tasks.

a) 必须继续响应针对受影响任务收到的每个TTT。

b) SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF Response.

b) 应以正常方式处理收到的受影响任务的任何响应。这是可以接受的,因为保证在TMF响应之前发送响应。

c) SHOULD receive the TMF Response concluding all the tasks in the set of affected tasks, unless the initiator has done something (e.g., LU reset, connection drop) that may prevent the TMF Response from being sent or received. The initiator MUST thus conclude all affected tasks as part of this step in either case and MUST discard any TMF Response received after the affected tasks are concluded.

c) 应接收结束受影响任务集中所有任务的TMF响应,除非发起者执行了可能阻止发送或接收TMF响应的操作(如LU重置、连接断开)。因此,无论哪种情况,发起人都必须结束所有受影响的任务,作为该步骤的一部分,并且必须放弃在受影响任务结束后收到的任何TMF响应。

The target iSCSI layer:

目标iSCSI层:

a) MUST wait for responses on currently valid Target Transfer Tags of the affected tasks from the issuing initiator. MAY wait for responses on currently valid Target Transfer Tags of the affected tasks from third-party initiators.

a) 必须等待发出启动器对受影响任务的当前有效目标传输标记的响应。可能会等待来自第三方启动器的受影响任务的当前有效目标传输标记的响应。

b) MUST wait (concurrent with the wait in Step a) for all commands of the affected tasks to be received based on the CmdSN ordering. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. However, in the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the commands that are not yet received on the issuing session in the command stream can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".

b) 必须等待(与步骤a中的等待同时),才能根据CmdSN顺序接收受影响任务的所有命令。不应在受第三方影响的会话上等待新命令——只有实例化的任务才能确定受影响的任务。但是,对于目标范围内的请求(即,目标热重设和目标冷重设),在命令流中的发出会话上尚未接收到的所有命令都可以被视为已接收,没有命令等待时间,即,可以删除任务管理功能的CmdSN之前的整个CmdSN空间“堵塞”。

c) MUST propagate the TMF Request to, and receive the response from, the target SCSI layer.

c) 必须将TMF请求传播到目标SCSI层,并从目标SCSI层接收响应。

d) MUST provide the Response Fence behavior for the TMF Response on the issuing session as specified in Section 4.2.2.3.2.

d) 必须按照第4.2.2.3.2节的规定,在发布会话上为TMF响应提供响应围栏行为。

e) MUST provide the Response Fence behavior on the first post-TMF Response on third-party sessions as specified in Section 4.2.2.3.3. If some tasks originate from non-iSCSI I_T_L nexuses, then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).

e) 必须按照第4.2.2.3.3节的规定,在第三方会话上的第一次TMF后响应上提供响应围栏行为。如果某些任务源自非iSCSI I_T_L nexuses,则目标公司确保所有受影响的任务已将其状态返回到启动器的方式由特定的非iSCSI传输协议定义。

Technically, the TMF servicing is complete in Step d). Data transfers corresponding to terminated tasks may, however, still be in progress on third-party iSCSI sessions even at the end of Step e). The TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step d) and MAY be sent at the end of Step d) despite these outstanding data transfers until after Step e).

从技术上讲,TMF维修在步骤d)中完成。但是,即使在步骤e)结束时,与已终止任务相对应的数据传输仍可能在第三方iSCSI会话上进行。在步骤d)结束之前,目标iSCSI层不得发送TMF响应,并且可以在步骤d)结束时发送TMF响应,尽管在步骤e)之后仍有这些未完成的数据传输。

4.2.3.4. FastAbort Multi-Task Abort Semantics
4.2.3.4. FastAbort多任务中止语义

Protocol behavior defined in this section SHOULD be implemented by all iSCSI implementations complying with this document, noting that some steps below may not be compatible with [RFC3720] semantics. However, protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 13.23) key to "FastAbort" on that session. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.

本节中定义的协议行为应由符合本文档要求的所有iSCSI实现来实现,注意以下某些步骤可能与[RFC3720]语义不兼容。但是,本节中定义的协议行为必须由iSCSI会话上的iSCSI实现在该会话上协商TaskReporting(第13.23节)键到“FastAbort”时显示。中止任务集、清除任务集、逻辑单元重置、目标热重置和目标冷重置TMF请求的执行包括在指定方上按指定顺序执行以下操作序列。

The initiator iSCSI layer:

启动器iSCSI层:

a) MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target.

a) 一旦TMF被发送到目标,就不能在发出iSCSI会话的发出连接上为受影响的任务向PDU发送更多数据。

b) SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF Response.

b) 应以正常方式处理收到的受影响任务的任何响应。这是可以接受的,因为保证在TMF响应之前发送响应。

c) MUST respond to each Async Message PDU with a Task Termination AsyncEvent (5) as defined in Section 11.9.

c) 必须使用第11.9节中定义的任务终止异步事件(5)响应每个异步消息PDU。

d) MUST treat the TMF Response as terminating all affected tasks for which responses have not been received and MUST discard any responses for affected tasks received after the TMF Response is passed to the SCSI layer (although the semantics defined in this section ensure that such an out-of-order scenario will never happen with a compliant target implementation).

d) 必须将TMF响应视为终止尚未收到响应的所有受影响任务,并且必须在TMF响应传递到SCSI层后放弃收到的受影响任务的任何响应(尽管本节中定义的语义确保了这种无序场景在兼容目标实现中永远不会发生)。

The target iSCSI layer:

目标iSCSI层:

a) MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".

a) 必须等待根据发出会话上的CmdSN顺序接收受影响任务的所有命令。不应在受第三方影响的会话上等待新命令——只有实例化的任务才能确定受影响的任务。对于目标范围内的请求(即,目标温重设和目标冷重设),在命令流中的发出会话上尚未接收到的所有命令都可以被视为在没有命令等待期的情况下接收到——即,任务管理功能的CmdSN之前的整个CmdSN空间都可以“插入”。

b) MUST propagate the TMF Request to, and receive the response from, the target SCSI layer.

b) 必须将TMF请求传播到目标SCSI层,并从目标SCSI层接收响应。

c) MUST leave all active "affected TTTs" (i.e., active TTTs associated with affected tasks) valid.

c) 必须使所有活动的“受影响的TTT”(即与受影响任务关联的活动TTT)保持有效。

d) MUST send an Asynchronous Message PDU with AsyncEvent=5 (Section 11.9) on:

d) 必须在以下位置发送AsyncEvent=5(第11.9节)的异步消息PDU:

1) each connection of each third-party session to which at least one affected task is allegiant if TaskReporting=FastAbort is operational on that third-party session, and

1) 如果TaskReporting=FastAbort在该第三方会话上运行,则至少有一个受影响任务是allegiant的每个第三方会话的每个连接,以及

2) each connection except the issuing connection of the issuing session that has at least one allegiant affected task.

2) 每个连接(至少有一个受allegiant影响的任务的发布会话的发布连接除外)。

If there are multiple affected LUs (say, due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task. The LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.

如果存在多个受影响的LU(例如,由于目标重置),则必须为至少有一个allegiant受影响任务的每个连接上的每个此类LU发送一条异步消息PDU。异步消息PDU中的LUN字段必须设置为与每个此类LU的LUN相匹配。

e) MUST address the Response Fence flag on the TMF Response on the issuing session as defined in Section 4.2.2.3.3.

e) 必须按照第4.2.2.3.3节的规定,在发布会话上处理TMF响应上的响应围栏标志。

f) MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in Section 4.2.2.3.3. If some tasks originate from non-iSCSI I_T_L nexuses, then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).

f) 必须按照第4.2.2.3.3节的规定,在第三方会话上的第一次TMF后响应上注明响应围栏标志。如果某些任务源自非iSCSI I_T_L nexuses,则目标公司确保所有受影响的任务已将其状态返回到启动器的方式由特定的非iSCSI传输协议定义。

g) MUST free up the affected TTTs (and STags for iSER, if applicable) and the corresponding buffers, if any, once it receives each associated NOP-Out acknowledgment that the initiator generated in response to each Async Message.

g) 一旦收到启动器响应每个异步消息生成的每个相关NOP Out确认,必须释放受影响的TTT(以及iSER的STAG,如果适用)和相应的缓冲区(如果有)。

Technically, the TMF servicing is complete in Step e). Data transfers corresponding to terminated tasks may, however, still be in progress even at the end of Step f). A TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step e) and MAY be sent at the end of Step e) despite these outstanding Data transfers until Step g). Step g) specifies an event to free up any such resources that may have been reserved to support outstanding data transfers.

从技术上讲,TMF维修在步骤e)中完成。然而,即使在步骤f)结束时,与终止的任务相对应的数据传输也可能仍在进行中。在步骤e)结束之前,目标iSCSI层不得发送TMF响应,并且可以在步骤e)结束时发送TMF响应,尽管在步骤g)之前存在这些未完成的数据传输。步骤g)指定一个事件以释放可能已保留以支持未完成数据传输的任何此类资源。

4.2.3.5. Affected Tasks Shared across Standard and FastAbort Sessions
4.2.3.5. 在标准和FastAbort会话中共享受影响的任务

If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality (Section 13.23), it may end up in a situation where some sessions have TaskReporting=RFC3720 operational (RFC 3720 sessions) while some other sessions have TaskReporting=FastAbort operational (FastAbort sessions) even while accessing a shared set of affected tasks (Section 4.2.3.2). If the issuing session is an RFC 3720 session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is a FastAbort session, the following behavior SHOULD be exhibited by the iSCSI target layer:

如果iSCSI目标实现能够支持TaskReporting=FastAbort功能(第13.23节),则可能会出现以下情况:某些会话的TaskReporting=RFC3720可操作(RFC 3720会话),而某些其他会话的TaskReporting=FastAbort可操作(FastAbort会话)即使在访问一组受影响的共享任务时(第4.2.3.2节)。如果发出会话是RFC 3720会话,iSCSI目标实现支持FastAbort,并且受影响的第三方会话是FastAbort会话,则iSCSI目标层应显示以下行为:

a) Between Steps c) and d) of the target behavior in Section 4.2.3.3, send an Asynchronous Message PDU with AsyncEvent=5 (Section 11.9) on each connection of each third-party session to which at least one affected task is allegiant. If there are multiple affected LUs, then send one Async Message PDU for each such LU on each connection that has at least one allegiant affected task. When sent, the LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.

a) 在第4.2.3.3节中目标行为的步骤c)和d)之间,在至少有一个受影响任务是allegiant的每个第三方会话的每个连接上发送异步消息PDU,其中AsyncEvent=5(第11.9节)。如果有多个受影响的LU,则在至少有一个allegiant受影响任务的每个连接上,为每个此类LU发送一条异步消息PDU。发送时,异步消息PDU中的LUN字段必须设置为与每个此类LU的LUN相匹配。

b) After Step e) of the target behavior in Section 4.2.3.3, free up the affected TTTs (and STags for iSER, if applicable) and the corresponding buffers, if any, once each associated NOP-Out acknowledgment is received that the third-party initiator generated in response to each Async Message sent in Step a).

b) 在第4.2.3.3节中目标行为的步骤e)之后,一旦收到第三方启动器响应步骤a中发送的每个异步消息而生成的每个相关NOP Out确认,则释放受影响的TTT(以及iSER的STAG,如果适用)和相应的缓冲区(如果有)。

If the issuing session is a FastAbort session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is an RFC 3720 session, the iSCSI target layer MUST NOT send Asynchronous Message PDUs on the third-party session to prompt the FastAbort behavior.

如果发出会话是FastAbort会话,iSCSI目标实现支持FastAbort,并且受影响的第三方会话是RFC 3720会话,则iSCSI目标层不得在第三方会话上发送异步消息PDU以提示FastAbort行为。

If the third-party affected session is a FastAbort session and the issuing session is a FastAbort session, the initiator in the third-party role MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 11.9. Note that an initiator MAY thus receive these Async Messages on a third-party affected session even if the session is a single-connection session.

如果受第三方影响的会话是FastAbort会话,而发出会话是FastAbort会话,则第三方角色的启动器必须按照第11.9节中的定义,以AsyncEvent=5响应每个异步消息PDU。请注意,即使会话是单个连接会话,启动器也可能因此在受影响的第三方会话上接收这些异步消息。

4.2.3.6. Rationale behind the FastAbort Semantics
4.2.3.6. FastAbort语义背后的基本原理

There are fundamentally three basic objectives behind the semantics specified in Sections 4.2.3.3 and 4.2.3.4.

第4.2.3.3节和第4.2.3.4节中规定的语义背后有三个基本目标。

a) Maintaining an ordered command flow I_T nexus abstraction to the target SCSI layer even with multi-connection sessions.

a) 即使使用多连接会话,也要维护到目标SCSI层的有序命令流连接抽象。

- Target iSCSI processing of a TMF Request must maintain the single flow illusion. The target behavior in Step b) of Section 4.2.3.3 and the target behavior in Step a) of Section 4.2.3.4 correspond to this objective.

- TMF请求的目标iSCSI处理必须保持单流错觉。第4.2.3.3节步骤b)中的目标行为和第4.2.3.4节步骤a)中的目标行为对应于该目标。

b) Maintaining a single ordered response flow I_T nexus abstraction to the initiator SCSI layer even with multi-connection sessions when one response (i.e., TMF Response) could imply the status of other unfinished tasks from the initiator's perspective.

b) 当一个响应(即TMF响应)可能从启动器的角度暗示其他未完成任务的状态时,即使使用多个连接会话,也要维护到启动器SCSI层的单个有序响应流I_T nexus抽象。

- The target must ensure that the initiator does not see "old" task responses (that were placed on the wire chronologically earlier than the TMF Response) after seeing the TMF Response. The target behavior in Step d) of Section 4.2.3.3 and the target behavior in Step e) of Section 4.2.3.4 correspond to this objective.

- 目标必须确保启动器在看到TMF响应后不会看到“旧”任务响应(按时间顺序放置在TMF响应之前的连线上)。第4.2.3.3节步骤d)中的目标行为和第4.2.3.4节步骤e)中的目标行为与该目标相对应。

- Whenever the result of a TMF action is visible across multiple I_T_L nexuses, [SAM2] requires the SCSI device server to trigger a UA on each of the other I_T_L nexuses. Once an initiator is notified of such a UA, the application client on the receiving initiator is required to clear its task state (Clause 5.5 of [SAM2]) for the affected tasks. It would thus be inappropriate to deliver a SCSI Response for a task after the task state is cleared on the initiator, i.e., after the UA is notified. The UA notification contained in

- 每当TMF操作的结果在多个I_T_L nexus中可见时,[SAM2]要求SCSI设备服务器在每个其他I_T_L nexus上触发UA。一旦启动器收到此类UA的通知,接收启动器上的应用程序客户端需要清除受影响任务的任务状态(SAM2第5.5条)。因此,在启动器上清除任务状态之后,即在通知UA之后,为任务发送SCSI响应是不合适的。中所载的UA通知

the first SCSI Response PDU on each affected third-party I_T_L nexus after the TMF action thus MUST NOT pass the affected task responses on any of the iSCSI sessions accessing the LU. The target behavior in Step e) of Section 4.2.3.3 and the target behavior in Step f) of Section 4.2.3.4 correspond to this objective.

因此,在TMF操作之后,每个受影响的第三方I_T_L nexus上的第一个SCSI响应PDU不得在访问LU的任何iSCSI会话上传递受影响的任务响应。第4.2.3.3节步骤e)中的目标行为和第4.2.3.4节步骤f)中的目标行为符合该目标。

c) Draining all active TTTs corresponding to affected tasks in a deterministic fashion.

c) 以确定性方式排空与受影响任务对应的所有活动TTT。

- Data-Out PDUs with stale TTTs arriving after the tasks are terminated can create a buffer management problem even for traditional iSCSI implementations and is fatal for the connection for iSCSI/iSER implementations. Either the termination of affected tasks should be postponed until the TTTs are retired (as in Step a) of Section 4.2.3.3), or the TTTs and the buffers should stay allocated beyond task termination to be deterministically freed up later (as in Steps c) and g) of Section 4.2.3.4).

- 任务终止后到达的带有过时TTT的数据输出PDU可能会产生缓冲区管理问题,即使对于传统的iSCSI实施也是如此,这对于iSCSI/iSER实施的连接来说是致命的。受影响任务的终止应推迟到TTT退役(如第4.2.3.3节步骤a所示),或者TTT和缓冲区应在任务终止后继续分配,以便稍后(如第4.2.3.4节步骤c)和g)确定释放。

The only other notable optimization is the plugging. If all tasks on an I_T nexus will be aborted anyway (as with a target reset), there is no need to wait to receive all commands to plug the CmdSN holes. The target iSCSI layer can simply plug all missing CmdSN slots and move on with TMF processing. The first objective (maintaining a single ordered command flow) is still met with this optimization because the target SCSI layer only sees ordered commands.

唯一其他值得注意的优化是堵塞。如果I_T nexus上的所有任务仍将中止(与目标重置一样),则无需等待接收所有命令以堵塞CmdSN漏洞。目标iSCSI层可以简单地插入所有缺失的CmdSN插槽,然后继续进行TMF处理。第一个目标(维护单个有序的命令流)仍然可以通过此优化实现,因为目标SCSI层只看到有序的命令。

4.2.4. iSCSI Login
4.2.4. iSCSI登录

The purpose of the iSCSI login is to enable a TCP connection for iSCSI use, authentication of the parties, negotiation of the session's parameters, and marking of the connection as belonging to an iSCSI session.

iSCSI登录的目的是启用TCP连接以供iSCSI使用、对各方进行身份验证、协商会话参数以及将连接标记为属于iSCSI会话。

A session is used to identify to a target all the connections with a given initiator that belong to the same I_T nexus. (For more details on how a session relates to an I_T nexus, see Section 4.4.2.)

会话用于向目标标识与给定启动器之间属于同一I_T nexus的所有连接。(有关会话如何与I_T nexus关联的更多详细信息,请参阅第4.4.2节。)

The targets listen on a well-known TCP port or other TCP port for incoming connections. The initiator begins the login process by connecting to one of these TCP ports.

目标在已知的TCP端口或其他TCP端口上侦听传入连接。启动器通过连接到其中一个TCP端口开始登录过程。

As part of the login process, the initiator and target SHOULD authenticate each other and MAY set a security association protocol for the session. This can occur in many different ways and is subject to negotiation; see Section 12.

作为登录过程的一部分,启动器和目标应相互验证,并可为会话设置安全关联协议。这可能以多种不同的方式发生,并需要协商;见第12节。

To protect the TCP connection, an IPsec security association MAY be established before the Login Request. For information on using IPsec security for iSCSI, see Section 9, [RFC3723], and [RFC7146].

为了保护TCP连接,可以在登录请求之前建立IPsec安全关联。有关将IPsec安全性用于iSCSI的信息,请参阅第9节[RFC3723]和[RFC7146]。

The iSCSI Login Phase is carried through Login Requests and Responses. Once suitable authentication has occurred and operational parameters have been set, the session transitions to the Full Feature Phase and the initiator may start to send SCSI commands. The security policy for whether and by what means a target chooses to authorize an initiator is beyond the scope of this document. For a more detailed description of the Login Phase, see Section 6.

iSCSI登录阶段通过登录请求和响应进行。一旦进行了适当的身份验证并设置了操作参数,会话将过渡到完整功能阶段,启动器可能会开始发送SCSI命令。目标是否以及通过何种方式选择授权启动器的安全策略超出了本文档的范围。有关登录阶段的更详细说明,请参阅第6节。

The login PDU includes the ISID part of the session ID (SSID). The target portal group that services the login is implied by the selection of the connection endpoint. For a new session, the TSIH is zero. As part of the response, the target generates a TSIH.

登录PDU包括会话ID(SSID)的ISID部分。连接端点的选择暗示了为登录提供服务的目标门户组。对于新会话,TSIH为零。作为响应的一部分,目标生成TSIH。

During session establishment, the target identifies the SCSI initiator port (the "I" in the "I_T nexus") through the value pair (InitiatorName, ISID). We describe InitiatorName later in this section. Any persistent state (e.g., persistent reservations) on the target that is associated with a SCSI initiator port is identified based on this value pair. Any state associated with the SCSI target port (the "T" in the "I_T nexus") is identified externally by the TargetName and Target Portal Group Tag (see Section 4.4.1). The ISID is subject to reuse restrictions because it is used to identify a persistent state (see Section 4.4.3).

在会话建立期间,目标通过值对(InitiatorName,ISID)标识SCSI启动器端口(“I_T nexus”中的“I”)。我们将在本节后面介绍InitiatorName。目标上与SCSI启动器端口关联的任何持久状态(例如,持久保留)都基于此值对进行标识。与SCSI目标端口(“I_T nexus”中的“T”)关联的任何状态都由TargetName和target Portal Group标记在外部标识(请参见第4.4.1节)。ISID受重用限制,因为它用于标识持久状态(见第4.4.3节)。

Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. Login Requests and Responses MUST be used exclusively during login. On any connection, the Login Phase MUST immediately follow TCP connection establishment, and a subsequent Login Phase MUST NOT occur before tearing down the connection.

在建立完整功能阶段之前,只允许登录请求和登录响应PDU。登录请求和响应必须在登录期间专用。在任何连接上,登录阶段必须紧跟在TCP连接建立之后,并且在断开连接之前不得出现后续登录阶段。

A target receiving any PDU except a Login Request before the Login Phase is started MUST immediately terminate the connection on which the PDU was received. Once the Login Phase has started, if the target receives any PDU except a Login Request, it MUST send a Login reject (with Status "invalid during login") and then disconnect. If the initiator receives any PDU except a Login Response, it MUST immediately terminate the connection.

在登录阶段开始之前接收任何PDU(登录请求除外)的目标必须立即终止接收PDU的连接。登录阶段开始后,如果目标接收到除登录请求之外的任何PDU,则必须发送登录拒绝(状态为“登录期间无效”),然后断开连接。如果启动器收到除登录响应之外的任何PDU,则必须立即终止连接。

4.2.5. iSCSI Full Feature Phase
4.2.5. iSCSI全功能阶段

Once the two sides successfully conclude the login on the first -- also called the leading -- connection in the session, the iSCSI session is in the iSCSI Full Feature Phase. A connection is in the Full Feature Phase if the session is in the Full Feature Phase and the connection login has completed successfully. An iSCSI connection is not in the Full Feature Phase when

一旦双方在会话中的第一个连接(也称为前导连接)上成功完成登录,iSCSI会话将进入iSCSI全功能阶段。如果会话处于完整功能阶段并且连接登录已成功完成,则连接处于完整功能阶段。在以下情况下,iSCSI连接未处于完整功能阶段:

a) it does not have an established transport connection, or

a) 它没有建立的传输连接,或者

b) when it has a valid transport connection, but a successful login was not performed or the connection is currently logged out.

b) 当它具有有效的传输连接,但未成功登录或连接当前已注销时。

In a normal Full Feature Phase, the initiator may send SCSI commands and data to the various LUs on the target by encapsulating them in iSCSI PDUs that go over the established iSCSI session.

在正常的全功能阶段,启动器可以通过将SCSI命令和数据封装在经过已建立的iSCSI会话的iSCSI PDU中,向目标上的各种LU发送SCSI命令和数据。

4.2.5.1. Command Connection Allegiance
4.2.5.1. 命令连接忠诚

For any iSCSI request issued over a TCP connection, the corresponding response and/or other related PDU(s) MUST be sent over the same connection. We call this "connection allegiance". If the original connection fails before the command is completed, the connection allegiance of the command may be explicitly reassigned to a different transport connection as described in detail in Section 7.2.

对于通过TCP连接发出的任何iSCSI请求,必须通过同一连接发送相应的响应和/或其他相关PDU。我们称之为“连接忠诚”。如果原始连接在命令完成之前失败,则可按照第7.2节的详细说明,将命令的连接效忠明确重新分配给不同的传输连接。

Thus, if an initiator issues a read command, the target MUST send the requested data, if any, followed by the status, to the initiator over the same TCP connection that was used to deliver the SCSI command. If an initiator issues a write command, the initiator MUST send the data, if any, for that command over the same TCP connection that was used to deliver the SCSI command. The target MUST return Ready To Transfer (R2T), if any, and the status over the same TCP connection that was used to deliver the SCSI command. Retransmission requests (SNACK PDUs), and the data and status that they generate, MUST also use the same connection.

因此,如果启动器发出读取命令,目标必须通过用于传递SCSI命令的同一TCP连接将请求的数据(如果有)和状态发送给启动器。如果启动器发出写入命令,则启动器必须通过用于传递SCSI命令的同一TCP连接发送该命令的数据(如果有)。目标必须返回Ready To Transfer(R2T)(如果有)以及用于传递SCSI命令的同一TCP连接上的状态。重传请求(PDU)及其生成的数据和状态也必须使用相同的连接。

However, consecutive commands that are part of a SCSI linked command-chain task (see [SAM2]) MAY use different connections. Connection allegiance is strictly per command and not per task. During the iSCSI Full Feature Phase, the initiator and target MAY interleave unrelated SCSI commands, their SCSI data, and responses over the session.

但是,作为SCSI链接命令链任务一部分的连续命令(请参见[SAM2])可能使用不同的连接。连接忠诚严格按命令而不是按任务。在iSCSI全功能阶段,启动器和目标可能会在会话中交错不相关的SCSI命令、它们的SCSI数据和响应。

4.2.5.2. Data Transfer Overview
4.2.5.2. 数据传输概述

Outgoing SCSI data (initiator-to-target user data or command parameters) is sent as either solicited data or unsolicited data. Solicited data are sent in response to R2T PDUs. Unsolicited data can be sent as part of an iSCSI Command PDU ("immediate data") or in separate iSCSI data PDUs.

传出SCSI数据(启动器到目标用户数据或命令参数)作为请求数据或非请求数据发送。请求的数据被发送以响应R2T PDU。未经请求的数据可以作为iSCSI命令PDU(“即时数据”)的一部分或在单独的iSCSI数据PDU中发送。

Immediate data are assumed to originate at offset 0 in the initiator SCSI write-buffer (outgoing data buffer). All other data PDUs have the buffer offset set explicitly in the PDU header.

假定即时数据源自启动器SCSI写入缓冲区(传出数据缓冲区)中的偏移量0。所有其他数据PDU都在PDU头中明确设置了缓冲区偏移量。

An initiator may send unsolicited data up to FirstBurstLength (see Section 13.14) as immediate (up to the negotiated maximum PDU length), in a separate PDU sequence, or both. All subsequent data MUST be solicited. The maximum length of an individual data PDU or the immediate-part of the first unsolicited burst MAY be negotiated at login.

发起者可以在单独的PDU序列中,或同时以即时(最多协商的最大PDU长度)的方式发送不超过FirstBurstLength(见第13.14节)的未经请求的数据。必须征求所有后续数据。单个数据PDU的最大长度或第一个未经请求的突发的直接部分可以在登录时协商。

The maximum amount of unsolicited data that can be sent with a command is negotiated at login through the FirstBurstLength (see Section 13.14) key. A target MAY separately enable immediate data (through the ImmediateData key) without enabling the more general (separate data PDUs) form of unsolicited data (through the InitialR2T key).

在登录时通过FirstBurstLength(参见第13.14节)键协商可通过命令发送的最大未经请求数据量。目标可以单独启用即时数据(通过ImmediateData键),而不启用更通用(单独数据PDU)形式的非请求数据(通过InitialR2T键)。

Unsolicited data for a write are meant to reduce the effect of latency on throughput (no R2T is needed to start sending data). In addition, immediate data is meant to reduce the protocol overhead (both bandwidth and execution time).

用于写入的未经请求的数据旨在减少延迟对吞吐量的影响(开始发送数据不需要R2T)。此外,即时数据旨在减少协议开销(带宽和执行时间)。

An iSCSI initiator MAY choose not to send unsolicited data, only immediate data or FirstBurstLength bytes of unsolicited data with a command. If any non-immediate unsolicited data is sent, the total unsolicited data MUST be either FirstBurstLength or all of the data, if the total amount is less than the FirstBurstLength.

iSCSI启动器可以选择不发送未经请求的数据,只发送即时数据或使用命令发送未经请求的数据的FirstBurstLength字节。如果发送了任何非即时未经请求的数据,则未经请求的总数据必须为FirstBurstLength或全部数据(如果总长度小于FirstBurstLength)。

It is considered an error for an initiator to send unsolicited data PDUs to a target that operates in R2T mode (only solicited data are allowed). It is also an error for an initiator to send more unsolicited data, whether immediate or as separate PDUs, than FirstBurstLength.

发起方向以R2T模式运行的目标发送未经请求的数据PDU(仅允许请求的数据)被视为错误。发起方发送的未经请求的数据(无论是立即发送的还是作为单独的PDU发送的)超过FirstBurstLength也是一个错误。

An initiator MUST honor an R2T data request for a valid outstanding command (i.e., carrying a valid Initiator Task Tag) and deliver all the requested data, provided the command is supposed to deliver

发起者必须对有效的未完成命令(即,携带有效的发起者任务标记)执行R2T数据请求,并交付所有请求的数据,前提是该命令应该交付

outgoing data and the R2T specifies data within the command bounds. The initiator action is unspecified for receiving an R2T request that specifies data, all or in part, outside of the bounds of the command.

传出数据和R2T指定命令边界内的数据。未指定启动器操作用于接收R2T请求,该请求指定全部或部分超出命令边界的数据。

A target SHOULD NOT silently discard data and then request retransmission through R2T. Initiators SHOULD NOT keep track of the data transferred to or from the target (scoreboarding). SCSI targets perform residual count calculation to check how much data was actually transferred to or from the device by a command. This may differ from the amount the initiator sent and/or received for reasons such as retransmissions and errors. Read or bidirectional commands implicitly solicit the transmission of the entire amount of data covered by the command. SCSI data packets are matched to their corresponding SCSI commands by using tags specified in the protocol.

目标不应默默地丢弃数据,然后通过R2T请求重新传输。发起人不应跟踪传输到目标或从目标传输来的数据(记分牌)。SCSI目标执行剩余计数计算,以检查通过命令实际向设备传输或从设备传输的数据量。由于重传和错误等原因,这可能与启动器发送和/或接收的数量不同。读取或双向命令隐式请求传输该命令涵盖的全部数据量。SCSI数据包通过使用协议中指定的标记与其相应的SCSI命令相匹配。

In addition, iSCSI initiators and targets MUST enforce some ordering rules. When unsolicited data is used, the order of the unsolicited data on each connection MUST match the order in which the commands on that connection are sent. Command and unsolicited data PDUs may be interleaved on a single connection as long as the ordering requirements of each are maintained (e.g., command N + 1 MAY be sent before the unsolicited Data-Out PDUs for command N, but the unsolicited Data-Out PDUs for command N MUST precede the unsolicited Data-Out PDUs of command N + 1). A target that receives data out of order MAY terminate the session.

此外,iSCSI启动器和目标必须强制执行某些排序规则。使用未经请求的数据时,每个连接上未经请求的数据的顺序必须与该连接上的命令的发送顺序相匹配。命令和未经请求的数据PDU可以在单个连接上交错,只要保持每个连接的订购要求(例如,命令N+1可以在命令N的未经请求的数据输出PDU之前发送,但命令N的未经请求的数据输出PDU必须在命令N+1的未经请求的数据输出PDU之前发送)。接收到无序数据的目标可能会终止会话。

4.2.5.3. Tags and Integrity Checks
4.2.5.3. 标签和完整性检查

Initiator tags for pending commands are unique initiator-wide for a session. Target tags are not strictly specified by the protocol. It is assumed that target tags are used by the target to tag (alone or in combination with the LUN) the solicited data. Target tags are generated by the target and "echoed" by the initiator.

挂起命令的启动器标记在会话的启动器范围内是唯一的。协议没有严格指定目标标记。假设目标使用目标标记(单独或与LUN组合)标记请求的数据。目标标记由目标生成,并由启动器“回显”。

These mechanisms are designed to accomplish efficient data delivery along with a large degree of control over the data flow.

这些机制旨在实现高效的数据交付以及对数据流的高度控制。

As the Initiator Task Tag is used to identify a task during its execution, the iSCSI initiator and target MUST verify that all other fields used in task-related PDUs have values that are consistent with the values used at the task instantiation, based on the Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the one used in the SCSI Command PDU used to instantiate the task). Using inconsistent field values is considered a protocol error.

由于启动器任务标记用于在任务执行期间标识任务,iSCSI启动器和目标必须基于启动器任务标记验证任务相关PDU中使用的所有其他字段的值是否与任务实例化时使用的值一致(例如,R2T PDU中使用的LUN必须与SCSI命令PDU中用于实例化任务的LUN相同)。使用不一致的字段值被视为协议错误。

4.2.5.4. SCSI Task Management during iSCSI Full Feature Phase
4.2.5.4. iSCSI全功能阶段的SCSI任务管理

SCSI task management assumes that individual tasks and task groups can be aborted based solely on the task tags (for individual tasks) or the timing of the task management command (for task groups) and that the task management action is executed synchronously -- i.e., no message involving an aborted task will be seen by the SCSI initiator after receiving the task management response. In iSCSI, initiators and targets interact asynchronously over several connections. iSCSI specifies the protocol mechanism and implementation requirements needed to present a synchronous SCSI view while using an asynchronous iSCSI infrastructure.

SCSI任务管理假定单个任务和任务组可以仅基于任务标记(针对单个任务)或任务管理命令(针对任务组)的计时而中止,并且任务管理操作是同步执行的,即。,SCSI启动器在收到任务管理响应后,不会看到任何涉及中止任务的消息。在iSCSI中,启动器和目标通过多个连接进行异步交互。iSCSI指定在使用异步iSCSI基础架构时显示同步SCSI视图所需的协议机制和实施要求。

4.2.6. iSCSI Connection Termination
4.2.6. iSCSI连接终止

An iSCSI connection may be terminated via a transport connection shutdown or a transport reset. A transport reset is assumed to be an exceptional event.

iSCSI连接可以通过传输连接关闭或传输重置来终止。传输重置被认为是异常事件。

Graceful TCP connection shutdowns are done by sending TCP FINs. A graceful transport connection shutdown SHOULD only be initiated by either party when the connection is not in the iSCSI Full Feature Phase. A target MAY terminate a Full Feature Phase connection on internal exception events, but it SHOULD announce the fact through an Asynchronous Message PDU. Connection termination with outstanding commands may require recovery actions.

正常的TCP连接关闭是通过发送TCP FIN完成的。只有当连接未处于iSCSI全功能阶段时,任何一方才应启动正常的传输连接关闭。目标可以在发生内部异常事件时终止全功能阶段连接,但它应该通过异步消息PDU宣布这一事实。未完成命令的连接终止可能需要恢复操作。

If a connection is terminated while in the Full Feature Phase, connection cleanup (see Section 7.14) is required prior to recovery. By doing connection cleanup before starting recovery, the initiator and target will avoid receiving stale PDUs after recovery.

如果在全功能阶段终止连接,则需要在恢复之前进行连接清理(参见第7.14节)。通过在开始恢复之前进行连接清理,启动器和目标将避免在恢复后接收过时的PDU。

4.2.7. iSCSI Names
4.2.7. iSCSI名称

Both targets and initiators require names for the purpose of identification. In addition, names enable iSCSI storage resources to be managed, regardless of location (address). An iSCSI Node Name is also the SCSI device name contained in the iSCSI node. The iSCSI name of a SCSI device is the principal object used in authentication of targets to initiators and initiators to targets. This name is also used to identify and manage iSCSI storage resources.

目标和发起者都需要姓名才能识别。此外,通过名称可以管理iSCSI存储资源,而不必考虑位置(地址)。iSCSI节点名称也是iSCSI节点中包含的SCSI设备名称。SCSI设备的iSCSI名称是用于向启动器验证目标和向目标验证启动器的主要对象。此名称还用于标识和管理iSCSI存储资源。

iSCSI names must be unique within the operation domain of the end user. However, because the operation domain of an IP network is potentially worldwide, the iSCSI name formats are architected to be worldwide unique. To assist naming authorities in the construction of worldwide unique names, iSCSI provides three name formats for different types of naming authorities.

iSCSI名称在最终用户的操作域中必须是唯一的。但是,由于IP网络的操作域可能是全球性的,因此iSCSI名称格式的体系结构是全球唯一的。为了帮助命名机构构建全球唯一的名称,iSCSI为不同类型的命名机构提供了三种名称格式。

iSCSI names are associated with iSCSI nodes, and not iSCSI network adapter cards, to ensure that the replacement of network adapter cards does not require reconfiguration of all SCSI and iSCSI resource allocation information.

iSCSI名称与iSCSI节点关联,而不是与iSCSI网络适配器卡关联,以确保网络适配器卡的更换不需要重新配置所有SCSI和iSCSI资源分配信息。

Some SCSI commands require that protocol-specific identifiers be communicated within SCSI CDBs. See Section 2.2 for the definition of the SCSI port name/identifier for iSCSI ports.

某些SCSI命令要求在SCSI CDB内通信特定于协议的标识符。有关iSCSI端口的SCSI端口名称/标识符的定义,请参见第2.2节。

An initiator may discover the iSCSI Target Names to which it has access, along with their addresses, using the SendTargets Text Request, or other techniques discussed in [RFC3721].

启动器可以使用SendTargets文本请求或[RFC3721]中讨论的其他技术来发现其有权访问的iSCSI目标名称及其地址。

iSCSI equipment that needs discovery functions beyond SendTargets SHOULD implement iSNS (see [RFC4171]) for extended discovery management capabilities and interoperability. Although [RFC3721] implies an SLP ([RFC2608]) implementation requirement, SLP has not been widely implemented or deployed for use with iSCSI in practice. iSCSI implementations therefore SHOULD NOT rely on SLP-based discovery interoperability.

需要SendTargets以外的发现功能的iSCSI设备应实施iSNS(请参见[RFC4171])以实现扩展的发现管理功能和互操作性。尽管[RFC3721]暗示了SLP([RFC2608])实施要求,但SLP在实践中并未广泛实施或部署用于iSCSI。因此,iSCSI实施不应依赖于基于SLP的发现互操作性。

4.2.7.1. iSCSI Name Properties
4.2.7.1. iSCSI名称属性

Each iSCSI node, whether it is an initiator, a target, or both, MUST have an iSCSI name. Whenever an iSCSI node contains an iSCSI initiator node and an iSCSI target node, the iSCSI Initiator Name MUST be the same as the iSCSI Target Name for the contained Nodes such that there is only one iSCSI Node Name for the iSCSI node overall. Note the related requirements in Section 9.2.1 on how to map CHAP names to iSCSI names in such a scenario.

每个iSCSI节点(无论是启动器、目标还是两者)都必须具有iSCSI名称。每当iSCSI节点包含iSCSI启动器节点和iSCSI目标节点时,iSCSI启动器名称必须与包含节点的iSCSI目标名称相同,以便整个iSCSI节点只有一个iSCSI节点名称。请注意第9.2.1节中有关在这种情况下如何将CHAP名称映射到iSCSI名称的相关要求。

Initiators and targets MUST support the receipt of iSCSI names of up to the maximum length of 223 bytes.

启动器和目标必须支持接收最大长度为223字节的iSCSI名称。

The initiator MUST present both its iSCSI Initiator Name and the iSCSI Target Name to which it wishes to connect in the first Login Request of a new session or connection. The only exception is if a Discovery session (see Section 4.3) is to be established. In this case, the iSCSI Initiator Name is still required, but the iSCSI Target Name MAY be omitted.

启动器必须在新会话或连接的第一个登录请求中同时显示其iSCSI启动器名称和要连接的iSCSI目标名称。唯一的例外是要建立发现会话(见第4.3节)。在这种情况下,仍然需要iSCSI启动器名称,但可以省略iSCSI目标名称。

iSCSI names have the following properties:

iSCSI名称具有以下属性:

- iSCSI names are globally unique. No two initiators or targets can have the same name.

- iSCSI名称是全局唯一的。两个启动器或目标不能具有相同的名称。

- iSCSI names are permanent. An iSCSI initiator node or target node has the same name for its lifetime.

- iSCSI名称是永久的。iSCSI启动器节点或目标节点在其生存期内具有相同的名称。

- iSCSI names do not imply a location or address. An iSCSI initiator or target can move or have multiple addresses. A change of address does not imply a change of name.

- iSCSI名称并不表示位置或地址。iSCSI启动器或目标可以移动或具有多个地址。地址的改变并不意味着姓名的改变。

- iSCSI names do not rely on a central name broker; the naming authority is distributed.

- iSCSI名称不依赖于中央名称代理;命名权限是分布式的。

- iSCSI names support integration with existing unique naming schemes.

- iSCSI名称支持与现有唯一命名方案的集成。

- iSCSI names rely on existing naming authorities. iSCSI does not create any new naming authority.

- iSCSI名称依赖于现有的命名机构。iSCSI不会创建任何新的命名机构。

The encoding of an iSCSI name has the following properties:

iSCSI名称的编码具有以下属性:

- iSCSI names have the same encoding method, regardless of the underlying protocols.

- iSCSI名称具有相同的编码方法,而与底层协议无关。

- iSCSI names are relatively simple to compare. The algorithm for comparing two iSCSI names for equivalence does not rely on an external server.

- iSCSI名称比较起来相对简单。比较两个iSCSI名称是否等效的算法不依赖于外部服务器。

- iSCSI names are composed only of printable ASCII and Unicode characters. iSCSI names allow the use of international character sets, but uppercase characters are prohibited. The iSCSI stringprep profile [RFC3722] maps uppercase characters to lowercase and SHOULD be used to prepare iSCSI names from input that may include uppercase characters. No whitespace characters are used in iSCSI names; see [RFC3722] for details.

- iSCSI名称仅由可打印的ASCII和Unicode字符组成。iSCSI名称允许使用国际字符集,但禁止使用大写字符。iSCSI stringprep配置文件[RFC3722]将大写字符映射为小写字符,并应用于从可能包含大写字符的输入中准备iSCSI名称。iSCSI名称中不使用空白字符;详见[RFC3722]。

- iSCSI names may be transported using both binary and ASCII-based protocols.

- iSCSI名称可以使用基于二进制和ASCII的协议传输。

An iSCSI name really names a logical software entity and is not tied to a port or other hardware that can be changed. For instance, an Initiator Name should name the iSCSI initiator node, not a particular NIC or HBA. When multiple NICs are used, they should generally all present the same iSCSI Initiator Name to the targets, because they are simply paths to the same SCSI layer. In most operating systems, the named entity is the operating system image.

iSCSI名称实际上是一个逻辑软件实体的名称,它与端口或其他可以更改的硬件无关。例如,启动器名称应命名iSCSI启动器节点,而不是特定的NIC或HBA。当使用多个NIC时,它们通常都应该向目标提供相同的iSCSI启动器名称,因为它们只是指向同一SCSI层的路径。在大多数操作系统中,命名实体是操作系统映像。

Similarly, a target name should not be tied to hardware interfaces that can be changed. A target name should identify the logical target and must be the same for the target, regardless of the physical portion being addressed. This assists iSCSI initiators in determining that the two targets it has discovered are really two paths to the same target.

类似地,目标名称不应绑定到可以更改的硬件接口。目标名称应标识逻辑目标,并且无论寻址的物理部分是什么,目标名称都必须相同。这有助于iSCSI启动器确定它发现的两个目标实际上是指向同一目标的两条路径。

The iSCSI name is designed to fulfill the functional requirements for Uniform Resource Names (URNs) [RFC1737]. For example, it is required that the name have a global scope, be independent of address or location, and be persistent and globally unique. Names must be extensible and scalable with the use of naming authorities. The name encoding should be both human and machine readable. See [RFC1737] for further requirements.

iSCSI名称旨在满足统一资源名称(URN)的功能要求[RFC1737]。例如,要求名称具有全局作用域,独立于地址或位置,并且具有持久性和全局唯一性。名称必须通过使用命名权限进行扩展和可伸缩。名称编码应该是人类和机器可读的。更多要求见[RFC1737]。

4.2.7.2. iSCSI Name Encoding
4.2.7.2. iSCSI名称编码

An iSCSI name MUST be a UTF-8 (see [RFC3629]) encoding of a string of Unicode characters with the following properties:

iSCSI名称必须是具有以下属性的Unicode字符字符串的UTF-8(请参见[RFC3629])编码:

- It is in Normalization Form C (see "Unicode Normalization Forms" [UNICODE]).

- 它是标准化形式C(参见“Unicode标准化形式”[Unicode])。

- It only contains characters allowed by the output of the iSCSI stringprep template (described in [RFC3722]).

- 它仅包含iSCSI stringprep模板输出所允许的字符(如[RFC3722]中所述)。

- The following characters are used for formatting iSCSI names:

- 以下字符用于格式化iSCSI名称:

dash ('-'=U+002d)

破折号('-'=U+002d)

dot ('.'=U+002e)

点('.'=U+002e)

           colon (':'=U+003a)
        
           colon (':'=U+003a)
        

- The UTF-8 encoding of the name is not larger than 223 bytes.

- 名称的UTF-8编码不大于223字节。

The stringprep process is described in [RFC3454]; iSCSI's use of the stringprep process is described in [RFC3722]. The stringprep process is a method designed by the Internationalized Domain Name (IDN) working group to translate human-typed strings into a format that can be compared as opaque strings. iSCSI names are expected to be used by administrators for purposes such as system configuration; for this reason, characters that may lead to human confusion among different iSCSI names (e.g., punctuation, spacing, diacritical marks) should be avoided, even when such characters are allowed as stringprep processing output by [RFC3722]. The stringprep process also converts strings into equivalent strings of lowercase characters.

[RFC3454]中描述了stringprep过程;[RFC3722]中描述了iSCSI对stringprep过程的使用。stringprep过程是由国际化域名(IDN)工作组设计的一种方法,用于将人工输入的字符串转换为可作为不透明字符串进行比较的格式。iSCSI名称预期将由管理员用于系统配置等目的;因此,即使[RFC3722]允许将这些字符作为stringprep处理输出,也应避免可能导致不同iSCSI名称之间的人为混淆的字符(例如标点、间距、变音符号)。stringprep进程还将字符串转换为等效的小写字符字符串。

The stringprep process does not need to be implemented if the names are generated using only characters allowed as output by the stringprep processing specified in [RFC3722]. Those allowed characters include all ASCII lowercase and numeric characters, as well as lowercase Unicode characters as specified in [RFC3722]. Once iSCSI names encoded in UTF-8 are "normalized" as described in this section, they may be safely compared byte for byte.

如果名称仅使用[RFC3722]中指定的stringprep处理所允许的输出字符生成,则无需执行stringprep处理。这些允许的字符包括所有ASCII小写和数字字符,以及[RFC3722]中指定的小写Unicode字符。一旦按照本节所述将UTF-8中编码的iSCSI名称“规范化”,就可以安全地逐字节比较它们。

4.2.7.3. iSCSI Name Structure
4.2.7.3. iSCSI名称结构

An iSCSI name consists of two parts -- a type designator followed by a unique name string.

iSCSI名称由两部分组成——一个类型指示符,后跟一个唯一的名称字符串。

iSCSI uses three existing naming authorities in constructing globally unique iSCSI names. The type designator in an iSCSI name indicates the naming authority on which the name is based. The three iSCSI name formats are the following:

iSCSI在构造全局唯一的iSCSI名称时使用了三个现有的命名机构。iSCSI名称中的类型指示符表示名称所基于的命名机构。三种iSCSI名称格式如下所示:

a) iSCSI-Qualified Name: based on domain names to identify a naming authority

a) iSCSI限定名称:基于域名来标识命名机构

b) NAA format Name: based on a naming format defined by [FC-FS3] for constructing globally unique identifiers, referred to as the Network Address Authority (NAA)

b) NAA格式名称:基于[FC-FS3]定义的用于构造全局唯一标识符的命名格式,称为网络地址授权(NAA)

c) EUI format Name: based on EUI names, where the IEEE Registration Authority assists in the formation of worldwide unique names (EUI-64 format)

c) EUI格式名称:基于EUI名称,IEEE注册机构协助形成全球唯一名称(EUI-64格式)

The corresponding type designator strings currently defined are:

当前定义的对应类型指示符字符串为:

a) iqn. - iSCSI Qualified name

a) iqn-iSCSI限定名

b) naa. - Remainder of the string is an INCITS T11-defined Network Address Authority identifier, in ASCII-encoded hexadecimal

b) naa字符串的其余部分是INCITS T11定义的网络地址授权标识符,采用ASCII编码的十六进制

c) eui. - Remainder of the string is an IEEE EUI-64 identifier, in ASCII-encoded hexadecimal

c) 尤伊字符串的其余部分是IEEE EUI-64标识符,采用ASCII编码的十六进制

These three naming authority designators were considered sufficient at the time of writing this document. The creation of additional naming type designators for iSCSI may be considered by the IETF and detailed in separate RFCs.

在编写本文件时,这三个命名机构名称已足够。IETF可考虑为iSCSI创建其他命名类型标识符,并在单独的RFC中详细说明。

The following table summarizes the current SCSI transport protocols and their naming formats.

下表总结了当前的SCSI传输协议及其命名格式。

        SCSI Transport Protocol       Naming Format
     +----------------------------+-------+-----+----+
     |                            | EUI-64| NAA |IQN |
     |----------------------------|-------|-----|----|
     | iSCSI (Internet SCSI)      |   X   |  X  | X  |
     |----------------------------|-------|-----|----|
     | FCP (Fibre Channel)        |       |  X  |    |
     |----------------------------|-------|-----|----|
     | SAS (Serial Attached SCSI) |       |  X  |    |
     +----------------------------+-------+-----+----+
        
        SCSI Transport Protocol       Naming Format
     +----------------------------+-------+-----+----+
     |                            | EUI-64| NAA |IQN |
     |----------------------------|-------|-----|----|
     | iSCSI (Internet SCSI)      |   X   |  X  | X  |
     |----------------------------|-------|-----|----|
     | FCP (Fibre Channel)        |       |  X  |    |
     |----------------------------|-------|-----|----|
     | SAS (Serial Attached SCSI) |       |  X  |    |
     +----------------------------+-------+-----+----+
        
4.2.7.4. Type "iqn." (iSCSI Qualified Name)
4.2.7.4. 键入“iqn.”(iSCSI限定名称)

This iSCSI name type can be used by any organization that owns a domain name. This naming format is useful when an end user or service provider wishes to assign iSCSI names for targets and/or initiators.

此iSCSI名称类型可由拥有域名的任何组织使用。当最终用户或服务提供商希望为目标和/或启动器分配iSCSI名称时,此命名格式非常有用。

To generate names of this type, the person or organization generating the name must own a registered domain name. This domain name does not have to resolve to an address; it just needs to be reserved to prevent others from generating iSCSI names using the same domain name.

要生成此类型的名称,生成名称的个人或组织必须拥有注册的域名。此域名不必解析为地址;它只需要保留,以防止其他人使用相同的域名生成iSCSI名称。

Since a domain name can expire, be acquired by another entity, or may be used to generate iSCSI names by both owners, the domain name must be additionally qualified by a date during which the naming authority owned the domain name. A date code is provided as part of the "iqn." format for this reason.

由于域名可能会过期、被另一个实体获取,或者可能被两个所有者用于生成iSCSI名称,因此必须在命名机构拥有该域名的日期之前对该域名进行附加限定。因此,日期代码作为“iqn.”格式的一部分提供。

The iSCSI qualified name string consists of:

iSCSI限定名称字符串包括:

- The string "iqn.", used to distinguish these names from "eui." formatted names.

- 字符串“iqn.”,用于区分这些名称与“eui.”格式的名称。

- A date code, in yyyy-mm format. This date MUST be a date during which the naming authority owned the domain name used in this format and SHOULD be the first month in which the domain name was owned by this naming authority at 00:01 GMT of the first day of the month. This date code uses the Gregorian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included.

- 日期代码,yyyy-mm格式。此日期必须是命名机构拥有此格式中使用的域名的日期,并且应该是该命名机构在该月第一天00:01 GMT拥有域名的第一个月。此日期代码使用公历。年份中的所有四位数字都必须存在。月份的两个数字都必须存在,一月==“01”和十二月==“12”。必须包括仪表板。

- A dot "."

- 一个“点”

- The reverse domain name of the naming authority (person or organization) creating this iSCSI name.

- 创建此iSCSI名称的命名机构(个人或组织)的反向域名。

- An optional, colon (:)-prefixed string within the character set and length boundaries that the owner of the domain name deems appropriate. This may contain product types, serial numbers, host identifiers, or software keys (e.g., it may include colons to separate organization boundaries). With the exception of the colon prefix, the owner of the domain name can assign everything after the reverse domain name as desired. It is the responsibility of the entity that is the naming authority to ensure that the iSCSI names it assigns are worldwide unique. For example, "Example Storage Arrays, Inc." might own the domain name "example.com".

- 域名所有者认为合适的字符集和长度边界内的可选冒号(:)前缀字符串。这可能包含产品类型、序列号、主机标识符或软件密钥(例如,它可能包括分隔组织边界的冒号)。除冒号前缀外,域名所有者可以根据需要分配反向域名后的所有内容。作为命名机构的实体有责任确保其分配的iSCSI名称在全球范围内是唯一的。例如,“example Storage Arrays,Inc.”可能拥有域名“example.com”。

The following are examples of iSCSI qualified names that might be generated by "EXAMPLE Storage Arrays, Inc."

以下是“EXAMPLE Storage Arrays,Inc.”可能生成的iSCSI限定名称示例

                    Naming     String defined by
      Type  Date     Auth      "example.com" naming authority
      +--++-----+ +---------+ +--------------------------------+
      | ||      | |         | |                                |
        
                    Naming     String defined by
      Type  Date     Auth      "example.com" naming authority
      +--++-----+ +---------+ +--------------------------------+
      | ||      | |         | |                                |
        

iqn.2001-04.com.example:storage:diskarrays-sn-a8675309 iqn.2001-04.com.example iqn.2001-04.com.example:storage.tape1.sys1.xyz iqn.2001-04.com.example:storage.disk2.sys1.xyz

iqn.2001-04.com.示例:存储:diskarrays-sn-a8675309 iqn.2001-04.com.示例iqn.2001-04.com.示例:storage.tape1.sys1.xyz iqn.2001-04.com.示例:storage.disk2.sys1.xyz

4.2.7.5. Type "eui." (IEEE EUI-64 Format)
4.2.7.5. 键入“eui.”(IEEE eui-64格式)

The IEEE Registration Authority provides a service for assigning globally unique identifiers [EUI]. The EUI-64 format is used to build a global identifier in other network protocols. For example, Fibre Channel defines a method of encoding it into a WorldWideName. For more information on registering for EUI identifiers, see [OUI].

IEEE注册机构提供分配全局唯一标识符[EUI]的服务。EUI-64格式用于在其他网络协议中构建全局标识符。例如,光纤通道定义了一种将其编码为WorldWideName的方法。有关注册EUI标识符的更多信息,请参阅[OUI]。

The format is "eui." followed by an EUI-64 identifier (16 ASCII-encoded hexadecimal digits).

格式为“eui”,后跟eui-64标识符(16位ASCII编码的十六进制数字)。

Example iSCSI name:

示例iSCSI名称:

         Type   EUI-64 identifier (ASCII-encoded hexadecimal)
         +--++--------------+
         |  ||              |
         eui.02004567A425678D
        
         Type   EUI-64 identifier (ASCII-encoded hexadecimal)
         +--++--------------+
         |  ||              |
         eui.02004567A425678D
        

The IEEE EUI-64 iSCSI name format might be used when a manufacturer is already registered with the IEEE Registration Authority and uses EUI-64 formatted worldwide unique names for its products.

如果制造商已在IEEE注册机构注册,并为其产品使用EUI-64格式的全球唯一名称,则可以使用IEEE EUI-64 iSCSI名称格式。

More examples of name construction are discussed in [RFC3721].

[RFC3721]中讨论了名称构造的更多示例。

4.2.7.6. Type "naa." (Network Address Authority)
4.2.7.6. 键入“naa.”(网络地址授权)

The INCITS T11 Framing and Signaling Specification [FC-FS3] defines a format called the Network Address Authority (NAA) format for constructing worldwide unique identifiers that use various identifier registration authorities. This identifier format is used by the Fibre Channel and SAS SCSI transport protocols. As FC and SAS constitute a large fraction of networked SCSI ports, the NAA format is a widely used format for SCSI transports. The objective behind iSCSI supporting a direct representation of an NAA format Name is to facilitate construction of a target device name that translates easily across multiple namespaces for a SCSI storage device containing ports served by different transports. More specifically, this format allows implementations wherein one NAA identifier can be assigned as the basis for the SCSI device name for a SCSI target with both SAS ports and iSCSI ports.

INCITS T11帧和信令规范[FC-FS3]定义了一种称为网络地址授权(NAA)格式的格式,用于构造使用各种标识符注册授权的全球唯一标识符。此标识符格式由光纤通道和SAS SCSI传输协议使用。由于FC和SAS构成了网络SCSI端口的很大一部分,NAA格式是SCSI传输中广泛使用的格式。iSCSI支持NAA格式名称的直接表示,其目的是为包含由不同传输服务的端口的SCSI存储设备构建一个目标设备名称,该名称可以轻松地跨多个名称空间进行转换。更具体地说,这种格式允许实现一个NAA标识符,作为同时具有SAS端口和iSCSI端口的SCSI目标的SCSI设备名称的基础。

The iSCSI NAA naming format is "naa.", followed by an NAA identifier represented in ASCII-encoded hexadecimal digits.

iSCSI NAA命名格式为“NAA”,后跟以ASCII编码的十六进制数字表示的NAA标识符。

An example of an iSCSI name with a 64-bit NAA value follows:

具有64位NAA值的iSCSI名称示例如下:

      Type  NAA identifier (ASCII-encoded hexadecimal)
      +--++--------------+
      |  ||              |
      naa.52004567BA64678D
        
      Type  NAA identifier (ASCII-encoded hexadecimal)
      +--++--------------+
      |  ||              |
      naa.52004567BA64678D
        

An example of an iSCSI name with a 128-bit NAA value follows:

具有128位NAA值的iSCSI名称示例如下:

      Type  NAA identifier (ASCII-encoded hexadecimal)
      +--++------------------------------+
      |  ||                              |
      naa.62004567BA64678D0123456789ABCDEF
        
      Type  NAA identifier (ASCII-encoded hexadecimal)
      +--++------------------------------+
      |  ||                              |
      naa.62004567BA64678D0123456789ABCDEF
        

The iSCSI NAA naming format might be used in an implementation when the infrastructure for generating NAA worldwide unique names is already in place because the device contains both SAS and iSCSI SCSI ports.

当用于生成NAA全球唯一名称的基础结构已经就绪时,可以在实现中使用iSCSI NAA命名格式,因为该设备同时包含SAS和iSCSI SCSI端口。

The NAA identifier formatted in an ASCII-hexadecimal representation has a maximum size of 32 characters (128-bit NAA format). As a result, there is no issue with this naming format exceeding the maximum size for iSCSI Node Names.

以ASCII十六进制表示形式格式化的NAA标识符的最大大小为32个字符(128位NAA格式)。因此,此命名格式不会超过iSCSI节点名称的最大大小。

4.2.8. Persistent State
4.2.8. 持续状态

iSCSI does not require any persistent state maintenance across sessions. However, in some cases, SCSI requires persistent identification of the SCSI initiator port name (see Sections 4.4.2 and 4.4.3.)

iSCSI不需要跨会话进行任何持久状态维护。但是,在某些情况下,SCSI需要持久标识SCSI启动器端口名(请参阅第4.4.2节和第4.4.3节)

iSCSI sessions do not persist through power cycles and boot operations.

iSCSI会话不会在电源循环和引导操作期间保持不变。

All iSCSI session and connection parameters are reinitialized on session and connection creation.

所有iSCSI会话和连接参数都会在会话和连接创建时重新初始化。

Commands persist beyond connection termination if the session persists and command recovery within the session is supported. However, when a connection is dropped, command execution, as perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the affected task), is suspended until a new allegiance is established by the "TASK REASSIGN" task management function. See Section 11.5.

如果会话持续存在并且支持会话内的命令恢复,则命令将在连接终止后继续存在。但是,当连接断开时,iSCSI感知到的命令执行(即涉及受影响任务的iSCSI协议交换)将暂停,直到“任务重新分配”任务管理功能建立新的忠诚。见第11.5节。

4.2.9. Message Synchronization and Steering
4.2.9. 消息同步和控制

iSCSI presents a mapping of the SCSI protocol onto TCP. This encapsulation is accomplished by sending iSCSI PDUs of varying lengths. Unfortunately, TCP does not have a built-in mechanism for signaling message boundaries at the TCP layer. iSCSI overcomes this obstacle by placing the message length in the iSCSI message header. This serves to delineate the end of the current message as well as the beginning of the next message.

iSCSI提供了SCSI协议到TCP的映射。此封装通过发送不同长度的iSCSI PDU来完成。不幸的是,TCP没有在TCP层为消息边界发送信号的内置机制。iSCSI通过将消息长度放在iSCSI消息头中克服了这一障碍。这用于描绘当前消息的结束以及下一消息的开始。

In situations where IP packets are delivered in order from the network, iSCSI message framing is not an issue and messages are processed one after the other. In the presence of IP packet reordering (i.e., frames being dropped), legacy TCP implementations store the "out of order" TCP segments in temporary buffers until the missing TCP segments arrive, at which time the data must be copied to the application buffers. In iSCSI, it is desirable to steer the SCSI data within these out-of-order TCP segments into the preallocated SCSI buffers rather than store them in temporary buffers. This decreases the need for dedicated reassembly buffers as well as the latency and bandwidth related to extra copies.

在IP数据包从网络按顺序传递的情况下,iSCSI消息帧不是问题,消息将逐个处理。在存在IP数据包重新排序(即丢弃帧)的情况下,传统TCP实现将“无序”TCP段存储在临时缓冲区中,直到丢失的TCP段到达,此时必须将数据复制到应用程序缓冲区。在iSCSI中,希望将这些无序TCP段中的SCSI数据引导到预先分配的SCSI缓冲区中,而不是将其存储在临时缓冲区中。这减少了对专用重组缓冲区的需要,以及与额外拷贝相关的延迟和带宽。

Relying solely on the "message length" information from the iSCSI message header may make it impossible to find iSCSI message boundaries in subsequent TCP segments due to the loss of a TCP segment that contains the iSCSI message length. The missing TCP segment(s) must be received before any of the following segments can be steered to the correct SCSI buffers (due to the inability to determine the iSCSI message boundaries). Since these segments cannot be steered to the correct location, they must be saved in temporary buffers that must then be copied to the SCSI buffers.

由于丢失了包含iSCSI消息长度的TCP段,仅依赖iSCSI消息头中的“消息长度”信息可能无法在后续TCP段中找到iSCSI消息边界。必须先接收丢失的TCP段,然后才能将以下任何段定向到正确的SCSI缓冲区(由于无法确定iSCSI消息边界)。由于无法将这些段定向到正确的位置,因此必须将它们保存在临时缓冲区中,然后将临时缓冲区复制到SCSI缓冲区中。

Different schemes can be used to recover synchronization. The details of any such schemes are beyond this protocol specification, but it suffices to note that [RFC4297] provides an overview of the direct data placement problem on IP networks, and [RFC5046] specifies a protocol extension for iSCSI that facilitates this direct data placement objective. The rest of this document refers to any such direct data placement protocol usage as an example of a "Sync and Steering layer".

可以使用不同的方案来恢复同步。任何此类方案的细节都超出了本协议规范的范围,但值得注意的是,[RFC4297]概述了IP网络上的直接数据放置问题,[RFC5046]为iSCSI指定了一个协议扩展,以实现此直接数据放置目标。本文档的其余部分将任何此类直接数据放置协议的使用作为“同步和指导层”的示例。

Under normal circumstances (no PDU loss or data reception out of order), iSCSI data steering can be accomplished by using the identifying tag and the data offset fields in the iSCSI header in addition to the TCP sequence number from the TCP header. The identifying tag helps associate the PDU with a SCSI buffer address, while the data offset and TCP sequence number are used to determine the offset within the buffer.

在正常情况下(没有PDU丢失或数据接收出现故障),除了使用TCP报头中的TCP序列号外,还可以使用iSCSI报头中的标识标签和数据偏移字段来完成iSCSI数据引导。标识标签有助于将PDU与SCSI缓冲区地址关联,而数据偏移量和TCP序列号用于确定缓冲区内的偏移量。

4.2.9.1. Sync/Steering and iSCSI PDU Length
4.2.9.1. 同步/转向和iSCSI PDU长度

When a large iSCSI message is sent, the TCP segment(s) that contains the iSCSI header may be lost. The remaining TCP segment(s) up to the next iSCSI message must be buffered (in temporary buffers) because the iSCSI header that indicates to which SCSI buffers the data are to be steered was lost. To minimize the amount of buffering, it is recommended that the iSCSI PDU length be restricted to a small value (perhaps a few TCP segments in length). During login, each end of the iSCSI session specifies the maximum iSCSI PDU length it will accept.

发送大型iSCSI消息时,包含iSCSI标头的TCP段可能会丢失。下一条iSCSI消息之前的剩余TCP段必须进行缓冲(在临时缓冲区中),因为指示数据将转向哪个SCSI缓冲区的iSCSI标头已丢失。为了最大限度地减少缓冲量,建议将iSCSI PDU长度限制为一个较小的值(长度可能为几个TCP段)。在登录期间,iSCSI会话的每一端都指定它将接受的最大iSCSI PDU长度。

4.3. iSCSI Session Types
4.3. iSCSI会话类型

iSCSI defines two types of sessions:

iSCSI定义了两种类型的会话:

a) Normal operational session - an unrestricted session.

a) 正常操作会话-非限制会话。

b) Discovery session - a session only opened for target discovery. The target MUST ONLY accept Text Requests with the SendTargets key and a Logout Request with reason "close the session". All other requests MUST be rejected.

b) 发现会话-仅为目标发现而打开的会话。目标必须只接受带有SendTargets键的文本请求和带有“关闭会话”原因的注销请求。必须拒绝所有其他请求。

The session type is defined during login with the SessionType=value parameter in the login command.

会话类型是在登录期间使用login命令中的SessionType=value参数定义的。

4.4. SCSI-to-iSCSI Concepts Mapping Model
4.4. SCSI到iSCSI概念映射模型

The following diagram shows an example of how multiple iSCSI nodes (targets in this case) can coexist within the same Network Entity and can share Network Portals (IP addresses and TCP ports). Other more complex configurations are also possible. For detailed descriptions of the components of these diagrams, see Section 4.4.1.

下图显示了多个iSCSI节点(本例中的目标)如何在同一网络实体内共存并共享网络入口(IP地址和TCP端口)的示例。其他更复杂的配置也是可能的。有关这些图表组件的详细说明,请参见第4.4.1节。

                 +-----------------------------------+
                 | Network Entity (iSCSI Client)     |
                 |                                   |
                 |          +-------------+          |
                 |          | iSCSI Node  |          |
                 |          | (Initiator) |          |
                 |          +-------------+          |
                 |              |      |             |
                 | +--------------+ +--------------+ |
                 | |Network Portal| |Network Portal| |
                 | |   192.0.2.4  | |   192.0.2.5  | |
                 +-+--------------+-+--------------+-+
                          |                  |
                          |   IP Networks    |
                          |                  |
                 +-+--------------+-+--------------+-+
                 | |Network Portal| |Network Portal| |
                 | |198.51.100.21 | |198.51.100.3  | |
                 | | TCP Port 3260| | TCP Port 3260| |
                 | +--------------+ +--------------+ |
                 |        |                  |       |
                 |         ------------------        |
                 |            |          |           |
                 | +-------------+ +--------------+  |
                 | | iSCSI Node  | | iSCSI Node   |  |
                 | | (Target)    | | (Target)     |  |
                 | +-------------+ +--------------+  |
                 |                                   |
                 |   Network Entity (iSCSI Server)   |
                 +-----------------------------------+
        
                 +-----------------------------------+
                 | Network Entity (iSCSI Client)     |
                 |                                   |
                 |          +-------------+          |
                 |          | iSCSI Node  |          |
                 |          | (Initiator) |          |
                 |          +-------------+          |
                 |              |      |             |
                 | +--------------+ +--------------+ |
                 | |Network Portal| |Network Portal| |
                 | |   192.0.2.4  | |   192.0.2.5  | |
                 +-+--------------+-+--------------+-+
                          |                  |
                          |   IP Networks    |
                          |                  |
                 +-+--------------+-+--------------+-+
                 | |Network Portal| |Network Portal| |
                 | |198.51.100.21 | |198.51.100.3  | |
                 | | TCP Port 3260| | TCP Port 3260| |
                 | +--------------+ +--------------+ |
                 |        |                  |       |
                 |         ------------------        |
                 |            |          |           |
                 | +-------------+ +--------------+  |
                 | | iSCSI Node  | | iSCSI Node   |  |
                 | | (Target)    | | (Target)     |  |
                 | +-------------+ +--------------+  |
                 |                                   |
                 |   Network Entity (iSCSI Server)   |
                 +-----------------------------------+
        
4.4.1. iSCSI Architecture Model
4.4.1. iSCSI体系结构模型

This section describes the part of the iSCSI Architecture Model that has the most bearing on the relationship between iSCSI and the SCSI Architecture Model.

本节介绍iSCSI体系结构模型中与iSCSI和SCSI体系结构模型之间的关系最为相关的部分。

- Network Entity - represents a device or gateway that is accessible from the IP network. A Network Entity must have one or more Network Portals (see the "Network Portal" item below), each of which can be used by some iSCSI nodes (see the next item) contained in that Network Entity to gain access to the IP network.

- 网络实体-表示可从IP网络访问的设备或网关。网络实体必须有一个或多个网络入口(请参阅下面的“网络入口”项),该网络实体中包含的某些iSCSI节点(请参阅下一项)可以使用每个入口访问IP网络。

- iSCSI Node - represents a single iSCSI initiator or iSCSI target, or an instance of each. There are one or more iSCSI nodes within a Network Entity. The iSCSI node is accessible via one or more Network Portals (see below). An iSCSI node is identified by its iSCSI name (see Sections 4.2.7 and 13). The separation of the iSCSI name from the addresses used by and for the iSCSI node allows multiple iSCSI nodes to use the same addresses and allows the same iSCSI node to use multiple addresses.

- iSCSI节点—表示单个iSCSI启动器或iSCSI目标,或每个iSCSI节点的一个实例。网络实体中有一个或多个iSCSI节点。iSCSI节点可通过一个或多个网络入口访问(请参见下文)。iSCSI节点由其iSCSI名称标识(请参阅第4.2.7和13节)。将iSCSI名称与iSCSI节点使用的地址分离,允许多个iSCSI节点使用相同的地址,并允许同一iSCSI节点使用多个地址。

- An alias string may also be associated with an iSCSI node. The alias allows an organization to associate a user-friendly string with the iSCSI name. However, the alias string is not a substitute for the iSCSI name.

- 别名字符串也可能与iSCSI节点关联。别名允许组织将用户友好的字符串与iSCSI名称关联。但是,别名字符串不能替代iSCSI名称。

- Network Portal - a component of a Network Entity that has a TCP/IP network address and that may be used by an iSCSI node within that Network Entity for the connection(s) within one of its iSCSI sessions. In an initiator, it is identified by its IP address. In a target, it is identified by its IP address and its listening TCP port.

- 网络入口—具有TCP/IP网络地址的网络实体的一个组件,该网络实体内的iSCSI节点可将该组件用于其一个iSCSI会话内的连接。在启动器中,它由其IP地址标识。在目标中,它由其IP地址和侦听TCP端口标识。

- Portal Groups - iSCSI supports multiple connections within the same session; some implementations will have the ability to combine connections in a session across multiple Network Portals. A portal group defines a set of Network Portals within an iSCSI node that collectively supports the capability of coordinating a session with connections that span these portals. Not all Network Portals within a portal group need to participate in every session connected through that portal group. One or more portal groups may provide access to an iSCSI node. Each Network Portal, as utilized by a given iSCSI node, belongs to exactly one portal group within that node. Portal groups are identified within an iSCSI node by a Portal Group Tag, a simple unsigned integer between 0 and 65535 (see

- 门户组—iSCSI支持同一会话中的多个连接;一些实现将能够在跨多个网络门户的会话中组合连接。门户组定义了iSCSI节点内的一组网络门户,这些门户共同支持通过跨这些门户的连接协调会话的功能。并非门户组中的所有网络门户都需要参与通过该门户组连接的每个会话。一个或多个门户组可以提供对iSCSI节点的访问。给定iSCSI节点使用的每个网络入口都只属于该节点内的一个入口组。iSCSI节点中的入口组由入口组标记标识,入口组标记是一个介于0和65535之间的简单无符号整数(请参阅

Section 13.9). All Network Portals with the same Portal Group Tag in the context of a given iSCSI node are in the same portal group.

第13.9节)。给定iSCSI节点上下文中具有相同门户组标记的所有网络门户都位于同一门户组中。

Both iSCSI initiators and iSCSI targets have portal groups, though only the iSCSI target portal groups are used directly in the iSCSI protocol (e.g., in SendTargets). For references to the initiator portal Groups, see Section 10.1.2.

iSCSI启动器和iSCSI目标都有入口组,但只有iSCSI目标入口组直接用于iSCSI协议(例如,在SendTargets中)。有关启动器门户组的参考,请参见第10.1.2节。

- Portals within a portal group should support similar session parameters, because they may participate in a common session.

- 门户组中的门户应支持类似的会话参数,因为它们可能参与公共会话。

The following diagram shows an example of one such configuration on a target and how a session that shares Network Portals within a portal group may be established.

下图显示了目标上的一个此类配置示例,以及如何建立在门户组内共享网络门户的会话。

       ----------------------------IP Network---------------------
              |                |                  |
         +----|----------------|----+        +----|---------+
         | +---------+ +---------+  |        | +---------+  |
         | | Network | | Network |  |        | | Network |  |
         | | Portal  | | Portal  |  |        | | Portal  |  |
         | +---------+ +---------+  |        | +---------+  |
         |    |                |    |        |    |         |
         |    |    Portal      |    |        |    | Portal  |
         |    |    Group 1     |    |        |    | Group 2 |
         +--------------------------+        +--------------+
              |                |                  |
     +--------|----------------|------------------|------------------+
     |        |                |                  |                  |
     | +----------------------------+ +----------------------------+ |
     | | iSCSI Session (Target side)| | iSCSI Session (Target side)| |
     | |                            | |                            | |
     | |        (TSIH = 56)         | |        (TSIH = 48)         | |
     | +----------------------------+ +----------------------------+ |
     |                                                               |
     |                      iSCSI Target Node                        |
     |             (within Network Entity, not shown)                |
     +---------------------------------------------------------------+
        
       ----------------------------IP Network---------------------
              |                |                  |
         +----|----------------|----+        +----|---------+
         | +---------+ +---------+  |        | +---------+  |
         | | Network | | Network |  |        | | Network |  |
         | | Portal  | | Portal  |  |        | | Portal  |  |
         | +---------+ +---------+  |        | +---------+  |
         |    |                |    |        |    |         |
         |    |    Portal      |    |        |    | Portal  |
         |    |    Group 1     |    |        |    | Group 2 |
         +--------------------------+        +--------------+
              |                |                  |
     +--------|----------------|------------------|------------------+
     |        |                |                  |                  |
     | +----------------------------+ +----------------------------+ |
     | | iSCSI Session (Target side)| | iSCSI Session (Target side)| |
     | |                            | |                            | |
     | |        (TSIH = 56)         | |        (TSIH = 48)         | |
     | +----------------------------+ +----------------------------+ |
     |                                                               |
     |                      iSCSI Target Node                        |
     |             (within Network Entity, not shown)                |
     +---------------------------------------------------------------+
        
4.4.2. SCSI Architecture Model
4.4.2. 构模型

This section describes the relationship between the SCSI Architecture Model [SAM2] and constructs of the SCSI device, SCSI port and I_T nexus, and the iSCSI constructs described in Section 4.4.1.

本节介绍SCSI体系结构模型[SAM2]与SCSI设备、SCSI端口和I_T nexus的结构之间的关系,以及第4.4.1节中描述的iSCSI结构。

This relationship implies implementation requirements in order to conform to the SAM-2 model and other SCSI operational functions.

这种关系意味着实现要求,以符合SAM-2模型和其他SCSI操作功能。

These requirements are detailed in Section 4.4.3.

这些要求详见第4.4.3节。

The following list outlines mappings of SCSI architectural elements to iSCSI.

以下列表概述了SCSI体系结构元素到iSCSI的映射。

a) SCSI Device - This is the SAM-2 term for an entity that contains one or more SCSI ports that are connected to a service delivery subsystem and supports a SCSI application protocol. For example, a SCSI initiator device contains one or more SCSI initiator ports and zero or more application clients. A SCSI target device contains one or more SCSI target ports and one or more LUs. For iSCSI, the SCSI device is the component within an iSCSI node that provides the SCSI functionality. As such, there can be at most one SCSI device within an iSCSI node. Access to the SCSI device can only be achieved in an iSCSI Normal operational session (see Section 4.3). The SCSI device name is defined to be the iSCSI name of the node and MUST be used in the iSCSI protocol.

a) SCSI设备-这是SAM-2术语,表示包含一个或多个连接到服务交付子系统并支持SCSI应用程序协议的SCSI端口的实体。例如,SCSI启动器设备包含一个或多个SCSI启动器端口和零个或多个应用程序客户端。SCSI目标设备包含一个或多个SCSI目标端口和一个或多个LU。对于iSCSI,SCSI设备是iSCSI节点中提供SCSI功能的组件。因此,iSCSI节点中最多可以有一个SCSI设备。只能在iSCSI正常操作会话中访问SCSI设备(请参阅第4.3节)。SCSI设备名称定义为节点的iSCSI名称,必须在iSCSI协议中使用。

b) SCSI Port - This is the SAM-2 term for an entity in a SCSI device that provides the SCSI functionality to interface with a service delivery subsystem or transport. For iSCSI, the definitions of the SCSI initiator port and the SCSI target port are different.

b) SCSI端口-这是SAM-2术语,用于表示SCSI设备中的实体,该设备提供SCSI功能以与服务交付子系统或传输接口。对于iSCSI,SCSI启动器端口和SCSI目标端口的定义不同。

SCSI initiator port: This maps to one endpoint of an iSCSI Normal operational session (see Section 4.3). An iSCSI Normal operational session is negotiated through the login process between an iSCSI initiator node and an iSCSI target node. At successful completion of this process, a SCSI initiator port is created within the SCSI initiator device. The SCSI initiator port Name and SCSI initiator port Identifier are both defined to be the iSCSI Initiator Name together with (a) a label that identifies it as an initiator port name/identifier and (b) the ISID portion of the session identifier.

SCSI启动器端口:此端口映射到iSCSI正常操作会话的一个端点(请参阅第4.3节)。iSCSI正常操作会话通过iSCSI启动器节点和iSCSI目标节点之间的登录过程进行协商。成功完成此过程后,将在SCSI启动器设备中创建SCSI启动器端口。SCSI启动器端口名称和SCSI启动器端口标识符都定义为iSCSI启动器名称,以及(a)将其标识为启动器端口名称/标识符的标签和(b)会话标识符的ISID部分。

SCSI target port: This maps to an iSCSI target portal group. The SCSI Target Port Name and the SCSI Target Port Identifier are both defined to be the iSCSI Target Name together with (a) a label that identifies it as a target port name/identifier and (b) the Target Portal Group Tag.

SCSI目标端口:此端口映射到iSCSI目标门户组。SCSI目标端口名称和SCSI目标端口标识符都被定义为iSCSI目标名称,以及(a)将其标识为目标端口名称/标识符的标签和(b)目标门户组标记。

The SCSI port name MUST be used in iSCSI. When used in SCSI parameter data, the SCSI port name MUST be encoded as:

iSCSI中必须使用SCSI端口名。在SCSI参数数据中使用时,SCSI端口名必须编码为:

1) the iSCSI name in UTF-8 format, followed by

1) UTF-8格式的iSCSI名称,后跟

2) a comma separator (1 byte), followed by

2) 逗号分隔符(1字节),后跟

3) the ASCII character 'i' (for SCSI initiator port) or the ASCII character 't' (for SCSI target port) (1 byte), followed by

3) ASCII字符“i”(用于SCSI启动器端口)或ASCII字符“t”(用于SCSI目标端口)(1字节),后跟

4) a comma separator (1 byte), followed by

4) 逗号分隔符(1字节),后跟

5) a text encoding as a hex-constant (see Section 6.1) of the ISID (for SCSI initiator port) or the Target Portal Group Tag (for SCSI target port), including the initial 0X or 0x and the terminating null (15 bytes for iSCSI initiator port, 7 bytes for iSCSI target port).

5) 作为ISID(用于SCSI启动器端口)或目标门户组标记(用于SCSI目标端口)的十六进制常量(参见第6.1节)的文本编码,包括初始0X或0X和终止null(对于iSCSI启动器端口为15字节,对于iSCSI目标端口为7字节)。

The ASCII character 'i' or 't' is the label that identifies this port as either a SCSI initiator port or a SCSI target port.

ASCII字符“i”或“t”是将此端口标识为SCSI启动器端口或SCSI目标端口的标签。

c) I_T nexus - This indicates a relationship between a SCSI initiator port and a SCSI target port, according to [SAM2]. For iSCSI, this relationship is a session, defined as a relationship between an iSCSI initiator's end of the session (SCSI initiator port) and the iSCSI target's portal group. The I_T nexus can be identified by the conjunction of the SCSI port names or by the iSCSI session identifier (SSID). iSCSI defines the I_T nexus identifier to be the tuple (iSCSI Initiator Name + ",i,0x" + ISID in text format, iSCSI Target Name + ",t,0x" + Target Portal Group Tag in text format). An uppercase hex prefix "0X" may alternatively be used in place of "0x".

c) I_T nexus-根据[SAM2],这表示SCSI启动器端口和SCSI目标端口之间的关系。对于iSCSI,此关系是一个会话,定义为iSCSI启动器的会话结束(SCSI启动器端口)与iSCSI目标的入口组之间的关系。I_T nexus可以通过连接SCSI端口名或iSCSI会话标识符(SSID)来识别。iSCSI将I_T nexus标识符定义为元组(iSCSI启动器名称+”,I,0x“+文本格式的ISID,iSCSI目标名称+”,T,0x“+文本格式的目标门户组标记)。也可以使用大写十六进制前缀“0X”代替“0X”。

NOTE: The I_T nexus identifier is not equal to the SSID.

注意:I_T nexus标识符不等于SSID。

4.4.3. Consequences of the Model
4.4.3. 模型的后果

This section describes implementation and behavioral requirements that result from the mapping of SCSI constructs to the iSCSI constructs defined above. Between a given SCSI initiator port and a given SCSI target port, only one I_T nexus (session) can exist. No more than one nexus relationship (parallel nexus) is allowed by [SAM2]. Therefore, at any given time, only one session with the same SSID can exist between a given iSCSI initiator node and an iSCSI target node.

本节描述了将SCSI结构映射到上面定义的iSCSI结构时产生的实现和行为要求。在给定的SCSI启动器端口和给定的SCSI目标端口之间,只能存在一个I_T nexus(会话)。[SAM2]不允许有多个nexus关系(并行nexus)。因此,在任何给定时间,给定iSCSI启动器节点和iSCSI目标节点之间只能存在一个具有相同SSID的会话。

These assumptions lead to the following conclusions and requirements:

这些假设得出以下结论和要求:

ISID RULE: Between a given iSCSI initiator and iSCSI target portal group (SCSI target port), there can only be one session with a given value for the ISID that identifies the SCSI initiator port. See Section 11.12.5.

ISID规则:在给定的iSCSI启动器和iSCSI目标门户组(SCSI目标端口)之间,只有一个会话具有标识SCSI启动器端口的ISID的给定值。见第11.12.5节。

The structure of the ISID that contains a naming authority component (see Section 11.12.5 and [RFC3721]) provides a mechanism to facilitate compliance with the ISID RULE. See Section 10.1.1.

包含命名机构组件的ISID结构(见第11.12.5节和[RFC3721])提供了一种机制,以促进遵守ISID规则。见第10.1.1节。

The iSCSI initiator node should manage the assignment of ISIDs prior to session initiation. The "ISID RULE" does not preclude the use of the same ISID from the same iSCSI initiator with different target portal groups on the same iSCSI target or on other iSCSI targets (see Section 10.1.1). Allowing this would be analogous to a single SCSI initiator port having relationships (nexus) with multiple SCSI target ports on the same SCSI target device or SCSI target ports on other SCSI target devices. It is also possible to have multiple sessions with different ISIDs to the same target portal group. Each such session would be considered to be with a different initiator even when the sessions originate from the same initiator device. The same ISID may be used by a different iSCSI initiator because it is the iSCSI name together with the ISID that identifies the SCSI initiator port.

iSCSI启动器节点应在会话启动之前管理ISID的分配。“ISID规则”不排除在同一iSCSI目标或其他iSCSI目标上使用来自同一iSCSI启动器的同一ISID以及不同的目标门户组(请参阅第10.1.1节)。允许这样做类似于单个SCSI启动器端口与同一SCSI目标设备上的多个SCSI目标端口或其他SCSI目标设备上的SCSI目标端口具有关系(nexus)。对于同一目标门户组,也可以有多个具有不同ISID的会话。即使会话来自同一个启动器设备,每个这样的会话也将被视为具有不同的启动器。不同的iSCSI启动器可能使用相同的ISID,因为标识SCSI启动器端口的是iSCSI名称和ISID。

NOTE: A consequence of the ISID RULE and the specification for the I_T nexus identifier is that two nexuses with the same identifier should never exist at the same time.

注:ISID规则和I_T nexus标识符规范的结果是,具有相同标识符的两个nexus不应同时存在。

TSIH RULE: The iSCSI target selects a non-zero value for the TSIH at session creation (when an initiator presents a 0 value at login). After being selected, the same TSIH value MUST be used whenever the initiator or target refers to the session and a TSIH is required.

TSIH规则:iSCSI目标在会话创建时为TSIH选择非零值(当启动器在登录时显示0值时)。选择后,无论何时启动器或目标引用会话并且需要TSIH,都必须使用相同的TSIH值。

4.4.3.1. I_T Nexus State
4.4.3.1. I_T Nexus State

Certain nexus relationships contain an explicit state (e.g., initiator-specific mode pages) that may need to be preserved by the device server [SAM2] in a LU through changes or failures in the iSCSI layer (e.g., session failures). In order for that state to be restored, the iSCSI initiator should reestablish its session (re-login) to the same target portal group using the previous ISID. That is, it should reinstate the session via iSCSI session reinstatement (Section 6.3.5) or continue via session continuation (Section 6.3.6). This is because the SCSI initiator port identifier and the SCSI target port identifier (or relative target port) form the datum that the SCSI LU device server uses to identify the I_T nexus.

某些nexus关系包含一个显式状态(例如,特定于启动器的模式页面),该状态可能需要通过iSCSI层中的更改或故障(例如,会话故障)由LU中的设备服务器[SAM2]保留。为了恢复该状态,iSCSI启动器应使用以前的ISID重新建立其到同一目标门户组的会话(重新登录)。也就是说,它应该通过iSCSI会话恢复(第6.3.5节)或通过会话继续(第6.3.6节)来恢复会话。这是因为SCSI启动器端口标识符和SCSI目标端口标识符(或相对目标端口)构成SCSI LU设备服务器用于标识I_T连接的数据。

4.4.3.2. Reservations
4.4.3.2. 保留地

There are two reservation management methods defined in the SCSI standards: reserve/release reservations, based on the RESERVE and RELEASE commands [SPC2]; and persistent reservations, based on the PERSISTENT RESERVE IN and PERSISTENT RESERVE OUT commands [SPC3]. Reserve/release reservations are obsolete [SPC3] and should not be used. Persistent reservations are suggested as an alternative; see Annex B of [SPC4].

SCSI标准中定义了两种保留管理方法:保留/释放保留,基于保留和释放命令[SPC2];和持久保留,基于持久保留输入和持久保留输出命令[SPC3]。保留/释放保留已过时[SPC3],不应使用。建议作为一种替代办法,持续保留;见[SPC4]附件B。

State for persistent reservations is required to persist through changes and failures at the iSCSI layer that result in I_T nexus failures; see [SPC3] for details and specific requirements.

在iSCSI层发生导致I_T nexus故障的更改和故障时,需要持续保留状态;有关详细信息和具体要求,请参见[SPC3]。

In contrast, [SPC2] does not specify detailed persistence requirements for reserve/release reservation state after an I_T nexus failure. Nonetheless, when reserve/release reservations are supported by an iSCSI target, the preferred implementation approach is to preserve reserve/release reservation state for iSCSI session reinstatement (see Section 6.3.5) or session continuation (see Section 6.3.6).

相反,[SPC2]没有为I_T nexus故障后的保留/释放保留状态指定详细的持久性要求。尽管如此,当iSCSI目标支持保留/释放保留时,首选的实现方法是保留保留/释放保留状态,以便iSCSI会话恢复(请参见第6.3.5节)或会话继续(请参见第6.3.6节)。

Two additional caveats apply to reserve/release reservations:

另外两个注意事项适用于保留/解除保留:

- Retention of a failed session's reserve/release reservation state by an iSCSI target, even after that failed iSCSI session is not reinstated or continued, may require an initiator to issue a reset (e.g., LOGICAL UNIT RESET; see Section 11.5) in order to remove that reservation state.

- iSCSI目标保留失败会话的保留/释放保留状态(即使在失败的iSCSI会话未恢复或继续之后)可能需要启动器发出重置(例如,逻辑单元重置;请参阅第11.5节)以删除该保留状态。

- Reserve/release reservations may not behave as expected when persistent reservations are also used on the same LU; see the discussion of "Exceptions to SPC-2 RESERVE and RELEASE behavior" in [SPC4].

- 当在同一个LU上也使用了持久保留时,保留/释放保留可能不会按预期运行;参见[SPC4]中“SPC-2保留和释放行为的例外情况”的讨论。

4.5. iSCSI UML Model
4.5. iSCSI UML模型

This section presents the application of the UML modeling concepts discussed in Section 3 to the iSCSI and SCSI Architecture Model discussed in Section 4.4.

本节介绍第3节中讨论的UML建模概念在第4.4节中讨论的iSCSI和SCSI体系结构模型中的应用。

                       +----------------+
                       | Network Entity |
                       +----------------+
                            @ 1     @ 1
                            |       |
     +----------------------+       |
     |                              |
     |                              | 0..*
     |                   +------------------+
     |                   | iSCSI Node       |
     |                   +------------------+
     |                       @       @
     |                       |       |
     |           +-----------+ =(a)= +-----------+
     |           |                               |
     |           | 0..1                          | 0..1
     | +------------------------+       +----------------------+
     | |    iSCSI Target Node   |       | iSCSI Initiator Node |
     | +------------------------+       +----------------------+
     |             @ 1                            @ 1
     |             +---------------+              |
     |                        1..* |              | 1..*
     |                    +-----------------------------+
     |                    |         Portal Group        |
     |                    +-----------------------------+
     |                                     O 1
     |                                     |
     |                                     | 1..*
     |               1..* +------------------------+
     +--------------------|        Network Portal  |
                          +------------------------+
        
                       +----------------+
                       | Network Entity |
                       +----------------+
                            @ 1     @ 1
                            |       |
     +----------------------+       |
     |                              |
     |                              | 0..*
     |                   +------------------+
     |                   | iSCSI Node       |
     |                   +------------------+
     |                       @       @
     |                       |       |
     |           +-----------+ =(a)= +-----------+
     |           |                               |
     |           | 0..1                          | 0..1
     | +------------------------+       +----------------------+
     | |    iSCSI Target Node   |       | iSCSI Initiator Node |
     | +------------------------+       +----------------------+
     |             @ 1                            @ 1
     |             +---------------+              |
     |                        1..* |              | 1..*
     |                    +-----------------------------+
     |                    |         Portal Group        |
     |                    +-----------------------------+
     |                                     O 1
     |                                     |
     |                                     | 1..*
     |               1..* +------------------------+
     +--------------------|        Network Portal  |
                          +------------------------+
        

(a) Each instance of an iSCSI node class MUST contain one iSCSI target node instance, one iSCSI initiator node instance, or both.

(a) iSCSI节点类的每个实例都必须包含一个iSCSI目标节点实例、一个iSCSI启动器节点实例或两者。

                    +----------------+
                    | Network Entity |
                    +----------------+
                         @ 1         @ 1
                         |           |              +------------------+
   +---------------------+           |              |   iSCSI Session  |
   |                                 |              +------------------+
   |                                 | 0..*         |     SSID[1]      |
   |                  +--------------------+        |     ISID[1]      |
   |                  |      iSCSI Node    |        +------------------+
   |                  +--------------------+                   @ 1
   |                  | iSCSI Node Name[1] |                   |
   |                  |    Alias [0..1]    |                   | 0..*
   |                  +--------------------+        +------------------+
   |                  |                    |        | iSCSI Connection |
   |                  +--------------------+        +------------------+
   |                         @ 1         @ 1        |      CID[1]      |
   |                         |           |          +------------------+
   |           +-------------+ ==(b)==   +---------+              0..* |
   |           | 1                                 | 1                 |
   | +------------------------+             +------------------------+ |
   | |   iSCSI Target Node    |             | iSCSI Initiator Node   | |
   | +------------------------+             +------------------------+ |
   | | iSCSI Target Name [1]  |             |iSCSI Initiator Name [1]| |
   | +------------------------+             +------------------------+ |
   |            @ 1                                    @ 1             |
   |            | 1..*                                 | 1..*          |
   | +--------------------------+           +------------------------+ |
   | |   Target Portal Group    |           | Initiator Portal Group | |
   | +--------------------------+           +------------------------+ |
   | |Target Portal Group Tag[1]|           | Portal Group Tag[1]    | |
   | +--------------------------+           +------------------------+ |
   |            o 1                                    o 1             |
   |            +------------+              +----------+               |
   |                    1..* |              | 1..*                     |
   |                +-------------------------+                        |
   |                |          Network Portal |                        |
   |                +-------------------------+                        |
   |          1..*  |         IP Address [1]  | 1                      |
   +----------------|         TCP Port [0..1] |<-----------------------+
                    +-------------------------+
        
                    +----------------+
                    | Network Entity |
                    +----------------+
                         @ 1         @ 1
                         |           |              +------------------+
   +---------------------+           |              |   iSCSI Session  |
   |                                 |              +------------------+
   |                                 | 0..*         |     SSID[1]      |
   |                  +--------------------+        |     ISID[1]      |
   |                  |      iSCSI Node    |        +------------------+
   |                  +--------------------+                   @ 1
   |                  | iSCSI Node Name[1] |                   |
   |                  |    Alias [0..1]    |                   | 0..*
   |                  +--------------------+        +------------------+
   |                  |                    |        | iSCSI Connection |
   |                  +--------------------+        +------------------+
   |                         @ 1         @ 1        |      CID[1]      |
   |                         |           |          +------------------+
   |           +-------------+ ==(b)==   +---------+              0..* |
   |           | 1                                 | 1                 |
   | +------------------------+             +------------------------+ |
   | |   iSCSI Target Node    |             | iSCSI Initiator Node   | |
   | +------------------------+             +------------------------+ |
   | | iSCSI Target Name [1]  |             |iSCSI Initiator Name [1]| |
   | +------------------------+             +------------------------+ |
   |            @ 1                                    @ 1             |
   |            | 1..*                                 | 1..*          |
   | +--------------------------+           +------------------------+ |
   | |   Target Portal Group    |           | Initiator Portal Group | |
   | +--------------------------+           +------------------------+ |
   | |Target Portal Group Tag[1]|           | Portal Group Tag[1]    | |
   | +--------------------------+           +------------------------+ |
   |            o 1                                    o 1             |
   |            +------------+              +----------+               |
   |                    1..* |              | 1..*                     |
   |                +-------------------------+                        |
   |                |          Network Portal |                        |
   |                +-------------------------+                        |
   |          1..*  |         IP Address [1]  | 1                      |
   +----------------|         TCP Port [0..1] |<-----------------------+
                    +-------------------------+
        

(b) Each instance of an iSCSI node class MUST contain one iSCSI target node instance, one iSCSI initiator node instance, or both. However, in all scenarios, note that an iSCSI node MUST only have a single iSCSI name. Note the related requirement in Section 4.2.7.1.

(b) iSCSI节点类的每个实例都必须包含一个iSCSI目标节点实例、一个iSCSI启动器节点实例或两者。但是,在所有情况下,请注意,iSCSI节点必须只有一个iSCSI名称。注意第4.2.7.1节中的相关要求。

4.6. Request/Response Summary
4.6. 请求/答复摘要

This section lists and briefly describes all the iSCSI PDU types (requests and responses).

本节列出并简要介绍所有iSCSI PDU类型(请求和响应)。

All iSCSI PDUs are built as a set of one or more header segments (basic and auxiliary) and zero or one data segments. The header group and the data segment may each be followed by a CRC (digest).

所有iSCSI PDU都构建为一组一个或多个报头段(基本和辅助)以及零个或一个数据段。报头组和数据段后面都可以跟一个CRC(摘要)。

The basic header segment has a fixed length of 48 bytes.

基本头段的固定长度为48字节。

4.6.1. Request/Response Types Carrying SCSI Payload
4.6.1. 承载SCSI负载的请求/响应类型
4.6.1.1. SCSI Command
4.6.1.1. SCSI命令

This request carries the SCSI CDB and all the other SCSI Execute Command [SAM2] procedure call IN arguments, such as task attributes, Expected Data Transfer Length for one or both transfer directions (the latter for bidirectional commands), and a task tag (as part of the I_T_L_x nexus). The I_T_L nexus is derived by the initiator and target from the LUN field in the request, and the I_T nexus is implicit in the session identification.

此请求携带SCSI CDB和所有其他SCSI Execute Command[SAM2]过程调用参数,例如任务属性、一个或两个传输方向的预期数据传输长度(后者用于双向命令)和任务标记(作为I_T_L_x nexus的一部分)。I_T_L nexus由发起方和目标方从请求中的LUN字段派生,并且I_T nexus隐含在会话标识中。

In addition, the SCSI Command PDU carries information required for the proper operation of the iSCSI protocol -- the command sequence number (CmdSN) and the expected status sequence number (ExpStatSN) on the connection it is issued.

此外,SCSI命令PDU还包含正确操作iSCSI协议所需的信息—发出连接的命令序列号(CmdSN)和预期状态序列号(ExpStatSN)。

All or part of the SCSI output (write) data associated with the SCSI command may be sent as part of the SCSI Command PDU as a data segment.

与SCSI命令关联的全部或部分SCSI输出(写入)数据可以作为SCSI命令PDU的一部分作为数据段发送。

4.6.1.2. SCSI Response
4.6.1.2. SCSI响应

The SCSI Response carries all the SCSI Execute Command procedure call (see [SAM2]) OUT arguments and the SCSI Execute Command procedure call return value.

SCSI响应包含所有SCSI执行命令过程调用(请参见[SAM2])OUT参数和SCSI执行命令过程调用返回值。

The SCSI Response contains the residual counts from the operation, if any; an indication of whether the counts represent an overflow or an underflow; and the SCSI status if the status is valid or a response code (a non-zero return value for the Execute Command procedure call) if the status is not valid.

SCSI响应包含操作的剩余计数(如果有);指示计数是溢出还是下溢;如果状态有效,则显示SCSI状态;如果状态无效,则显示响应代码(执行命令过程调用的非零返回值)。

For a valid status that indicates that the command has been processed but resulted in an exception (e.g., a SCSI CHECK CONDITION), the PDU data segment contains the associated sense data. The use of Autosense ([SAM2]) is REQUIRED by iSCSI.

对于指示命令已被处理但导致异常(例如SCSI检查条件)的有效状态,PDU数据段包含相关的检测数据。iSCSI要求使用Autosense([SAM2])。

Some data segment content may also be associated (in the data segment) with a non-zero response code.

某些数据段内容还可能(在数据段中)与非零响应代码相关联。

In addition, the SCSI Response PDU carries information required for the proper operation of the iSCSI protocol:

此外,SCSI响应PDU包含正确操作iSCSI协议所需的信息:

- ExpDataSN - the number of Data-In PDUs that a target has sent (to enable the initiator to check that all have arrived)

- ExpDataSN—目标已发送的PDU中的数据数(使启动器能够检查所有数据是否已到达)

- StatSN - the status sequence number on this connection

- StatSN—此连接上的状态序列号

- ExpCmdSN - the next expected command sequence number at the target

- ExpCmdSN—目标上的下一个预期命令序列号

- MaxCmdSN - the maximum CmdSN acceptable at the target from this initiator

- MaxCmdSN—此启动器在目标位置可接受的最大CmdSN

4.6.1.3. Task Management Function Request
4.6.1.3. 任务管理功能请求

The Task Management Function Request provides an initiator with a way to explicitly control the execution of one or more SCSI tasks or iSCSI functions. The PDU carries a function identifier (i.e., which task management function to perform) and enough information to unequivocally identify the task or task set on which to perform the action, even if the task(s) to act upon has not yet arrived or has been discarded due to an error.

任务管理功能请求为启动器提供了显式控制一个或多个SCSI任务或iSCSI功能执行的方法。PDU带有一个功能标识符(即,要执行的任务管理功能)和足够的信息,以明确标识要在其上执行操作的任务或任务集,即使要执行的任务尚未到达或由于错误而被丢弃。

The referenced tag identifies an individual task if the function refers to an individual task.

如果函数引用单个任务,则引用的标记标识单个任务。

The I_T_L nexus identifies task sets. In iSCSI, the I_T_L nexus is identified by the LUN and the session identification (the session identifies an I_T nexus).

I_T_L nexus标识任务集。在iSCSI中,I_T_L连接由LUN和会话标识(会话标识I_T连接)标识。

For task sets, the CmdSN of the Task Management Function Request helps identify the tasks upon which to act, namely all tasks associated with a LUN and having a CmdSN preceding the Task Management Function Request CmdSN.

对于任务集,任务管理功能请求的CmdSN有助于识别要执行操作的任务,即与LUN关联且在任务管理功能请求CmdSN之前具有CmdSN的所有任务。

For a task management function, the coordination between responses to the tasks affected and the Task Management Function Response is done by the target.

对于任务管理功能,受影响任务的响应与任务管理功能响应之间的协调由目标完成。

4.6.1.4. Task Management Function Response
4.6.1.4. 任务管理功能响应

The Task Management Function Response carries an indication of function completion for a Task Management Function Request, including how it completed (response and qualifier) and additional information for failure responses.

任务管理功能响应包含任务管理功能请求的功能完成指示,包括其完成方式(响应和限定符)以及故障响应的附加信息。

After the Task Management Function Response indicates task management function completion, the initiator will not receive any additional responses from the affected tasks.

在任务管理功能响应指示任务管理功能完成后,启动器将不会收到来自受影响任务的任何其他响应。

4.6.1.5. SCSI Data-Out and SCSI Data-In
4.6.1.5. SCSI数据输出和SCSI数据输入

SCSI Data-Out and SCSI Data-In are the main vehicles by which SCSI data payload is carried between the initiator and target. Data payload is associated with a specific SCSI command through the Initiator Task Tag. For target convenience, outgoing solicited data also carries a Target Transfer Tag (copied from R2T) and the LUN. Each PDU contains the payload length and the data offset relative to the buffer address contained in the SCSI Execute Command procedure call.

SCSI数据输出和SCSI数据输入是SCSI数据有效负载在启动器和目标之间传输的主要载体。数据有效负载通过启动器任务标记与特定SCSI命令相关联。为方便目标,传出请求的数据还带有目标传输标记(从R2T复制)和LUN。每个PDU包含有效负载长度和相对于SCSI执行命令过程调用中包含的缓冲区地址的数据偏移量。

In each direction, the data transfer is split into "sequences". An end-of-sequence is indicated by the F bit.

在每个方向上,数据传输被分成“序列”。序列的末尾由F位表示。

An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in response to an R2T.

传出序列要么是未经请求的(只有第一个序列可以是未经请求的),要么由响应R2T而发送的所有数据输出PDU组成。

Input sequences enable the switching of direction for bidirectional commands as required.

输入序列可根据需要切换双向命令的方向。

For input, the target may request positive acknowledgment of input data. This is limited to sessions that support error recovery and is implemented through the A bit in the SCSI Data-In PDU header.

对于输入,目标可以请求输入数据的肯定确认。这仅限于支持错误恢复的会话,并通过SCSI Data in PDU头中的A位实现。

Data-In and Data-Out PDUs also carry the DataSN to enable the initiator and target to detect missing PDUs (discarded due to an error).

数据输入和数据输出PDU还携带数据N,以使启动器和目标能够检测丢失的PDU(由于错误而丢弃)。

In addition, the StatSN is carried by the Data-In PDUs.

此外,StatSN由PDU中的数据携带。

To enable a SCSI command to be processed while involving a minimum number of messages, the last SCSI Data-In PDU passed for a command may also contain the status if the status indicates termination with no exceptions (no sense or response involved).

为了使SCSI命令能够在涉及最少消息数的情况下进行处理,如果状态指示无异常终止(不涉及检测或响应),则为命令传递的PDU中的最后一个SCSI数据也可能包含状态。

4.6.1.6. Ready To Transfer (R2T)
4.6.1.6. 准备转移(R2T)

R2T is the mechanism by which the SCSI target "requests" the initiator for output data. R2T specifies to the initiator the offset of the requested data relative to the buffer address from the Execute Command procedure call and the length of the solicited data.

R2T是SCSI目标向启动器“请求”输出数据的机制。R2T向发起者指定相对于来自执行命令过程调用的缓冲区地址的请求数据的偏移量和请求数据的长度。

To help the SCSI target associate the resulting Data-Out with an R2T, the R2T carries a Target Transfer Tag that will be copied by the initiator in the solicited SCSI Data-Out PDUs. There are no protocol-specific requirements with regard to the value of these tags, but it is assumed that together with the LUN, they will enable the target to associate data with an R2T.

为了帮助SCSI目标将结果数据输出与R2T关联,R2T携带一个目标传输标记,该标记将由发起方在请求的SCSI数据输出PDU中复制。关于这些标记的值,没有特定于协议的要求,但假定它们与LUN一起,将使目标能够将数据与R2T关联。

R2T also carries information required for proper operation of the iSCSI protocol, such as:

R2T还携带正确操作iSCSI协议所需的信息,例如:

- R2TSN (to enable an initiator to detect a missing R2T)

- R2TSN(使启动器能够检测缺失的R2T)

- StatSN

- 斯塔森

- ExpCmdSN

- ExpCmdSN

- MaxCmdSN

- MaxCmdSN

4.6.2. Requests/Responses Carrying SCSI and iSCSI Payload
4.6.2. 承载SCSI和iSCSI负载的请求/响应
4.6.2.1. Asynchronous Message
4.6.2.1. 异步消息

Asynchronous Message PDUs are used to carry SCSI asynchronous event notifications (AENs) and iSCSI asynchronous messages.

异步消息PDU用于承载SCSI异步事件通知(AEN)和iSCSI异步消息。

When carrying an AEN, the event details are reported as sense data in the data segment.

携带AEN时,事件详细信息作为数据段中的检测数据报告。

4.6.3. Requests/Responses Carrying iSCSI-Only Payload
4.6.3. 仅承载iSCSI负载的请求/响应
4.6.3.1. Text Requests and Text Responses
4.6.3.1. 文本请求和文本响应

Text Requests and Responses are designed as a parameter negotiation vehicle and as a vehicle for future extension.

文本请求和响应被设计为参数协商工具和将来扩展的工具。

In the data segment, Text Requests/Responses carry text information using a simple "key=value" syntax.

在数据段中,文本请求/响应使用简单的“key=value”语法携带文本信息。

Text Requests/Responses may form extended sequences using the same Initiator Task Tag. The initiator uses the F (Final) flag bit in the Text Request header to indicate its readiness to terminate a sequence. The target uses the F bit in the Text Response header to indicate its consent to sequence termination.

文本请求/响应可以使用相同的启动器任务标记形成扩展序列。发起者使用文本请求头中的F(Final)标志位指示其准备终止序列。目标使用文本响应头中的F位表示其同意序列终止。

Text Requests and Responses also use the Target Transfer Tag to indicate continuation of an operation or a new beginning. A target that wishes to continue an operation will set the Target Transfer Tag in a Text Response to a value different from the default 0xffffffff. An initiator willing to continue will copy this value into the Target Transfer Tag of the next Text Request. If the initiator wants to restart the current target negotiation (start fresh), it will set the Target Transfer Tag to 0xffffffff.

文本请求和响应还使用目标传输标记来指示操作的继续或新的开始。希望继续操作的目标将在文本响应中将目标传输标记设置为不同于默认0xFFFFFF的值。愿意继续的发起者将把这个值复制到下一个文本请求的目标传输标记中。如果启动器希望重新启动当前目标协商(start fresh),则会将目标传输标记设置为0xFFFFFF。

Although a complete exchange is always started by the initiator, specific parameter negotiations may be initiated by the initiator or target.

虽然完整的交换总是由启动器启动,但特定的参数协商可能由启动器或目标启动。

4.6.3.2. Login Requests and Login Responses
4.6.3.2. 登录请求和登录响应

Login Requests and Responses are used exclusively during the Login Phase of each connection to set up the session and connection parameters. (The Login Phase consists of a sequence of Login Requests and Responses carrying the same Initiator Task Tag.)

登录请求和响应在每个连接的登录阶段专门用于设置会话和连接参数。(登录阶段由一系列带有相同启动器任务标记的登录请求和响应组成。)

A connection is identified by an arbitrarily selected connection ID (CID) that is unique within a session.

连接由会话中唯一的任意选择的连接ID(CID)标识。

Similar to the Text Requests and Responses, Login Requests/Responses carry key=value text information with a simple syntax in the data segment.

与文本请求和响应类似,登录请求/响应在数据段中带有简单语法的key=value文本信息。

The Login Phase proceeds through several stages (security negotiation, operational parameter negotiation) that are selected with two binary coded fields in the header -- the Current Stage (CSG) and the Next Stage (NSG) -- with the appearance of the latter being signaled by the "Transit" flag (T).

登录阶段通过几个阶段(安全协商、操作参数协商)进行,这些阶段通过标头中的两个二进制编码字段选择——当前阶段(CSG)和下一阶段(NSG)——后者的外观由“Transit”标志(T)发出信号。

The first Login Phase of a session plays a special role, called the leading login, which determines some header fields (e.g., the version number, the maximum number of connections, and the session identification).

会话的第一个登录阶段起着特殊的作用,称为前导登录,它确定一些头字段(例如,版本号、最大连接数和会话标识)。

The CmdSN initial value is also set by the leading login.

CmdSN初始值也由主要登录名设置。

The StatSN for each connection is initiated by the connection login.

每个连接的StatSN由连接登录启动。

A Login Request may indicate an implied logout (cleanup) of the connection to be logged in (a connection restart) by using the same connection ID (CID) as an existing connection as well as the same session-identifying elements of the session to which the old connection was associated.

登录请求可以通过使用与现有连接相同的连接ID(CID)以及识别旧连接关联的会话元素的相同会话来指示要登录的连接的隐含注销(清除)(连接重新启动)。

4.6.3.3. Logout Requests and Logout Responses
4.6.3.3. 注销请求和注销响应

Logout Requests and Responses are used for the orderly closing of connections for recovery or maintenance. The Logout Request may be issued following a target prompt (through an Asynchronous Message) or at an initiator's initiative. When issued on the connection to be logged out, no other request may follow it.

注销请求和响应用于有序关闭连接以进行恢复或维护。注销请求可以在目标提示后(通过异步消息)发出,也可以由发起方主动发出。当在要注销的连接上发出请求时,随后可能不会有其他请求。

The Logout Response indicates that the connection or session cleanup is completed and no other responses will arrive on the connection (if received on the logging-out connection). In addition, the Logout Response indicates how long the target will continue to hold resources for recovery (e.g., command execution that continues on a new connection) in the Time2Retain field and how long the initiator must wait before proceeding with recovery in the Time2Wait field.

注销响应表示连接或会话清理已完成,并且连接上不会出现其他响应(如果在注销连接上收到)。此外,注销响应还指示目标将在Time2Retain字段中继续保留用于恢复的资源(例如,在新连接上继续执行的命令)的时间,以及启动器在Time2Wait字段中继续恢复之前必须等待的时间。

4.6.3.4. SNACK Request
4.6.3.4. 快餐请求

With the SNACK Request, the initiator requests retransmission of numbered responses or data from the target. A single SNACK Request covers a contiguous set of missing items, called a run, of a given type of items. The type is indicated in a type field in the PDU header. The run is composed of an initial item (StatSN, DataSN, R2TSN) and the number of missed Status, Data, or R2T PDUs. For long Data-In sequences, the target may request (at predefined minimum intervals) a positive acknowledgment for the data sent. A SNACK Request with a type field that indicates ACK and the number of Data-In PDUs acknowledged conveys this positive acknowledgment.

通过SNACK请求,发起方请求重新传输来自目标的编号响应或数据。一个零食请求包含一组连续的缺少的项目,称为运行,属于给定类型的项目。该类型在PDU标题中的类型字段中指示。运行由初始项(StatSN、DataSN、R2TSN)和缺失状态、数据或R2T PDU的数量组成。对于序列中的长数据,目标可以请求(以预定义的最小间隔)发送数据的肯定确认。带有类型字段(指示ACK和PDU中已确认数据的数量)的快餐请求传递此肯定确认。

4.6.3.5. Reject
4.6.3.5. 拒绝

Reject enables the target to report an iSCSI error condition (e.g., protocol, unsupported option) that uses a Reason field in the PDU header and includes the complete header of the bad PDU in the Reject PDU data segment.

Reject使目标能够报告iSCSI错误情况(例如,协议、不支持的选项),该情况在PDU头中使用原因字段,并在Reject PDU数据段中包含坏PDU的完整头。

4.6.3.6. NOP-Out Request and NOP-In Response
4.6.3.6. NOP Out请求和NOP In响应

This request/response pair may be used by an initiator and target as a "ping" mechanism to verify that a connection/session is still active and all of its components are operational. Such a ping may be

该请求/响应对可由发起方和目标方用作“ping”机制,以验证连接/会话是否仍然处于活动状态以及其所有组件是否可操作。这样的一个ping可能是

triggered by the initiator or target. The triggering party indicates that it wants a reply by setting a value different from the default 0xffffffff in the corresponding Initiator/Target Transfer Tag.

由启动器或目标触发。触发方通过在相应的启动器/目标传输标记中设置不同于默认0xffffffff的值来指示它想要应答。

NOP-In/NOP-Out may also be used in "unidirectional" fashion to convey to the initiator/target command, status, or data counter values when there is no other "carrier" and there is a need to update the initiator/target.

NOP In/NOP Out还可以“单向”方式使用,以在没有其他“载体”且需要更新启动器/目标时向启动器/目标传送命令、状态或数据计数器值。

5. SCSI Mode Parameters for iSCSI
5. iSCSI的SCSI模式参数

There are no iSCSI-specific mode pages.

没有特定于iSCSI的模式页面。

6. Login and Full Feature Phase Negotiation
6. 登录和全功能阶段协商

iSCSI parameters are negotiated at session or connection establishment by using Login Requests and Responses (see Section 4.2.4) and during the Full Feature Phase (Section 4.2.5) by using Text Requests and Responses. In both cases, the mechanism used is an exchange of iSCSI-text-key=value pairs. For brevity, iSCSI-text-keys are called just "keys" in the rest of this document.

iSCSI参数在会话或连接建立时通过使用登录请求和响应(参见第4.2.4节)进行协商,在完整功能阶段(第4.2.5节)通过使用文本请求和响应进行协商。在这两种情况下,使用的机制都是iSCSI文本键=值对的交换。为简洁起见,在本文档的其余部分中,iSCSI文本密钥仅称为“密钥”。

Keys are either declarative or require negotiation, and the key description indicates whether the key is declarative or requires negotiation.

密钥是声明性的或需要协商的,密钥描述指示密钥是声明性的还是需要协商的。

For the declarative keys, the declaring party sets a value for the key. The key specification indicates whether the key can be declared by the initiator, the target, or both.

对于声明性键,声明方为键设置一个值。密钥规范指示密钥是否可以由启动器、目标或两者声明。

For the keys that require negotiation, one of the parties (the proposing party) proposes a value or set of values by including the key=value in the data part of a Login or Text Request or Response. The other party (the accepting party) makes a selection based on the value or list of values proposed and includes the selected value in a key=value in the data part of the following Login or Text Response or Request. For most of the keys, both the initiator and target can be proposing parties.

对于需要协商的密钥,其中一方(提议方)通过在登录或文本请求或响应的数据部分包含key=值来提议一个值或一组值。另一方(接受方)根据提议的值或值列表进行选择,并在以下登录或文本响应或请求的数据部分的key=value中包含所选值。对于大多数密钥,发起方和目标方都可以是提议方。

The login process proceeds in two stages -- the security negotiation stage and the operational parameter negotiation stage. Both stages are optional, but at least one of them has to be present to enable setting some mandatory parameters.

登录过程分为两个阶段——安全协商阶段和操作参数协商阶段。这两个阶段都是可选的,但必须至少有一个阶段存在,才能启用某些强制参数的设置。

If present, the security negotiation stage precedes the operational parameter negotiation stage.

如果存在,则安全协商阶段先于操作参数协商阶段。

Progression from stage to stage is controlled by the T (Transit) bit in the Login Request/Response PDU header. Through the T bit set to 1, the initiator indicates that it would like to transition. The target agrees to the transition (and selects the next stage) when ready. A field in the Login PDU header indicates the current stage (CSG), and during transition, another field indicates the next stage (NSG) proposed (initiator) and selected (target).

从一个阶段到另一个阶段的进度由登录请求/响应PDU头中的T(传输)位控制。通过将T位设置为1,启动器指示它要转换。准备就绪时,目标同意过渡(并选择下一阶段)。登录PDU头中的一个字段表示当前阶段(CSG),在转换过程中,另一个字段表示下一阶段(NSG)建议(发起方)和选择(目标)。

The text negotiation process is used to negotiate or declare operational parameters. The negotiation process is controlled by the F (Final) bit in the PDU header. During text negotiations, the F bit is used by the initiator to indicate that it is ready to finish the negotiation and by the target to acquiesce the end of negotiation.

文本协商过程用于协商或声明操作参数。协商过程由PDU头中的F(最终)位控制。在文本协商期间,发起方使用F位表示准备完成协商,目标方使用F位表示默认协商结束。

Since some key=value pairs may not fit entirely in a single PDU, the C (Continue) bit is used (both in Login and Text) to indicate that "more follows".

由于某些键=值对可能不完全适合单个PDU,因此使用C(Continue)位(在登录和文本中)来表示“更多”。

The text negotiation uses an additional mechanism by which a target may deliver larger amounts of data to an inquiring initiator. The target sets a Target Task Tag to be used as a bookmark that, when returned by the initiator, means "go on". If reset to a "neutral value", it means "forget about the rest".

文本协商使用了一种额外的机制,通过该机制,目标可以向询问的发起方传递更多的数据。目标将目标任务标记设置为书签,当启动器返回时,该书签表示“继续”。如果重置为“中性值”,则表示“忘记其余部分”。

This section details the types of keys and values used, the syntax rules for parameter formation, and the negotiation schemes to be used with different types of parameters.

本节详细介绍了使用的键和值的类型、参数形成的语法规则以及与不同类型的参数一起使用的协商方案。

6.1. Text Format
6.1. 文本格式

The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are case sensitive; they are to be presented and interpreted as they appear in this document without change of case.

启动器和目标发送一组以UTF-8 Unicode编码的键=值对。本文件中规定的所有文本键和文本值均区分大小写;在不改变案例的情况下,应按照本文件中出现的内容进行呈现和解释。

The following character symbols are used in this document for text items (the hexadecimal values represent Unicode code points):

以下字符符号在本文档中用于文本项(十六进制值表示Unicode代码点):

   (a-z, A-Z) (0x61-0x7a, 0x41-0x5a) - letters
                   (0-9) (0x30-0x39) - digits
                          " " (0x20) - space
                          "." (0x2e) - dot
                          "-" (0x2d) - minus
                          "+" (0x2b) - plus
                          "@" (0x40) - commercial at
                          "_" (0x5f) - underscore
                          "=" (0x3d) - equal
                          ":" (0x3a) - colon
        
   (a-z, A-Z) (0x61-0x7a, 0x41-0x5a) - letters
                   (0-9) (0x30-0x39) - digits
                          " " (0x20) - space
                          "." (0x2e) - dot
                          "-" (0x2d) - minus
                          "+" (0x2b) - plus
                          "@" (0x40) - commercial at
                          "_" (0x5f) - underscore
                          "=" (0x3d) - equal
                          ":" (0x3a) - colon
        
                          "/" (0x2f) - solidus or slash
                          "[" (0x5b) - left bracket
                          "]" (0x5d) - right bracket
                         null (0x00) - null separator
                          "," (0x2c) - comma
                          "~" (0x7e) - tilde
        
                          "/" (0x2f) - solidus or slash
                          "[" (0x5b) - left bracket
                          "]" (0x5d) - right bracket
                         null (0x00) - null separator
                          "," (0x2c) - comma
                          "~" (0x7e) - tilde
        

Key=value pairs may span PDU boundaries. An initiator or target that sends partial key=value text within a PDU indicates that more text follows by setting the C bit in the Text or Login Request or the Text or Login Response to 1. Data segments in a series of PDUs that have the C bit set to 1 and end with a PDU that has the C bit set to 0, or that include a single PDU that has the C bit set to 0, have to be considered as forming a single logical-text-data-segment (LTDS).

键=值对可能跨越PDU边界。在PDU内发送部分key=value文本的启动器或目标通过将文本或登录请求或文本或登录响应中的C位设置为1,指示后面有更多文本。必须将C位设置为1并以C位设置为0的PDU结束的一系列PDU中的数据段,或包括C位设置为0的单个PDU的数据段视为形成单个逻辑文本数据段(LTD)。

Every key=value pair, including the last or only pair in a LTDS, MUST be followed by one null (0x00) delimiter.

每个key=value对(包括LTDS中的最后一对或唯一一对)后面必须跟一个null(0x00)分隔符。

A key-name is whatever precedes the first "=" in the key=value pair. The term "key" is used frequently in this document in place of "key-name".

键名是键=值对中第一个“=”之前的名称。本文件中经常使用术语“密钥”代替“密钥名称”。

A value is whatever follows the first "=" in the key=value pair up to the end of the key=value pair, but not including the null delimiter.

值是在key=value对中的第一个“=”之后一直到key=value对末尾的值,但不包括空分隔符。

The following definitions will be used in the rest of this document:

本文件其余部分将使用以下定义:

- standard-label: A string of one or more characters that consists of letters, digits, dot, minus, plus, commercial at, or underscore. A standard-label MUST begin with a capital letter and must not exceed 63 characters.

- 标准标签:由一个或多个字符组成的字符串,由字母、数字、点、减、加、商业at或下划线组成。标准标签必须以大写字母开头,且不得超过63个字符。

- key-name: A standard-label.

- 关键字名称:标准标签。

- text-value: A string of zero or more characters that consists of letters, digits, dot, minus, plus, commercial at, underscore, slash, left bracket, right bracket, or colon.

- 文本值:由零个或多个字符组成的字符串,由字母、数字、点、减、加、商业at、下划线、斜杠、左括号、右括号或冒号组成。

- iSCSI-name-value: A string of one or more characters that consists of minus, dot, colon, or any character allowed by the output of the iSCSI stringprep template as specified in [RFC3722] (see also Section 4.2.7.2).

- iSCSI名称值:由一个或多个字符组成的字符串,由减号、点、冒号或[RFC3722]中指定的iSCSI stringprep模板输出所允许的任何字符组成(另请参见第4.2.7.2节)。

- iSCSI-local-name-value: A UTF-8 string; no null characters are allowed in the string. This encoding is to be used for localized (internationalized) aliases.

- iSCSI本地名称值:一个UTF-8字符串;字符串中不允许有空字符。此编码用于本地化(国际化)别名。

- boolean-value: The string "Yes" or "No".

- 布尔值:字符串“是”或“否”。

- hex-constant: A hexadecimal constant encoded as a string that starts with "0x" or "0X" followed by one or more digits or the letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex-constants are used to encode numerical values or binary strings. When used to encode numerical values, the excessive use of leading 0 digits is discouraged. The string following 0X (or 0x) represents a base16 number that starts with the most significant base16 digit, followed by all other digits in decreasing order of significance and ending with the least significant base16 digit. When used to encode binary strings, hexadecimal constants have an implicit byte-length that includes four bits for every hexadecimal digit of the constant, including leading zeroes. For example, a hex-constant of n hexadecimal digits has a byte-length of (the integer part of) (n + 1)/2.

- 十六进制常量:编码为字符串的十六进制常量,以“0x”或“0x”开头,后跟一个或多个数字或字母A、b、c、d、e、f、A、b、c、d、e或f。十六进制常量用于编码数值或二进制字符串。当用于编码数值时,不鼓励过度使用前导0位。0X(或0X)后面的字符串表示一个base16数字,该数字以最有效的base16位开始,然后按重要性降序排列所有其他数字,最后以最低有效的base16位结束。当用于编码二进制字符串时,十六进制常量具有隐式字节长度,该长度包括常量的每个十六进制数字的四位,包括前导零。例如,n个十六进制数字的十六进制常数的字节长度为(n+1)/2的整数部分。

- decimal-constant: An unsigned decimal number with the digit 0 or a string of one or more digits that starts with a non-zero digit. Decimal-constants are used to encode numerical values or binary strings. Decimal-constants can only be used to encode binary strings if the string length is explicitly specified. There is no implicit length for decimal strings. Decimal-constants MUST NOT be used for parameter values if the values can be equal to or greater than 2**64 (numerical) or for binary strings that can be longer than 64 bits.

- 十进制常数:数字为0的无符号十进制数,或一个或多个以非零数字开头的数字串。十进制常量用于编码数值或二进制字符串。只有在明确指定字符串长度的情况下,十进制常量才能用于编码二进制字符串。十进制字符串没有隐式长度。如果参数值可以等于或大于2**64(数字),或长度可以大于64位的二进制字符串,则十进制常量不得用于参数值。

- base64-constant: Base64 constant encoded as a string that starts with "0b" or "0B" followed by 1 or more digits, letters, plus sign, slash, or equals sign. The encoding is done according to [RFC4648].

- base64常量:base64常量编码为字符串,以“0b”或“0b”开头,后跟一个或多个数字、字母、加号、斜杠或等号。根据[RFC4648]进行编码。

- numerical-value: An unsigned integer always less than 2**64 encoded as a decimal-constant or a hex-constant. Unsigned integer arithmetic applies to numerical-values.

- 数值:始终小于2**64的无符号整数,编码为十进制常量或十六进制常量。无符号整数算术适用于数值。

- large-numerical-value: An unsigned integer that can be larger than or equal to 2**64 encoded as a hex-constant or base64-constant. Unsigned integer arithmetic applies to large-numerical-values.

- 大数值:一个无符号整数,可以大于或等于2**64,编码为十六进制常量或base64常量。无符号整数算法适用于大数值。

- numerical-range: Two numerical-values separated by a tilde, where the value to the right of the tilde must not be lower than the value to the left.

- 数值范围:由一个波浪线分隔的两个数值,其中波浪线右侧的值不得小于左侧的值。

- regular-binary-value: A binary string not longer than 64 bits encoded as a decimal-constant, hex-constant, or base64-constant. The length of the string is either specified by the key definition or is the implicit byte-length of the encoded string.

- 常规二进制值:长度不超过64位的二进制字符串,编码为十进制常量、十六进制常量或base64常量。字符串的长度由键定义指定,或者是编码字符串的隐式字节长度。

- large-binary-value: A binary string longer than 64 bits encoded as a hex-constant or base64-constant. The length of the string is either specified by the key definition or is the implicit byte-length of the encoded string.

- 大二进制值:长度超过64位的二进制字符串,编码为十六进制常量或base64常量。字符串的长度由键定义指定,或者是编码字符串的隐式字节长度。

- binary-value: A regular-binary-value or a large-binary-value. Operations on binary values are key-specific.

- 二进制值:常规二进制值或大二进制值。对二进制值的操作是特定于键的。

- simple-value: Text-value, iSCSI-name-value, boolean-value, numerical-value, a numerical-range, or a binary-value.

- 简单值:文本值、iSCSI名称值、布尔值、数值、数值范围或二进制值。

- list-of-values: A sequence of text-values separated by a comma.

- 值列表:由逗号分隔的文本值序列。

If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes, not including the delimiter (comma or zero byte).

如果未另行指定,则简单值(不是其编码表示)的最大长度为255字节,不包括分隔符(逗号或零字节)。

Any iSCSI target or initiator MUST support receiving at least 8192 bytes of key=value data in a negotiation sequence. When proposing or accepting authentication methods that explicitly require support for very long authentication items, the initiator and target MUST support receiving at least 64 kilobytes of key=value data.

任何iSCSI目标或启动器都必须支持在协商序列中接收至少8192字节的key=value数据。当建议或接受明确要求支持超长身份验证项的身份验证方法时,启动器和目标必须支持接收至少64 KB的key=value数据。

6.2. Text Mode Negotiation
6.2. 文本模式协商

During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information.

在登录期间以及之后,通过交换文本信息来声明或协商某些会话或连接参数。

The initiator starts the negotiation and/or declaration through a Text or Login Request and indicates when it is ready for completion (by setting the F bit to 1 and keeping it at 1 in a Text Request, or the T bit in the Login Request). As negotiation text may span PDU boundaries, a Text or Login Request or a Text or Login Response PDU that has the C bit set to 1 MUST NOT have the F bit or T bit set to 1.

发起人通过文本或登录请求启动协商和/或声明,并指示何时准备完成(通过在文本请求中将F位设置为1并保持为1,或在登录请求中将T位保持为1)。由于协商文本可能跨越PDU边界,因此C位设置为1的文本或登录请求或文本或登录响应PDU不得将F位或T位设置为1。

A target receiving a Text or Login Request with the C bit set to 1 MUST answer with a Text or Login Response with no data segment (DataSegmentLength 0). An initiator receiving a Text or Login Response with the C bit set to 1 MUST answer with a Text or Login Request with no data segment (DataSegmentLength 0).

接收C位设置为1的文本或登录请求的目标必须使用无数据段(DataSegmentLength 0)的文本或登录响应进行应答。接收C位设置为1的文本或登录响应的启动器必须使用无数据段(DataSegmentLength 0)的文本或登录请求进行应答。

A target or initiator SHOULD NOT use a Text or Login Response or a Text or Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule.

除非通用或密钥特定协商规则明确要求,否则目标或发起方不应使用无数据段(DataSegmentLength 0)的文本或登录响应或文本或登录请求。

There MUST NOT be more than one outstanding Text Request, or Text Response PDU on an iSCSI connection. An outstanding PDU in this context is one that has not been acknowledged by the remote iSCSI side.

iSCSI连接上不能有多个未完成的文本请求或文本响应PDU。在此上下文中,未完成的PDU是远程iSCSI端尚未确认的PDU。

The format of a declaration is:

声明的格式为:

      Declarer-> <key>=<valuex>
        
      Declarer-> <key>=<valuex>
        

The general format of text negotiation is:

文本协商的一般形式是:

      Proposer-> <key>=<valuex>
        
      Proposer-> <key>=<valuex>
        
      Acceptor-> <key>={<valuey>|NotUnderstood|Irrelevant|Reject}
        
      Acceptor-> <key>={<valuey>|NotUnderstood|Irrelevant|Reject}
        

Thus, a declaration is a one-way textual exchange (unless the key is not understood by the receiver), while a negotiation is a two-way exchange.

因此,声明是单向文本交换(除非接收方不理解密钥),而协商是双向交换。

The proposer or declarer can be either the initiator or the target, and the acceptor can be either the target or initiator, respectively. Targets are not limited to respond to key=value pairs as proposed by the initiator. The target may propose key=value pairs of its own.

提议人或声明人可以是发起人或目标人,接受人可以是目标人或发起人。目标不限于响应发起方提出的键=值对。目标可以提出自己的键=值对。

All negotiations are explicit (i.e., the result MUST only be based on newly exchanged or declared values). There are no implicit proposals. If a proposal is not made, then a reply cannot be expected. Conservative design also requires that default values should not be relied upon when the use of some other value has serious consequences.

所有谈判都是明确的(即,结果必须仅基于新交换或声明的值)。没有隐含的建议。如果没有提出建议,那么就不可能得到答复。保守设计还要求,当使用其他值产生严重后果时,不应依赖默认值。

The value proposed or declared can be a numerical-value, a numerical-range defined by the lower and upper value with both integers separated by a tilde, a binary value, a text-value, an iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes or No), or a list of comma-separated text-values. A range, a large-numerical-value, an iSCSI-name-value, and an iSCSI-local-name-value MAY ONLY be used if explicitly allowed. An accepted value can be a numerical-value, a large-numerical-value, a text-value, or a boolean-value.

建议或声明的值可以是数值、由下限值和上限值定义的数值范围,其中两个整数由波浪号分隔、二进制值、文本值、iSCSI名称值、iSCSI本地名称值、布尔值(是或否)或逗号分隔的文本值列表。只有在明确允许的情况下,才能使用范围、大数值、iSCSI名称值和iSCSI本地名称值。接受的值可以是数值、大数值、文本值或布尔值。

If a specific key is not relevant for the current negotiation, the acceptor may answer with the constant "Irrelevant" for all types of negotiations. However, the negotiation is not considered to have failed if the answer is "Irrelevant". The "Irrelevant" answer is meant for those cases in which several keys are presented by a proposing party but the selection made by the acceptor for one of the

如果特定密钥与当前协商不相关,则对于所有类型的协商,接受方可以使用常量“无关”进行回答。但是,如果答案是“不相关”,则不认为谈判失败。“不相关”答案适用于提议方提供多个密钥,但接受方选择其中一个密钥的情况

keys makes other keys irrelevant. The following example illustrates the use of "Irrelevant":

关键点使其他关键点不相关。以下示例说明了“无关”的用法:

      I->T InitialR2T=No,ImmediateData=Yes,FirstBurstLength=4192
      T->I InitialR2T=Yes,ImmediateData=No,FirstBurstLength=Irrelevant
      I->T X-rdname-vkey1=(bla,alb,None), X-rdname-vkey2=(bla,alb)
      T->I X-rdname-vkey1=None, X-rdname-vkey2=Irrelevant
        
      I->T InitialR2T=No,ImmediateData=Yes,FirstBurstLength=4192
      T->I InitialR2T=Yes,ImmediateData=No,FirstBurstLength=Irrelevant
      I->T X-rdname-vkey1=(bla,alb,None), X-rdname-vkey2=(bla,alb)
      T->I X-rdname-vkey1=None, X-rdname-vkey2=Irrelevant
        

Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, the answer for a key that is not understood MUST be key=NotUnderstood. Note that NotUnderstood is a valid answer for both declarative and negotiated keys. The general iSCSI philosophy is that comprehension precedes processing for any iSCSI key. A proposer of an iSCSI key, negotiated or declarative, in a text key exchange MUST thus be able to properly handle a NotUnderstood response.

在不影响基本功能的情况下,接受方可以忽略任何未被接受方理解的密钥。但是,未理解的密钥的答案必须是key=notunderspected。请注意,NotUnderstanding对于声明键和协商键都是有效的答案。iSCSI的一般原理是,对任何iSCSI密钥的处理都要先理解。因此,在文本密钥交换中协商或声明iSCSI密钥的提议者必须能够正确处理未理解的响应。

The proper way to handle a NotUnderstood response depends on where the key is specified and whether the key is declarative or negotiated. An iSCSI implementation MUST comprehend all text keys defined in this document. Returning a NotUnderstood response on any of these text keys therefore MUST be considered a protocol error and handled accordingly. For all other "later" keys, i.e., text keys defined in later specifications, a NotUnderstood answer concludes the negotiation for a negotiated key, whereas for a declarative key a NotUnderstood answer simply informs the declarer of a lack of comprehension by the receiver.

处理NotUnderstanding响应的正确方法取决于指定密钥的位置以及密钥是声明性的还是协商的。iSCSI实现必须理解本文档中定义的所有文本键。因此,对这些文本键中的任何一个返回未理解的响应都必须视为协议错误,并进行相应的处理。对于所有其他“更晚”的密钥,即在更晚的规范中定义的文本密钥,未理解的答案结束协商密钥的协商,而对于声明性密钥,未理解的答案只是通知声明方接收方不理解。

In either case, a NotUnderstood answer always requires that the protocol behavior associated with that key not be used within the scope of the key (connection/session) by either side.

在任何一种情况下,一个不可理解的答案总是要求与该密钥相关联的协议行为不在任何一方的密钥(连接/会话)范围内使用。

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular, the use of "Reject", "Irrelevant", and "NotUnderstood" as proposed values).

常数“无”、“拒绝”、“无关”和“不理解”是保留的,只能按此处所述使用。违反此规则是协议错误(尤其是使用“拒绝”、“无关”和“不理解”作为建议值)。

"Reject" or "Irrelevant" are legitimate negotiation options where allowed, but their excessive use is discouraged. A negotiation is considered complete when the acceptor has sent the key value pair even if the value is "Reject", "Irrelevant", or "NotUnderstood". Sending the key again would be a renegotiation and is forbidden for many keys.

在允许的情况下,“拒绝”或“无关”是合法的谈判选项,但不鼓励过度使用。即使值为“拒绝”、“无关”或“未理解”,当接受方已发送密钥-值对时,协商也被视为完成。再次发送密钥将是一次重新协商,对于许多密钥都是禁止的。

If the acceptor sends "Reject" as an answer, the negotiated key is left at its current value (or default if no value was set). If the current value is not acceptable to the proposer on the connection or to the session in which it is sent, the proposer MAY choose to terminate the connection or session.

如果接受方发送“拒绝”作为应答,协商密钥将保留其当前值(如果未设置值,则为默认值)。如果当前值在连接或发送该值的会话中不为投标人所接受,投标人可选择终止连接或会话。

All keys in this document MUST be supported by iSCSI initiators and targets when used as specified here. If used as specified, these keys MUST NOT be answered with NotUnderstood.

按此处指定使用时,iSCSI启动器和目标必须支持本文档中的所有密钥。如果按规定使用,这些钥匙不得以NotUnderstanding(未理解)回答。

Implementers may introduce new private keys by prefixing them with X-followed by their (reverse) domain name, or with new public keys registered with IANA. For example, the entity owning the domain example.com can issue:

实现者可能会引入新的私钥,方法是在它们前面加上X-前缀,后跟它们的(反向)域名,或者加上在IANA注册的新公钥。例如,拥有域example.com的实体可以发布:

X-com.example.bar.foo.do_something=3

X-com.example.bar.foo.do\u something=3

Each new public key in the course of standardization MUST define the acceptable responses to the key, including NotUnderstood as appropriate. Unlike [RFC3720], note that this document prohibits the X# prefix for new public keys. Based on iSCSI implementation experience, we know that there is no longer a need for a standard name prefix for keys that allow a NotUnderstood response. Note that NotUnderstood will generally have to be allowed for new public keys for backwards compatibility, as well as for private X- keys. Thus, the name prefix "X#" in new public key-names does not carry any significance. To avoid confusion, new public key-names MUST NOT begin with an "X#" prefix.

标准化过程中的每个新公钥都必须定义对该密钥的可接受响应,包括适当的不可理解响应。与[RFC3720]不同,请注意,本文档禁止新公钥使用X前缀。根据iSCSI实施经验,我们知道不再需要为允许不可理解响应的密钥提供标准名称前缀。注意NotUnderstand通常必须允许新的公钥向后兼容,以及私有X密钥。因此,新公钥名称中的名称前缀“X#”没有任何意义。为避免混淆,新公钥名称不得以“X#”前缀开头。

Implementers MAY also introduce new values, but ONLY for new keys or authentication methods (see Section 12) or digests (see Section 13.1).

实现者也可以引入新值,但仅针对新密钥或身份验证方法(参见第12节)或摘要(参见第13.1节)。

Whenever parameter actions or acceptance are dependent on other parameters, the dependency rules and parameter sequence must be specified with the parameters.

当参数操作或接受依赖于其他参数时,必须使用参数指定依赖规则和参数顺序。

In the Login Phase (see Section 6.3), every stage is a separate negotiation. In the Full Feature Phase, a Text Request/Response sequence is a negotiation. Negotiations MUST be handled as atomic operations. For example, all negotiated values go into effect after the negotiation concludes in agreement or are ignored if the negotiation fails.

在登录阶段(见第6.3节),每个阶段都是单独的协商。在全功能阶段,文本请求/响应序列是协商。谈判必须作为原子行动来处理。例如,所有协商值在协商达成一致后生效,或在协商失败时被忽略。

Some parameters may be subject to integrity rules (e.g., parameter-x must not exceed parameter-y, or parameter-u not 1 implies that parameter-v be Yes). Whenever required, integrity rules are specified with the keys. Checking for compliance with the integrity

某些参数可能受完整性规则的约束(例如,参数-x不得超过参数-y,或者参数-u非1表示参数-v为是)。只要需要,完整性规则都会与密钥一起指定。检查是否符合完整性

rule must only be performed after all the parameters are available (the existent and the newly negotiated). An iSCSI target MUST perform integrity checking before the new parameters take effect. An initiator MAY perform integrity checking.

只有在所有参数都可用(现有参数和新协商的参数)后才能执行规则。在新参数生效之前,iSCSI目标必须执行完整性检查。启动器可以执行完整性检查。

An iSCSI initiator or target MAY terminate a negotiation that does not terminate within an implementation-specific reasonable time or number of exchanges but SHOULD allow at least six (6) exchanges.

iSCSI启动器或目标可以终止协商,该协商不会在特定于实施的合理时间或交换次数内终止,但应允许至少六(6)次交换。

6.2.1. List Negotiations
6.2.1. 清单谈判

In list negotiation, the originator sends a list of values (which may include "None"), in order of preference.

在列表协商中,发起者按照优先顺序发送一个值列表(可能包括“无”)。

The responding party MUST respond with the same key and the first value that it supports (and is allowed to use for the specific originator) selected from the originator list.

响应方必须使用从发起人列表中选择的相同键和它支持的第一个值(并允许用于特定发起人)进行响应。

The constant "None" MUST always be used to indicate a missing function. However, "None" is only a valid selection if it is explicitly proposed. When "None" is proposed as a selection item in a negotiation for a key, it indicates to the responder that not supporting any functionality related to that key is legal, and if "None" is the negotiation result for such a key, it means that key-specific semantics are not operational for the negotiation scope (connection or session) of that key.

常量“None”必须始终用于指示缺少的函数。但是,“无”只有在明确提出时才是有效的选择。当“无”被提议作为密钥协商中的选择项时,它向响应者指示不支持与该密钥相关的任何功能是合法的,并且如果“无”是此类密钥的协商结果,则意味着特定于密钥的语义对于该密钥的协商范围(连接或会话)不可操作。

If an acceptor does not understand any particular value in a list, it MUST ignore it. If an acceptor does not support, does not understand, or is not allowed to use any of the proposed options with a specific originator, it may use the constant "Reject" or terminate the negotiation. The selection of a value not proposed MUST be handled by the originator as a protocol error.

如果接受程序不理解列表中的任何特定值,则必须忽略该值。如果承兑人不支持、不理解或不允许对特定发起人使用任何提议的选项,则可使用常量“拒绝”或终止谈判。未提议值的选择必须由发起人作为协议错误处理。

6.2.2. Simple-Value Negotiations
6.2.2. 简单的价值谈判

For simple-value negotiations, the accepting party MUST answer with the same key. The value it selects becomes the negotiation result.

对于简单的价值谈判,接受方必须使用相同的密钥进行回答。它选择的值将成为协商结果。

Proposing a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject"; otherwise, the acceptor MUST select an admissible value.

提出一个不可接受的值(例如,不在规定范围内)可以用常量“拒绝”来回答;否则,接受方必须选择一个允许值。

The selection, by the acceptor, of a value not admissible under the selection rules is considered a protocol error. The selection rules are key-specific.

接受方根据选择规则选择不可接受的值被视为协议错误。选择规则是特定于键的。

For a numerical range, the value selected MUST be an integer within the proposed range or "Reject" (if the range is unacceptable).

对于数值范围,选择的值必须是建议范围内的整数或“拒绝”(如果范围不可接受)。

For Boolean negotiations (i.e., keys taking the values "Yes" or "No"), the accepting party MUST answer with the same key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value with which to answer are expressed as Boolean functions of the value received, and the value that the accepting party would have selected if given a choice.

对于布尔协商(即,取值为“是”或“否”的键),当收到的值不能自行确定协商结果时,接受方必须使用相同的键和协商结果进行回答。传输的最后一个值成为协商结果。选择要回答的值的规则表示为所接收值的布尔函数,以及接受方在给出选择时本应选择的值。

Specifically, the two cases in which answers are OPTIONAL are:

具体而言,答案可选的两种情况是:

- The Boolean function is "AND" and the value "No" is received. The outcome of the negotiation is "No".

- 布尔函数为“AND”,并接收到值“No”。谈判的结果是“不”。

- The Boolean function is "OR" and the value "Yes" is received. The outcome of the negotiation is "Yes".

- 布尔函数为“或”,并收到值“是”。谈判的结果是“是”。

Responses are REQUIRED in all other cases, and the value chosen and sent by the acceptor becomes the outcome of the negotiation.

在所有其他情况下都需要回复,并且由接受方选择和发送的值成为协商的结果。

6.3. Login Phase
6.3. 登录阶段

The Login Phase establishes an iSCSI connection between an initiator and a target; it also creates a new session or associates the connection to an existing session. The Login Phase sets the iSCSI protocol parameters and security parameters, and authenticates the initiator and target to each other.

登录阶段在启动器和目标之间建立iSCSI连接;它还会创建新会话或将连接与现有会话相关联。登录阶段设置iSCSI协议参数和安全参数,并相互验证启动器和目标。

The Login Phase is only implemented via Login Requests and Responses. The whole Login Phase is considered as a single task and has a single Initiator Task Tag (similar to the linked SCSI commands).

登录阶段仅通过登录请求和响应实现。整个登录阶段被视为单个任务,并具有单个启动器任务标记(类似于链接的SCSI命令)。

There MUST NOT be more than one outstanding Login Request or Login Response on an iSCSI connection. An outstanding PDU in this context is one that has not been acknowledged by the remote iSCSI side.

iSCSI连接上不能有多个未完成的登录请求或登录响应。在此上下文中,未完成的PDU是远程iSCSI端尚未确认的PDU。

The default MaxRecvDataSegmentLength is used during login.

登录时使用默认的MaxRecvDataSegmentLength。

The Login Phase sequence of requests and responses proceeds as follows:

请求和响应的登录阶段顺序如下:

- Login initial request

- 登录初始请求

- Login partial response (optional)

- 登录部分响应(可选)

- More Login Requests and Responses (optional)

- 更多登录请求和响应(可选)

- Login Final-Response (mandatory)

- 登录最终响应(必填)

The initial Login Request of any connection MUST include the InitiatorName key=value pair. The initial Login Request of the first connection of a session MAY also include the SessionType key=value pair. For any connection within a session whose type is not "Discovery", the first Login Request MUST also include the TargetName key=value pair.

任何连接的初始登录请求都必须包括InitiatorName key=value对。会话的第一个连接的初始登录请求还可能包括SessionType key=value对。对于类型不是“发现”的会话中的任何连接,第一个登录请求还必须包括TargetName key=value对。

The Login Final-Response accepts or rejects the Login Request.

登录最终响应接受或拒绝登录请求。

The Login Phase MAY include a SecurityNegotiation stage and a LoginOperationalNegotiation stage and MUST include at least one of them, but the included stage MAY be empty except for the mandatory names.

登录阶段可能包括SecurityNegotiationStage和LoginOperationalNegotiationStage,并且必须至少包括其中一个阶段,但所包括的阶段可能为空,但强制名称除外。

The Login Requests and Responses contain a field (CSG) that indicates the current negotiation stage (SecurityNegotiation or LoginOperationalNegotiation). If both stages are used, the SecurityNegotiation MUST precede the LoginOperationalNegotiation.

登录请求和响应包含一个字段(CSG),该字段指示当前协商阶段(SecurityNegotiation或LoginOperationalNegotiation)。如果使用两个阶段,则安全协商必须在LoginOperationalNegotiation之前进行。

Some operational parameters can be negotiated outside the login through Text Requests and Responses.

一些操作参数可以通过文本请求和响应在登录外部协商。

Authentication-related security keys (Section 12) MUST be completely negotiated within the Login Phase. The use of underlying IPsec security is specified in Section 9.3, in [RFC3723], and in [RFC7146]. iSCSI support for security within the protocol only consists of authentication in the Login Phase.

与身份验证相关的安全密钥(第12节)必须在登录阶段内完全协商。第9.3节、[RFC3723]和[RFC7146]中规定了基础IPsec安全性的使用。iSCSI对协议内安全性的支持仅包括登录阶段的身份验证。

In some environments, a target or an initiator is not interested in authenticating its counterpart. It is possible to bypass authentication through the Login Request and Response.

在某些环境中,目标或启动器对验证其对应方不感兴趣。可以通过登录请求和响应绕过身份验证。

The initiator and target MAY want to negotiate iSCSI authentication parameters. Once this negotiation is completed, the channel is considered secure.

启动器和目标可能希望协商iSCSI身份验证参数。一旦协商完成,通道就被认为是安全的。

Most of the negotiation keys are only allowed in a specific stage. The keys used during the SecurityNegotiation stage are listed in Section 12, and the keys used during the LoginOperationalNegotiation stage are discussed in Section 13. Only a limited set of keys (marked as Any-Stage in Section 13) may be used in either of the two stages.

大多数协商密钥只允许在特定阶段使用。第12节列出了安全协商阶段使用的密钥,第13节讨论了登录操作协商阶段使用的密钥。两个阶段中的任何一个阶段只能使用有限的一组钥匙(在第13节中标记为任何阶段)。

Any given Login Request or Response belongs to a specific stage; this determines the negotiation keys allowed with the request or response. Sending a key that is not allowed in the current stage is considered a protocol error.

任何给定的登录请求或响应都属于特定阶段;这决定了请求或响应允许的协商密钥。发送当前阶段不允许的密钥被视为协议错误。

Stage transition is performed through a command exchange (request/response) that carries the T bit and the same CSG code. During this exchange, the next stage is selected by the target via the Next Stage code (NSG). The selected NSG MUST NOT exceed the value stated by the initiator. The initiator can request a transition whenever it is ready, but a target can only respond with a transition after one is proposed by the initiator.

通过携带T位和相同CSG代码的命令交换(请求/响应)执行阶段转换。在此交换过程中,目标通过下一阶段代码(NSG)选择下一阶段。所选NSG不得超过启动器规定的值。发起方可以随时请求转换,但目标方只能在发起方提出转换后响应转换。

In a negotiation sequence, the T bit settings in one Login Request-Login Response pair have no bearing on the T bit settings of the next pair. An initiator that has the T bit set to 1 in one pair and is answered with a T bit setting of 0 may issue the next request with the T bit set to 0.

在协商序列中,一个登录请求-登录响应对中的T位设置与下一对的T位设置无关。一对中T位设置为1并以T位设置为0应答的启动器可以发出下一个T位设置为0的请求。

When a transition is requested by the initiator and acknowledged by the target, both the initiator and target switch to the selected stage.

当启动器请求转换并由目标确认时,启动器和目标都切换到所选阶段。

Targets MUST NOT submit parameters that require an additional initiator Login Request in a Login Response with the T bit set to 1.

目标不得在T位设置为1的登录响应中提交需要额外启动器登录请求的参数。

Stage transitions during login (including entering and exit) are only possible as outlined in the following table:

登录期间的阶段转换(包括进入和退出)仅可按下表所述进行:

     +-----------------------------------------------------------+
     |From      To ->  | Security    | Operational | FullFeature |
     | |               |             |             |             |
     | V               |             |             |             |
     +-----------------------------------------------------------+
     | (start)         | yes         | yes         | no          |
     +-----------------------------------------------------------+
     | Security        | no          | yes         | yes         |
     +-----------------------------------------------------------+
     | Operational     | no          | no          | yes         |
     +-----------------------------------------------------------+
        
     +-----------------------------------------------------------+
     |From      To ->  | Security    | Operational | FullFeature |
     | |               |             |             |             |
     | V               |             |             |             |
     +-----------------------------------------------------------+
     | (start)         | yes         | yes         | no          |
     +-----------------------------------------------------------+
     | Security        | no          | yes         | yes         |
     +-----------------------------------------------------------+
     | Operational     | no          | no          | yes         |
     +-----------------------------------------------------------+
        

The Login Final-Response that accepts a Login Request can only come as a response to a Login Request with the T bit set to 1, and both the request and response MUST indicate FullFeaturePhase as the next phase via the NSG field.

接受登录请求的登录最终响应只能作为对T位设置为1的登录请求的响应,并且请求和响应必须通过NSG字段将FullFeaturePhase指示为下一阶段。

Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login, except for responses to specific keys that explicitly allow repeated key declarations (e.g., TargetAddress). An attempt to renegotiate/redeclare parameters not specifically allowed MUST be detected by the initiator and target. If such an attempt is detected by the target, the target MUST respond with a Login reject (initiator error); if detected by the initiator, the initiator MUST drop the connection.

发起方和目标方都不应在登录期间多次尝试声明或协商参数,除非响应明确允许重复密钥声明的特定密钥(例如TargetAddress)。发起者和目标必须检测到重新协商/重新声明不允许的参数的尝试。如果目标检测到此类尝试,目标必须以登录拒绝(启动器错误)响应;如果启动器检测到,则启动器必须断开连接。

6.3.1. Login Phase Start
6.3.1. 登录阶段开始

The Login Phase starts with a Login Request from the initiator to the target. The initial Login Request includes:

登录阶段从发起方向目标方发出登录请求开始。初始登录请求包括:

- Protocol version supported by the initiator

- 启动器支持的协议版本

- iSCSI Initiator Name and iSCSI Target Name

- iSCSI启动器名称和iSCSI目标名称

- ISID, TSIH, and connection IDs

- ISID、TSIH和连接ID

- Negotiation stage that the initiator is ready to enter

- 发起人准备进入的协商阶段

A login may create a new session, or it may add a connection to an existing session. Between a given iSCSI initiator node (selected only by an InitiatorName) and a given iSCSI target defined by an iSCSI TargetName and a Target Portal Group Tag, the login results are defined by the following table:

登录可以创建新会话,也可以向现有会话添加连接。在给定的iSCSI启动器节点(仅由InitiatorName选择)和由iSCSI TargetName和目标门户组标记定义的给定iSCSI目标之间,登录结果由下表定义:

    +----------------------------------------------------------------+
    |ISID    | TSIH        | CID    |   Target Action                |
    +----------------------------------------------------------------+
    |new     | non-zero    | any    |   fail the login               |
    |        |             |        |   ("session does not exist")   |
    +----------------------------------------------------------------+
    |new     | zero        | any    |   instantiate a new session    |
    +----------------------------------------------------------------+
    |existing| zero        | any    |   do session reinstatement     |
    |        |             |        |   (see Section 6.3.5)          |
    +----------------------------------------------------------------+
    |existing| non-zero    | new    |   add a new connection to      |
    |        | existing    |        |   the session                  |
    +----------------------------------------------------------------+
    |existing| non-zero    |existing|   do connection reinstatement  |
    |        | existing    |        |   (see Section 7.1.4.3)        |
    +----------------------------------------------------------------+
    |existing| non-zero    | any    |   fail the login               |
    |        | new         |        |   ("session does not exist")   |
    +----------------------------------------------------------------+
        
    +----------------------------------------------------------------+
    |ISID    | TSIH        | CID    |   Target Action                |
    +----------------------------------------------------------------+
    |new     | non-zero    | any    |   fail the login               |
    |        |             |        |   ("session does not exist")   |
    +----------------------------------------------------------------+
    |new     | zero        | any    |   instantiate a new session    |
    +----------------------------------------------------------------+
    |existing| zero        | any    |   do session reinstatement     |
    |        |             |        |   (see Section 6.3.5)          |
    +----------------------------------------------------------------+
    |existing| non-zero    | new    |   add a new connection to      |
    |        | existing    |        |   the session                  |
    +----------------------------------------------------------------+
    |existing| non-zero    |existing|   do connection reinstatement  |
    |        | existing    |        |   (see Section 7.1.4.3)        |
    +----------------------------------------------------------------+
    |existing| non-zero    | any    |   fail the login               |
    |        | new         |        |   ("session does not exist")   |
    +----------------------------------------------------------------+
        

The determination of "existing" or "new" is made by the target.

由目标公司确定“现有”或“新”。

Optionally, the Login Request may include:

可选地,登录请求可以包括:

- Security parameters OR

- 安全参数或

- iSCSI operational parameters AND/OR

- iSCSI操作参数和/或

- The next negotiation stage that the initiator is ready to enter

- 发起人准备进入的下一个协商阶段

The target can answer the login in the following ways:

目标可以通过以下方式回答登录:

- Login Response with Login reject. This is an immediate rejection from the target that causes the connection to terminate and the session to terminate if this is the first (or only) connection of a new session. The T bit, the CSG field, and the NSG field are reserved.

- 带有登录拒绝的登录响应。这是来自目标的立即拒绝,如果这是新会话的第一个(或唯一)连接,则会导致连接终止和会话终止。保留T位、CSG字段和NSG字段。

- Login Response with Login accept as the Final-Response (T bit set to 1 and the NSG in both request and response is set to FullFeaturePhase). The response includes the protocol version supported by the target and the session ID and may include iSCSI operational or security parameters (that depend on the current stage).

- 登录响应,登录接受作为最终响应(T位设置为1,请求和响应中的NSG都设置为FullFeaturePhase)。响应包括目标支持的协议版本和会话ID,还可能包括iSCSI操作或安全参数(取决于当前阶段)。

- Login Response with Login accept as a partial response (NSG not set to FullFeaturePhase in both request and response) that indicates the start of a negotiation sequence. The response includes the protocol version supported by the target and either security or iSCSI parameters (when no security mechanism is chosen) supported by the target.

- Login Response,Login accept作为部分响应(请求和响应中NSG未设置为FullFeaturePhase),指示协商序列的开始。响应包括目标支持的协议版本以及目标支持的安全或iSCSI参数(当未选择安全机制时)。

If the initiator decides to forego the SecurityNegotiation stage, it issues the Login with the CSG set to LoginOperationalNegotiation, and the target may reply with a Login Response that indicates that it is unwilling to accept the connection (see Section 11.13) without SecurityNegotiation and will terminate the connection with a response of Authentication failure (see Section 11.13.5).

如果发起者决定放弃SecurityNegotiation阶段,它会发出CSG设置为LoginOperationalNegotiation的登录,目标可能会回复一个登录响应,表明它不愿意接受连接(参见第11.13节)没有SecurityNegotiation,并将以认证失败的响应终止连接(见第11.13.5节)。

If the initiator is willing to negotiate iSCSI security, but is unwilling to make the initial parameter proposal and may accept a connection without iSCSI security, it issues the Login with the T bit set to 1, the CSG set to SecurityNegotiation, and the NSG set to LoginOperationalNegotiation. If the target is also ready to skip security, the Login Response only contains the TargetPortalGroupTag key (see Section 13.9), the T bit set to 1, the CSG set to SecurityNegotiation, and the NSG set to LoginOperationalNegotiation.

如果发起方愿意协商iSCSI安全性,但不愿意提出初始参数建议,并且可能接受没有iSCSI安全性的连接,则发起方将发送登录,T位设置为1,CSG设置为SecurityNegotiation,NSG设置为LoginOperationalNegotiation。如果目标也准备跳过安全性,则登录响应仅包含TargetPortalGroupTag密钥(参见第13.9节)、设置为1的T位、设置为SecurityNegotiation的CSG以及设置为LoginOperationalNegotiation的NSG。

An initiator that chooses to operate without iSCSI security and with all the operational parameters taking the default values issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation, and the NSG set to FullFeaturePhase. If the target is also ready to forego security and can finish its LoginOperationalNegotiation, the Login Response has the T bit set to 1, the CSG set to LoginOperationalNegotiation, and the NSG set to FullFeaturePhase in the next stage.

选择在没有iSCSI安全性且所有操作参数均采用默认值的情况下运行的启动器将发出登录,T位设置为1,CSG设置为LoginOperationalNegotiation,NSG设置为FullFeaturePhase。如果目标也准备放弃安全性,并且可以完成其LoginOperationalNegotiation,则在下一阶段,登录响应的T位设置为1,CSG设置为LoginOperationalNegotiation,NSG设置为FullFeaturePhase。

During the Login Phase, the iSCSI target MUST return the TargetPortalGroupTag key with the first Login Response PDU with which it is allowed to do so (i.e., the first Login Response issued after the first Login Request with the C bit set to 0) for all session types. The TargetPortalGroupTag key value indicates the iSCSI portal group servicing the Login Request PDU. If the reconfiguration of iSCSI portal groups is a concern in a given environment, the iSCSI initiator should use this key to ascertain that it had indeed initiated the Login Phase with the intended target portal group.

在登录阶段,对于所有会话类型,iSCSI目标必须返回TargetPortalGroupTag密钥以及允许其使用的第一个登录响应PDU(即,在第一个登录请求之后发出的第一个登录响应,C位设置为0)。TargetPortalGroupTag键值表示为登录请求PDU提供服务的iSCSI门户组。如果在给定环境中需要重新配置iSCSI门户组,则iSCSI启动器应使用此密钥来确定它确实已使用目标门户组启动了登录阶段。

6.3.2. iSCSI Security Negotiation
6.3.2. iSCSI安全协商

The security exchange sets the security mechanism and authenticates the initiator and the target to each other. The exchange proceeds according to the authentication method chosen in the negotiation phase and is conducted using the key=value parameters carried in the Login Requests and Responses.

安全交换设置安全机制,并相互验证启动器和目标。交换根据在协商阶段选择的身份验证方法进行,并使用登录请求和响应中包含的key=value参数进行。

An initiator-directed negotiation proceeds as follows:

发起人指导的协商进行如下:

- The initiator sends a Login Request with an ordered list of the options it supports (authentication algorithm). The options are listed in the initiator's order of preference. The initiator MAY also send private or public extension options.

- 启动器发送一个登录请求,其中包含它支持的选项的有序列表(身份验证算法)。选项按启动器的首选顺序列出。发起者还可以发送私有或公共扩展选项。

- The target MUST reply with the first option in the list it supports and is allowed to use for the specific initiator, unless it does not support any, in which case it MUST answer with "Reject" (see Section 6.2). The parameters are encoded in UTF-8 as key=value. For security parameters, see Section 12.

- 目标必须使用其支持的列表中的第一个选项进行回复,并且允许用于特定启动器,除非它不支持任何选项,在这种情况下,它必须回答“拒绝”(参见第6.2节)。参数在UTF-8中编码为key=value。有关安全参数,请参见第12节。

- When the initiator considers itself ready to conclude the SecurityNegotiation stage, it sets the T bit to 1 and the NSG to what it would like the next stage to be. The target will then set the T bit to 1 and set the NSG to the next stage in the Login Response when it finishes sending its security keys. The next stage selected will be the one the target selected. If the next stage is FullFeaturePhase, the target MUST reply with a Login Response with the TSIH value.

- 当发起方认为自己已准备好结束SecurityNegotiation阶段时,它将T位设置为1,并将NSG设置为它希望下一阶段的状态。然后,目标将T位设置为1,并在发送完安全密钥后将NSG设置为登录响应的下一阶段。选定的下一阶段将是目标选定的阶段。如果下一阶段是FullFeaturePhase,则目标必须使用带有TSIH值的登录响应进行回复。

If the security negotiation fails at the target, then the target MUST send the appropriate Login Response PDU. If the security negotiation fails at the initiator, the initiator SHOULD close the connection.

如果安全协商在目标上失败,则目标必须发送相应的登录响应PDU。如果启动器的安全协商失败,则启动器应关闭连接。

It should be noted that the negotiation might also be directed by the target if the initiator does support security but is not ready to direct the negotiation (propose options); see Appendix B for an example.

需要注意的是,如果发起人确实支持安全性,但尚未准备好指导协商,则协商也可能由目标公司指导(提出选项);有关示例,请参见附录B。

6.3.3. Operational Parameter Negotiation during the Login Phase
6.3.3. 登录阶段的操作参数协商

Operational parameter negotiation during the Login Phase MAY be done:

可在登录阶段进行操作参数协商:

- starting with the first Login Request if the initiator does not propose any security/integrity option.

- 如果发起人未提出任何安全/完整性选项,则从第一个登录请求开始。

- starting immediately after the security negotiation if the initiator and target perform such a negotiation.

- 如果发起方和目标方执行此类协商,则在安全协商后立即开始。

Operational parameter negotiation MAY involve several Login Request-Login Response exchanges started and terminated by the initiator. The initiator MUST indicate its intent to terminate the negotiation by setting the T bit to 1; the target sets the T bit to 1 on the last response.

操作参数协商可能涉及发起方启动和终止的多个登录请求-登录响应交换。发起者必须通过将T位设置为1来表明其终止协商的意图;目标在最后一个响应中将T位设置为1。

Even when the initiator indicates its intent to switch stages by setting the T bit to 1 in a Login Request, the target MAY respond with a Login Response with the T bit set to 0. In that case, the initiator SHOULD continue to set the T bit to 1 in subsequent Login Requests (even empty requests) that it sends, until the target sends a Login Response with the T bit set to 1 or sends a key that requires the initiator to set the T bit to 0.

即使当发起方通过在登录请求中将T位设置为1来表示其切换阶段的意图时,目标方也可以使用T位设置为0的登录响应进行响应。在这种情况下,启动器应在其发送的后续登录请求(甚至是空请求)中继续将T位设置为1,直到目标发送T位设置为1的登录响应或发送要求启动器将T位设置为0的密钥。

Some session-specific parameters can only be specified during the Login Phase of the first connection of a session (i.e., begun by a Login Request that contains a zero-valued TSIH) -- the leading Login Phase (e.g., the maximum number of connections that can be used for this session).

某些特定于会话的参数只能在会话的第一个连接的登录阶段(即,由包含零值TSIH的登录请求开始)指定(例如,可用于此会话的最大连接数)。

A session is operational once it has at least one connection in the Full Feature Phase. New or replacement connections can only be added to a session after the session is operational.

会话在完整功能阶段至少有一个连接后即可运行。新连接或替换连接只能在会话运行后添加到会话中。

For operational parameters, see Section 13.

有关操作参数,请参见第13节。

6.3.4. Connection Reinstatement
6.3.4. 连接恢复

Connection reinstatement is the process of an initiator logging in with an ISID-TSIH-CID combination that is possibly active from the target's perspective, which causes the implicit logging out of the connection corresponding to the CID and reinstatement of a new Full Feature Phase iSCSI connection in its place (with the same CID). Thus, the TSIH in the Login Request PDU MUST be non-zero, and the CID does not change during a connection reinstatement. The Login Request performs the logout function of the old connection if an explicit logout was not performed earlier. In sessions with a single connection, this may imply the opening of a second connection with the sole purpose of cleaning up the first. Targets MUST support opening a second connection even when they do not support multiple connections in the Full Feature Phase if ErrorRecoveryLevel is 2 and SHOULD support opening a second connection if ErrorRecoveryLevel is less than 2.

连接恢复是指启动器使用ISID-TSIH-CID组合登录的过程,从目标的角度来看,ISID-TSIH-CID组合可能处于活动状态,这会导致隐式注销对应于CID的连接,并在其位置恢复新的全功能阶段iSCSI连接(使用相同的CID)。因此,登录请求PDU中的TSIH必须为非零,并且CID在连接恢复期间不会更改。如果先前未执行显式注销,则登录请求将执行旧连接的注销功能。在具有单个连接的会话中,这可能意味着打开第二个连接的唯一目的是清理第一个连接。如果ErrorRecoveryLevel为2,则目标必须支持打开第二个连接,即使它们在完整功能阶段不支持多个连接,如果ErrorRecoveryLevel小于2,则应支持打开第二个连接。

If the operational ErrorRecoveryLevel is 2, connection reinstatement enables future task reassignment. If the operational ErrorRecoveryLevel is less than 2, connection reinstatement is the

如果operational ErrorRecoveryLevel为2,则连接恢复将启用将来的任务重新分配。如果操作错误RecoveryLevel小于2,则连接恢复是最重要的

replacement of the old CID without enabling task reassignment. In this case, all the tasks that were active on the old CID must be immediately terminated without further notice to the initiator.

在不启用任务重新分配的情况下替换旧CID。在这种情况下,必须立即终止旧CID上处于活动状态的所有任务,而无需进一步通知启动器。

The initiator connection state MUST be CLEANUP_WAIT (Section 8.1.3) when the initiator attempts a connection reinstatement.

当启动器尝试恢复连接时,启动器连接状态必须为CLEANUP_WAIT(第8.1.3节)。

In practical terms, in addition to the implicit logout of the old connection, reinstatement is equivalent to a new connection login.

实际上,除了隐式注销旧连接外,恢复相当于新连接登录。

6.3.5. Session Reinstatement, Closure, and Timeout
6.3.5. 会话恢复、关闭和超时

Session reinstatement is the process of an initiator logging in with an ISID that is possibly active from the target's perspective for that initiator, thus implicitly logging out the session that corresponds to the ISID and reinstating a new iSCSI session in its place (with the same ISID). Therefore, the TSIH in the Login PDU MUST be zero to signal session reinstatement. Session reinstatement causes all the tasks that were active on the old session to be immediately terminated by the target without further notice to the initiator.

会话恢复是指启动器使用ISID登录的过程,从目标方的角度来看,ISID可能处于活动状态,从而隐式注销与ISID对应的会话,并在其位置恢复新的iSCSI会话(使用相同的ISID)。因此,登录PDU中的TSIH必须为零,以表示会话恢复。会话恢复会导致目标立即终止在旧会话上处于活动状态的所有任务,而无需进一步通知启动器。

The initiator session state MUST be FAILED (Section 8.3) when the initiator attempts a session reinstatement.

当启动器尝试恢复会话时,启动器会话状态必须失败(第8.3节)。

Session closure is an event defined to be one of the following:

会话关闭是定义为以下事件之一的事件:

- a successful "session close" logout.

- 成功的“会话关闭”注销。

- a successful "connection close" logout for the last Full Feature Phase connection when no other connection in the session is waiting for cleanup (Section 8.2) and no tasks in the session are waiting for reassignment.

- 当会话中没有其他连接等待清理(第8.2节)且会话中没有任务等待重新分配时,最后一个完整功能阶段连接的成功“连接关闭”注销。

Session timeout is an event defined to occur when the last connection state timeout expires and no tasks are waiting for reassignment. This takes the session to the FREE state (see the session state diagrams in Section 8.3).

会话超时是定义为在上次连接状态超时过期且没有任务等待重新分配时发生的事件。这将使会话进入空闲状态(请参阅第8.3节中的会话状态图)。

6.3.5.1. Loss of Nexus Notification
6.3.5.1. 失去联系通知

The iSCSI layer provides the SCSI layer with the "I_T nexus loss" notification when any one of the following events happens:

当发生以下任一事件时,iSCSI层向SCSI层提供“I_T nexus丢失”通知:

- successful completion of session reinstatement

- 成功完成会话恢复

- session closure event

- 会话结束事件

- session timeout event

- 会话超时事件

Certain SCSI object clearing actions may result due to the notification in the SCSI end nodes, as documented in Appendix E.

某些SCSI对象清除操作可能由于SCSI终端节点中的通知而导致,如附录E中所述。

6.3.6. Session Continuation and Failure
6.3.6. 会话继续和失败

Session continuation is the process by which the state of a preexisting session continues to be used by connection reinstatement (Section 6.3.4) or by adding a connection with a new CID. Either of these actions associates the new transport connection with the session state.

会话继续是指通过连接恢复(第6.3.4节)或通过添加具有新CID的连接,继续使用先前存在会话的状态的过程。这些操作都会将新传输连接与会话状态相关联。

Session failure is an event where the last Full Feature Phase connection reaches the CLEANUP_WAIT state (Section 8.2) or completes a successful recovery logout, thus causing all active tasks (that are formerly allegiant to the connection) to start waiting for task reassignment.

会话失败是指最后一个完整功能阶段连接达到清除等待状态(第8.2节)或成功完成恢复注销,从而导致所有活动任务(以前是连接的allegiant)开始等待任务重新分配的事件。

6.4. Operational Parameter Negotiation outside the Login Phase
6.4. 登录阶段之外的操作参数协商

Some operational parameters MAY be negotiated outside (after) the Login Phase.

某些操作参数可能在登录阶段之外(之后)协商。

Parameter negotiation in the Full Feature Phase is done through Text Requests and Responses. Operational parameter negotiation MAY involve several Text Request-Text Response exchanges, all of which use the same Initiator Task Tag; the initiator always starts and terminates each of these exchanges. The initiator MUST indicate its intent to finish the negotiation by setting the F bit to 1; the target sets the F bit to 1 on the last response.

全功能阶段的参数协商是通过文本请求和响应完成的。操作参数协商可能涉及多个文本请求文本响应交换,所有这些交换都使用相同的启动器任务标签;启动器始终启动和终止这些交换。发起者必须通过将F位设置为1来表明其完成协商的意图;目标在最后一个响应中将F位设置为1。

If the target responds to a Text Request with the F bit set to 1 with a Text Response with the F bit set to 0, the initiator should keep sending the Text Request (even empty requests) with the F bit set to 1 while it still wants to finish the negotiation, until it receives the Text Response with the F bit set to 1. Responding to a Text Request with the F bit set to 1 with an empty (no key=value pairs) response with the F bit set to 0 is discouraged.

如果目标响应文本请求时F位设置为1,而文本响应时F位设置为0,则发起方应继续发送F位设置为1的文本请求(即使是空请求),同时仍希望完成协商,直到收到F位设置为1的文本响应。不鼓励使用F位设置为0的空(无键=值对)响应F位设置为1的文本请求。

Even when the initiator indicates its intent to finish the negotiation by setting the F bit to 1 in a Text Request, the target MAY respond with a Text Response with the F bit set to 0. In that case, the initiator SHOULD continue to set the F bit to 1 in subsequent Text Requests (even empty requests) that it sends, until the target sends the final Text Response with the F bit set to 1. Note that in the same case of a Text Request with the F bit set to 1, the target SHOULD NOT respond with an empty (no key=value pairs) Text Response with the F bit set to 0, because such a response may cause the initiator to abandon the negotiation.

即使当发起方通过在文本请求中将F位设置为1来表示其完成协商的意图时,目标方也可以使用F位设置为0的文本响应进行响应。在这种情况下,发起者应在其发送的后续文本请求(甚至是空请求)中继续将F位设置为1,直到目标发送F位设置为1的最终文本响应。注意,在F位设置为1的文本请求的相同情况下,目标不应使用F位设置为0的空(无键=值对)文本响应进行响应,因为这样的响应可能会导致启动器放弃协商。

Targets MUST NOT submit parameters that require an additional initiator Text Request in a Text Response with the F bit set to 1.

目标不得在F位设置为1的文本响应中提交需要额外启动器文本请求的参数。

In a negotiation sequence, the F bit settings in one Text Request-Text Response pair have no bearing on the F bit settings of the next pair. An initiator that has the F bit set to 1 in a request and is being answered with an F bit setting of 0 may issue the next request with the F bit set to 0.

在协商序列中,一个文本请求文本响应对中的F位设置与下一对的F位设置无关。在请求中,如果F位设置为1,并且正在使用F位设置0进行应答,则发起方可以发出下一个F位设置为0的请求。

Whenever the target responds with the F bit set to 0, it MUST set the Target Transfer Tag to a value other than the default 0xffffffff.

每当目标以设置为0的F位响应时,它必须将目标传输标记设置为默认0xFFFFFF以外的值。

An initiator MAY reset an operational parameter negotiation by issuing a Text Request with the Target Transfer Tag set to the value 0xffffffff after receiving a response with the Target Transfer Tag set to a value other than 0xffffffff. A target may reset an operational parameter negotiation by answering a Text Request with a Reject PDU.

在接收到目标传输标记设置为0xFFFFFF以外的值的响应后,启动器可以通过发出文本请求,将目标传输标记设置为0xFFFFFF值,从而重置操作参数协商。目标可以通过使用拒绝PDU回答文本请求来重置操作参数协商。

Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence, except for responses to specific keys that explicitly allow repeated key declarations (e.g., TargetAddress). If such an attempt is detected by the target, the target MUST respond with a Reject PDU with a reason of "Protocol Error". The initiator MUST reset the negotiation as outlined above.

在任何协商序列中,发起方和目标方都不应多次尝试声明或协商参数,除非响应明确允许重复密钥声明的特定密钥(例如TargetAddress)。如果目标检测到此类尝试,目标必须以“协议错误”为理由,用拒绝PDU进行响应。发起人必须按照上述说明重置协商。

Parameters negotiated by a text exchange negotiation sequence only become effective after the negotiation sequence is completed.

文本交换协商序列协商的参数只有在协商序列完成后才生效。

7. iSCSI Error Handling and Recovery
7. iSCSI错误处理和恢复
7.1. Overview
7.1. 概述
7.1.1. Background
7.1.1. 出身背景

The following two considerations prompted the design of much of the error recovery functionality in iSCSI:

以下两个考虑因素促使设计了iSCSI中的大部分错误恢复功能:

- An iSCSI PDU may fail the digest check and be dropped, despite being received by the TCP layer. The iSCSI layer must optionally be allowed to recover such dropped PDUs.

- iSCSI PDU可能无法通过摘要检查并被丢弃,尽管TCP层已接收到它。必须选择性地允许iSCSI层恢复此类丢失的PDU。

- A TCP connection may fail at any time during the data transfer. All the active tasks must optionally be allowed to be continued on a different TCP connection within the same session.

- 在数据传输过程中,TCP连接随时可能失败。必须有选择地允许在同一会话中的不同TCP连接上继续执行所有活动任务。

Implementations have considerable flexibility in deciding what degree of error recovery to support, when to use it, and by which mechanisms to achieve the required behavior. Only the externally visible actions of the error recovery mechanisms must be standardized to ensure interoperability.

实现在决定支持何种程度的错误恢复、何时使用以及通过何种机制实现所需行为方面具有相当大的灵活性。只有错误恢复机制的外部可见操作必须标准化,以确保互操作性。

This section describes a general model for recovery in support of interoperability. See Appendix D for further details on how the described model may be implemented. Compliant implementations do not have to match the implementation details of this model as presented, but the external behavior of such implementations must correspond to the externally observable characteristics of the presented model.

本节介绍了支持互操作性的一般恢复模型。有关如何实施所述模型的更多详细信息,请参见附录D。兼容的实现不必与所呈现的模型的实现细节相匹配,但此类实现的外部行为必须与所呈现模型的外部可观察特征相对应。

7.1.2. Goals
7.1.2. 目标

The major design goals of the iSCSI error recovery scheme are as follows:

iSCSI错误恢复方案的主要设计目标如下:

- Allow iSCSI implementations to meet different requirements by defining a collection of error recovery mechanisms from which implementations may choose.

- 通过定义一组可供实施选择的错误恢复机制,允许iSCSI实施满足不同的要求。

- Ensure interoperability between any two implementations supporting different sets of error recovery capabilities.

- 确保支持不同错误恢复功能集的任意两个实现之间的互操作性。

- Define the error recovery mechanisms to ensure command ordering even in the face of errors, for initiators that demand ordering.

- 定义错误恢复机制,以确保即使在出现错误的情况下,也能为需要排序的启动器进行命令排序。

- Do not make additions in the fast path, but allow moderate complexity in the error recovery path.

- 不要在快速路径中添加,但在错误恢复路径中允许中等复杂度。

- Prevent both the initiator and target from attempting to recover the same set of PDUs at the same time. For example, there must be a clear "error recovery functionality distribution" between the initiator and target.

- 防止启动器和目标同时尝试恢复同一组PDU。例如,启动器和目标之间必须有明确的“错误恢复功能分布”。

7.1.3. Protocol Features and State Expectations
7.1.3. 协议特性和状态期望

The initiator mechanisms defined in connection with error recovery are:

与错误恢复相关的启动器机制包括:

a) NOP-Out to probe sequence numbers of the target (Section 11.18)

a) NOP Out探测目标的序列号(第11.18节)

b) Command retry (Section 7.2.1)

b) 命令重试(第7.2.1节)

c) Recovery R2T support (Section 7.8)

c) 恢复R2T支持(第7.8节)

d) Requesting retransmission of status/data/R2T using the SNACK facility (Section 11.16)

d) 使用快餐设施请求重新传输状态/数据/R2T(第11.16节)

e) Acknowledging the receipt of the data (Section 11.16)

e) 确认收到数据(第11.16节)

f) Reassigning the connection allegiance of a task to a different TCP connection (Section 7.2.2)

f) 将任务的连接忠诚度重新分配给不同的TCP连接(第7.2.2节)

g) Terminating the entire iSCSI session to start afresh (Section 7.1.4.4)

g) 终止整个iSCSI会话以重新启动(第7.1.4.4节)

The target mechanisms defined in connection with error recovery are:

与错误恢复相关的目标机制包括:

a) NOP-In to probe sequence numbers of the initiator (Section 11.19)

a) NOP输入到启动器的探针序列号(第11.19节)

b) Requesting retransmission of data using the recovery R2T feature (Section 7.8)

b) 使用恢复R2T功能请求重新传输数据(第7.8节)

c) SNACK support (Section 11.16)

c) 零食支持(第11.16节)

d) Requesting that parts of read data be acknowledged (Section 11.7.2)

d) 要求确认部分读取数据(第11.7.2节)

e) Allegiance reassignment support (Section 7.2.2)

e) 忠诚重新分配支持(第7.2.2节)

f) Terminating the entire iSCSI session to force the initiator to start over (Section 7.1.4.4)

f) 终止整个iSCSI会话以强制启动器重新启动(第7.1.4.4节)

For any outstanding SCSI command, it is assumed that iSCSI, in conjunction with SCSI at the initiator, is able to keep enough information to be able to rebuild the command PDU and that outgoing

对于任何未完成的SCSI命令,假定iSCSI与启动器处的SCSI一起能够保留足够的信息,以便能够重建命令PDU和传出命令

data is available (in host memory) for retransmission while the command is outstanding. It is also assumed that at the target, incoming data (read data) MAY be kept for recovery, or it can be reread from a device server.

命令未执行时,数据(在主机内存中)可用于重新传输。还假定在目标位置,传入数据(读取数据)可以保留以进行恢复,也可以从设备服务器重新读取。

It is further assumed that a target will keep the "status and sense" for a command it has executed if it supports status retransmission.

进一步假设,如果目标支持状态重传,则目标将保持其已执行命令的“状态和感知”。

A target that agrees to support data retransmission is expected to be prepared to retransmit the outgoing data (i.e., Data-In) on request until either the status for the completed command is acknowledged or the data in question has been separately acknowledged.

同意支持数据重传的目标应准备根据请求重传传出数据(即数据输入),直到确认已完成命令的状态或单独确认相关数据。

7.1.4. Recovery Classes
7.1.4. 恢复班

iSCSI enables the following classes of recovery (in the order of increasing scope of affected iSCSI tasks):

iSCSI支持以下恢复级别(按受影响iSCSI任务范围的增加顺序):

- within a command (i.e., without requiring command restart)

- 在命令内(即,无需命令重新启动)

- within a connection (i.e., without requiring the connection to be rebuilt, but perhaps requiring command restart)

- 在连接内(即,不需要重建连接,但可能需要命令重新启动)

- connection recovery (i.e., perhaps requiring connections to be rebuilt and commands to be reissued)

- 连接恢复(即,可能需要重建连接并重新发布命令)

- session recovery

- 会话恢复

The recovery scenarios detailed in the rest of this section are representative rather than exclusive. In every case, they detail the lowest recovery class that MAY be attempted. The implementer is left to decide under which circumstances to escalate to the next recovery class and/or what recovery classes to implement. Both the iSCSI target and initiator MAY escalate the error handling to an error recovery class, which impacts a larger number of iSCSI tasks in any of the cases identified in the following discussion.

本节其余部分详细介绍的恢复场景具有代表性,而非排他性。在每种情况下,它们都详细说明了可能尝试的最低恢复级别。由实施者决定在何种情况下升级到下一个恢复类和/或实施何种恢复类。iSCSI目标和启动器都可能将错误处理升级到错误恢复级别,这会在以下讨论中确定的任何情况下影响大量iSCSI任务。

In all classes, the implementer has the choice of deferring errors to the SCSI initiator (with an appropriate response code), in which case the task, if any, has to be removed from the target and all the side effects, such as ACA, must be considered.

在所有类中,实现者都可以选择将错误推迟到SCSI启动器(使用适当的响应代码),在这种情况下,任务(如果有)必须从目标中删除,并且必须考虑所有副作用,例如ACA。

The use of within-connection and within-command recovery classes MUST NOT be attempted before the connection is in the Full Feature Phase.

在连接处于完整功能阶段之前,不得尝试使用连接内和命令内恢复类。

In the detailed description of the recovery classes, the mandating terms (MUST, SHOULD, MAY, etc.) indicate normative actions to be executed if the recovery class is supported (see Section 7.1.5 for the related negotiation semantics) and used.

在恢复类的详细描述中,强制条款(必须、应该、可能等)表示如果支持并使用恢复类(有关协商语义,请参见第7.1.5节),则要执行的规范性行动。

7.1.4.1. Recovery Within-command
7.1.4.1. 命令内恢复

At the target, the following cases lend themselves to within-command recovery:

在目标系统中,以下情况适用于命令内恢复:

Lost data PDU - realized through one of the following:

丢失数据PDU-通过以下方式之一实现:

a) Data digest error - dealt with as specified in Section 7.8, using the option of a recovery R2T

a) 数据摘要错误-按照第7.8节的规定处理,使用恢复R2T选项

b) Sequence reception timeout (no data or partial-data-and-no-F-bit) - considered an implicit sequence error and dealt with as specified in Section 7.9, using the option of a recovery R2T

b) 序列接收超时(无数据或部分数据和无F位)-视为隐式序列错误,并按照第7.9节的规定,使用恢复R2T选项进行处理

c) Header digest error, which manifests as a sequence reception timeout or a sequence error - dealt with as specified in Section 7.9, using the option of a recovery R2T

c) 报头摘要错误,表现为序列接收超时或序列错误-按照第7.9节的规定,使用恢复R2T选项进行处理

At the initiator, the following cases lend themselves to within-command recovery:

在启动器处,以下情况有助于命令内恢复:

Lost data PDU or lost R2T - realized through one of the following:

丢失的数据PDU或丢失的R2T-通过以下方式之一实现:

a) Data digest error - dealt with as specified in Section 7.8, using the option of a SNACK

a) 数据摘要错误-按照第7.8节的规定处理,使用零食选项

b) Sequence reception timeout (no status) or response reception timeout - dealt with as specified in Section 7.9, using the option of a SNACK

b) 序列接收超时(无状态)或响应接收超时-按照第7.9节的规定处理,使用零食选项

c) Header digest error, which manifests as a sequence reception timeout or a sequence error - dealt with as specified in Section 7.9, using the option of a SNACK

c) 标题摘要错误,表现为序列接收超时或序列错误-按照第7.9节的规定,使用快捷键选项进行处理

To avoid a race with the target, which may already have a recovery R2T or a termination response on its way, an initiator SHOULD NOT originate a SNACK for an R2T based on its internal timeouts (if any). Recovery in this case is better left to the target.

为了避免与目标的竞争(目标可能已经有恢复R2T或终止响应),发起者不应基于其内部超时(如果有)为R2T发起零食。在这种情况下,恢复最好留给目标。

The timeout values used by the initiator and target are outside the scope of this document. A sequence reception timeout is generally a large enough value to allow the data sequence transfer to be complete.

启动器和目标使用的超时值超出了本文档的范围。序列接收超时通常是一个足够大的值,以允许完成数据序列传输。

7.1.4.2. Recovery Within-connection
7.1.4.2. 连接内恢复

At the initiator, the following cases lend themselves to within-connection recovery:

在启动器处,以下情况有助于连接内恢复:

a) Requests not acknowledged for a long time. Requests are acknowledged explicitly through the ExpCmdSN or implicitly by receiving data and/or status. The initiator MAY retry non-acknowledged commands as specified in Section 7.2.

a) 长时间未确认的请求。请求通过ExpCmdSN显式确认,或通过接收数据和/或状态隐式确认。发起者可以按照第7.2节的规定重试未确认的命令。

b) Lost iSCSI numbered response. It is recognized by either identifying a data digest error on a Response PDU or a Data-In PDU carrying the status, or receiving a Response PDU with a higher StatSN than expected. In the first case, digest error handling is done as specified in Section 7.8, using the option of a SNACK. In the second case, sequence error handling is done as specified in Section 7.9, using the option of a SNACK.

b) 丢失iSCSI编号的响应。通过识别响应PDU上的数据摘要错误或PDU中携带状态的数据,或接收StatSN高于预期的响应PDU来识别。在第一种情况下,按照第7.8节的规定,使用零食选项进行摘要错误处理。在第二种情况下,序列错误处理按照第7.9节的规定进行,使用零食选项。

At the target, the following cases lend themselves to within-connection recovery:

在目标位置,以下情况有助于连接内恢复:

- Status/Response not acknowledged for a long time. The target MAY issue a NOP-In (with a valid Target Transfer Tag or otherwise) that carries the next status sequence number it is going to use in the StatSN field. This helps the initiator detect any missing StatSN(s) and issue a SNACK for the status.

- 状态/响应长时间未确认。目标可以发出NOP In(带有有效的目标传输标签或其他),该NOP In携带它将在StatSN字段中使用的下一个状态序列号。这有助于发起者检测任何缺失的StatSN,并发出状态提示。

The timeout values used by the initiator and the target are outside the scope of this document.

启动器和目标使用的超时值超出了本文档的范围。

7.1.4.3. Connection Recovery
7.1.4.3. 连接恢复

At an iSCSI initiator, the following cases lend themselves to connection recovery:

在iSCSI启动器上,以下情况有助于连接恢复:

a) TCP connection failure: The initiator MUST close the connection. It then MUST either implicitly or explicitly log out the failed connection with the reason code "remove the connection for recovery" and reassign connection allegiance for all commands still in progress associated with the failed connection on one or more connections (some or all of which MAY be newly established connections) using the "TASK REASSIGN" task management function (see Section 11.5.1). For an initiator, a command is in progress as long as it has not received a response or a Data-In PDU including status.

a) TCP连接失败:启动器必须关闭连接。然后,它必须隐式或显式地注销失败的连接,原因代码为“删除用于恢复的连接”,并使用“任务重新分配”任务管理功能(参见第11.5.1节)。对于启动器,只要未收到响应或PDU中的数据(包括状态),命令即处于进行中。

Note: The logout function is mandatory. However, a new connection establishment is only mandatory if the failed connection was the last or only connection in the session.

注意:注销功能是必需的。但是,只有当失败的连接是会话中的最后一个或唯一连接时,才必须建立新的连接。

b) Receiving an Asynchronous Message that indicates that one or all connections in a session have been dropped. The initiator MUST handle it as a TCP connection failure for the connection(s) referred to in the message.

b) 接收异步消息,该消息指示会话中的一个或所有连接已断开。对于消息中提到的连接,启动器必须将其作为TCP连接故障处理。

At an iSCSI target, the following cases lend themselves to connection recovery:

在iSCSI目标上,以下情况有助于连接恢复:

- TCP connection failure: The target MUST close the connection and, if more than one connection is available, the target SHOULD send an Asynchronous Message that indicates that it has dropped the connection. Then, the target will wait for the initiator to continue recovery.

- TCP连接失败:目标必须关闭连接,如果有多个连接可用,目标应发送一条异步消息,指示其已断开连接。然后,目标将等待启动器继续恢复。

7.1.4.4. Session Recovery
7.1.4.4. 会话恢复

Session recovery should be performed when all other recovery attempts have failed. Very simple initiators and targets MAY perform session recovery on all iSCSI errors and rely on recovery on the SCSI layer and above.

当所有其他恢复尝试失败时,应执行会话恢复。非常简单的启动器和目标可以对所有iSCSI错误执行会话恢复,并依赖SCSI层及更高级别的恢复。

Session recovery implies the closing of all TCP connections, internally aborting all executing and queued tasks for the given initiator at the target, terminating all outstanding SCSI commands with an appropriate SCSI service response at the initiator, and restarting a session on a new set of connection(s) (TCP connection establishment and login on all new connections).

会话恢复意味着关闭所有TCP连接,在内部中止目标上给定启动器的所有正在执行和排队的任务,在启动器上使用适当的SCSI服务响应终止所有未完成的SCSI命令,并在新连接集上重新启动会话(TCP连接建立和登录所有新连接)。

For possible clearing effects of session recovery on SCSI and iSCSI objects, refer to Appendix E.

有关会话恢复对SCSI和iSCSI对象可能产生的清除影响,请参阅附录E。

7.1.5. Error Recovery Hierarchy
7.1.5. 错误恢复层次结构

The error recovery classes described so far are organized into a hierarchy for ease in understanding and to limit the complexity of the implementation. With a few well-defined recovery levels, interoperability is easier to achieve. The attributes of this hierarchy are as follows:

迄今为止描述的错误恢复类被组织成一个层次结构,以便于理解并限制实现的复杂性。有了几个定义良好的恢复级别,互操作性更容易实现。此层次结构的属性如下所示:

a) Each level is a superset of the capabilities of the previous level. For example, Level 1 support implies supporting all capabilities of Level 0 and more.

a) 每个级别都是上一级别功能的超集。例如,级别1支持意味着支持级别0及以上的所有功能。

b) As a corollary, supporting a higher error recovery level means increased sophistication and possibly an increase in resource requirements.

b) 因此,支持更高的错误恢复级别意味着更高的复杂性,并且可能增加资源需求。

c) Supporting error recovery level "n" is advertised and negotiated by each iSCSI entity by exchanging the text key "ErrorRecoveryLevel=n". The lower of the two exchanged values is the operational ErrorRecoveryLevel for the session.

c) 支持错误恢复级别“n”由每个iSCSI实体通过交换文本键“ErrorRecoveryLevel=n”来公布和协商。两个交换值中较低的一个是会话的operational ErrorRecoveryLevel。

The following diagram represents the error recovery hierarchy.

下图表示错误恢复层次结构。

                            +
                           / \
                          / 2 \      <-- Connection recovery
                         +-----+
                        /   1   \    <-- Digest failure recovery
                       +---------+
                      /     0     \  <-- Session failure recovery
                     +-------------+
        
                            +
                           / \
                          / 2 \      <-- Connection recovery
                         +-----+
                        /   1   \    <-- Digest failure recovery
                       +---------+
                      /     0     \  <-- Session failure recovery
                     +-------------+
        

The following table lists the error recovery (ER) capabilities expected from the implementations that support each error recovery level.

下表列出了支持每个错误恢复级别的实现所需的错误恢复(ER)功能。

    +-------------------+--------------------------------------------+
    |ErrorRecoveryLevel | Associated Error Recovery Capabilities     |
    +-------------------+--------------------------------------------+
    |        0          | Session recovery class                     |
    |                   | (Session Recovery)                         |
    +-------------------+--------------------------------------------+
    |        1          | Digest failure recovery (see Note below)   |
    |                   | plus the capabilities of ER Level 0        |
    +-------------------+--------------------------------------------+
    |        2          | Connection recovery class                  |
    |                   | (Connection Recovery)                      |
    |                   | plus the capabilities of ER Level 1        |
    +-------------------+--------------------------------------------+
        
    +-------------------+--------------------------------------------+
    |ErrorRecoveryLevel | Associated Error Recovery Capabilities     |
    +-------------------+--------------------------------------------+
    |        0          | Session recovery class                     |
    |                   | (Session Recovery)                         |
    +-------------------+--------------------------------------------+
    |        1          | Digest failure recovery (see Note below)   |
    |                   | plus the capabilities of ER Level 0        |
    +-------------------+--------------------------------------------+
    |        2          | Connection recovery class                  |
    |                   | (Connection Recovery)                      |
    |                   | plus the capabilities of ER Level 1        |
    +-------------------+--------------------------------------------+
        

Note: Digest failure recovery is comprised of two recovery classes: the Within-connection recovery class (recovery within-connection) and the Within-command recovery class (recovery within-command).

注意:摘要故障恢复由两个恢复类组成:连接内恢复类(连接内恢复)和命令内恢复类(命令内恢复)。

When a defined value of ErrorRecoveryLevel is proposed by an originator in a text negotiation, the originator MUST support the functionality defined for the proposed value and, additionally, functionality corresponding to any defined value numerically less than the proposed value. When a defined value of ErrorRecoveryLevel

当发起人在文本协商中提出ErrorRecoveryLevel的定义值时,发起人必须支持为该建议值定义的功能,此外,还必须支持与数值小于该建议值的任何定义值对应的功能。当定义的ErrorRecoveryLevel值

is returned by a responder in a text negotiation, the responder MUST support the functionality corresponding to the ErrorRecoveryLevel it is accepting.

由响应者在文本协商中返回,响应者必须支持与其接受的ErrorRecoveryLevel对应的功能。

When either party attempts to use error recovery functionality beyond what is negotiated, the recovery attempts MAY fail, unless an a priori agreement outside the scope of this document exists between the two parties to provide such support.

当任何一方试图使用超出协商范围的错误恢复功能时,恢复尝试可能会失败,除非双方之间存在超出本文件范围的提供此类支持的先验协议。

Implementations MUST support error recovery level "0", while the rest are OPTIONAL to implement. In implementation terms, the above striation means that the following incremental sophistication with each level is required:

实现必须支持错误恢复级别“0”,而其余实现是可选的。在实施方面,上述条痕意味着每个级别需要以下增量复杂性:

    +-------------------+--------------------------------------------+
    | Level Transition  | Incremental Requirement                    |
    +-------------------+--------------------------------------------+
    |        0->1       | PDU retransmissions on the same connection |
    +-------------------+--------------------------------------------+
    |        1->2       | Retransmission across connections and      |
    |                   | allegiance reassignment                    |
    +-------------------+--------------------------------------------+
        
    +-------------------+--------------------------------------------+
    | Level Transition  | Incremental Requirement                    |
    +-------------------+--------------------------------------------+
    |        0->1       | PDU retransmissions on the same connection |
    +-------------------+--------------------------------------------+
    |        1->2       | Retransmission across connections and      |
    |                   | allegiance reassignment                    |
    +-------------------+--------------------------------------------+
        
7.2. Retry and Reassign in Recovery
7.2. 在恢复中重试并重新分配

This section summarizes two important and somewhat related iSCSI protocol features used in error recovery.

本节总结了错误恢复中使用的两个重要且有些相关的iSCSI协议功能。

7.2.1. Usage of Retry
7.2.1. 重试的使用

By resending the same iSCSI Command PDU ("retry") in the absence of a command acknowledgment (by way of an ExpCmdSN update) or a response, an initiator attempts to "plug" (what it thinks are) the discontinuities in CmdSN ordering on the target end. Discarded command PDUs, due to digest errors, may have created these discontinuities.

在没有命令确认(通过ExpCmdSN更新)或响应的情况下,通过重新发送相同的iSCSI命令PDU(“重试”),启动器尝试在目标端“插入”(它认为是)CmdSN顺序中的不连续性。由于摘要错误而丢弃的命令PDU可能造成了这些不连续性。

Retry MUST NOT be used for reasons other than plugging command sequence gaps and, in particular, cannot be used for requesting PDU retransmissions from a target. Any such PDU retransmission requests for a currently allegiant command in progress may be made using the SNACK mechanism described in Section 11.16, although the usage of SNACK is OPTIONAL.

除堵塞命令序列间隙外,不得使用“重试”,尤其不能用于从目标请求PDU重新传输。对于当前正在进行的allegiant命令,任何此类PDU重传请求都可以使用第11.16节中描述的SNACK机制发出,尽管SNACK的使用是可选的。

If initiators, as part of plugging command sequence gaps as described above, inadvertently issue retries for allegiant commands already in progress (i.e., targets did not see the discontinuities in CmdSN ordering), the duplicate commands are silently ignored by targets as specified in Section 4.2.2.1.

如果作为上述填补命令序列间隙的一部分,启动器无意中对已在执行的allegiant命令发出重试(即,目标没有看到CmdSN排序中的不连续性),则重复命令将被目标自动忽略,如第4.2.2.1节所述。

When an iSCSI command is retried, the command PDU MUST carry the original Initiator Task Tag and the original operational attributes (e.g., flags, function names, LUN, CDB, etc.) as well as the original CmdSN. The command being retried MUST be sent on the same connection as the original command, unless the original connection was already successfully logged out.

重试iSCSI命令时,命令PDU必须带有原始启动器任务标记和原始操作属性(例如,标志、功能名称、LUN、CDB等)以及原始CmdSN。重试的命令必须在与原始命令相同的连接上发送,除非原始连接已成功注销。

7.2.2. Allegiance Reassignment
7.2.2. 效忠重新分配

By issuing a "TASK REASSIGN" task management request (Section 11.5.1), the initiator signals its intent to continue an already active command (but with no current connection allegiance) as part of connection recovery. This means that a new connection allegiance is requested for the command, which seeks to associate it to the connection on which the task management request is being issued. Before the allegiance reassignment is attempted for a task, an implicit or explicit Logout with the reason code "remove the connection for recovery" (see Section 11.14.1) MUST be successfully completed for the previous connection to which the task was allegiant.

通过发出“任务重新分配”任务管理请求(第11.5.1节),发起者表示其打算继续执行已激活的命令(但没有当前的连接忠诚),作为连接恢复的一部分。这意味着将为命令请求新的连接效忠,该命令试图将其与发出任务管理请求的连接相关联。在尝试为任务重新分配忠诚之前,必须为任务所属的上一个连接成功完成隐式或显式注销,原因代码为“删除恢复连接”(见第11.14.1节)。

In reassigning connection allegiance for a command, the target SHOULD continue the command from its current state. For example, when reassigning read commands, the target SHOULD take advantage of the ExpDataSN field provided by the Task Management Function Request (which must be set to 0 if there was no data transfer) and bring the read command to completion by sending the remaining data and sending (or resending) the status. The ExpDataSN acknowledges all data sent up to, but not including, the Data-In PDU and/or R2T with the DataSN (or R2TSN) equal to the ExpDataSN. However, targets may choose to send/receive all unacknowledged data or all of the data on a reassignment of connection allegiance if unable to recover or maintain accurate state. Initiators MUST NOT subsequently request data retransmission through Data SNACK for PDUs numbered less than the ExpDataSN (i.e., prior to the acknowledged sequence number). For all types of commands, a reassignment request implies that the task is still considered in progress by the initiator, and the target must conclude the task appropriately if the target returns the "Function complete" response to the reassignment request. This might possibly involve retransmission of data/R2T/status PDUs as necessary but MUST involve the (re)transmission of the status PDU.

在为命令重新分配连接效忠时,目标应从其当前状态继续执行该命令。例如,在重新分配读取命令时,目标应利用任务管理功能请求提供的EXPDASN字段(如果没有数据传输,则必须设置为0),并通过发送剩余数据和发送(或重新发送)状态来完成读取命令。ExpDataSN确认发送至(但不包括)PDU和/或R2T中的数据的所有数据,其中DataSN(或R2TSN)等于ExpDataSN。但是,如果无法恢复或保持准确状态,目标可以选择发送/接收所有未确认的数据或重新分配连接忠诚时的所有数据。发起者随后不得通过编号小于EXPDASN(即,在确认序列号之前)的PDU的数据零食请求数据重传。对于所有类型的命令,重新分配请求意味着发起者仍认为任务正在进行中,如果目标返回对重新分配请求的“功能完成”响应,则目标必须适当结束任务。这可能需要重新传输数据/R2T/状态PDU,但必须涉及(重新)传输状态PDU。

It is OPTIONAL for targets to support the allegiance reassignment. This capability is negotiated via the ErrorRecoveryLevel text key during the login time. When a target does not support allegiance reassignment, it MUST respond with a task management response code of "Task allegiance reassignment not supported". If allegiance reassignment is supported by the target but the task is still allegiant to a different connection, or a successful recovery Logout of the previously allegiant connection was not performed, the target MUST respond with a task management response code of "Task still allegiant".

目标支持效忠重新分配是可选的。此功能在登录期间通过ErrorRecoveryLevel文本键协商。当目标不支持效忠重新分配时,它必须使用“不支持任务效忠重新分配”的任务管理响应代码进行响应。如果目标支持效忠重新分配,但任务仍然效忠于其他连接,或者未成功恢复注销以前的效忠连接,则目标必须使用任务管理响应代码“task still allegiant”进行响应。

If allegiance reassignment is supported by the target, the task management response to the reassignment request MUST be issued before the reassignment becomes effective.

如果目标公司支持效忠重新分配,则必须在重新分配生效之前发出任务管理部门对重新分配请求的响应。

If a SCSI command that involves data input is reassigned, any SNACK Tag it holds for a final response from the original connection is deleted, and the default value of 0 MUST be used instead.

如果重新分配了涉及数据输入的SCSI命令,则会删除它为原始连接的最终响应保留的任何零食标记,并且必须使用默认值0。

7.3. Usage of Reject PDU in Recovery
7.3. 拒绝PDU在恢复中的使用

Targets MUST NOT implicitly terminate an active task by sending a Reject PDU for any PDU exchanged during the life of the task. If the target decides to terminate the task, a Response PDU (SCSI, Text, Task, etc.) must be returned by the target to conclude the task. If the task had never been active before the Reject (i.e., the Reject is on the command PDU), targets should not send any further responses because the command itself is being discarded.

目标不得通过为任务生命周期内交换的任何PDU发送拒绝PDU来隐式终止活动任务。如果目标决定终止任务,则目标必须返回响应PDU(SCSI、文本、任务等)以结束任务。如果任务在拒绝之前从未处于活动状态(即,拒绝在命令PDU上),则目标不应发送任何进一步的响应,因为命令本身正在被丢弃。

The above rule means that the initiator can eventually expect a response on receiving Rejects, if the received Reject is for a PDU other than the command PDU itself. The non-command Rejects only have diagnostic value in logging the errors, and they can be used for retransmission decisions by the initiators.

上述规则意味着,如果接收到的拒绝是针对PDU而不是命令PDU本身,则发起方最终可以期望收到拒绝时的响应。非命令拒绝仅在记录错误时具有诊断价值,它们可用于启动器的重新传输决策。

The CmdSN of the rejected command PDU (if it is a non-immediate command) MUST NOT be considered received by the target (i.e., a command sequence gap must be assumed for the CmdSN), even though the CmdSN of the rejected command PDU may be reliably ascertained. Upon receiving the Reject, the initiator MUST plug the CmdSN gap in order to continue to use the session. The gap may be plugged by either transmitting a command PDU with the same CmdSN or aborting the task (see Section 7.11 for information regarding how an abort may plug a CmdSN gap).

即使可以可靠地确定被拒绝命令PDU的CmdSN,目标也不得认为已接收到被拒绝命令PDU的CmdSN(如果是非即时命令)(即,必须为CmdSN假定命令序列间隔)。收到拒绝后,发起方必须插入CmdSN间隙才能继续使用会话。可以通过使用相同的CmdSN发送命令PDU或中止任务来堵塞间隙(有关中止如何堵塞CmdSN间隙的信息,请参阅第7.11节)。

When a data PDU is rejected and its DataSN can be ascertained, a target MUST advance the ExpDataSN for the current data burst if a recovery R2T is being generated. The target MAY advance its ExpDataSN if it does not attempt to recover the lost data PDU.

当数据PDU被拒绝且其数据编号可以确定时,如果正在生成恢复R2T,则目标必须提前当前数据突发的EXPDASN。如果目标不尝试恢复丢失的数据PDU,它可能会提前EXPDASCN。

7.4. Error Recovery Considerations for Discovery Sessions
7.4. 发现会话的错误恢复注意事项
7.4.1. ErrorRecoveryLevel for Discovery Sessions
7.4.1. 发现会话的ErrorRecoveryLevel

The negotiation of the key ErrorRecoveryLevel is not required for Discovery sessions -- i.e., for sessions that negotiated "SessionType=Discovery" -- because the default value of 0 is necessary and sufficient for Discovery sessions. It is, however, possible that some legacy iSCSI implementations might attempt to negotiate the ErrorRecoveryLevel key on Discovery sessions. When such a negotiation attempt is made by the remote side, a compliant iSCSI implementation MUST propose a value of 0 (zero) in response. The operational ErrorRecoveryLevel for Discovery sessions thus MUST be 0. This naturally follows from the functionality constraints that Section 4.3 imposes on Discovery sessions.

发现会话不需要协商密钥ErrorRecoveryLevel,即协商“SessionType=Discovery”的会话,因为默认值0对于发现会话来说是必要且足够的。但是,某些旧式iSCSI实施可能会尝试在发现会话上协商ErrorRecoveryLevel密钥。当远程端进行此类协商尝试时,符合要求的iSCSI实施必须提出0(零)作为响应。因此,发现会话的operational ErrorRecoveryLevel必须为0。这自然源于第4.3节对发现会话施加的功能约束。

7.4.2. Reinstatement Semantics for Discovery Sessions
7.4.2. 发现会话的恢复语义

Discovery sessions are intended to be relatively short-lived. Initiators are not expected to establish multiple Discovery sessions to the same iSCSI Network Portal. An initiator may use the same iSCSI Initiator Name and ISID when establishing different unique sessions with different targets and/or different portal groups. This behavior is discussed in Section 10.1.1 and is, in fact, encouraged as conservative reuse of ISIDs.

发现会话的寿命相对较短。启动器不应建立到同一iSCSI网络入口的多个发现会话。当使用不同的目标和/或不同的门户组建立不同的唯一会话时,启动器可以使用相同的iSCSI启动器名称和ISID。第10.1.1节讨论了这种行为,事实上,作为ISID的保守重用,鼓励这种行为。

The ISID RULE in Section 4.4.3 states that there must not be more than one session with a matching 4-tuple: <InitiatorName, ISID, TargetName, TargetPortalGroupTag>. While the spirit of the ISID RULE applies to Discovery sessions the same as it does for Normal sessions, note that some Discovery sessions differ from the Normal sessions in two important aspects:

第4.4.3节中的ISID规则规定,具有匹配4元组的会话不得超过一个:<InitiatorName,ISID,TargetName,TargetPortalGroupTag>。虽然ISID规则的精神适用于发现会话,与适用于正常会话的精神相同,但请注意,某些发现会话在两个重要方面与正常会话不同:

a) Because Appendix C allows a Discovery session to be established without specifying a TargetName key in the Login Request PDU (let us call such a session an "Unnamed" Discovery session), there is no target node context to enforce the ISID RULE.

a) 由于附录C允许在不在登录请求PDU中指定TargetName密钥的情况下建立发现会话(让我们将此类会话称为“未命名”发现会话),因此没有目标节点上下文来实施ISID规则。

b) Portal groups are defined only in the context of a target node. When the TargetName key is NULL-valued (i.e., not specified), the TargetPortalGroupTag thus cannot be ascertained to enforce the ISID RULE.

b) 门户组仅在目标节点的上下文中定义。当TargetName键为空值(即未指定)时,无法确定TargetPortalGroupTag以强制执行ISID规则。

The following two sections describe Unnamed Discovery sessions and Named Discovery sessions, respectively.

以下两部分分别描述未命名发现会话和命名发现会话。

7.4.2.1. Unnamed Discovery Sessions
7.4.2.1. 未命名的发现会话

For Unnamed Discovery sessions, neither the TargetName nor the TargetPortalGroupTag is available to the targets in order to enforce the ISID RULE. Therefore, the following rule applies.

对于未命名的发现会话,目标无法使用TargetName或TargetPortalGroupTag来强制执行ISID规则。因此,以下规则适用。

UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the following 4-tuple for Unnamed Discovery sessions: <InitiatorName, ISID, NULL, TargetAddress>. The following semantics are implied by this uniqueness requirement.

未命名ISID规则:目标必须为未命名发现会话强制以下4元组的唯一性:<InitiatorName,ISID,NULL,TargetAddress>。此唯一性要求隐含了以下语义。

Targets SHOULD allow concurrent establishment of one Discovery session with each of its Network Portals by the same initiator port with a given iSCSI Node Name and an ISID. Each of the concurrent Discovery sessions, if established by the same initiator port to other Network Portals, MUST be treated as independent sessions -- i.e., one session MUST NOT reinstate the other.

目标应允许通过具有给定iSCSI节点名称和ISID的同一启动器端口与其每个网络入口同时建立一个发现会话。如果每个并发发现会话由同一启动器端口建立到其他网络门户,则必须将其视为独立会话——即,一个会话不得恢复另一个会话。

A new Unnamed Discovery session that has a matching <InitiatorName, ISID, NULL, TargetAddress> to an existing Discovery session MUST reinstate the existing Unnamed Discovery session. Note thus that only an Unnamed Discovery session may reinstate another Unnamed Discovery session.

如果新的未命名发现会话与现有发现会话具有匹配的<InitiatorName,ISID,NULL,TargetAddress>,则必须恢复现有的未命名发现会话。因此请注意,只有未命名的发现会话可以恢复另一个未命名的发现会话。

7.4.2.2. Named Discovery Sessions
7.4.2.2. 命名发现会话

For Named Discovery sessions, the TargetName key is specified by the initiator, and thus the target can unambiguously ascertain the TargetPortalGroupTag as well. Since all the four elements of the 4-tuple are known, the ISID RULE MUST be enforced by targets with no changes from Section 4.4.3 semantics. A new session with a matching <InitiatorName, ISID, TargetName, TargetPortalGroupTag> thus will reinstate an existing session. Note in this case that any new iSCSI session (Discovery or Normal) with the matching 4-tuple may reinstate an existing Named Discovery iSCSI session.

对于命名发现会话,TargetName密钥由启动器指定,因此目标也可以明确地确定TargetPortalGroupTag。由于4元组的所有四个元素都是已知的,因此目标必须在不改变第4.4.3节语义的情况下实施ISID规则。因此,具有匹配的<InitiatorName、ISID、TargetName、TargetPortalGroupTag>的新会话将恢复现有会话。请注意,在这种情况下,任何具有匹配的4元组的新iSCSI会话(发现或正常)都可能恢复现有的命名发现iSCSI会话。

7.4.3. Target PDUs during Discovery
7.4.3. 发现过程中的目标PDU

Targets SHOULD NOT send any responses other than a Text Response and Logout Response on a Discovery session, once in the Full Feature Phase.

一旦处于完整功能阶段,目标不应在发现会话上发送除文本响应和注销响应以外的任何响应。

Implementation Note: A target may simply drop the connection in a Discovery session when it would have requested a Logout via an Async Message on Normal sessions.

实现说明:当目标在正常会话上通过异步消息请求注销时,它可以在发现会话中简单地断开连接。

7.5. Connection Timeout Management
7.5. 连接超时管理

iSCSI defines two session-global timeout values (in seconds) -- Time2Wait and Time2Retain -- that are applicable when an iSCSI Full Feature Phase connection is taken out of service either intentionally or by an exception. Time2Wait is the initial "respite time" before attempting an explicit/implicit Logout for the CID in question or task reassignment for the affected tasks (if any). Time2Retain is the maximum time after the initial respite interval that the task and/or connection state(s) is/are guaranteed to be maintained on the target to cater to a possible recovery attempt. Recovery attempts for the connection and/or task(s) SHOULD NOT be made before Time2Wait seconds but MUST be completed within Time2Retain seconds after that initial Time2Wait waiting period.

iSCSI定义了两个会话全局超时值(以秒为单位)--Time2Wait和Time2Retain--当iSCSI全功能阶段连接有意或因异常而停止服务时适用。Time2Wait是尝试显式/隐式注销相关CID或重新分配受影响任务(如果有)之前的初始“暂停时间”。Time2Retain是初始暂停间隔后保证在目标上保持任务和/或连接状态以满足可能的恢复尝试的最长时间。连接和/或任务的恢复尝试不应在Time2Wait秒之前进行,但必须在初始Time2Wait等待期之后的Time2Retain秒内完成。

7.5.1. Timeouts on Transport Exception Events
7.5.1. 传输异常事件超时

A transport connection shutdown or a transport reset without any preceding iSCSI protocol interactions informing the endpoints of the fact causes a Full Feature Phase iSCSI connection to be abruptly terminated. The timeout values to be used in this case are the negotiated values of DefaultTime2Wait (Section 13.15) and DefaultTime2Retain (Section 13.16) text keys for the session.

在没有任何先前的iSCSI协议交互通知端点的情况下关闭传输连接或重置传输会导致完全功能阶段iSCSI连接突然终止。本例中使用的超时值是会话的DefaultTime2Wait(第13.15节)和DefaultTime2Retain(第13.16节)文本键的协商值。

7.5.2. Timeouts on Planned Decommissioning
7.5.2. 计划退役超时

Any planned decommissioning of a Full Feature Phase iSCSI connection is preceded by either a Logout Response PDU or an Async Message PDU. The Time2Wait and Time2Retain field values (Section 11.15) in a Logout Response PDU, and the Parameter2 and Parameter3 fields of an Async Message (AsyncEvent types "drop the connection" or "drop all the connections"; see Section 11.9.1), specify the timeout values to be used in each of these cases.

任何计划的全功能阶段iSCSI连接停用之前都会有一个注销响应PDU或一个异步消息PDU。注销响应PDU中的Time2Wait和Time2Retain字段值(第11.15节)以及异步消息的Parameter2和Parameter3字段(AsyncEvent类型“删除连接”或“删除所有连接”;请参阅第11.9.1节)指定在每种情况下使用的超时值。

These timeout values are only applicable for the affected connection and the tasks active on that connection. These timeout values have no bearing on initiator timers (if any) that are already running on connections or tasks associated with that session.

这些超时值仅适用于受影响的连接以及该连接上活动的任务。这些超时值与已在与该会话关联的连接或任务上运行的启动器计时器(如果有)无关。

7.6. Implicit Termination of Tasks
7.6. 任务的隐性终止

A target implicitly terminates the active tasks due to iSCSI protocol dynamics in the following cases:

在以下情况下,由于iSCSI协议动态,目标隐式终止活动任务:

a) When a connection is implicitly or explicitly logged out with the reason code "close the connection" and there are active tasks allegiant to that connection.

a) 当连接以“close the connection”(关闭连接)的原因码隐式或显式注销,并且该连接存在活动任务allegiant时。

b) When a connection fails and eventually the connection state times out (state transition M1 in Section 8.2.2), and there are active tasks allegiant to that connection.

b) 当一个连接失败并最终连接状态超时时(第8.2.2节中的状态转换M1),并且存在到该连接的活动任务allegiant。

c) When a successful Logout with the reason code "remove the connection for recovery" is performed while there are active tasks allegiant to that connection, and those tasks eventually time out after the Time2Wait and Time2Retain periods without allegiance reassignment.

c) 在存在与该连接相关的活动任务且这些任务最终在Time2Wait和Time2Retain时间段后超时而未重新分配忠诚度的情况下,成功注销并显示原因代码“移除连接以进行恢复”时。

d) When a connection is implicitly or explicitly logged out with the reason code "close the session" and there are active tasks in that session.

d) 当连接以“关闭会话”的原因码隐式或显式注销,并且该会话中存在活动任务时。

If the tasks terminated in cases a), b), c), and d) above are SCSI tasks, they must be internally terminated as if with CHECK CONDITION status. This status is only meaningful for appropriately handling the internal SCSI state and SCSI side effects with respect to ordering, because this status is never communicated back as a terminating status to the initiator. However, additional actions may have to be taken at the SCSI level, depending on the SCSI context as defined by the SCSI standards (e.g., queued commands and ACA; UA for the next command on the I_T nexus in cases a), b), and c); etc. -- see [SAM2] and [SPC3]).

如果在上述情况a)、b)、c)和d)中终止的任务是SCSI任务,则它们必须在内部终止,就像使用检查条件状态一样。此状态仅对适当处理内部SCSI状态和与订购有关的SCSI副作用有意义,因为此状态永远不会作为终止状态传回启动器。但是,根据SCSI标准定义的SCSI上下文(例如,排队命令和ACA;在情况a)、b和c中,为I_T nexus上的下一个命令使用UA),可能必须在SCSI级别采取额外的操作;等——见[SAM2]和[SPC3])。

7.7. Format Errors
7.7. 格式错误

The following two explicit violations of PDU layout rules are format errors:

以下两个明显违反PDU布局规则的行为是格式错误:

a) Illegal contents of any PDU header field except the Opcode (legal values are specified in Section 11).

a) 任何PDU头字段(操作码除外)的非法内容(第11节规定了合法值)。

b) Inconsistent field contents (consistent field contents are specified in Section 11).

b) 字段内容不一致(第11节规定了一致的字段内容)。

Format errors indicate a major implementation flaw in one of the parties.

格式错误表示其中一方存在重大的实现缺陷。

When a target or an initiator receives an iSCSI PDU with a format error, it MUST immediately terminate all transport connections in the session with either a connection close or a connection reset, and escalate the format error to session recovery (see Section 7.1.4.4).

当目标或启动器收到带有格式错误的iSCSI PDU时,它必须立即终止会话中的所有传输连接,关闭连接或重置连接,并将格式错误升级到会话恢复(请参阅第7.1.4.4节)。

All initiator-detected PDU construction errors MUST be considered as format errors. Some examples of such errors are:

所有启动器检测到的PDU构造错误都必须视为格式错误。此类错误的一些示例如下:

- NOP-In with a valid TTT but an invalid LUN

- NOP In具有有效的TTT,但LUN无效

- NOP-In with a valid ITT (i.e., a NOP-In response) and also a valid TTT

- NOP In带有有效的ITT(即NOP响应)和有效的TTT

- SCSI Response PDU with Status=CHECK CONDITION, but DataSegmentLength = 0

- SCSI响应PDU,状态=检查条件,但数据段长度=0

7.8. Digest Errors
7.8. 摘要错误

The discussion below regarding the legal choices in handling digest errors excludes session recovery as an explicit option, but either party detecting a digest error may choose to escalate the error to session recovery.

下面关于处理摘要错误的法律选择的讨论将会话恢复排除在外,作为一个明确的选项,但检测摘要错误的任何一方都可以选择将错误升级到会话恢复。

When a target or an initiator receives any iSCSI PDU with a header digest error, it MUST either discard the header and all data up to the beginning of a later PDU or close the connection. Because the digest error indicates that the length field of the header may have been corrupted, the location of the beginning of a later PDU needs to be reliably ascertained by other means, such as the operation of a Sync and Steering layer.

当目标或启动器接收到任何带有标头摘要错误的iSCSI PDU时,它必须放弃标头和所有数据,直到稍后的PDU开始,或者关闭连接。由于摘要错误指示报头的长度字段可能已损坏,因此需要通过诸如同步和引导层的操作等其他手段可靠地确定稍后PDU的开始位置。

When a target receives any iSCSI PDU with a payload digest error, it MUST answer with a Reject PDU with a reason code of Data-Digest-Error and discard the PDU.

当目标接收到任何带有负载摘要错误的iSCSI PDU时,它必须使用带有数据摘要错误原因码的拒绝PDU进行应答,并丢弃该PDU。

- If the discarded PDU is a solicited or unsolicited iSCSI data PDU (for immediate data in a command PDU, the non-data PDU rule below applies), the target MUST do one of the following:

- 如果丢弃的PDU是请求的或未经请求的iSCSI数据PDU(对于命令PDU中的即时数据,以下非数据PDU规则适用),则目标必须执行以下操作之一:

a) Request retransmission with a recovery R2T.

a) 使用恢复R2T请求重新传输。

b) Terminate the task with a SCSI Response PDU with a CHECK CONDITION Status and an iSCSI Condition of "Protocol Service CRC error" (Section 11.4.7.2). If the target chooses to implement this option, it MUST wait to receive all the data (signaled by a data PDU with the Final bit set for all outstanding R2Ts) before sending the SCSI Response PDU. A task management command (such as an ABORT TASK) from the initiator during this wait may also conclude the task.

b) 使用带有检查条件状态和iSCSI条件“协议服务CRC错误”的SCSI响应PDU终止任务(第11.4.7.2节)。如果目标选择实现此选项,则在发送SCSI响应PDU之前,它必须等待接收所有数据(由数据PDU发出信号,并为所有未完成的R2T设置了最终位)。在此等待期间,发起者发出的任务管理命令(如中止任务)也可能结束任务。

- No further action is necessary for targets if the discarded PDU is a non-data PDU. In the case of immediate data being present on a discarded command, the immediate data is implicitly recovered when the task is retried (see Section 7.2.1), followed by the entire data transfer for the task.

- 如果丢弃的PDU是非数据PDU,则无需对目标执行进一步操作。如果丢弃的命令上存在即时数据,则在重试任务时(参见第7.2.1节),即时数据将隐式恢复,然后进行任务的整个数据传输。

When an initiator receives any iSCSI PDU with a payload digest error, it MUST discard the PDU.

当启动器收到任何带有负载摘要错误的iSCSI PDU时,它必须丢弃该PDU。

- If the discarded PDU is an iSCSI data PDU, the initiator MUST do one of the following:

- 如果丢弃的PDU是iSCSI数据PDU,则启动器必须执行以下操作之一:

a) Request the desired data PDU through SNACK. In response to the SNACK, the target MUST either resend the data PDU or reject the SNACK with a Reject PDU with a reason code of "SNACK reject", in which case:

a) 通过Snapshot请求所需的数据PDU。作为对零食的响应,目标公司必须重新发送数据PDU或拒绝零食,拒绝PDU的原因码为“零食拒绝”,在这种情况下:

a.1) If the status has not already been sent for the command, the target MUST terminate the command with a CHECK CONDITION Status and an iSCSI Condition of "SNACK rejected" (Section 11.4.7.2).

a、 1)如果尚未发送命令的状态,则目标必须使用检查条件状态和iSCSI条件“快餐拒绝”(第11.4.7.2节)终止命令。

a.2) If the status was already sent, no further action is necessary for the target. The initiator in this case MUST wait for the status to be received and then discard it, so as to internally signal the completion with CHECK CONDITION Status and an iSCSI Condition of "Protocol Service CRC error" (Section 11.4.7.2).

a、 2)如果状态已发送,则无需对目标执行进一步操作。在这种情况下,启动器必须等待接收到状态,然后放弃该状态,以便在内部用“协议服务CRC错误”的检查条件状态和iSCSI条件发出完成信号(第11.4.7.2节)。

b) Abort the task and terminate the command with an error.

b) 中止任务并在出现错误时终止命令。

- If the discarded PDU is a response PDU or an unsolicited PDU (e.g., Async, Reject), the initiator MUST do one of the following:

- 如果丢弃的PDU是响应PDU或未经请求的PDU(例如,异步、拒绝),则启动器必须执行以下操作之一:

a) Request PDU retransmission with a status of SNACK.

a) 请求状态为的PDU重新传输。

b) Log out the connection for recovery, and continue the tasks on a different connection instance as described in Section 7.2.

b) 注销连接以进行恢复,然后在不同的连接实例上继续执行任务,如第7.2节所述。

c) Log out to close the connection (abort all the commands associated with the connection).

c) 注销以关闭连接(中止与连接关联的所有命令)。

Note that an unsolicited PDU carries the next StatSN value on an iSCSI connection, thereby advancing the StatSN. When an initiator discards one of these PDUs due to a payload digest error, the entire PDU, including the header, MUST be discarded. Consequently, the initiator MUST treat the exception like a loss of any other solicited response PDU.

请注意,未经请求的PDU在iSCSI连接上携带下一个StatSN值,从而提升StatSN。当启动器由于负载摘要错误而丢弃其中一个PDU时,必须丢弃整个PDU,包括标头。因此,发起者必须将异常视为任何其他请求响应PDU的丢失。

7.9. Sequence Errors
7.9. 序列错误

When an initiator receives an iSCSI R2T/data PDU with an out-of-order R2TSN/DataSN or a SCSI Response PDU with an ExpDataSN that implies missing data PDU(s), it means that the initiator must have detected a header or payload digest error on one or more earlier R2T/data PDUs.

当启动器接收到带有无序R2TSN/DataSN的iSCSI R2T/data PDU或带有EXPDASN的SCSI响应PDU(表示缺少数据PDU)时,这意味着启动器必须在一个或多个早期R2T/data PDU上检测到标头或负载摘要错误。

The initiator MUST address these implied digest errors as described in Section 7.8. When a target receives a data PDU with an out-of-order DataSN, it means that the target must have hit a header or payload digest error on at least one of the earlier data PDUs. The target MUST address these implied digest errors as described in Section 7.8.

发起者必须按照第7.8节所述解决这些隐含的摘要错误。当一个目标接收到一个数据PDU,其中包含一个无序的DataSN时,这意味着该目标必须在至少一个较早的数据PDU上遇到报头或有效负载摘要错误。目标公司必须解决第7.8节所述的这些隐含摘要错误。

When an initiator receives an iSCSI status PDU with an out-of-order StatSN that implies missing responses, it MUST address the one or more missing status PDUs as described in Section 7.8. As a side effect of receiving the missing responses, the initiator may discover missing data PDUs. If the initiator wants to recover the missing data for a command, it MUST NOT acknowledge the received responses that start from the StatSN of the relevant command until it has completed receiving all the data PDUs of the command.

当启动器收到一个iSCSI状态PDU,其StatSN出现故障,这意味着缺少响应时,它必须按照第7.8节所述解决一个或多个缺少的状态PDU。作为接收丢失的响应的副作用,发起方可以发现丢失的数据pdu。如果启动器希望恢复某个命令的丢失数据,则在完成接收该命令的所有数据PDU之前,不得确认从相关命令的StatSN开始接收的响应。

When an initiator receives duplicate R2TSNs (due to proactive retransmission of R2Ts by the target) or duplicate DataSNs (due to proactive SNACKs by the initiator), it MUST discard the duplicates.

当发起方收到重复的R2TSN(由于目标方主动重新传输R2T)或重复的数据N(由于发起方主动发送零食)时,它必须丢弃重复的R2TSN。

7.10. Message Error Checking
7.10. 消息错误检查

In iSCSI implementations to date, there has been some uncertainty regarding the extent to which incoming messages have to be checked for protocol errors, beyond what is strictly required for processing the inbound message. This section addresses this question.

到目前为止,在iSCSI实施中,除了处理入站消息所严格要求的范围外,还存在一些不确定因素,即必须在多大程度上检查传入消息是否存在协议错误。本节讨论这个问题。

Unless this document requires it, an iSCSI implementation is not required to do an exhaustive protocol conformance check on an incoming iSCSI PDU. The iSCSI implementation in particular is not required to double-check the remote iSCSI implementation's conformance to protocol requirements.

除非本文档有所要求,否则不需要iSCSI实施来对传入的iSCSI PDU执行详尽的协议一致性检查。特别是iSCSI实施不需要仔细检查远程iSCSI实施是否符合协议要求。

7.11. SCSI Timeouts
7.11. SCSI超时

An iSCSI initiator MAY attempt to plug a command sequence gap on the target end (in the absence of an acknowledgment of the command by way of the ExpCmdSN) before the ULP timeout by retrying the unacknowledged command, as described in Section 7.2.

如第7.2节所述,iSCSI启动器可通过重试未确认的命令,在ULP超时之前尝试在目标端(在没有通过ExpCmdSN确认命令的情况下)插入命令序列间隙。

On a ULP timeout for a command (that carried a CmdSN of n), if the iSCSI initiator intends to continue the session it MUST abort the command by using either an appropriate Task Management Function Request for the specific command or a "close the connection" logout.

在命令(带有n的CmdSN)的ULP超时时,如果iSCSI启动器打算继续会话,则必须通过使用针对特定命令的适当任务管理功能请求或“关闭连接”注销来中止该命令。

When using an ABORT TASK, if the ExpCmdSN is still less than (n + 1), the target may see the abort request while missing the original command itself, due to one of the following reasons:

使用中止任务时,如果ExpCmdSN仍然小于(n+1),则由于以下原因之一,目标可能会在缺少原始命令本身的情况下看到中止请求:

- The original command was dropped due to digest error.

- 由于摘要错误,原始命令被删除。

- The connection on which the original command was sent was successfully logged out. On logout, the unacknowledged commands issued on the connection being logged out are discarded.

- 发送原始命令的连接已成功注销。注销时,在注销的连接上发出的未确认命令将被丢弃。

If the abort request is received and the original command is missing, targets MUST consider the original command with that RefCmdSN as received and issue a task management response with the response code "Function complete". This response concludes the task on both ends. If the abort request is received and the target can determine (based on the Referenced Task Tag) that the command was received and executed, and also that the response was sent prior to the abort, then the target MUST respond with the response code "Task Does Not Exist".

如果接收到中止请求且原始命令丢失,则目标必须考虑原始命令,RefCmdSN接收到该命令,并发出响应管理代码“函数完成”的任务管理响应。此响应结束了两端的任务。如果接收到中止请求,并且目标可以确定(基于引用的任务标记)已接收并执行命令,并且在中止之前已发送响应,则目标必须使用响应代码“任务不存在”进行响应。

7.12. Negotiation Failures
7.12. 谈判失败

Text Request and Response sequences, when used to set/negotiate operational parameters, constitute the negotiation/parameter setting. A negotiation failure is considered to be one or more of the following:

文本请求和响应序列用于设置/协商操作参数时,构成协商/参数设置。谈判失败被视为以下一项或多项:

- For a negotiated key, none of the choices are acceptable to one of the sides in the negotiation.

- 对于协商密钥,协商中的一方不接受任何选择。

- For a declarative key, the declared value is not acceptable to the other side in the negotiation.

- 对于声明性密钥,协商中的另一方不接受声明的值。

- The Text Request timed out and possibly terminated.

- 文本请求超时,可能已终止。

- The Text Request was answered with a Reject PDU.

- 文本请求得到了拒绝PDU的答复。

The following two rules should be used to address negotiation failures:

应使用以下两条规则来解决协商失败问题:

a) During login, any failure in negotiation MUST be considered a login process failure; the Login Phase, along with the connection, MUST be terminated. If the target detects the failure, it must terminate the login with the appropriate Login response code.

a) 在登录过程中,任何协商失败都必须视为登录过程失败;登录阶段以及连接必须终止。如果目标检测到故障,则必须使用相应的登录响应代码终止登录。

b) A failure in negotiation during the Full Feature Phase will terminate the entire negotiation sequence, which may consist of a series of Text Requests that use the same Initiator Task Tag. The operational parameters of the session or the connection MUST continue to be the values agreed upon during an earlier successful negotiation (i.e., any partial results of this unsuccessful negotiation MUST NOT take effect and MUST be discarded).

b) 在全功能阶段协商失败将终止整个协商序列,该序列可能由使用相同启动器任务标记的一系列文本请求组成。会话或连接的操作参数必须继续为先前成功协商期间商定的值(即,此不成功协商的任何部分结果不得生效,必须丢弃)。

7.13. Protocol Errors
7.13. 协议错误

Mapping framed messages over a "streaming" connection such as TCP makes the proposed mechanisms vulnerable to simple software framing errors. On the other hand, the introduction of framing mechanisms to limit the effects of these errors may be onerous on performance for simple implementations. Command sequence numbers and the mechanisms for dropping and reestablishing connections (discussed earlier in Section 7 and its subsections) help handle this type of mapping errors.

通过“流式”连接(如TCP)映射帧消息会使建议的机制容易受到简单软件帧错误的影响。另一方面,引入帧机制来限制这些错误的影响可能会对简单实现的性能造成很大的影响。命令序列号和删除和重新建立连接的机制(在第7节及其小节中讨论)有助于处理此类映射错误。

All violations of iSCSI PDU exchange sequences specified in this document are also protocol errors. This category of errors can only be addressed by fixing the implementations; iSCSI defines Reject and response codes to enable this.

本文档中指定的所有违反iSCSI PDU交换序列的行为也是协议错误。这类错误只能通过修复实现来解决;iSCSI定义拒绝和响应代码以启用此功能。

7.14. Connection Failures
7.14. 连接故障

iSCSI can keep a session in operation if it is able to keep/establish at least one TCP connection between the initiator and the target in a timely fashion. Targets and/or initiators may recognize a failing connection by either transport-level means (TCP), a gap in the command sequence number, a response stream that is not filled for a long time, or a failing iSCSI NOP (acting as a ping). The latter MAY be used periodically to increase the speed and likelihood of detecting connection failures. As an example for transport-level means, initiators and targets MAY also use the keep-alive option (see [RFC1122]) on the TCP connection to enable early link failure detection on otherwise idle links.

如果iSCSI能够在启动器和目标之间及时保持/建立至少一个TCP连接,则可以使会话保持运行。目标和/或启动器可以通过传输级别方式(TCP)、命令序列号中的间隙、长时间未填充的响应流或失败的iSCSI NOP(充当ping)来识别失败的连接。后者可定期用于提高检测连接故障的速度和可能性。作为传输级手段的示例,启动器和目标还可以在TCP连接上使用保持活动选项(请参见[RFC1122]),以便在其他空闲链路上启用早期链路故障检测。

On connection failure, the initiator and target MUST do one of the following:

连接失败时,启动器和目标必须执行以下操作之一:

a) Attempt connection recovery within the session (Connection Recovery).

a) 尝试在会话中恢复连接(连接恢复)。

b) Log out the connection with the reason code "close the connection" (Section 11.14.5), reissue missing commands, and implicitly terminate all active commands. This option requires support for the Within-connection recovery class (recovery within-connection).

b) 注销连接,原因码为“关闭连接”(第11.14.5节),重新发出缺失的命令,并隐式终止所有激活的命令。此选项要求支持连接内恢复类(连接内恢复)。

c) Perform session recovery (Session Recovery).

c) 执行会话恢复(会话恢复)。

Either side may choose to escalate to session recovery (via the initiator dropping all the connections or via an Async Message that announces the similar intent from a target), and the other side MUST give it precedence. On a connection failure, a target MUST terminate and/or discard all of the active immediate commands, regardless of which of the above options is used (i.e., immediate commands are not recoverable across connection failures).

任何一方都可以选择升级到会话恢复(通过发起方放弃所有连接或通过异步消息从目标方宣布类似意图),另一方必须给予它优先权。在连接失败时,目标必须终止和/或放弃所有活动的立即命令,而不管使用了上述哪个选项(即,立即命令在连接失败时不可恢复)。

7.15. Session Errors
7.15. 会话错误

If all of the connections of a session fail and cannot be reestablished in a short time, or if initiators detect protocol errors repeatedly, an initiator may choose to terminate a session and establish a new session.

如果会话的所有连接都失败并且无法在短时间内重新建立,或者如果启动器重复检测到协议错误,则启动器可以选择终止会话并建立新会话。

In this case, the initiator takes the following actions:

在这种情况下,启动器将执行以下操作:

- Resets or closes all the transport connections.

- 重置或关闭所有传输连接。

- Terminates all outstanding requests with an appropriate response before initiating a new session. If the same I_T nexus is intended to be reestablished, the initiator MUST employ session reinstatement (see Section 6.3.5).

- 在启动新会话之前,使用适当的响应终止所有未完成的请求。如果打算重新建立相同的I_T nexus,则发起方必须采用会话恢复(见第6.3.5节)。

When the session timeout (the connection state timeout for the last failed connection) happens on the target, it takes the following actions:

当目标上发生会话超时(上次失败连接的连接状态超时)时,它将执行以下操作:

- Resets or closes the TCP connections (closes the session).

- 重置或关闭TCP连接(关闭会话)。

- Terminates all active tasks that were allegiant to the connection(s) that constituted the session.

- 终止与构成会话的连接相关的所有活动任务。

A target MUST also be prepared to handle a session reinstatement request from the initiator that may be addressing session errors.

目标还必须准备好处理发起者可能正在处理会话错误的会话恢复请求。

8. State Transitions
8. 状态迁移

iSCSI connections and iSCSI sessions go through several well-defined states from the time they are created to the time they are cleared.

iSCSI连接和iSCSI会话从创建到清除都经历了几个定义良好的状态。

The connection state transitions are described in two separate but dependent sets of state diagrams for ease in understanding. The first set of diagrams, "standard connection state diagrams", describes the connection state transitions when the iSCSI connection is not waiting for, or undergoing, a cleanup by way of an explicit or implicit logout. The second set, "connection cleanup state diagram", describes the connection state transitions while performing the iSCSI connection cleanup. While the first set has two diagrams -- one each for initiator and target -- the second set has a single diagram applicable to both initiators and targets.

为了便于理解,连接状态转换在两组独立但相互依赖的状态图中描述。第一组图“标准连接状态图”描述了iSCSI连接未等待或正在通过显式或隐式注销进行清理时的连接状态转换。第二组“连接清理状态图”描述了执行iSCSI连接清理时的连接状态转换。虽然第一组有两个关系图——启动器和目标各一个——但第二组有一个关系图,适用于启动器和目标。

The "session state diagram" describes the state transitions an iSCSI session would go through during its lifetime, and it depends on the states of possibly multiple iSCSI connections that participate in the session.

“会话状态图”描述了iSCSI会话在其生存期内将经历的状态转换,它取决于参与会话的可能多个iSCSI连接的状态。

States and transitions are described in text, tables, and diagrams. The diagrams are used for illustration. The text and the tables are the governing specification.

状态和转换在文本、表格和图表中描述。这些图表用于说明。正文和表格为适用规范。

8.1. Standard Connection State Diagrams
8.1. 标准连接状态图
8.1.1. State Descriptions for Initiators and Targets
8.1.1. 启动器和目标的状态描述

State descriptions for the standard connection state diagram are as follows:

标准连接状态图的状态描述如下:

S1: FREE

S1:免费

- initiator: State on instantiation, or after successful connection closure.

- 启动器:实例化时或成功关闭连接后的状态。

- target: State on instantiation, or after successful connection closure.

- 目标:实例化时或成功关闭连接后的状态。

S2: XPT_WAIT

S2:XPT_等待

- initiator: Waiting for a response to its transport connection establishment request.

- 启动器:正在等待对其传输连接建立请求的响应。

- target: Illegal.

- 目标:非法。

S3: XPT_UP

S3:XPT\u UP

- initiator: Illegal.

- 发起者:非法。

- target: Waiting for the login process to commence.

- 目标:等待登录过程开始。

S4: IN_LOGIN

S4:IN_登录

- initiator: Waiting for the login process to conclude, possibly involving several PDU exchanges.

- 发起人:等待登录过程结束,可能涉及多个PDU交换。

- target: Waiting for the login process to conclude, possibly involving several PDU exchanges.

- 目标:等待登录过程结束,可能涉及多个PDU交换。

S5: LOGGED_IN

S5:已登录

- initiator: In the Full Feature Phase, waiting for all internal, iSCSI, and transport events.

- 启动器:在完整功能阶段,等待所有内部、iSCSI和传输事件。

- target: In the Full Feature Phase, waiting for all internal, iSCSI, and transport events.

- 目标:在完整功能阶段,等待所有内部、iSCSI和传输事件。

S6: IN_LOGOUT

中六:登出

- initiator: Waiting for a Logout Response.

- 启动器:正在等待注销响应。

- target: Waiting for an internal event signaling completion of logout processing.

- 目标:等待内部事件信号完成注销处理。

S7: LOGOUT_REQUESTED

S7:要求注销

- initiator: Waiting for an internal event signaling readiness to proceed with Logout.

- 启动器:等待内部事件信号准备就绪以继续注销。

- target: Waiting for the Logout process to start after having requested a Logout via an Async Message.

- 目标:通过异步消息请求注销后,等待注销进程启动。

S8: CLEANUP_WAIT

S8:请稍候

- initiator: Waiting for the context and/or resources to initiate the cleanup processing for this CSM.

- 启动器:等待上下文和/或资源为此CSM启动清理处理。

- target: Waiting for the cleanup process to start for this CSM.

- 目标:等待此CSM的清理进程启动。

8.1.2. State Transition Descriptions for Initiators and Targets
8.1.2. 启动器和目标的状态转换说明

T1:

T1:

- initiator: Transport connect request was made (e.g., TCP SYN sent).

- 发起人:已发出传输连接请求(例如,已发送TCP SYN)。

- target: Illegal.

- 目标:非法。

T2:

T2:

- initiator: Transport connection request timed out, a transport reset was received, or an internal event of receiving a Logout Response (success) on another connection for a "close the session" Logout Request was received.

- 启动器:传输连接请求超时,接收到传输重置,或者接收到在另一个连接上接收“关闭会话”注销请求的注销响应(成功)的内部事件。

- target: Illegal.

- 目标:非法。

T3:

T3:

- initiator: Illegal.

- 发起者:非法。

- target: Received a valid transport connection request that establishes the transport connection.

- 目标:收到建立传输连接的有效传输连接请求。

T4:

T4:

- initiator: Transport connection established, thus prompting the initiator to start the iSCSI Login.

- 启动器:已建立传输连接,从而提示启动器启动iSCSI登录。

- target: Initial iSCSI Login Request was received.

- 目标:收到初始iSCSI登录请求。

T5:

T5:

- initiator: The final iSCSI Login Response with a Status-Class of zero was received.

- 启动器:收到状态类为零的最终iSCSI登录响应。

- target: The final iSCSI Login Request to conclude the Login Phase was received, thus prompting the target to send the final iSCSI Login Response with a Status-Class of zero.

- 目标:接收到结束登录阶段的最终iSCSI登录请求,从而提示目标发送状态类为零的最终iSCSI登录响应。

T6:

T6:

- initiator: Illegal.

- 发起者:非法。

- target: Timed out waiting for an iSCSI Login, transport disconnect indication was received, transport reset was received, or an internal event indicating a transport timeout was received. In all these cases, the connection is to be closed.

- 目标:等待iSCSI登录超时,收到传输断开连接指示,收到传输重置,或收到指示传输超时的内部事件。在所有这些情况下,都要关闭连接。

T7:

T7:

- initiator: One of the following events caused the transition:

- 启动器:以下事件之一导致转换:

a) The final iSCSI Login Response was received with a non-zero Status-Class.

a) 最终iSCSI登录响应是通过非零状态类接收的。

b) Login timed out.

b) 登录超时。

c) A transport disconnect indication was received.

c) 接收到传输断开指示。

d) A transport reset was received.

d) 接收到传输重置。

e) An internal event indicating a transport timeout was received.

e) 接收到指示传输超时的内部事件。

f) An internal event of receiving a Logout Response (success) on another connection for a "close the session" Logout Request was received.

f) 收到“关闭会话”注销请求的另一个连接上收到注销响应(成功)的内部事件。

In all these cases, the transport connection is closed.

在所有这些情况下,传输连接都是关闭的。

- target: One of the following events caused the transition:

- 目标:以下事件之一导致转换:

a) The final iSCSI Login Request to conclude the Login Phase was received, prompting the target to send the final iSCSI Login Response with a non-zero Status-Class.

a) 接收到结束登录阶段的最终iSCSI登录请求,提示目标发送具有非零状态类的最终iSCSI登录响应。

b) Login timed out.

b) 登录超时。

c) A transport disconnect indication was received.

c) 接收到传输断开指示。

d) A transport reset was received.

d) 接收到传输重置。

e) An internal event indicating a transport timeout was received.

e) 接收到指示传输超时的内部事件。

f) On another connection, a "close the session" Logout Request was received.

f) 在另一个连接上,收到“关闭会话”注销请求。

In all these cases, the connection is to be closed.

在所有这些情况下,都要关闭连接。

T8:

T8:

- initiator: An internal event of receiving a Logout Response (success) on another connection for a "close the session" Logout Request was received, thus closing this connection and requiring no further cleanup.

- 启动器:收到另一个连接上收到“关闭会话”注销请求的注销响应(成功)的内部事件,因此关闭此连接,无需进一步清理。

- target: An internal event of sending a Logout Response (success) on another connection for a "close the session" Logout Request was received, or an internal event of a successful connection/session reinstatement was received, thus prompting the target to close this connection cleanly.

- 目标:收到针对“关闭会话”注销请求在另一个连接上发送注销响应(成功)的内部事件,或收到成功连接/会话恢复的内部事件,从而提示目标完全关闭此连接。

T9, T10:

T9,T10:

- initiator: An internal event that indicates the readiness to start the Logout process was received, thus prompting an iSCSI Logout to be sent by the initiator.

- 启动器:收到一个内部事件,指示已准备好启动注销过程,从而提示启动器发送iSCSI注销。

- target: An iSCSI Logout Request was received.

- 目标:收到iSCSI注销请求。

T11, T12:

T11、T12:

- initiator: An Async PDU with AsyncEvent "Request Logout" was received.

- 启动器:接收到带有AsyncEvent“请求注销”的异步PDU。

- target: An internal event that requires the decommissioning of the connection was received, thus causing an Async PDU with an AsyncEvent "Request Logout" to be sent.

- 目标:接收到要求断开连接的内部事件,从而导致发送带有AsyncEvent“Request Logout”的异步PDU。

T13:

T13:

- initiator: An iSCSI Logout Response (success) was received, or an internal event of receiving a Logout Response (success) on another connection for a "close the session" Logout Request was received.

- 启动器:接收到iSCSI注销响应(成功),或接收到在另一个连接上接收“关闭会话”注销请求的注销响应(成功)的内部事件。

- target: An internal event was received that indicates successful processing of the Logout, which prompts an iSCSI Logout Response (success) to be sent; an internal event of sending a Logout Response (success) on another connection for a "close the session" Logout Request was received; or

- 目标:收到一个内部事件,指示成功处理注销,提示发送iSCSI注销响应(成功);收到在另一个连接上发送“关闭会话”注销请求的注销响应(成功)的内部事件;或

an internal event of a successful connection/session reinstatement was received. In all these cases, the transport connection is closed.

收到成功恢复连接/会话的内部事件。在所有这些情况下,传输连接都是关闭的。

T14:

T14:

- initiator: An Async PDU with AsyncEvent "Request Logout" was received again.

- 启动器:再次收到带有AsyncEvent“请求注销”的异步PDU。

- target: Illegal.

- 目标:非法。

T15, T16:

T15、T16:

- initiator: One or more of the following events caused this transition:

- 启动器:以下一个或多个事件导致了此转换:

a) An internal event that indicates a transport connection timeout was received, thus prompting a transport reset or transport connection closure.

a) 指示接收到传输连接超时的内部事件,从而提示传输重置或传输连接关闭。

b) A transport reset was received.

b) 接收到传输重置。

c) A transport disconnect indication was received.

c) 接收到传输断开指示。

d) An Async PDU with AsyncEvent "Drop connection" (for this CID) was received.

d) 接收到带有AsyncEvent“Drop connection”(用于此CID)的异步PDU。

e) An Async PDU with AsyncEvent "Drop all connections" was received.

e) 接收到带有AsyncEvent“删除所有连接”的异步PDU。

- target: One or more of the following events caused this transition:

- 目标:以下一个或多个事件导致了此转换:

a) Internal event that indicates that a transport connection timeout was received, thus prompting a transport reset or transport connection closure.

a) 指示接收到传输连接超时的内部事件,从而提示传输重置或传输连接关闭。

b) An internal event of a failed connection/session reinstatement was received.

b) 接收到连接/会话恢复失败的内部事件。

c) A transport reset was received.

c) 接收到传输重置。

d) A transport disconnect indication was received.

d) 接收到传输断开指示。

e) An internal emergency cleanup event was received, which prompts an Async PDU with AsyncEvent "Drop connection" (for this CID), or event "Drop all connections".

e) 接收到内部紧急清理事件,该事件提示异步PDU使用AsyncEvent“Drop connection”(对于此CID)或事件“Drop all connections”。

T17:

T17:

- initiator: One or more of the following events caused this transition:

- 启动器:以下一个或多个事件导致了此转换:

a) A Logout Response (failure, i.e., a non-zero status) was received, or Logout timed out.

a) 收到注销响应(失败,即非零状态),或注销超时。

b) Any of the events specified for T15 and T16 occurred.

b) 发生为T15和T16指定的任何事件。

- target: One or more of the following events caused this transition:

- 目标:以下一个或多个事件导致了此转换:

a) An internal event that indicates a failure of the Logout processing was received, which prompts a Logout Response (failure, i.e., a non-zero status) to be sent.

a) 接收到指示注销处理失败的内部事件,提示发送注销响应(失败,即非零状态)。

b) Any of the events specified for T15 and T16 occurred.

b) 发生为T15和T16指定的任何事件。

T18:

T18:

- initiator: An internal event of receiving a Logout Response (success) on another connection for a "close the session" Logout Request was received.

- 启动器:收到另一个连接的“关闭会话”注销请求的注销响应(成功)的内部事件。

- target: An internal event of sending a Logout Response (success) on another connection for a "close the session" Logout Request was received, or an internal event of a successful connection/session reinstatement was received. In both these cases, the connection is closed.

- 目标:收到针对“关闭会话”注销请求在另一个连接上发送注销响应(成功)的内部事件,或者收到成功连接/会话恢复的内部事件。在这两种情况下,连接都是关闭的。

The CLEANUP_WAIT state (S8) implies that there are possible iSCSI tasks that have not reached conclusion and are still considered busy.

CLEANUP_WAIT状态(S8)表示可能存在尚未结束且仍被视为繁忙的iSCSI任务。

8.1.3. Standard Connection State Diagram for an Initiator
8.1.3. 启动器的标准连接状态图

Symbolic names for states:

国家的符号名称:

S1: FREE

S1:免费

S2: XPT_WAIT

S2:XPT_等待

S4: IN_LOGIN

S4:IN_登录

S5: LOGGED_IN

S5:已登录

S6: IN_LOGOUT

中六:登出

S7: LOGOUT_REQUESTED

S7:要求注销

S8: CLEANUP_WAIT

S8:请稍候

States S5, S6, and S7 constitute the Full Feature Phase operation of the connection.

状态S5、S6和S7构成连接的全功能阶段操作。

The state diagram is as follows:

状态图如下所示:

                        -------<-------------+
            +--------->/ S1    \<----+       |
         T13|       +->\       /<-+   \      |
            |      /    ---+---    \   \     |
            |     /        |     T2 \   |    |
            |  T8 |        |T1       |  |    |
            |     |        |        /   |T7  |
            |     |        |       /    |    |
            |     |        |      /     |    |
            |     |        V     /     /     |
            |     |     ------- /     /      |
            |     |    / S2    \     /       |
            |     |    \       /    /        |
            |     |     ---+---    /         |
            |     |        |T4    /          |
            |     |        V     /           | T18
            |     |     ------- /            |
            |     |    / S4    \             |
            |     |    \       /             |
            |     |     ---+---              |         T15
            |     |        |T5      +--------+---------+
            |     |        |       /T16+-----+------+  |
            |     |        |      /   -+-----+--+   |  |
            |     |        |     /   /  S7   \  |T12|  |
            |     |        |    / +->\       /<-+   V  V
            |     |        |   / /    -+-----       -------
            |     |        |  / /T11   |T10        /  S8   \
            |     |        V / /       V  +----+   \       /
            |     |      ---+-+-      ----+--  |    -------
            |     |     / S5    \T9  / S6    \<+      ^
            |     +-----\       /--->\       / T14    |
            |            -------      --+---+---------+T17
            +---------------------------+
        
                        -------<-------------+
            +--------->/ S1    \<----+       |
         T13|       +->\       /<-+   \      |
            |      /    ---+---    \   \     |
            |     /        |     T2 \   |    |
            |  T8 |        |T1       |  |    |
            |     |        |        /   |T7  |
            |     |        |       /    |    |
            |     |        |      /     |    |
            |     |        V     /     /     |
            |     |     ------- /     /      |
            |     |    / S2    \     /       |
            |     |    \       /    /        |
            |     |     ---+---    /         |
            |     |        |T4    /          |
            |     |        V     /           | T18
            |     |     ------- /            |
            |     |    / S4    \             |
            |     |    \       /             |
            |     |     ---+---              |         T15
            |     |        |T5      +--------+---------+
            |     |        |       /T16+-----+------+  |
            |     |        |      /   -+-----+--+   |  |
            |     |        |     /   /  S7   \  |T12|  |
            |     |        |    / +->\       /<-+   V  V
            |     |        |   / /    -+-----       -------
            |     |        |  / /T11   |T10        /  S8   \
            |     |        V / /       V  +----+   \       /
            |     |      ---+-+-      ----+--  |    -------
            |     |     / S5    \T9  / S6    \<+      ^
            |     +-----\       /--->\       / T14    |
            |            -------      --+---+---------+T17
            +---------------------------+
        

The following state transition table represents the above diagram. Each row represents the starting state for a given transition, which, after taking a transition marked in a table cell, would end in the state represented by the column of the cell. For example, from state S1, the connection takes the T1 transition to arrive at state S2. The fields marked "-" correspond to undefined transitions.

下面的状态转换表表示上图。每一行表示给定转换的开始状态,在表单元格中标记转换后,该转换将以单元格列表示的状态结束。例如,从状态S1开始,连接通过T1转换到达状态S2。标有“-”的字段对应于未定义的转换。

      +----+---+---+---+---+----+---+
      |S1  |S2 |S4 |S5 |S6 |S7  |S8 |
   ---+----+---+---+---+---+----+---+
    S1| -  |T1 | - | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S2|T2  |-  |T4 | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S4|T7  |-  |-  |T5 | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S5|T8  |-  |-  | - |T9 |T11 |T15|
   ---+----+---+---+---+---+----+---+
    S6|T13 |-  |-  | - |T14|-   |T17|
   ---+----+---+---+---+---+----+---+
    S7|T18 |-  |-  | - |T10|T12 |T16|
   ---+----+---+---+---+---+----+---+
    S8| -  |-  |-  | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
        
      +----+---+---+---+---+----+---+
      |S1  |S2 |S4 |S5 |S6 |S7  |S8 |
   ---+----+---+---+---+---+----+---+
    S1| -  |T1 | - | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S2|T2  |-  |T4 | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S4|T7  |-  |-  |T5 | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S5|T8  |-  |-  | - |T9 |T11 |T15|
   ---+----+---+---+---+---+----+---+
    S6|T13 |-  |-  | - |T14|-   |T17|
   ---+----+---+---+---+---+----+---+
    S7|T18 |-  |-  | - |T10|T12 |T16|
   ---+----+---+---+---+---+----+---+
    S8| -  |-  |-  | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
        
8.1.4. Standard Connection State Diagram for a Target
8.1.4. 目标的标准连接状态图

Symbolic names for states:

国家的符号名称:

S1: FREE

S1:免费

S3: XPT_UP

S3:XPT\u UP

S4: IN_LOGIN

S4:IN_登录

S5: LOGGED_IN

S5:已登录

S6: IN_LOGOUT

中六:登出

S7: LOGOUT_REQUESTED

S7:要求注销

S8: CLEANUP_WAIT

S8:请稍候

States S5, S6, and S7 constitute the Full Feature Phase operation of the connection.

状态S5、S6和S7构成连接的全功能阶段操作。

The state diagram is as follows:

状态图如下所示:

                           -------<-------------+
               +--------->/ S1    \<----+       |
            T13|       +->\       /<-+   \      |
               |      /    ---+---    \   \     |
               |     /        |     T6 \   |    |
               |  T8 |        |T3       |  |    |
               |     |        |        /   |T7  |
               |     |        |       /    |    |
               |     |        |      /     |    |
               |     |        V     /     /     |
               |     |     ------- /     /      |
               |     |    / S3    \     /       |
               |     |    \       /    /        | T18
               |     |     ---+---    /         |
               |     |        |T4    /          |
               |     |        V     /           |
               |     |     ------- /            |
               |     |    / S4    \             |
               |     |    \       /             |
               |     |     ---+---         T15  |
               |     |        |T5      +--------+---------+
               |     |        |       /T16+-----+------+  |
               |     |        |      /  -+-----+---+   |  |
               |     |        |     /   /  S7   \  |T12|  |
               |     |        |    / +->\       /<-+   V  V
               |     |        |   / /    -+-----       -------
               |     |        |  / /T11   |T10        /  S8   \
               |     |        V / /       V           \       /
               |     |      ---+-+-      -------       -------
               |     |     / S5    \T9  / S6    \        ^
               |     +-----\       /--->\       /        |
               |            -------      --+---+---------+T17
               +---------------------------+
        
                           -------<-------------+
               +--------->/ S1    \<----+       |
            T13|       +->\       /<-+   \      |
               |      /    ---+---    \   \     |
               |     /        |     T6 \   |    |
               |  T8 |        |T3       |  |    |
               |     |        |        /   |T7  |
               |     |        |       /    |    |
               |     |        |      /     |    |
               |     |        V     /     /     |
               |     |     ------- /     /      |
               |     |    / S3    \     /       |
               |     |    \       /    /        | T18
               |     |     ---+---    /         |
               |     |        |T4    /          |
               |     |        V     /           |
               |     |     ------- /            |
               |     |    / S4    \             |
               |     |    \       /             |
               |     |     ---+---         T15  |
               |     |        |T5      +--------+---------+
               |     |        |       /T16+-----+------+  |
               |     |        |      /  -+-----+---+   |  |
               |     |        |     /   /  S7   \  |T12|  |
               |     |        |    / +->\       /<-+   V  V
               |     |        |   / /    -+-----       -------
               |     |        |  / /T11   |T10        /  S8   \
               |     |        V / /       V           \       /
               |     |      ---+-+-      -------       -------
               |     |     / S5    \T9  / S6    \        ^
               |     +-----\       /--->\       /        |
               |            -------      --+---+---------+T17
               +---------------------------+
        

The following state transition table represents the above diagram and follows the conventions described for the initiator diagram.

以下状态转换表表示上述关系图,并遵循启动器关系图中描述的约定。

      +----+---+---+---+---+----+---+
      |S1  |S3 |S4 |S5 |S6 |S7  |S8 |
   ---+----+---+---+---+---+----+---+
    S1| -  |T3 | - | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S3|T6  |-  |T4 | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S4|T7  |-  |-  |T5 | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S5|T8  |-  |-  | - |T9 |T11 |T15|
   ---+----+---+---+---+---+----+---+
    S6|T13 |-  |-  | - |-  |-   |T17|
   ---+----+---+---+---+---+----+---+
    S7|T18 |-  |-  | - |T10|T12 |T16|
   ---+----+---+---+---+---+----+---+
    S8| -  |-  |-  | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
        
      +----+---+---+---+---+----+---+
      |S1  |S3 |S4 |S5 |S6 |S7  |S8 |
   ---+----+---+---+---+---+----+---+
    S1| -  |T3 | - | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S3|T6  |-  |T4 | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S4|T7  |-  |-  |T5 | - | -  | - |
   ---+----+---+---+---+---+----+---+
    S5|T8  |-  |-  | - |T9 |T11 |T15|
   ---+----+---+---+---+---+----+---+
    S6|T13 |-  |-  | - |-  |-   |T17|
   ---+----+---+---+---+---+----+---+
    S7|T18 |-  |-  | - |T10|T12 |T16|
   ---+----+---+---+---+---+----+---+
    S8| -  |-  |-  | - | - | -  | - |
   ---+----+---+---+---+---+----+---+
        
8.2. Connection Cleanup State Diagram for Initiators and Targets
8.2. 启动器和目标的连接清理状态图

Symbolic names for states:

国家的符号名称:

R1: CLEANUP_WAIT (same as S8)

R1:清理_等待(与S8相同)

R2: IN_CLEANUP

R2:IN_清理

R3: FREE (same as S1)

R3:自由(与S1相同)

Whenever a connection state machine in cleanup (let's call it CSM-C) enters the CLEANUP_WAIT state (S8), it must go through the state transitions described in the connection cleanup state diagram, using either a) a separate Full Feature Phase connection (let's call it CSM-E, for explicit) in the LOGGED_IN state in the same session or b) a new transport connection (let's call it CSM-I, for implicit) in the FREE state that is to be added to the same session. In the CSM-E case, an explicit logout for the CID that corresponds to CSM-C (as either a connection or session logout) needs to be performed to complete the cleanup. In the CSM-I case, an implicit logout for the CID that corresponds to CSM-C needs to be performed by way of connection reinstatement (Section 6.3.4) for that CID. In either case, the protocol exchanges on CSM-E or CSM-I determine the state transitions for CSM-C. Therefore, this cleanup state diagram is only applicable to the instance of the connection in cleanup (i.e., CSM-C). In the case of an implicit logout, for example, CSM-C

每当处于清理状态的连接状态机(我们称之为CSM-C)进入清理等待状态(S8),它必须通过连接清理状态图中描述的状态转换,使用a)或单独的全功能阶段连接(我们称之为CSM-E,用于显式)在同一会话的LOGGED_in状态或b)中,将要添加到同一会话的空闲状态的新传输连接(我们称之为CSM-I,隐式)。在CSM-E情况下,需要执行对应于CSM-C的CID的显式注销(作为连接或会话注销)以完成清理。在CSM-I情况下,需要通过恢复该CID的连接(第6.3.4节),对对应于CSM-C的CID执行隐式注销。在这两种情况下,CSM-E或CSM-I上的协议交换决定CSM-C的状态转换。因此,此清理状态图仅适用于清理中的连接实例(即CSM-C)。例如,在隐式注销的情况下,CSM-C

reaches FREE (R3) at the time CSM-I reaches LOGGED_IN. In the case of an explicit logout, CSM-C reaches FREE (R3) when CSM-E receives a successful Logout Response while continuing to be in the LOGGED_IN state.

在CSM-I到达登录时到达空闲(R3)。在显式注销的情况下,当CSM-E收到成功的注销响应并继续处于登录状态时,CSM-C达到自由(R3)。

An initiator must initiate an explicit or implicit connection logout for a connection in the CLEANUP_WAIT state, if the initiator intends to continue using the associated iSCSI session.

如果启动器打算继续使用关联的iSCSI会话,则启动器必须为处于清除等待状态的连接启动显式或隐式连接注销。

The following state diagram applies to both initiators and targets. (M1, M2, M3, and M4 are defined in Section 8.2.2.)

以下状态图适用于启动器和目标。(M1、M2、M3和M4的定义见第8.2.2节。)

                           ---------
                          / R1      \
                      +---\         /<-+
                     /     ----+----    \
                    /          |         \ M3
                 M1 |          |M2        |
                    |          |         /
                    |          |        /
                    |          |       /
                    |          V      /
                    |       ---------/
                    |      / R2      \
                    |      \         /
                    |       ---------
                    |          |
                    |          |M4
                    |          |
                    |          |
                    |          |
                    |          V
                    |       --------
                    |      / R3     \
                    +----->\        /
                            --------
        
                           ---------
                          / R1      \
                      +---\         /<-+
                     /     ----+----    \
                    /          |         \ M3
                 M1 |          |M2        |
                    |          |         /
                    |          |        /
                    |          |       /
                    |          V      /
                    |       ---------/
                    |      / R2      \
                    |      \         /
                    |       ---------
                    |          |
                    |          |M4
                    |          |
                    |          |
                    |          |
                    |          V
                    |       --------
                    |      / R3     \
                    +----->\        /
                            --------
        

The following state transition table represents the above diagram and follows the same conventions as in earlier sections.

以下状态转换表表示上图,并遵循与前面章节相同的约定。

        +----+----+----+
        |R1  |R2  |R3  |
   -----+----+----+----+
    R1  | -  |M2  |M1  |
   -----+----+----+----+
    R2  |M3  | -  |M4  |
   -----+----+----+----+
    R3  | -  | -  | -  |
   -----+----+----+----+
        
        +----+----+----+
        |R1  |R2  |R3  |
   -----+----+----+----+
    R1  | -  |M2  |M1  |
   -----+----+----+----+
    R2  |M3  | -  |M4  |
   -----+----+----+----+
    R3  | -  | -  | -  |
   -----+----+----+----+
        
8.2.1. State Descriptions for Initiators and Targets
8.2.1. 启动器和目标的状态描述

R1: CLEANUP_WAIT (same as S8)

R1:清理_等待(与S8相同)

- initiator: Waiting for the internal event to initiate the cleanup processing for CSM-C.

- 启动器:等待内部事件启动CSM-C的清理处理。

- target: Waiting for the cleanup process to start for CSM-C.

- 目标:等待CSM-C的清理过程启动。

R2: IN_CLEANUP

R2:IN_清理

- initiator: Waiting for the connection cleanup process to conclude for CSM-C.

- 启动器:正在等待CSM-C的连接清理过程结束。

- target: Waiting for the connection cleanup process to conclude for CSM-C.

- 目标:等待CSM-C的连接清理过程结束。

R3: FREE (same as S1)

R3:自由(与S1相同)

- initiator: End state for CSM-C.

- 启动器:CSM-C的结束状态。

- target: End state for CSM-C.

- 目标:CSM-C的结束状态。

8.2.2. State Transition Descriptions for Initiators and Targets
8.2.2. 启动器和目标的状态转换说明

M1: One or more of the following events was received:

M1:收到以下一个或多个事件:

- initiator:

- 发起人:

* An internal event that indicates connection state timeout.

* 指示连接状态超时的内部事件。

* An internal event of receiving a successful Logout Response on a different connection for a "close the session" Logout.

* 在“关闭会话”注销的不同连接上接收成功注销响应的内部事件。

- target:

- 目标:

* An internal event that indicates connection state timeout.

* 指示连接状态超时的内部事件。

* An internal event of sending a Logout Response (success) on a different connection for a "close the session" Logout Request.

* 针对“关闭会话”注销请求在不同连接上发送注销响应(成功)的内部事件。

M2: An implicit/explicit logout process was initiated by the initiator.

M2:启动器启动了隐式/显式注销过程。

- In CSM-I usage:

- 在CSM-I使用中:

* initiator: An internal event requesting the connection (or session) reinstatement was received, thus prompting a connection (or session) reinstatement Login to be sent, transitioning CSM-I to state IN_LOGIN.

* 启动器:接收到请求恢复连接(或会话)的内部事件,从而提示发送连接(或会话)恢复登录,并将CSM-I转换为登录状态。

* target: A connection/session reinstatement Login was received while in state XPT_UP.

* 目标:在处于XPT_UP状态时收到连接/会话恢复登录。

- In CSM-E usage:

- 在CSM-E使用中:

* initiator: An internal event was received that indicates that an explicit logout was sent for this CID in state LOGGED_IN.

* 启动器:接收到一个内部事件,该事件指示此处于已登录状态的CID已发送显式注销。

* target: An explicit logout was received for this CID in state LOGGED_IN.

* 目标:收到此处于已登录状态的CID的显式注销。

M3: Logout failure was detected.

M3:检测到注销失败。

- In CSM-I usage:

- 在CSM-I使用中:

* initiator: CSM-I failed to reach LOGGED_IN and arrived into FREE instead.

* 发起者:CSM-I未能到达登录的\u,而是到达免费。

* target: CSM-I failed to reach LOGGED_IN and arrived into FREE instead.

* 目标:CSM-I未能到达登录的_,而是到达免费。

- In CSM-E usage:

- 在CSM-E使用中:

* initiator: either CSM-E moved out of LOGGED_IN, or Logout timed out and/or aborted, or Logout Response (failure) was received.

* 启动器:CSM-E移出已登录的\u,或注销超时和/或中止,或收到注销响应(失败)。

* target: either CSM-E moved out of LOGGED_IN, Logout timed out and/or aborted, or an internal event that indicates that a failed Logout processing was received. A Logout Response (failure) was sent in the last case.

* 目标:CSM-E移出已登录、注销超时和/或中止,或者是指示接收到注销处理失败的内部事件。在最后一个案例中发送了注销响应(失败)。

M4: Successful implicit/explicit logout was performed.

M4:执行了成功的隐式/显式注销。

- In CSM-I usage:

- 在CSM-I使用中:

* initiator: CSM-I reached state LOGGED_IN, or an internal event of receiving a Logout Response (success) on another connection for a "close the session" Logout Request was received.

* 启动器:CSM-I已达到已登录状态,或收到另一个连接上收到“关闭会话”注销请求的注销响应(成功)的内部事件。

* target: CSM-I reached state LOGGED_IN, or an internal event of sending a Logout Response (success) on a different connection for a "close the session" Logout Request was received.

* 目标:CSM-I已达到已登录状态,或接收到“关闭会话”注销请求在不同连接上发送注销响应(成功)的内部事件。

- In CSM-E usage:

- 在CSM-E使用中:

* initiator: CSM-E stayed in LOGGED_IN and received a Logout Response (success), or an internal event of receiving a Logout Response (success) on another connection for a "close the session" Logout Request was received.

* 启动器:CSM-E保持登录状态并收到注销响应(成功),或者收到另一个连接上收到“关闭会话”注销请求的注销响应(成功)的内部事件。

* target: CSM-E stayed in LOGGED_IN and an internal event indicating a successful Logout processing was received, or an internal event of sending a Logout Response (success) on a different connection for a "close the session" Logout Request was received.

* 目标:CSM-E保持登录状态,并收到指示成功注销处理的内部事件,或收到针对“关闭会话”注销请求在不同连接上发送注销响应(成功)的内部事件。

8.3. Session State Diagrams
8.3. 会话状态图
8.3.1. Session State Diagram for an Initiator
8.3.1. 启动器的会话状态图

Symbolic names for states:

国家的符号名称:

Q1: FREE

问题1:免费

Q3: LOGGED_IN

问题3:已登录

Q4: FAILED

问题4:失败

State Q3 represents the Full Feature Phase operation of the session.

状态Q3表示会话的完整功能阶段操作。

The state diagram is as follows. (N1, N3, N4, N5, and N6 are defined in Section 8.3.4.)

状态图如下所示。(第8.3.4节对N1、N3、N4、N5和N6进行了定义。)

                                   ---------
                                  / Q1      \
                      +---------->\         /<-+
                     /             ----+----   |
                    /                  |       |N3
                N6  |                  |N1     |
                    |                  |       |
                    |       N4         |       |
                    | +------------+   |      /
                    | |            |   |     /
                    | |            |   |    /
                    | |            V   V   /
                  --+-+---         -------+-
                 / Q4     \ N5    / Q3      \
                 \        /<------\         /
                  --------         ---------
        
                                   ---------
                                  / Q1      \
                      +---------->\         /<-+
                     /             ----+----   |
                    /                  |       |N3
                N6  |                  |N1     |
                    |                  |       |
                    |       N4         |       |
                    | +------------+   |      /
                    | |            |   |     /
                    | |            |   |    /
                    | |            V   V   /
                  --+-+---         -------+-
                 / Q4     \ N5    / Q3      \
                 \        /<------\         /
                  --------         ---------
        

The state transition table is as follows:

状态转换表如下所示:

        +---+---+---+
        |Q1 |Q3 |Q4 |
   -----+---+---+---+
    Q1  | - |N1 | - |
   -----+---+---+---+
    Q3  |N3 | - |N5 |
   -----+---+---+---+
    Q4  |N6 |N4 | - |
   -----+---+---+---+
        
        +---+---+---+
        |Q1 |Q3 |Q4 |
   -----+---+---+---+
    Q1  | - |N1 | - |
   -----+---+---+---+
    Q3  |N3 | - |N5 |
   -----+---+---+---+
    Q4  |N6 |N4 | - |
   -----+---+---+---+
        
8.3.2. Session State Diagram for a Target
8.3.2. 目标的会话状态图

Symbolic names for states:

国家的符号名称:

Q1: FREE

问题1:免费

Q2: ACTIVE

问题2:主动

Q3: LOGGED_IN

问题3:已登录

Q4: FAILED

问题4:失败

Q5: IN_CONTINUE

问题5:请继续

State Q3 represents the Full Feature Phase operation of the session.

状态Q3表示会话的完整功能阶段操作。

The state diagram is as follows:

状态图如下所示:

                                           ---------
                     +------------------->/ Q1      \
                    /     +-------------->\         /<-+
                    |     |                ---+-----   |
                    |     |                 ^ |        |N3
                 N6 |     |N11            N9| V N1     |
                    |     |                 +--------  |
                    |     |                / Q2      \ |
                    |     |                \         / |
                    |  ---+-----            +--+-----  |
                    | / Q5      \              |       |
                    | \         / N10          |       |
                    |  -+-+----+-----------+   | N2   /
                    |   ^ |                |   |     /
                    | N7| |N8              |   |    /
                    |   | |                |   V   /
                  --+---+-V                V------+-
                 / Q4      \ N5           / Q3      \
                 \         /<-------------\         /
                  ---------                ---------
        
                                           ---------
                     +------------------->/ Q1      \
                    /     +-------------->\         /<-+
                    |     |                ---+-----   |
                    |     |                 ^ |        |N3
                 N6 |     |N11            N9| V N1     |
                    |     |                 +--------  |
                    |     |                / Q2      \ |
                    |     |                \         / |
                    |  ---+-----            +--+-----  |
                    | / Q5      \              |       |
                    | \         / N10          |       |
                    |  -+-+----+-----------+   | N2   /
                    |   ^ |                |   |     /
                    | N7| |N8              |   |    /
                    |   | |                |   V   /
                  --+---+-V                V------+-
                 / Q4      \ N5           / Q3      \
                 \         /<-------------\         /
                  ---------                ---------
        

The state transition table is as follows:

状态转换表如下所示:

        +----+----+----+----+----+
        |Q1  |Q2  |Q3  |Q4  |Q5  |
   -----+----+----+----+----+----+
    Q1  | -  |N1  | -  | -  | -  |
   -----+----+----+----+----+----+
    Q2  |N9  | -  |N2  | -  | -  |
   -----+----+----+----+----+----+
    Q3  |N3  | -  | -  |N5  | -  |
   -----+----+----+----+----+----+
    Q4  |N6  | -  | -  | -  |N7  |
   -----+----+----+----+----+----+
    Q5  |N11 | -  |N10 |N8  | -  |
   -----+----+----+----+----+----+
        
        +----+----+----+----+----+
        |Q1  |Q2  |Q3  |Q4  |Q5  |
   -----+----+----+----+----+----+
    Q1  | -  |N1  | -  | -  | -  |
   -----+----+----+----+----+----+
    Q2  |N9  | -  |N2  | -  | -  |
   -----+----+----+----+----+----+
    Q3  |N3  | -  | -  |N5  | -  |
   -----+----+----+----+----+----+
    Q4  |N6  | -  | -  | -  |N7  |
   -----+----+----+----+----+----+
    Q5  |N11 | -  |N10 |N8  | -  |
   -----+----+----+----+----+----+
        
8.3.3. State Descriptions for Initiators and Targets
8.3.3. 启动器和目标的状态描述

Q1: FREE

问题1:免费

- initiator: State on instantiation or after cleanup.

- 启动器:实例化时或清理后的状态。

- target: State on instantiation or after cleanup.

- 目标:实例化时或清理后的状态。

Q2: ACTIVE

问题2:主动

- initiator: Illegal.

- 发起者:非法。

- target: The first iSCSI connection in the session transitioned to IN_LOGIN, waiting for it to complete the login process.

- 目标:会话中的第一个iSCSI连接已转换为in_登录,等待它完成登录过程。

Q3: LOGGED_IN

问题3:已登录

- initiator: Waiting for all session events.

- 启动器:正在等待所有会话事件。

- target: Waiting for all session events.

- 目标:等待所有会话事件。

Q4: FAILED

问题4:失败

- initiator: Waiting for session recovery or session continuation.

- 启动器:正在等待会话恢复或会话继续。

- target: Waiting for session recovery or session continuation.

- 目标:等待会话恢复或会话继续。

Q5: IN_CONTINUE

问题5:请继续

- initiator: Illegal.

- 发起者:非法。

- target: Waiting for session continuation attempt to reach a conclusion.

- 目标:等待会话继续尝试得出结论。

8.3.4. State Transition Descriptions for Initiators and Targets
8.3.4. 启动器和目标的状态转换说明

N1:

N1:

- initiator: At least one transport connection reached the LOGGED_IN state.

- 启动器:至少有一个传输连接达到登录状态。

- target: The first iSCSI connection in the session had reached the IN_LOGIN state.

- 目标:会话中的第一个iSCSI连接已达到in_登录状态。

N2:

N2:

- initiator: Illegal.

- 发起者:非法。

- target: At least one iSCSI connection reached the LOGGED_IN state.

- 目标:至少有一个iSCSI连接达到登录状态。

N3:

N3:

- initiator: Graceful closing of the session via session closure (Section 6.3.6).

- 发起人:通过会话关闭优雅地关闭会话(第6.3.6节)。

- target: Graceful closing of the session via session closure (Section 6.3.6) or a successful session reinstatement cleanly closed the session.

- 目标:通过会话关闭(第6.3.6节)优雅地关闭会话,或成功恢复会话干净地关闭会话。

N4:

N4:

- initiator: A session continuation attempt succeeded.

- 启动器:会话继续尝试成功。

- target: Illegal.

- 目标:非法。

N5: - initiator: Session failure (Section 6.3.6) occurred.

N5:-启动器:发生会话故障(第6.3.6节)。

- target: Session failure (Section 6.3.6) occurred.

- 目标:发生会话失败(第6.3.6节)。

N6:

N6:

- initiator: Session state timeout occurred, or a session reinstatement cleared this session instance. This results in the freeing of all associated resources, and the session state is discarded.

- 启动器:发生会话状态超时,或会话恢复已清除此会话实例。这将释放所有相关资源,并丢弃会话状态。

- target: Session state timeout occurred, or a session reinstatement cleared this session instance. This results in the freeing of all associated resources, and the session state is discarded.

- 目标:发生会话状态超时,或会话恢复已清除此会话实例。这将释放所有相关资源,并丢弃会话状态。

N7:

N7:

- initiator: Illegal.

- 发起者:非法。

- target: A session continuation attempt was initiated.

- 目标:已启动会话继续尝试。

N8:

N8:

- initiator: Illegal.

- 发起者:非法。

- target: The last session continuation attempt failed.

- 目标:上次会话继续尝试失败。

N9:

N9:

- initiator: Illegal.

- 发起者:非法。

- target: Login attempt on the leading connection failed.

- 目标:尝试登录前导连接失败。

N10:

N10:

- initiator: Illegal.

- 发起者:非法。

- target: A session continuation attempt succeeded.

- 目标:会话继续尝试成功。

N11:

N11:

- initiator: Illegal.

- 发起者:非法。

- target: A successful session reinstatement cleanly closed the session.

- 目标:成功的会话恢复干净地关闭了会话。

9. Security Considerations
9. 安全考虑

Historically, native storage systems have not had to consider security, because their environments offered minimal security risks. That is, these environments consisted of storage devices either directly attached to hosts or connected via a Storage Area Network (SAN) distinctly separate from the communications network. The use of storage protocols, such as SCSI, over IP networks requires that security concerns be addressed. iSCSI implementations must provide means of protection against active attacks (e.g., pretending to be another identity; message insertion, deletion, modification, and replaying) and passive attacks (e.g., eavesdropping, gaining advantage by analyzing the data sent over the line).

从历史上看,本地存储系统不必考虑安全性,因为它们的环境提供了最小的安全风险。也就是说,这些环境由直接连接到主机或通过与通信网络明显分离的存储区域网络(SAN)连接的存储设备组成。在IP网络上使用SCSI等存储协议需要解决安全问题。iSCSI实施必须提供针对主动攻击(例如,假装是另一个身份;消息插入、删除、修改和重放)和被动攻击(例如,窃听,通过分析通过线路发送的数据获得优势)的保护手段。

Although technically possible, iSCSI SHOULD NOT be configured without security, specifically in-band authentication; see Section 9.2. iSCSI configured without security should be confined to closed environments that have very limited and well-controlled security risks. [RFC3723] specifies the mechanisms that must be used in order to mitigate risks fully described in that document.

尽管在技术上可行,但iSCSI的配置不应没有安全性,特别是带内身份验证;见第9.2节。在没有安全性的情况下配置的iSCSI应限于安全风险非常有限且控制良好的封闭环境。[RFC3723]规定了必须使用的机制,以减轻该文件中充分描述的风险。

The following section describes the security mechanisms provided by an iSCSI implementation.

以下部分介绍iSCSI实现提供的安全机制。

9.1. iSCSI Security Mechanisms
9.1. iSCSI安全机制

The entities involved in iSCSI security are the initiator, target, and the IP communication endpoints. iSCSI scenarios in which multiple initiators or targets share a single communication endpoint are expected. To accommodate such scenarios, iSCSI supports two separate security mechanisms: in-band authentication between the initiator and the target at the iSCSI connection level (carried out by exchange of iSCSI Login PDUs), and packet protection (integrity, authentication, and confidentiality) by IPsec at the IP level. The two security mechanisms complement each other. The in-band authentication provides end-to-end trust (at login time) between the iSCSI initiator and the target, while IPsec provides a secure channel between the IP communication endpoints. iSCSI can be used to access sensitive information for which significant security protection is appropriate. As further specified in the rest of this security considerations section, both iSCSI security mechanisms are mandatory to implement (MUST). The use of in-band authentication is strongly recommended (SHOULD). In contrast, the use of IPsec is optional (MAY), as the security risks that it addresses may only be present over a subset of the networks used by an iSCSI connection or a session; a specific example is that when an iSCSI session spans data centers, IPsec VPN gateways at the data center boundaries to protect the WAN connectivity between data centers may be appropriate in combination with in-band iSCSI authentication.

iSCSI安全性涉及的实体包括启动器、目标和IP通信端点。iSCSI场景中,多个启动器或目标共享一个通信端点。为了适应这种情况,iSCSI支持两种独立的安全机制:在iSCSI连接级别上的启动器和目标之间的带内身份验证(由iSCSI登录PDU的交换执行),以及在IP级别上的IPsec数据包保护(完整性、身份验证和机密性)。这两种安全机制相辅相成。带内身份验证在iSCSI启动器和目标之间提供端到端信任(登录时),而IPsec在IP通信端点之间提供安全通道。iSCSI可用于访问敏感信息,对于这些敏感信息,需要进行重要的安全保护。如本安全注意事项部分的其余部分所述,这两种iSCSI安全机制都是必须实施的(必须实施)。强烈建议(应)使用带内身份验证。相反,IPsec的使用是可选的(可能),因为它解决的安全风险可能只存在于iSCSI连接或会话使用的网络子集上;一个具体示例是,当iSCSI会话跨越数据中心时,数据中心边界处的IPsec VPN网关(用于保护数据中心之间的WAN连接)可能适合与带内iSCSI身份验证相结合。

Further details on typical iSCSI scenarios and the relationship between the initiators, targets, and the communication endpoints can be found in [RFC3723].

有关典型iSCSI场景以及启动器、目标和通信端点之间关系的更多详细信息,请参见[RFC3723]。

9.2. In-Band Initiator-Target Authentication
9.2. 带内启动器目标身份验证

During login, the target MAY authenticate the initiator and the initiator MAY authenticate the target. The authentication is performed on every new iSCSI connection by an exchange of iSCSI Login PDUs using a negotiated authentication method.

登录期间,目标可以对启动器进行身份验证,而启动器可以对目标进行身份验证。通过使用协商身份验证方法交换iSCSI登录PDU,在每个新iSCSI连接上执行身份验证。

The authentication method cannot assume an underlying IPsec protection, because IPsec is optional to use. An attacker should gain as little advantage as possible by inspecting the authentication phase PDUs. Therefore, a method using cleartext (or equivalent) passwords MUST NOT be used; on the other hand, identity protection is not strictly required.

身份验证方法不能采用基础IPsec保护,因为IPsec是可选的。通过检查身份验证阶段PDU,攻击者应获得尽可能少的优势。因此,不得使用使用明文(或等效)密码的方法;另一方面,身份保护并非严格要求。

The authentication mechanism protects against an unauthorized login to storage resources by using a false identity (spoofing). Once the authentication phase is completed, if the underlying IPsec is not used, all PDUs are sent and received in the clear. The

身份验证机制通过使用虚假身份(欺骗)防止未经授权登录到存储资源。身份验证阶段完成后,如果未使用基础IPsec,则所有PDU都以明文形式发送和接收。这个

authentication mechanism alone (without underlying IPsec) should only be used when there is no risk of eavesdropping or of message insertion, deletion, modification, and replaying.

只有在不存在窃听或消息插入、删除、修改和重播风险的情况下,才应单独使用身份验证机制(无底层IPsec)。

Section 12 defines several authentication methods and the exact steps that must be followed in each of them, including the iSCSI-text-keys and their allowed values in each step. Whenever an iSCSI initiator gets a response whose keys, or their values, are not according to the step definition, it MUST abort the connection.

第12节定义了几种身份验证方法以及每个方法中必须遵循的确切步骤,包括iSCSI文本密钥及其在每个步骤中允许的值。每当iSCSI启动器收到密钥或其值不符合步骤定义的响应时,它必须中止连接。

Whenever an iSCSI target gets a request or response whose keys, or their values, are not according to the step definition, it MUST answer with a Login reject with the "Initiator Error" or "Missing Parameter" status. These statuses are not intended for cryptographically incorrect values such as the CHAP response, for which the "Authentication Failure" status MUST be specified. The importance of this rule can be illustrated in CHAP with target authentication (see Section 12.1.3), where the initiator would have been able to conduct a reflection attack by omitting its response key (CHAP_R), using the same CHAP challenge as the target and reflecting the target's response back to the target. In CHAP, this is prevented because the target must answer the missing CHAP_R key with a Login reject with the "Missing Parameter" status.

每当iSCSI目标收到其密钥或其值不符合步骤定义的请求或响应时,它必须以“启动器错误”或“缺少参数”状态的登录拒绝进行应答。这些状态不适用于加密错误的值,例如CHAP响应,必须为其指定“身份验证失败”状态。此规则的重要性可在CHAP目标身份验证(见第12.1.3节)中说明,其中启动器可以通过省略其响应密钥(CHAP_R)来进行反射攻击,使用与目标相同的CHAP质询,并将目标的响应反射回目标。在CHAP中,这是不允许的,因为目标必须使用“missing Parameter”(缺少参数)状态的登录拒绝来回答缺少的CHAP\R密钥。

For some of the authentication methods, a key specifies the identity of the iSCSI initiator or target for authentication purposes. The value associated with that key MAY be different from the iSCSI name and SHOULD be configurable (CHAP_N: see Section 12.1.3; SRP_U: see Section 12.1.2). For this reason, iSCSI implementations SHOULD manage authentication in a way that impersonation across iSCSI names via these authentication identities is not possible. Specifically, implementations SHOULD allow configuration of an authentication identity for a Name if different, and authentication credentials for that identity. During the login time, implementations SHOULD verify the Name-to-identity relationship in addition to authenticating the identity through the negotiated authentication method.

对于某些身份验证方法,密钥指定用于身份验证的iSCSI启动器或目标的标识。与该密钥关联的值可能不同于iSCSI名称,并且应该是可配置的(第章:请参阅第12.1.3节;SRP:请参阅第12.1.2节)。因此,iSCSI实施应以不可能通过这些身份验证身份跨iSCSI名称进行模拟的方式管理身份验证。具体地说,实现应该允许配置名称(如果不同)的身份验证标识以及该标识的身份验证凭据。在登录期间,除了通过协商身份验证方法验证身份之外,实现还应该验证名称与身份之间的关系。

When an iSCSI session has multiple TCP connections, either concurrently or sequentially, the authentication method and identities should not vary among the connections. Therefore, all connections in an iSCSI session SHOULD use the same authentication method, iSCSI name, and authentication identity (for authentication methods that use an authentication identity). Implementations SHOULD check this and cause an authentication failure on a new connection that uses a different authentication method, iSCSI name, or authentication identity from those already used in the session. In

当iSCSI会话同时或按顺序具有多个TCP连接时,身份验证方法和标识不应因连接而异。因此,iSCSI会话中的所有连接都应使用相同的身份验证方法、iSCSI名称和身份验证标识(对于使用身份验证标识的身份验证方法)。实施应对此进行检查,并在使用与会话中已使用的身份验证方法、iSCSI名称或身份验证标识不同的身份验证方法、iSCSI名称或身份验证标识的新连接上导致身份验证失败。在里面

addition, implementations SHOULD NOT support both authenticated and unauthenticated TCP connections in the same iSCSI session, added either concurrently or sequentially to the session.

此外,在同一iSCSI会话中,实现不应同时支持已验证和未验证的TCP连接,该会话可以同时或顺序添加到会话中。

9.2.1. CHAP Considerations
9.2.1. 第三章注意事项

Compliant iSCSI initiators and targets MUST implement the CHAP authentication method [RFC1994] (according to Section 12.1.3, including the target authentication option).

符合要求的iSCSI启动器和目标必须实施CHAP身份验证方法[RFC1994](根据第12.1.3节,包括目标身份验证选项)。

When CHAP is performed over a non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support the use of up to 128-bit random CHAP secrets, including the means to generate such secrets and to accept them from an external generation source. Implementations MUST NOT provide secret generation (or expansion) means other than random generation.

在非加密通道上执行CHAP时,容易受到离线字典攻击。实现必须支持使用多达128位的随机CHAP机密,包括生成此类机密并从外部生成源接受这些机密的方法。除随机生成外,实现不得提供秘密生成(或扩展)方法。

An administrative entity of an environment in which CHAP is used with a secret that has less than 96 random bits MUST enforce IPsec encryption (according to the implementation requirements in Section 9.3.2) to protect the connection. Moreover, in this case, IKE authentication with group pre-shared cryptographic keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks by other members.

如果CHAP与少于96个随机位的秘密一起使用,则环境的管理实体必须强制IPsec加密(根据第9.3.2节中的实施要求)以保护连接。此外,在这种情况下,不应使用带有组预共享加密密钥的IKE身份验证,除非不需要保护组成员免受其他成员的脱机字典攻击。

CHAP secrets MUST be an integral number of bytes (octets). A compliant implementation SHOULD NOT continue with the login step in which it should send a CHAP response (CHAP_R; see Section 12.1.3) unless it can verify that the CHAP secret is at least 96 bits or that IPsec encryption is being used to protect the connection.

CHAP机密必须是整数字节(八位字节)。符合要求的实施不应继续执行登录步骤,在该步骤中,它应发送CHAP响应(CHAP\R;请参阅第12.1.3节),除非它可以验证CHAP机密是否至少为96位或IPsec加密是否用于保护连接。

Any CHAP secret used for initiator authentication MUST NOT be configured for authentication of any target, and any CHAP secret used for target authentication MUST NOT be configured for authentication of any initiator. If the CHAP response received by one end of an iSCSI connection is the same as the CHAP response that the receiving endpoint would have generated for the same CHAP challenge, the response MUST be treated as an authentication failure and cause the connection to close (this ensures that the same CHAP secret is not used for authentication in both directions). Also, if an iSCSI implementation can function as both initiator and target, different CHAP secrets and identities MUST be configured for these two roles. The following is an example of the attacks prevented by the above requirements:

不得将用于启动器身份验证的任何CHAP机密配置为任何目标的身份验证,也不得将用于目标身份验证的任何CHAP机密配置为任何启动器的身份验证。如果iSCSI连接的一端接收到的CHAP响应与接收端点为同一CHAP质询生成的CHAP响应相同,则该响应必须视为身份验证失败并导致连接关闭(这可确保同一CHAP机密不会在两个方向上用于身份验证)。此外,如果iSCSI实现可以同时作为启动器和目标,则必须为这两个角色配置不同的CHAP机密和身份。以下是通过上述要求防止的攻击示例:

a) "Rogue" wants to impersonate "Storage" to Alice and knows that a single secret is used for both directions of Storage-Alice authentication.

a) “Rogue”想要向Alice模拟“存储”,并且知道一个秘密用于存储和Alice身份验证的两个方向。

b) Rogue convinces Alice to open two connections to itself and identifies itself as Storage on both connections.

b) Rogue说服Alice打开与自身的两个连接,并将自己标识为两个连接上的存储器。

c) Rogue issues a CHAP challenge on Connection 1, waits for Alice to respond, and then reflects Alice's challenge as the initial challenge to Alice on Connection 2.

c) Rogue在连接1上发出CHAP质询,等待Alice响应,然后将Alice的质询反映为连接2上对Alice的初始质询。

d) If Alice doesn't check for the reflection across connections, Alice's response on Connection 2 enables Rogue to impersonate Storage on Connection 1, even though Rogue does not know the Alice-Storage CHAP secret.

d) 如果Alice没有检查连接之间的反射,Alice对连接2的响应将使Rogue能够模拟连接1上的存储,即使Rogue不知道Alice存储CHAP秘密。

Originators MUST NOT reuse the CHAP challenge sent by the responder for the other direction of a bidirectional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs.

发起人不得将响应者发送的CHAP质询重新用于双向身份验证的另一个方向。响应者必须检查是否存在这种情况,如果出现这种情况,请关闭iSCSI TCP连接。

The same CHAP secret SHOULD NOT be configured for authentication of multiple initiators or multiple targets, as this enables any of them to impersonate any other one of them, and compromising one of them enables the attacker to impersonate any of them. It is recommended that iSCSI implementations check for the use of identical CHAP secrets by different peers when this check is feasible and take appropriate measures to warn users and/or administrators when this is detected.

不应为多个启动器或多个目标的身份验证配置相同的CHAP机密,因为这使任何启动器或目标都能够模拟其中任何一个,而泄露其中一个启动器或目标则使攻击者能够模拟其中任何一个启动器或目标。建议iSCSI实施在可行时检查不同对等方是否使用相同的CHAP机密,并在检测到此情况时采取适当措施警告用户和/或管理员。

When an iSCSI initiator or target authenticates itself to counterparts in multiple administrative domains, it SHOULD use a different CHAP secret for each administrative domain to avoid propagating security compromises across domains.

当iSCSI启动器或目标向多个管理域中的对应方进行身份验证时,它应该为每个管理域使用不同的CHAP密钥,以避免跨域传播安全危害。

Within a single administrative domain:

在单个管理域内:

- A single CHAP secret MAY be used for authentication of an initiator to multiple targets.

- 单个CHAP密码可用于将启动器身份验证到多个目标。

- A single CHAP secret MAY be used for an authentication of a target to multiple initiators when the initiators use an external server (e.g., RADIUS [RFC2865]) to verify the target's CHAP responses and do not know the target's CHAP secret.

- 当发起方使用外部服务器(例如RADIUS[RFC2865])验证目标方的CHAP响应且不知道目标方的CHAP机密时,单个CHAP机密可用于向多个发起方验证目标方。

If an external response verification server (e.g., RADIUS) is not used, employing a single CHAP secret for authentication of a target to multiple initiators requires that all such initiators know that target's secret. Any of these initiators can impersonate the target to any other such initiator, and compromise of such an initiator enables an attacker to impersonate the target to all such initiators. Targets SHOULD use separate CHAP secrets for authentication to each

如果未使用外部响应验证服务器(例如RADIUS),则使用单个CHAP机密对多个启动器进行目标身份验证需要所有此类启动器都知道该目标的机密。这些启动器中的任何一个都可以向任何其他此类启动器模拟目标,而此类启动器的泄露使攻击者能够向所有此类启动器模拟目标。目标应使用单独的CHAP机密对每个目标进行身份验证

initiator when such risks are of concern; in this situation, it may be useful to configure a separate logical iSCSI target with its own iSCSI Node Name for each initiator or group of initiators among which such separation is desired.

当此类风险引起关注时,发起人;在这种情况下,可能需要为每个启动器或启动器组配置一个单独的逻辑iSCSI目标,该目标具有自己的iSCSI节点名称,其中需要这样的分离。

The above requirements strengthen the security properties of CHAP authentication for iSCSI by comparison to the basic CHAP authentication mechanism [RFC1994]. It is very important to adhere to these requirements, especially the requirements for strong (large randomly generated) CHAP secrets, as iSCSI implementations and deployments that fail to use strong CHAP secrets are likely to be highly vulnerable to off-line dictionary attacks on CHAP secrets.

与基本CHAP身份验证机制相比,上述要求增强了iSCSI CHAP身份验证的安全属性[RFC1994]。遵守这些要求非常重要,尤其是对强(随机生成的大)CHAP机密的要求,因为无法使用强CHAP机密的iSCSI实施和部署可能极易受到针对CHAP机密的离线字典攻击。

Replacement of CHAP with a better authentication mechanism is anticipated in a future version of iSCSI. The FC-SP-2 standard [FC-SP-2] has specified the Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) authentication mechanism [RFC5433] as an alternative to (and possible future replacement for) Fibre Channel's similar usage of strengthened CHAP. Another possible replacement for CHAP is a secure password mechanism, e.g., an updated version of iSCSI's current SRP authentication mechanism.

在iSCSI的未来版本中,预计将使用更好的身份验证机制替换CHAP。FC-SP-2标准[FC-SP-2]已指定可扩展身份验证协议-通用预共享密钥(EAP-GPSK)身份验证机制[RFC5433]作为光纤通道类似使用增强CHAP的替代品(以及未来可能的替代品)。CHAP的另一种替代品是安全密码机制,例如。,iSCSI当前SRP身份验证机制的更新版本。

9.2.2. SRP Considerations
9.2.2. SRP考虑事项

The strength of the SRP authentication method (specified in [RFC2945]) is dependent on the characteristics of the group being used (i.e., the prime modulus N and generator g). As described in [RFC2945], N is required to be a Sophie Germain prime (of the form N = 2q + 1, where q is also prime) and the generator g is a primitive root of GF(N). In iSCSI authentication, the prime modulus N MUST be at least 768 bits.

SRP认证方法的强度(在[RFC2945]中规定)取决于所用组的特征(即,素模N和生成器g)。如[RFC2945]所述,N必须是Sophie-Germain素数(形式为N=2q+1,其中q也是素数),且生成器g是GF(N)的本原根。在iSCSI身份验证中,基本模数N必须至少为768位。

The list of allowed SRP groups is provided in [RFC3723].

[RFC3723]中提供了允许的SRP组列表。

9.2.3. Kerberos Considerations
9.2.3. Kerberos注意事项

iSCSI uses raw Kerberos V5 [RFC4120] for authenticating a client (iSCSI initiator) principal to a service (iSCSI target) principal. Note that iSCSI does not use the Generic Security Service Application Program Interface (GSS-API) [RFC2743] or the Kerberos V5 GSS-API security mechanism [RFC4121]. This means that iSCSI implementations supporting the KRB5 AuthMethod (Section 12.1) are directly involved in the Kerberos protocol. When Kerberos V5 is used for authentication, the following actions MUST be performed as specified in [RFC4120]:

iSCSI使用原始Kerberos V5[RFC4120]将客户端(iSCSI启动器)主体身份验证为服务(iSCSI目标)主体。请注意,iSCSI不使用通用安全服务应用程序接口(GSS-API)[RFC2743]或Kerberos V5 GSS-API安全机制[RFC4121]。这意味着支持KRB5 AuthMethod(第12.1节)的iSCSI实现直接涉及Kerberos协议。当Kerberos V5用于身份验证时,必须按照[RFC4120]中的规定执行以下操作:

- The target MUST validate KRB_AP_REQ to ensure that the initiator can be trusted.

- 目标必须验证KRB_AP_REQ,以确保可以信任启动器。

- When mutual authentication is selected, the initiator MUST validate KRB_AP_REP to determine the outcome of mutual authentication.

- 选择相互身份验证时,启动器必须验证KRB_AP_REP以确定相互身份验证的结果。

As Kerberos V5 is capable of providing mutual authentication, implementations SHOULD support mutual authentication by default for login authentication.

由于kerberosv5能够提供相互身份验证,因此实现应该默认支持登录身份验证的相互身份验证。

Note, however, that Kerberos authentication only assures that the server (iSCSI target) can be trusted by the Kerberos client (initiator) and vice versa; an initiator should employ appropriately secured service discovery techniques (e.g., iSNS; see Section 4.2.7) to ensure that it is talking to the intended target principal.

但是,请注意,Kerberos身份验证仅确保Kerberos客户端(启动器)可以信任服务器(iSCSI目标),反之亦然;发起方应采用适当的安全服务发现技术(例如,iSNS;请参阅第4.2.7节),以确保它正在与预期的目标主体对话。

iSCSI does not use Kerberos v5 for either integrity or confidentiality protection of the iSCSI protocol. iSCSI uses IPsec for those purposes as specified in Section 9.3.

iSCSI不使用Kerberos v5来保护iSCSI协议的完整性或机密性。iSCSI将IPsec用于第9.3节中指定的目的。

9.3. IPsec
9.3. IPsec

iSCSI uses the IPsec mechanism for packet protection (cryptographic integrity, authentication, and confidentiality) at the IP level between the iSCSI communicating endpoints. The following sections describe the IPsec protocols that must be implemented for data authentication and integrity; confidentiality; and cryptographic key management.

iSCSI使用IPsec机制在iSCSI通信端点之间的IP级别进行数据包保护(加密完整性、身份验证和机密性)。以下各节描述了数据认证和完整性必须实现的IPsec协议;保密性;密码和密钥管理。

An iSCSI initiator or target may provide the required IPsec support fully integrated or in conjunction with an IPsec front-end device. In the latter case, the compliance requirements with regard to IPsec support apply to the "combined device". Only the "combined device" is to be considered an iSCSI device.

iSCSI启动器或目标可以提供完全集成或与IPsec前端设备结合使用所需的IPsec支持。在后一种情况下,有关IPsec支持的符合性要求适用于“组合设备”。只有“组合设备”才被视为iSCSI设备。

Detailed considerations and recommendations for using IPsec for iSCSI are provided in [RFC3723] as updated by [RFC7146]. The IPsec requirements are reproduced here for convenience and are intended to match those in [RFC7146]; in the event of a discrepancy, the requirements in [RFC7146] apply.

[RFC3723]中提供了将IPsec用于iSCSI的详细注意事项和建议,并由[RFC7146]更新。此处复制IPsec要求是为了方便,旨在与[RFC7146]中的要求相匹配;如果存在差异,[RFC7146]中的要求适用。

9.3.1. Data Authentication and Integrity
9.3.1. 数据认证和完整性

Data authentication and integrity are provided by a cryptographic keyed Message Authentication Code in every sent packet. This code protects against message insertion, deletion, and modification. Protection against message replay is realized by using a sequence counter.

数据认证和完整性由每个发送数据包中的加密密钥消息认证码提供。此代码可防止消息插入、删除和修改。通过使用序列计数器实现对消息重放的保护。

An iSCSI-compliant initiator or target MUST provide data authentication and integrity by implementing IPsec v2 [RFC2401] with ESPv2 [RFC2406] in tunnel mode, SHOULD provide data authentication and integrity by implementing IPsec v3 [RFC4301] with ESPv3 [RFC4303] in tunnel mode, and MAY provide data authentication and integrity by implementing either IPsec v2 or v3 with the appropriate version of ESP in transport mode. The IPsec implementation MUST fulfill the following iSCSI-specific requirements:

符合iSCSI的启动器或目标必须通过在隧道模式下实现IPsec v2[RFC2401]和ESPv2[RFC2406]来提供数据身份验证和完整性,应通过在隧道模式下实现IPsec v3[RFC4301]和ESPv3[RFC4303]来提供数据身份验证和完整性,并且可以通过在传输模式下使用适当版本的ESP实现IPsec v2或v3来提供数据身份验证和完整性。IPsec实施必须满足以下特定于iSCSI的要求:

- HMAC-SHA1 MUST be implemented in the specific form of HMAC-SHA-1-96 [RFC2404].

- HMAC-SHA1必须以HMAC-SHA-1-96[RFC2404]的具体形式实施。

- AES CBC MAC with XCBC extensions using 128-bit keys SHOULD be implemented [RFC3566].

- 应使用128位密钥实现带有XCBC扩展的AES CBC MAC[RFC3566]。

- Implementations that support IKEv2 [RFC5996] SHOULD also implement AES Galois Message Authentication Code (GMAC) [RFC4543] using 128-bit keys.

- 支持IKEv2[RFC5996]的实现还应该使用128位密钥实现AES Galois消息身份验证码(GMAC)[RFC4543]。

The ESP anti-replay service MUST also be implemented.

还必须实施ESP防重播服务。

At the high speeds at which iSCSI is expected to operate, a single IPsec SA could rapidly exhaust the ESP 32-bit sequence number space, requiring frequent rekeying of the SA, as rollover of the ESP sequence number within a single SA is prohibited for both ESPv2 [RFC2406] and ESPv3 [RFC4303]. In order to provide the means to avoid this potentially undesirable frequent rekeying, implementations that are capable of operating at speeds of 1 gigabit/second or higher MUST implement extended (64-bit) sequence numbers for ESPv2 (and ESPv3, if supported) and SHOULD use extended sequence numbers for all iSCSI traffic. Extended sequence number negotiation as part of security association establishment is specified in [RFC4304] for IKEv1 and [RFC5996] for IKEv2.

在iSCSI预期运行的高速下,单个IPsec SA可能会快速耗尽ESP 32位序列号空间,需要频繁地重新键入SA,因为ESPv2[RFC2406]和ESPv3[RFC4303]都禁止在单个SA内滚动ESP序列号。为了提供避免这种可能不需要的频繁密钥更新的方法,能够以1千兆位/秒或更高速度运行的实现必须为ESPv2(和ESPv3,如果支持)实现扩展(64位)序列号,并且应该为所有iSCSI通信使用扩展序列号。[RFC4304]针对IKEv1和[RFC5996]针对IKEv2规定了作为安全关联建立一部分的扩展序列号协商。

9.3.2. Confidentiality
9.3.2. 保密性

Confidentiality is provided by encrypting the data in every packet. When confidentiality is used, it MUST be accompanied by data authentication and integrity to provide comprehensive protection against eavesdropping and against message insertion, deletion, modification, and replaying.

通过加密每个数据包中的数据来提供机密性。当使用保密性时,它必须伴随着数据身份验证和完整性,以提供全面的保护,防止窃听和消息插入、删除、修改和重播。

An iSCSI-compliant initiator or target MUST provide confidentiality by implementing IPsec v2 [RFC2401] with ESPv2 [RFC2406] in tunnel mode, SHOULD provide confidentiality by implementing IPsec v3 [RFC4301] with ESPv3 [RFC4303] in tunnel mode, and MAY provide

符合iSCSI的启动器或目标必须通过在隧道模式下实现IPsec v2[RFC2401]和ESPv2[RFC2406]来提供机密性,应该通过在隧道模式下实现IPsec v3[RFC4301]和ESPv3[RFC4303]来提供机密性,并且可以提供

confidentiality by implementing either IPsec v2 or v3 with the appropriate version of ESP in transport mode, with the following iSCSI-specific requirements that apply to IPsec v2 and IPsec v3:

通过在传输模式下使用适当版本的ESP实现IPsec v2或v3,并满足适用于IPsec v2和IPsec v3的以下iSCSI特定要求,实现机密性:

- 3DES in CBC mode MAY be implemented [RFC2451].

- 可以实现CBC模式下的3DE[RFC2451]。

- AES in CBC mode with 128-bit keys MUST be implemented [RFC3602]; other key sizes MAY be supported.

- 必须实现CBC模式下具有128位密钥的AES[RFC3602];可能支持其他密钥大小。

- AES in Counter mode MAY be implemented [RFC3686].

- 可以实现计数器模式下的AES[RFC3686]。

- Implementations that support IKEv2 [RFC5996] SHOULD also implement AES Galois/Counter Mode (GCM) with 128-bit keys [RFC4106]; other key sizes MAY be supported.

- 支持IKEv2[RFC5996]的实现还应使用128位密钥[RFC4106]实现AES伽罗瓦/计数器模式(GCM);可能支持其他密钥大小。

Due to its inherent weakness, DES in CBC mode MUST NOT be used.

由于其固有的弱点,不能使用CBC模式下的DES。

The NULL encryption algorithm MUST also be implemented.

还必须实现空加密算法。

9.3.3. Policy, Security Associations, and Cryptographic Key Management
9.3.3. 策略、安全关联和加密密钥管理

A compliant iSCSI implementation MUST meet the cryptographic key management requirements of the IPsec protocol suite. Authentication, security association negotiation, and cryptographic key management MUST be provided by implementing IKE [RFC2409] using the IPsec DOI [RFC2407] and SHOULD be provided by implementing IKEv2 [RFC5996], with the following iSCSI-specific requirements:

符合要求的iSCSI实施必须满足IPsec协议套件的加密密钥管理要求。身份验证、安全关联协商和加密密钥管理必须通过使用IPsec DOI[RFC2407]实现IKE[RFC2409]来提供,并且应通过实现IKEv2[RFC5996]来提供,并满足以下iSCSI特定要求:

a) Peer authentication using a pre-shared cryptographic key MUST be supported. Certificate-based peer authentication using digital signatures MAY be supported. For IKEv1 ([RFC2409]), peer authentication using the public key encryption methods outlined in Sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used.

a) 必须支持使用预共享加密密钥的对等身份验证。可能支持使用数字签名的基于证书的对等身份验证。对于IKEv1([RFC2409]),不应使用[RFC2409]第5.2节和第5.3节中概述的公钥加密方法进行对等身份验证。

b) When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority. IKE negotiators SHOULD check certificate validity via the pertinent Certificate Revocation List (CRL) or via the use of the Online Certificate Status Protocol (OCSP) [RFC6960] before accepting a PKI certificate for use in IKE authentication procedures. OCSP support within the IKEv2 protocol is specified in [RFC4806]. These checks may not be needed in environments where a small number of certificates are statically configured as trust anchors.

b) 当使用数字签名实现身份验证时,IKE谈判者应使用IKE证书请求有效载荷来指定证书颁发机构。IKE谈判者在接受用于IKE身份验证过程的PKI证书之前,应通过相关证书撤销列表(CRL)或通过使用在线证书状态协议(OCSP)[RFC6960]检查证书有效性。[RFC4806]中规定了IKEv2协议内的OCSP支持。在将少量证书静态配置为信任锚的环境中,可能不需要这些检查。

c) Conformant iSCSI implementations of IKEv1 MUST support Main Mode and SHOULD support Aggressive Mode. Main Mode with a pre-shared key authentication method SHOULD NOT be used when either the initiator or the target uses dynamically assigned addresses. While in many cases pre-shared keys offer good security, situations in which dynamically assigned addresses are used force the use of a group pre-shared key, which creates vulnerability to a man-in-the-middle attack.

c) IKEv1的一致性iSCSI实现必须支持主模式,并应支持主动模式。当启动器或目标使用动态分配的地址时,不应使用带有预共享密钥身份验证方法的主模式。虽然在许多情况下,预共享密钥提供了良好的安全性,但在使用动态分配的地址的情况下,强制使用组预共享密钥,这会造成中间人攻击的漏洞。

d) In the IKEv1 Phase 2 Quick Mode, in exchanges for creating the Phase 2 SA, the Identification Payload MUST be present.

d) 在IKEv1阶段2快速模式下,作为创建阶段2 SA的交换,必须存在识别有效载荷。

e) The following identification type requirements apply to IKEv1: ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), and ID_FQDN Identification Types MUST be supported; ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT be used.

e) 以下标识类型要求适用于IKEv1:必须支持ID_IPV4_ADDR、ID_IPV6_ADDR(如果协议栈支持IPV6)和ID_FQDN标识类型;应支持ID\u用户\u FQDN。不应使用IP子网、IP地址范围、ID_DER_ASN1_DN和ID_DER_ASN1_GN标识类型。不得使用ID\u密钥\u ID标识类型。

f) If IKEv2 is supported, the following identification requirements apply: ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), and ID_FQDN Identification Types MUST be supported; ID_RFC822_ADDR SHOULD be supported. The ID_DER_ASN1_DN and ID_DER_ASN1_GN Identification Types SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT be used.

f) 如果支持IKEv2,则以下标识要求适用:必须支持ID_IPV4_ADDR、ID_IPV6_ADDR(如果协议栈支持IPV6)和ID_FQDN标识类型;应支持ID\u RFC822\u ADDR。不应使用ID_DER_ASN1_DN和ID_DER_ASN1_GN标识类型。不得使用ID\u密钥\u ID标识类型。

The reasons for the "MUST NOT" and "SHOULD NOT" for identification type requirements in preceding bullets e) and f) are:

上述项目符号e)和f)中标识类型要求的“不得”和“不应”原因如下:

- IP Subnet and IP Address Range are too broad to usefully identify an iSCSI endpoint.

- IP子网和IP地址范围太宽,无法有效标识iSCSI端点。

- The DN and GN types are X.500 identities; it is usually better to use an identity from subjectAltName in a PKI certificate.

- DN和GN类型为X.500标识;通常最好在PKI证书中使用subjectAltName中的标识。

- ID_KEY_ID is not interoperable as specified.

- ID\u KEY\u ID不可按指定进行互操作。

Manual cryptographic keying MUST NOT be used, because it does not provide the necessary rekeying support.

不得使用手动加密密钥,因为它不提供必要的密钥更新支持。

When Diffie-Hellman (DH) groups are used, a DH group of at least 2048 bits SHOULD be offered as a part of all proposals to create IPsec security associations to protect iSCSI traffic, with both IKEv1 and IKEv2.

当使用Diffie-Hellman(DH)组时,应提供至少2048位的DH组,作为创建IPsec安全关联以保护iSCSI通信的所有建议的一部分,包括IKEv1和IKEv2。

When IPsec is used, the receipt of an IKEv1 Phase 2 delete message or an IKEv2 INFORMATIONAL exchange that deletes the SA SHOULD NOT be interpreted as a reason for tearing down the iSCSI TCP connection. If additional traffic is sent on it, a new IKE SA will be created to protect it.

使用IPsec时,接收到IKEv1第2阶段删除消息或删除SA的IKEv2信息交换不应被解释为断开iSCSI TCP连接的原因。如果在其上发送额外流量,将创建一个新的IKE SA来保护它。

The method used by the initiator to determine whether the target should be connected using IPsec is regarded as an issue of IPsec policy administration and thus not defined in the iSCSI standard.

启动器用于确定是否应使用IPsec连接目标的方法被视为IPsec策略管理的一个问题,因此未在iSCSI标准中定义。

The method used by an initiator that supports both IPsec v2 and v3 to determine which versions of IPsec are supported by the target is also regarded as an issue of IPsec policy administration and thus not defined in the iSCSI standard. If both IPsec v2 and v3 are supported by both the initiator and target, the use of IPsec v3 is recommended.

同时支持IPsec v2和v3的启动器用于确定目标支持的IPsec版本的方法也被视为IPsec策略管理的问题,因此在iSCSI标准中没有定义。如果启动器和目标都支持IPsec v2和v3,则建议使用IPsec v3。

If an iSCSI target is discovered via a SendTargets request in a Discovery session not using IPsec, the initiator should assume that it does not need IPsec to establish a session to that target. If an iSCSI target is discovered using a Discovery session that does use IPsec, the initiator SHOULD use IPsec when establishing a session to that target.

如果在不使用IPsec的发现会话中通过SendTargets请求发现iSCSI目标,则启动器应假定不需要IPsec来建立到该目标的会话。如果使用使用IPsec的发现会话发现iSCSI目标,则启动器在建立到该目标的会话时应使用IPsec。

9.4. Security Considerations for the X#NodeArchitecture Key
9.4. X#节点体系结构密钥的安全注意事项

The security considerations in this section are specific to the X#NodeArchitecture discussed in Section 13.26.

本节中的安全注意事项特定于第13.26节中讨论的X节点体系结构。

This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are:

该扩展键传输发送它的节点的具体实现细节;在某些环境中,这些细节可能被认为是敏感的。例如,如果已知某个软件或固件版本存在安全漏洞,则可能不希望通过此密钥宣布该版本的存在。针对这一安全问题的对策是:

a) sending less detailed information in the key values,

a) 在键值中发送不太详细的信息,

b) not sending the extension key, or

b) 未发送扩展密钥,或

c) using IPsec ([RFC4303]) to provide confidentiality for the iSCSI connection on which the key is sent.

c) 使用IPsec([RFC4303])为发送密钥的iSCSI连接提供机密性。

To support the first and second countermeasures, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. In addition, all implementations SHOULD provide an administrative mechanism to configure a verbosity level of the key value, thereby controlling the amount of information sent.

为了支持第一个和第二个对策,此扩展密钥的所有实现必须提供一个管理机制来禁用发送密钥。此外,所有实现都应该提供管理机制来配置键值的详细级别,从而控制发送的信息量。

For example, a lower verbosity level might enable transmission of node architecture component names only, but no version numbers. The choice of which countermeasure is most appropriate depends on the environment. However, sending less detailed information in the key values may be an acceptable countermeasure in many environments, since it provides a compromise between sending too much information and the other more complete countermeasures of not sending the key at all or using IPsec.

例如,较低的详细级别可能只允许传输节点体系结构组件名称,而不允许传输版本号。选择哪种对策最合适取决于环境。然而,在许多环境中,发送密钥值中不太详细的信息可能是一种可接受的对策,因为它在发送太多信息和根本不发送密钥或使用IPsec的其他更完整的对策之间提供了折衷。

In addition to security considerations involving transmission of the key contents, any logging method(s) used for the key values MUST keep the information secure from intruders. For all implementations, the requirements to address this security concern are as follows:

除了涉及密钥内容传输的安全注意事项外,用于密钥值的任何日志记录方法都必须确保信息的安全,以防入侵者。对于所有实现,解决此安全问题的要求如下:

a) Display of the log MUST only be possible with administrative rights to the node.

a) 只有对节点具有管理权限时才能显示日志。

b) Options to disable logging to disk and to keep logs for a fixed duration SHOULD be provided.

b) 应提供禁用磁盘日志记录和将日志保留固定时间的选项。

Finally, it is important to note that different nodes may have different levels of risk, and these differences may affect the implementation. The components of risk include assets, threats, and vulnerabilities. Consider the following example iSCSI nodes, which demonstrate differences in assets and vulnerabilities of the nodes, and, as a result, differences in implementation:

最后,需要注意的是,不同的节点可能具有不同的风险级别,这些差异可能会影响实现。风险的组成部分包括资产、威胁和漏洞。考虑下面的示例iSCSI节点,它演示了节点的资产和漏洞的差异,因此,实现中的差异:

a) One iSCSI target based on a special-purpose operating system: Since the iSCSI target controls access to the data storage containing company assets, the asset level is seen as very high. Also, because of the special-purpose operating system, in which vulnerabilities are less well known, the vulnerability level is viewed as low.

a) 一个基于专用操作系统的iSCSI目标:由于iSCSI目标控制对包含公司资产的数据存储的访问,因此资产级别被视为非常高。此外,由于专用操作系统的漏洞不太为人所知,因此漏洞级别被视为较低。

b) Multiple iSCSI initiators in a blade farm, each running a general-purpose operating system: The asset level of each node is viewed as low, since blades are replaceable and low cost. However, the vulnerability level is viewed as high, since there may be many well-known vulnerabilities to that general-purpose operating system. For this target, an appropriate implementation might be the logging of received key values but no transmission of the key. For this initiator, an appropriate implementation might be transmission of the key but no logging of received key values.

b) 刀片服务器场中有多个iSCSI启动器,每个启动器都运行一个通用操作系统:每个节点的资产级别被视为较低,因为刀片是可更换的且成本较低。但是,由于该通用操作系统可能存在许多众所周知的漏洞,因此漏洞级别被视为很高。对于这个目标,一个合适的实现可能是记录接收到的键值,但不传输键值。对于该启动器,适当的实现可能是传输密钥,但不记录接收到的密钥值。

9.5. SCSI Access Control Considerations
9.5. SCSI访问控制注意事项

iSCSI is a SCSI transport protocol and as such does not apply any access controls on SCSI-level operations such as SCSI task management functions (e.g., LU reset; see Section 11.5.1). SCSI-level access controls (e.g., ACCESS CONTROL OUT; see [SPC3]) have to be appropriately deployed in practice to address SCSI-level security considerations, in addition to security via iSCSI connection and packet protection mechanisms that were already discussed in preceding sections.

iSCSI是一种SCSI传输协议,因此不会对SCSI级别的操作应用任何访问控制,例如SCSI任务管理功能(例如LU重置;请参阅第11.5.1节)。SCSI级别的访问控制(例如,访问控制输出;请参见[SPC3])在实践中必须适当部署,以解决SCSI级别的安全问题,此外,通过iSCSI连接和数据包保护机制实现的安全问题已在前面章节中讨论过。

10. Notes to Implementers
10. 实施者须知

This section notes some of the performance and reliability considerations of the iSCSI protocol. This protocol was designed to allow efficient silicon and software implementations. The iSCSI task tag mechanism was designed to enable Direct Data Placement (DDP -- a DMA form) at the iSCSI level or lower.

本节将介绍iSCSI协议的一些性能和可靠性注意事项。该协议旨在实现高效的硅和软件实现。iSCSI任务标记机制旨在支持iSCSI级别或更低级别的直接数据放置(DDP——DMA形式)。

The guiding assumption made throughout the design of this protocol is that targets are resource constrained relative to initiators.

在整个协议设计过程中所做的指导性假设是,相对于启动器,目标是资源受限的。

Implementers are also advised to consider the implementation consequences of the iSCSI-to-SCSI mapping model as outlined in Section 4.4.3.

还建议实施者考虑ISCSI对SCSI映射模型的执行后果,如4.4.3节中概述的。

10.1. Multiple Network Adapters
10.1. 多个网络适配器

The iSCSI protocol allows multiple connections, not all of which need to go over the same network adapter. If multiple network connections are to be utilized with hardware support, the iSCSI protocol command-data-status allegiance to one TCP connection ensures that there is no need to replicate information across network adapters or otherwise require them to cooperate.

iSCSI协议允许多个连接,而不是所有连接都需要通过同一网络适配器。如果要在硬件支持的情况下使用多个网络连接,iSCSI协议命令“数据状态”与一个TCP连接的一致性可确保无需跨网络适配器复制信息或以其他方式要求它们协作。

However, some task management commands may require some loose form of cooperation or replication at least on the target.

但是,某些任务管理命令可能需要某种松散形式的协作或复制,至少在目标系统上是这样。

10.1.1. Conservative Reuse of ISIDs
10.1.1. ISID的保守重用

Historically, the SCSI model (and implementations and applications based on that model) has assumed that SCSI ports are static, physical entities. Recent extensions to the SCSI model have taken advantage of persistent worldwide unique names for these ports. In iSCSI, however, the SCSI initiator ports are the endpoints of dynamically created sessions, so the presumptions of "static and physical" do not apply. In any case, the "model" sections (particularly,

过去,SCSI模型(以及基于该模型的实现和应用程序)假定SCSI端口是静态的物理实体。SCSI模型的最新扩展利用了这些端口的持久全球唯一名称。但是,在iSCSI中,SCSI启动器端口是动态创建会话的端点,因此“静态和物理”的假设不适用。在任何情况下,“模型”部分(特别是,

Section 4.4.1) provide for persistent, reusable names for the iSCSI-type SCSI initiator ports even though there does not need to be any physical entity bound to these names.

第4.4.1)节)为iSCSI类型SCSI启动器端口提供了持久的、可重用的名称,即使这些名称不需要绑定任何物理实体。

To both minimize the disruption of legacy applications and better facilitate the SCSI features that rely on persistent names for SCSI ports, iSCSI implementations SHOULD attempt to provide a stable presentation of SCSI initiator ports (both to the upper OS layers and the targets to which they connect). This can be achieved in an initiator implementation by conservatively reusing ISIDs. In other words, the same ISID should be used in the login process to multiple target portal groups (of the same iSCSI target or different iSCSI targets). The ISID RULE (Section 4.4.3) only prohibits reuse to the same target portal group. It does not "preclude" reuse to other target portal groups. The principle of conservative reuse "encourages" reuse to other target portal groups. When a SCSI target device sees the same (InitiatorName, ISID) pair in different sessions to different target portal groups, it can identify the underlying SCSI initiator port on each session as the same SCSI port. In effect, it can recognize multiple paths from the same source.

为了最大限度地减少对传统应用程序的中断,并更好地促进依赖SCSI端口持久名称的SCSI功能,iSCSI实施应尝试提供SCSI启动器端口的稳定表示(向上层操作系统层及其连接的目标)。这可以通过保守地重用ISID在启动器实现中实现。换句话说,在登录到多个目标门户组(相同iSCSI目标或不同iSCSI目标)的过程中,应使用相同的ISID。ISID规则(第4.4.3节)仅禁止对同一目标门户组进行重用。它并不“排除”对其他目标门户组的重用。保守重用原则“鼓励”对其他目标门户组进行重用。当SCSI目标设备在不同的会话中看到同一对(InitiatorName,ISID)到不同的目标门户组时,它可以将每个会话上的底层SCSI启动器端口标识为相同的SCSI端口。实际上,它可以识别来自同一源的多条路径。

10.1.2. iSCSI Name, ISID, and TPGT Use
10.1.2. iSCSI名称、ISID和TPGT使用

The designers of the iSCSI protocol are aware that legacy SCSI transports rely on initiator identity to assign access to storage resources. Although newer techniques that simplify access control are available, support for configuration and authentication schemes that are based on initiator identity is deemed important in order to support legacy systems and administration software. iSCSI thus supports the notion that it should be possible to assign access to storage resources based on "initiator device" identity.

iSCSI协议的设计者知道,传统SCSI传输依赖于启动器标识来分配对存储资源的访问。虽然可以使用简化访问控制的较新技术,但为了支持遗留系统和管理软件,对基于启动器身份的配置和身份验证方案的支持被认为是重要的。因此,iSCSI支持这样一种概念,即应该能够根据“启动器设备”标识分配对存储资源的访问。

When there are multiple hardware or software components coordinated as a single iSCSI node, there must be some (logical) entity that represents the iSCSI node that makes the iSCSI Node Name available to all components involved in session creation and login. Similarly, this entity that represents the iSCSI node must be able to coordinate session identifier resources (the ISID for initiators) to enforce both the ISID RULE and the TSIH RULE (see Section 4.4.3).

当有多个硬件或软件组件协调为单个iSCSI节点时,必须有某个(逻辑)实体表示iSCSI节点,使iSCSI节点名称可用于会话创建和登录中涉及的所有组件。类似地,此表示iSCSI节点的实体必须能够协调会话标识符资源(启动器的ISID),以实施ISID规则和TSIH规则(请参见第4.4.3节)。

For targets, because of the closed environment, implementation of this entity should be straightforward. However, vendors of iSCSI hardware (e.g., NICs or HBAs) intended for targets SHOULD provide mechanisms for configuration of the iSCSI Node Name across the portal groups instantiated by multiple instances of these components within a target.

对于目标,由于环境封闭,该实体的实现应该简单明了。但是,面向目标的iSCSI硬件(如NIC或HBA)供应商应提供跨门户组配置iSCSI节点名称的机制,门户组由目标中这些组件的多个实例实例化。

However, complex targets making use of multiple Target Portal Group Tags may reconfigure them to achieve various quality goals. The initiators have two mechanisms at their disposal to discover and/or check reconfiguring targets -- the Discovery session type and a key returned by the target during login to confirm the TPGT. An initiator should attempt to "rediscover" the target configuration whenever a session is terminated unexpectedly.

但是,使用多个目标门户组标记的复杂目标可能会重新配置它们以实现各种质量目标。启动器有两种机制可用于发现和/或检查重新配置的目标——发现会话类型和目标在登录期间返回的密钥,以确认TPGT。每当会话意外终止时,启动器应尝试“重新发现”目标配置。

For initiators, in the long term, it is expected that operating system vendors will take on the role of this entity and provide standard APIs that can inform components of their iSCSI Node Name and can configure and/or coordinate ISID allocation, use, and reuse.

对于启动器,从长远来看,预计操作系统供应商将承担此实体的角色,并提供标准API,这些API可以通知组件其iSCSI节点名称,并可以配置和/或协调ISID分配、使用和重用。

Recognizing that such initiator APIs are not available today, other implementations of the role of this entity are possible. For example, a human may instantiate the (common) node name as part of the installation process of each iSCSI component involved in session creation and login. This may be done by pointing the component to either a vendor-specific location for this datum or a system-wide location. The structure of the ISID namespace (see Section 11.12.5 and [RFC3721]) facilitates implementation of the ISID coordination by allowing each component vendor to independently (of other vendor's components) coordinate allocation, use, and reuse of its own partition of the ISID namespace in a vendor-specific manner. Partitioning of the ISID namespace within initiator portal groups managed by that vendor allows each such initiator portal group to act independently of all other portal groups when selecting an ISID for a login; this facilitates enforcement of the ISID RULE (see Section 4.4.3) at the initiator.

认识到目前还没有此类启动器API,可以实现该实体角色的其他实现。例如,在会话创建和登录所涉及的每个iSCSI组件的安装过程中,人员可以实例化(公共)节点名称。这可以通过将部件指向该基准的供应商特定位置或系统范围内的位置来实现。ISID名称空间的结构(见第11.12.5节和[RFC3721])通过允许每个组件供应商以特定于供应商的方式(独立于其他供应商的组件)协调其自身ISID名称空间分区的分配、使用和重用,促进了ISID协调的实施。在该供应商管理的发起方门户组内对ISID命名空间进行分区,允许每个此类发起方门户组在选择ISID进行登录时独立于所有其他门户组进行操作;这有助于在发起方实施ISID规则(见第4.4.3节)。

A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in initiators MUST implement a mechanism for configuring the iSCSI Node Name. Vendors and administrators must ensure that iSCSI Node Names are worldwide unique. It is therefore important that when one chooses to reuse the iSCSI Node Name of a disabled unit one does not reassign that name to the original unit unless its worldwide uniqueness can be ascertained again.

打算在启动器中使用的iSCSI硬件(如NIC或HBA)的供应商必须实施配置iSCSI节点名称的机制。供应商和管理员必须确保iSCSI节点名称在全球范围内是唯一的。因此,重要的是,如果选择重用禁用单元的iSCSI节点名称,则不要将该名称重新分配给原始单元,除非可以再次确定其全球唯一性。

In addition, a vendor of iSCSI hardware must implement a mechanism to configure and/or coordinate ISIDs for all sessions managed by multiple instances of that hardware within a given iSCSI node. Such configuration might be either permanently preassigned at the factory (in a necessarily globally unique way), statically assigned (e.g., partitioned across all the NICs at initialization in a locally unique way), or dynamically assigned (e.g., on-line allocator, also in a locally unique way). In the latter two cases, the configuration may

此外,iSCSI硬件供应商必须实施一种机制,为给定iSCSI节点内由该硬件的多个实例管理的所有会话配置和/或协调ISID。此类配置可以在工厂永久预先分配(以必要的全局唯一方式)、静态分配(例如,在初始化时以本地唯一方式在所有NIC之间分区)或动态分配(例如,在线分配器,也以本地唯一方式)。在后两种情况下,配置可能会发生变化

be via public APIs (perhaps driven by an independent vendor's software, such as the OS vendor) or private APIs driven by the vendor's own software.

可以通过公共API(可能由独立供应商的软件驱动,如操作系统供应商)或由供应商自己的软件驱动的私有API。

The process of name assignment and coordination has to be as encompassing and automated as possible, as years of legacy usage have shown that it is highly error-prone. It should be mentioned that today SCSI has alternative schemes of access control that can be used by all transports, and their security is not dependent on strict naming coordination.

名称分配和协调过程必须尽可能全面和自动化,因为多年的遗留使用表明它极易出错。应该提到的是,现在SCSI有可供所有传输使用的访问控制替代方案,它们的安全性不依赖于严格的命名协调。

10.2. Autosense and Auto Contingent Allegiance (ACA)
10.2. 自动感知和自动或有效忠(ACA)

"Autosense" refers to the automatic return of sense data to the initiator in cases where a command did not complete successfully. iSCSI initiators and targets MUST support and use Autosense.

“自动感知”是指在命令未成功完成的情况下,自动将感知数据返回到启动器。iSCSI启动器和目标必须支持并使用Autosense。

ACA helps preserve ordered command execution in the presence of errors. As there can be many commands in-flight between an initiator and a target, SCSI initiator functionality in some operating systems depends on ACA to enforce ordered command execution during error recovery, and hence iSCSI initiator implementations for those operating systems need to support ACA. In order to support error recovery for these operating systems and iSCSI initiators, iSCSI targets SHOULD support ACA.

ACA有助于在出现错误时保持命令的有序执行。由于启动器和目标之间可能有许多命令在运行,因此某些操作系统中的SCSI启动器功能依赖于ACA在错误恢复期间强制执行有序的命令,因此这些操作系统的iSCSI启动器实施需要支持ACA。为了支持这些操作系统和iSCSI启动器的错误恢复,iSCSI目标应支持ACA。

10.3. iSCSI Timeouts
10.3. iSCSI超时

iSCSI recovery actions are often dependent on iSCSI timeouts being recognized and acted upon before SCSI timeouts. Determining the right timeouts to use for various iSCSI actions (command acknowledgments expected, status acknowledgments, etc.) is very much dependent on infrastructure (e.g., hardware, links, TCP/IP stack, iSCSI driver). As a guide, the implementer may use an average NOP-Out/NOP-In turnaround delay multiplied by a "safety factor" (e.g., 4) as a good estimate for the basic delay of the iSCSI stack for a given connection. The safety factor should account for network load variability. For connection teardown, the implementer may want to also consider TCP common practice for the given infrastructure.

iSCSI恢复操作通常取决于在SCSI超时之前识别和执行的iSCSI超时。确定用于各种iSCSI操作(预期的命令确认、状态确认等)的正确超时在很大程度上取决于基础结构(例如,硬件、链路、TCP/IP堆栈、iSCSI驱动程序)。作为指导,实施者可以使用平均NOP Out/NOP In周转延迟乘以“安全系数”(例如,4)作为给定连接的iSCSI堆栈基本延迟的良好估计。安全系数应考虑网络负载的可变性。对于连接拆卸,实现者可能也想考虑TCP对给定基础设施的共同实践。

Text negotiations MAY also be subject to either time limits or limits in the number of exchanges. Those limits SHOULD be generous enough to avoid affecting interoperability (e.g., allowing each key to be negotiated on a separate exchange).

文本谈判也可能受到时间限制或交流次数限制的限制。这些限制应足够宽松,以避免影响互操作性(例如,允许在单独的交换上协商每个密钥)。

The relationship between iSCSI timeouts and SCSI timeouts should also be considered. SCSI timeouts should be longer than iSCSI timeouts plus the time required for iSCSI recovery whenever iSCSI recovery is

还应考虑iSCSI超时和SCSI超时之间的关系。SCSI超时时间应长于iSCSI超时时间加上iSCSI恢复所需的时间

planned. Alternatively, an implementer may choose to interlock iSCSI timeouts and recovery with SCSI timeouts so that SCSI recovery will become active only where iSCSI is not planned to, or failed to, recover.

计划。或者,实施者可以选择将iSCSI超时和恢复与SCSI超时联锁,以便只有在iSCSI未计划恢复或无法恢复的情况下,SCSI恢复才会处于活动状态。

The implementer may also want to consider the interaction between various iSCSI exception events -- such as a digest failure -- and subsequent timeouts. When iSCSI error recovery is active, a digest failure is likely to result in discovering a missing command or data PDU. In these cases, an implementer may want to lower the timeout values to enable faster initiation for recovery procedures.

实现者可能还想考虑各种ISCSI异常事件之间的交互——例如摘要故障——以及随后的超时。当iSCSI错误恢复处于活动状态时,摘要故障可能会导致发现丢失的命令或数据PDU。在这些情况下,实现者可能希望降低超时值,以便更快地启动恢复过程。

10.4. Command Retry and Cleaning Old Command Instances
10.4. 命令重试并清理旧的命令实例

To avoid having old, retried command instances appear in a valid command window after a command sequence number wraparound, the protocol requires (see Section 4.2.2.1) that on every connection on which a retry has been issued a non-immediate command be issued and acknowledged within an interval of 2**31 - 1 commands from the CmdSN of the retried command. This requirement can be fulfilled by an implementation in several ways.

为避免在命令序列号环绕后,旧的重试命令实例出现在有效的命令窗口中,协议要求(见第4.2.2.1节)在已发出重试的每个连接上,将在重试命令的CmdSN的2**31-1个命令间隔内发出并确认一个非立即命令。这一要求可以通过多种方式实现。

The simplest technique to use is to send a (non-retry) non-immediate SCSI command (or a NOP if no SCSI command is available for a while) after every command retry on the connection on which the retry was attempted. Because errors are deemed rare events, this technique is probably the most effective, as it does not involve additional checks at the initiator when issuing commands.

最简单的方法是在尝试重试的连接上的每个命令重试后,发送(非重试)非立即SCSI命令(如果暂时没有可用的SCSI命令,则发送NOP)。因为错误被认为是罕见的事件,所以这种技术可能是最有效的,因为它在发出命令时不涉及启动器的额外检查。

10.5. Sync and Steering Layer, and Performance
10.5. 同步和控制层,以及性能

While a Sync and Steering layer is optional, an initiator/target that does not have it working against a target/initiator that demands sync and steering may experience performance degradation caused by packet reordering and loss. Providing a sync and steering mechanism is recommended for all high-speed implementations.

虽然同步和引导层是可选的,但没有同步和引导层的启动器/目标与需要同步和引导的目标/启动器协同工作时,可能会因数据包重新排序和丢失而导致性能下降。对于所有高速实施,建议提供同步和转向机制。

10.6. Considerations for State-Dependent Devices and Long-Lasting SCSI Operations

10.6. 状态相关设备和持久SCSI操作的注意事项

Sequential access devices operate on the principle that the position of the device is based on the last command processed. As such, command processing order, and knowledge of whether or not the previous command was processed, are of the utmost importance to maintain data integrity. For example, inadvertent retries of SCSI commands when it is not known if the previous SCSI command was processed is a potential data integrity risk.

顺序存取设备的工作原理是设备的位置基于最后处理的命令。因此,命令处理顺序以及是否处理了前一个命令的知识对于维护数据完整性至关重要。例如,在不知道是否处理了以前的SCSI命令时,无意中重试SCSI命令可能会带来数据完整性风险。

For a sequential access device, consider the scenario in which a SCSI SPACE command to backspace one filemark is issued and then reissued due to no status received for the command. If the first SPACE command was actually processed, the reissued SPACE command, if processed, will cause the position to change. Thus, a subsequent write operation will write data to the wrong position, and any previous data at that position will be overwritten.

对于顺序访问设备,考虑一个场景,其中SCSI空间命令发出回退一个文件框,然后由于没有接收到命令的状态而重新发布。如果实际处理了第一个SPACE命令,则重新发出的SPACE命令(如果已处理)将导致位置更改。因此,后续的写入操作会将数据写入错误的位置,并且该位置的任何先前数据都将被覆盖。

For a medium changer device, consider the scenario in which an EXCHANGE MEDIUM command (the SOURCE ADDRESS and DESTINATION ADDRESS are the same, thus performing a swap) is issued and then reissued due to no status received for the command. If the first EXCHANGE MEDIUM command was actually processed, the reissued EXCHANGE MEDIUM command, if processed, will perform the swap again. The net effect is that no swap was performed, thus putting data integrity at risk.

对于介质交换设备,考虑交换媒体命令(源地址和目的地址相同,因此执行交换)的情况,然后由于没有接收到命令的状态而重新发布。如果实际处理了第一个EXCHANGE介质命令,则重新发出的EXCHANGE介质命令(如果已处理)将再次执行交换。其净影响是没有进行交换,从而使数据完整性面临风险。

All commands that change the state of the device (e.g., SPACE commands for sequential access devices and EXCHANGE MEDIUM commands for medium changer devices) MUST be issued as non-immediate commands for deterministic and ordered delivery to iSCSI targets.

所有更改设备状态的命令(例如,用于顺序访问设备的空间命令和用于介质转换器设备的交换介质命令)必须作为非即时命令发出,以确定和有序地传送到iSCSI目标。

For many of those state-changing commands, the execution model also assumes that the command is executed exactly once. Devices implementing READ POSITION and LOCATE provide a means for SCSI-level command recovery, and new tape-class devices should support those commands. In their absence, a retry at the SCSI level is difficult, and error recovery at the iSCSI level is advisable.

对于许多改变状态的命令,执行模型还假设命令只执行一次。实现读取位置和定位的设备提供了SCSI级命令恢复的方法,新的磁带类设备应该支持这些命令。如果没有它们,则很难在SCSI级别重试,建议在iSCSI级别进行错误恢复。

Devices operating on long-latency delivery subsystems and performing long-lasting SCSI operations may need mechanisms that enable connection replacement while commands are running (e.g., during an extended copy operation).

在长延迟交付子系统上运行并执行长时间SCSI操作的设备可能需要在命令运行时(例如,在扩展复制操作期间)启用连接替换的机制。

10.6.1. Determining the Proper ErrorRecoveryLevel
10.6.1. 确定正确的ErrorRecoveryLevel

The implementation and use of a specific ErrorRecoveryLevel should be determined based on the deployment scenarios of a given iSCSI implementation. Generally, the following factors must be considered before deciding on the proper level of recovery:

特定ErrorRecoveryLevel的实现和使用应根据给定iSCSI实现的部署场景确定。通常,在决定适当的回收水平之前,必须考虑以下因素:

a) Application resilience to I/O failures.

a) 应用程序对I/O故障的恢复能力。

b) Required level of availability in the face of transport connection failures.

b) 面临传输连接故障时所需的可用性级别。

c) Probability of transport-layer "checksum escape" (message error undetected by TCP checksum -- see [RFC3385] for related discussion). This in turn decides the iSCSI digest failure frequency and thus the criticality of iSCSI-level error recovery. The details of estimating this probability are outside the scope of this document.

c) 传输层“校验和转义”的概率(TCP校验和未检测到的消息错误——相关讨论请参见[RFC3385])。这进而决定了iSCSI摘要故障频率,从而决定了iSCSI级别错误恢复的重要性。估计该概率的详细信息不在本文件范围内。

A consideration of the above factors for SCSI tape devices as an example suggests that implementations SHOULD use ErrorRecoveryLevel=1 when transport connection failure is not a concern and SCSI-level recovery is unavailable, and ErrorRecoveryLevel=2 when there is a high likelihood of connection failure during a backup/retrieval.

以SCSI磁带设备的上述因素为例,建议在传输连接故障不是问题且SCSI级别恢复不可用时,实施应使用ErrorRecoveryLevel=1;在备份/检索过程中连接故障的可能性很高时,实施应使用ErrorRecoveryLevel=2。

For extended copy operations, implementations SHOULD use ErrorRecoveryLevel=2 whenever there is a relatively high likelihood of connection failure.

对于扩展复制操作,只要连接失败的可能性相对较高,实现就应该使用ErrorRecoveryLevel=2。

10.7. Multi-Task Abort Implementation Considerations
10.7. 多任务中止实现注意事项

Multi-task abort operations are typically issued in emergencies, such as clearing a device lock-up, HA failover/failback, etc. In these circumstances, it is desirable to rapidly go through the error-handling process as opposed to the target waiting on multiple third-party initiators that may not even be functional anymore -- especially if this emergency is triggered because of one such initiator failure. Therefore, both iSCSI target and initiator implementations SHOULD support FastAbort multi-task abort semantics (Section 4.2.3.4).

多任务中止操作通常在紧急情况下发出,如清除设备锁定、HA故障切换/回切等。在这些情况下,希望快速完成错误处理过程,而不是让目标等待多个第三方启动器,这些启动器甚至可能不再起作用——特别是如果由于其中一个启动器故障而触发此紧急情况。因此,iSCSI目标和启动器实施都应支持FastAbort多任务中止语义(第4.2.3.4节)。

Note that in both standard semantics (Section 4.2.3.3) and FastAbort semantics (Section 4.2.3.4) there may be outstanding data transfers even after the TMF completion is reported on the issuing session. In the case of iSCSI/iSER [RFC7145], these would be tagged data transfers for STags not owned by any active tasks. Whether or not real buffers support these data transfers is implementation dependent. However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases. A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-Out sequences (Section 4.2.3.3) or NOP-Out acknowledgments (Section 4.2.3.4) so as to reclaim the associated buffer, STag, and TTT resources as appropriate.

请注意,在标准语义(第4.2.3.3节)和FastAbort语义(第4.2.3.4节)中,即使在发布会话上报告TMF完成后,也可能存在未完成的数据传输。在iSCSI/iSER[RFC7145]的情况下,这些将被标记为不属于任何活动任务的STAG的数据传输。实际缓冲区是否支持这些数据传输取决于实现。但是,在任何情况下,目标iSCSI层都必须以静默方式放弃逻辑上的数据传输。在实现定义的内部超时上,目标还可以选择丢弃其未接收到预期数据输出序列(第4.2.3.3节)或NOP输出确认(第4.2.3.4节)的连接,以便酌情回收相关的缓冲区、STag和TTT资源。

11. iSCSI PDU Formats
11. iSCSI PDU格式

All multi-byte integers that are specified in formats defined in this document are to be represented in network byte order (i.e., big-endian). Any field that appears in this document assumes that the most significant byte is the lowest numbered byte and the most significant bit (within byte or field) is the lowest numbered bit unless specified otherwise.

以本文件中定义的格式指定的所有多字节整数均应以网络字节顺序(即big-endian)表示。除非另有规定,否则本文档中出现的任何字段都假定最高有效字节是编号最低的字节,最高有效位(在字节或字段中)是编号最低的位。

Any compliant sender MUST set all bits not defined and all reserved fields to 0, unless specified otherwise. Any compliant receiver MUST ignore any bit not defined and all reserved fields unless specified otherwise. Receipt of reserved code values in defined fields MUST be reported as a protocol error.

除非另有规定,否则任何兼容发送方必须将所有未定义的位和所有保留字段设置为0。除非另有规定,否则任何兼容接收器必须忽略任何未定义的位和所有保留字段。接收到定义字段中的保留代码值时,必须报告为协议错误。

Reserved fields are marked by the word "reserved", some abbreviation of "reserved", or by "." for individual bits when no other form of marking is technically feasible.

保留字段用“Reserved”(保留)一词、“Reserved”(保留)的缩写,或在技术上不可行的情况下,用“.”标记单个位。

11.1. iSCSI PDU Length and Padding
11.1. iSCSI PDU长度和填充

iSCSI PDUs are padded to the closest integer number of 4-byte words. The padding bytes SHOULD be sent as 0.

iSCSI PDU填充到最接近的4字节字整数。填充字节应作为0发送。

11.2. PDU Template, Header, and Opcodes
11.2. PDU模板、标头和操作码

All iSCSI PDUs have one or more header segments and, optionally, a data segment. After the entire header segment group, a header digest MAY follow. The data segment MAY also be followed by a data digest.

所有iSCSI PDU都有一个或多个标头段和一个数据段(可选)。在整个标题段组之后,可能会出现标题摘要。数据段后面还可以是数据摘要。

The Basic Header Segment (BHS) is the first segment in all of the iSCSI PDUs. The BHS is a fixed-length 48-byte header segment. It MAY be followed by Additional Header Segments (AHS), a Header-Digest, a Data Segment, and/or a Data-Digest.

基本头段(BHS)是所有iSCSI PDU中的第一段。BHS是一个固定长度的48字节报头段。它后面可以是附加的报头段(AH)、报头摘要、数据段和/或数据摘要。

The overall structure of an iSCSI PDU is as follows:

iSCSI PDU的总体结构如下所示:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0/ Basic Header Segment (BHS)                                    /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48/ Additional Header Segment 1 (AHS) (optional)                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
     / Additional Header Segment 2 (AHS) (optional)                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
     +---------------+---------------+---------------+---------------+
     / Additional Header Segment n (AHS) (optional)                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    k/ Header-Digest (optional)                                      /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    l/ Data Segment (optional)                                       /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    m/ Data-Digest (optional)                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0/ Basic Header Segment (BHS)                                    /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48/ Additional Header Segment 1 (AHS) (optional)                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
     / Additional Header Segment 2 (AHS) (optional)                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
     +---------------+---------------+---------------+---------------+
     / Additional Header Segment n (AHS) (optional)                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    k/ Header-Digest (optional)                                      /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    l/ Data Segment (optional)                                       /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    m/ Data-Digest (optional)                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
        

All PDU segments and digests are padded to the closest integer number of 4-byte words. For example, all PDU segments and digests start at a 4-byte word boundary, and the padding ranges from 0 to 3 bytes. The padding bytes SHOULD be sent as 0.

所有PDU段和摘要都填充到最接近的4字节字整数。例如,所有PDU段和摘要都从4字节的字边界开始,填充范围为0到3字节。填充字节应作为0发送。

iSCSI Response PDUs do not have AH Segments.

iSCSI响应PDU没有AH段。

11.2.1. Basic Header Segment (BHS)
11.2.1. 基本头段(BHS)

The BHS is 48 bytes long. The Opcode and DataSegmentLength fields appear in all iSCSI PDUs. In addition, when used, the Initiator Task Tag and Logical Unit Number always appear in the same location in the header.

行李处理系统的长度为48字节。操作码和DataSegmentLength字段出现在所有iSCSI PDU中。此外,使用时,启动器任务标记和逻辑单元号始终显示在标头中的同一位置。

The format of the BHS is:

行李处理系统的格式为:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|I| Opcode    |F| Opcode-specific fields                      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Opcode-specific fields                                 |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20/ Opcode-specific fields                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|I| Opcode    |F| Opcode-specific fields                      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Opcode-specific fields                                 |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20/ Opcode-specific fields                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48
        
11.2.1.1. I (Immediate) Bit
11.2.1.1. I(立即)位

For Request PDUs, the I bit set to 1 is an immediate delivery marker.

对于请求PDU,设置为1的I位是立即传递标记。

11.2.1.2. Opcode
11.2.1.2. 操作码

The Opcode indicates the type of iSCSI PDU the header encapsulates.

操作码指示标头封装的iSCSI PDU的类型。

The Opcodes are divided into two categories: initiator Opcodes and target Opcodes. Initiator Opcodes are in PDUs sent by the initiator (Request PDUs). Target Opcodes are in PDUs sent by the target (Response PDUs).

操作码分为两类:启动器操作码和目标操作码。启动器操作码位于启动器发送的PDU中(请求PDU)。目标操作码位于目标发送的PDU中(响应PDU)。

Initiators MUST NOT use target Opcodes, and targets MUST NOT use initiator Opcodes.

启动器不得使用目标操作码,目标也不得使用启动器操作码。

Initiator Opcodes defined in this specification are:

本规范中定义的启动器操作码为:

0x00 NOP-Out

0x00无输出

0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block)

0x01 SCSI命令(封装SCSI命令描述符块)

0x02 SCSI Task Management Function Request

0x02 SCSI任务管理功能请求

0x03 Login Request

0x03登录请求

0x04 Text Request

0x04文本请求

0x05 SCSI Data-Out (for write operations)

0x05 SCSI数据输出(用于写操作)

0x06 Logout Request

0x06注销请求

0x10 SNACK Request

0x10零食请求

0x1c-0x1e Vendor-specific codes

0x1c-0x1e供应商特定代码

Target Opcodes are:

目标操作码是:

0x20 NOP-In

0x20 NOP输入

0x21 SCSI Response - contains SCSI status and possibly sense information or other response information

0x21 SCSI响应-包含SCSI状态和可能的检测信息或其他响应信息

0x22 SCSI Task Management Function Response

0x22 SCSI任务管理功能响应

0x23 Login Response

0x23登录响应

0x24 Text Response

0x24文本响应

0x25 SCSI Data-In (for read operations)

0x25 SCSI数据输入(用于读取操作)

0x26 Logout Response

0x26注销响应

0x31 Ready To Transfer (R2T) - sent by target when it is ready to receive data

0x31准备传输(R2T)-由目标在准备接收数据时发送

0x32 Asynchronous Message - sent by target to indicate certain special conditions

0x32异步消息-由目标发送以指示某些特殊情况

0x3c-0x3e Vendor-specific codes

0x3c-0x3e供应商特定代码

0x3f Reject

0x3f拒绝

All other Opcodes are unassigned.

所有其他操作码均未分配。

11.2.1.3. F (Final) Bit
11.2.1.3. F(最终)位

When set to 1 it indicates the final (or only) PDU of a sequence.

当设置为1时,表示序列的最终(或唯一)PDU。

11.2.1.4. Opcode-Specific Fields
11.2.1.4. 操作码特定字段

These fields have different meanings for different Opcode types.

对于不同的操作码类型,这些字段具有不同的含义。

11.2.1.5. TotalAHSLength
11.2.1.5. 总长度

This is the total length of all AHS header segments in units of 4-byte words, including padding, if any.

这是所有AHS头段的总长度,以4字节字为单位,包括填充(如果有)。

The TotalAHSLength is only used in PDUs that have an AHS and MUST be 0 in all other PDUs.

TotalAHSLength仅在具有AHS的PDU中使用,并且在所有其他PDU中必须为0。

11.2.1.6. DataSegmentLength
11.2.1.6. 数据段长度

This is the data segment payload length in bytes (excluding padding). The DataSegmentLength MUST be 0 whenever the PDU has no data segment.

这是以字节为单位的数据段有效负载长度(不包括填充)。只要PDU没有数据段,DataSegmentLength就必须为0。

11.2.1.7. LUN
11.2.1.7. 伦

Some Opcodes operate on a specific LU. The Logical Unit Number (LUN) field identifies which LU. If the Opcode does not relate to a LU, this field is either ignored or may be used in an Opcode-specific way. The LUN field is 64 bits and should be formatted in accordance with [SAM2]. For example, LUN[0] from [SAM2] is BHS byte 8 and so on up to LUN[7] from [SAM2], which is BHS byte 15.

某些操作码在特定的LU上运行。逻辑单元号(LUN)字段标识哪个LU。如果操作码与LU不相关,则忽略此字段或以特定于操作码的方式使用此字段。LUN字段为64位,应按照[SAM2]进行格式化。例如,[SAM2]中的LUN[0]是BHS字节8,依此类推,直到[SAM2]中的LUN[7]是BHS字节15。

11.2.1.8. Initiator Task Tag
11.2.1.8. 启动器任务标记

The initiator assigns a task tag to each iSCSI task it issues. While a task exists, this tag MUST uniquely identify the task session-wide. SCSI may also use the Initiator Task Tag as part of the SCSI task identifier when the timespan during which an iSCSI Initiator Task Tag must be unique extends over the timespan during which a SCSI task tag must be unique. However, the iSCSI Initiator Task Tag must exist and be unique even for untagged SCSI commands.

启动器为其发出的每个iSCSI任务分配一个任务标记。当任务存在时,此标记必须唯一标识任务会话范围。当iSCSI启动器任务标记必须唯一的时间跨度扩展到SCSI任务标记必须唯一的时间跨度时,SCSI也可以将启动器任务标记用作SCSI任务标识符的一部分。但是,iSCSI启动器任务标记必须存在,并且即使对于未标记的SCSI命令也是唯一的。

An ITT value of 0xffffffff is reserved and MUST NOT be assigned for a task by the initiator. The only instance in which it may be seen on the wire is in a target-initiated NOP-In PDU (Section 11.19) and in the initiator response to that PDU, if necessary.

ITT值0xFFFFFF为保留值,且启动器不得为任务分配该值。在线路上可以看到的唯一实例是PDU中的目标启动NOP(第11.19节)和该PDU的启动器响应(如有必要)。

11.2.2. Additional Header Segment (AHS)
11.2.2. 附加标题段(AHS)

The general format of an AHS is:

AHS的一般格式为:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0| AHSLength                     | AHSType       | AHS-Specific  |
     +---------------+---------------+---------------+---------------+
    4/ AHS-Specific                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    x
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0| AHSLength                     | AHSType       | AHS-Specific  |
     +---------------+---------------+---------------+---------------+
    4/ AHS-Specific                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    x
        
11.2.2.1. AHSType
11.2.2.1. 阿什蒂佩

The AHSType field is coded as follows:

AHSType字段编码如下:

bit 0-1 - Reserved

位0-1-保留

bit 2-7 - AHS code

第2-7位-AHS代码

0 - Reserved

0-保留

1 - Extended CDB

1-扩展CDB

2 - Bidirectional Read Expected Data Transfer Length

2-双向读取预期数据传输长度

3 - 63 Reserved

3-63保留

11.2.2.2. AHSLength
11.2.2.2. AHSLength

This field contains the effective length in bytes of the AHS, excluding AHSType and AHSLength and padding, if any. The AHS is padded to the smallest integer number of 4-byte words (i.e., from 0 up to 3 padding bytes).

此字段包含AHS的有效长度(以字节为单位),不包括AHSType和AHSLENGHT以及填充(如果有)。AHS填充为4字节字的最小整数(即从0到3个填充字节)。

11.2.2.3. Extended CDB AHS
11.2.2.3. 扩展CDB AHS

The format of the Extended CDB AHS is:

扩展CDB AHS的格式为:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0| AHSLength (CDBLength - 15)    | 0x01          |  Reserved     |
     +---------------+---------------+---------------+---------------+
    4/ ExtendedCDB...+padding                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    x
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0| AHSLength (CDBLength - 15)    | 0x01          |  Reserved     |
     +---------------+---------------+---------------+---------------+
    4/ ExtendedCDB...+padding                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    x
        

This type of AHS MUST NOT be used if the CDBLength is less than 17.

如果CDBLength小于17,则不得使用此类AHS。

The length includes the reserved byte 3.

长度包括保留字节3。

11.2.2.4. Bidirectional Read Expected Data Transfer Length AHS
11.2.2.4. 双向读取预期数据传输长度AHS

The format of the Bidirectional Read Expected Data Transfer Length AHS is:

双向读取预期数据传输长度AHS的格式为:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0| AHSLength (0x0005)            | 0x02          | Reserved      |
     +---------------+---------------+---------------+---------------+
    4| Bidirectional Read Expected Data Transfer Length              |
     +---------------+---------------+---------------+---------------+
    8
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0| AHSLength (0x0005)            | 0x02          | Reserved      |
     +---------------+---------------+---------------+---------------+
    4| Bidirectional Read Expected Data Transfer Length              |
     +---------------+---------------+---------------+---------------+
    8
        
11.2.3. Header Digest and Data Digest
11.2.3. 标题摘要和数据摘要

Optional header and data digests protect the integrity of the header and data, respectively. The digests, if present, are located, respectively, after the header and PDU-specific data and cover, respectively, the header and the PDU data, each including the padding bytes, if any.

可选的头和数据摘要分别保护头和数据的完整性。摘要(如果存在)分别位于标头和PDU特定数据之后,并且分别位于标头和PDU数据之后,每个摘要都包括填充字节(如果有的话)。

The existence and type of digests are negotiated during the Login Phase.

摘要的存在和类型在登录阶段协商。

The separation of the header and data digests is useful in iSCSI routing applications, in which only the header changes when a message is forwarded. In this case, only the header digest should be recalculated.

头和数据摘要的分离在iSCSI路由应用程序中非常有用,在这种应用程序中,转发消息时只有头会更改。在这种情况下,只应重新计算标题摘要。

Digests are not included in data or header length fields.

摘要不包括在数据或标题长度字段中。

A zero-length Data Segment also implies a zero-length Data-Digest.

零长度数据段也意味着零长度数据摘要。

11.2.4. Data Segment
11.2.4. 数据段

The (optional) Data Segment contains PDU-associated data. Its payload effective length is provided in the BHS field -- DataSegmentLength. The Data Segment is also padded to an integer number of 4-byte words.

(可选)数据段包含与PDU关联的数据。其有效载荷有效长度在BHS字段--DataSegmentLength中提供。数据段也被填充为4字节字的整数。

11.3. SCSI Command
11.3. SCSI命令

The format of the SCSI Command PDU is:

SCSI命令PDU的格式为:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|I| 0x01      |F|R|W|. .|ATTR | Reserved                      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Logical Unit Number (LUN)                                     |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Expected Data Transfer Length                                 |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32/ SCSI Command Descriptor Block (CDB)                           /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48/ AHS (optional)                                                /
     +---------------+---------------+---------------+---------------+
    x/ Header-Digest (optional)                                      /
     +---------------+---------------+---------------+---------------+
    y/ (DataSegment, Command Data) (optional)                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    z/ Data-Digest (optional)                                        /
     +---------------+---------------+---------------+---------------+
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|I| 0x01      |F|R|W|. .|ATTR | Reserved                      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Logical Unit Number (LUN)                                     |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Expected Data Transfer Length                                 |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32/ SCSI Command Descriptor Block (CDB)                           /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48/ AHS (optional)                                                /
     +---------------+---------------+---------------+---------------+
    x/ Header-Digest (optional)                                      /
     +---------------+---------------+---------------+---------------+
    y/ (DataSegment, Command Data) (optional)                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    z/ Data-Digest (optional)                                        /
     +---------------+---------------+---------------+---------------+
        
11.3.1. Flags and Task Attributes (Byte 1)
11.3.1. 标志和任务属性(字节1)

The flags for a SCSI Command PDU are:

SCSI命令PDU的标志为:

bit 0 (F) is set to 1 when no unsolicited SCSI Data-Out PDUs follow this PDU. When F = 1 for a write and if Expected Data Transfer Length is larger than the DataSegmentLength, the target may solicit additional data through R2T.

当没有未经请求的SCSI数据输出PDU跟随此PDU时,位0(F)设置为1。当写入的F=1时,如果预期的数据传输长度大于DataSegmentLength,则目标可以通过R2T请求额外的数据。

bit 1 (R) is set to 1 when the command is expected to input data.

当命令预期输入数据时,位1(R)设置为1。

bit 2 (W) is set to 1 when the command is expected to output data.

当命令预期输出数据时,位2(W)设置为1。

bit 3-4 Reserved.

保留第3-4位。

bit 5-7 contains Task Attributes.

位5-7包含任务属性。

Task Attributes (ATTR) have one of the following integer values (see [SAM2] for details):

任务属性(ATTR)具有以下整数值之一(有关详细信息,请参阅[SAM2]):

0 - Untagged

0-未标记

1 - Simple

1-简单

2 - Ordered

2-有序

3 - Head of queue

3-列队队长

4 - ACA

4-ACA

5-7 - Reserved

5-7-保留

At least one of the W and F bits MUST be set to 1.

必须将W和F位中的至少一位设置为1。

Either or both of R and W MAY be 1 when the Expected Data Transfer Length and/or the Bidirectional Read Expected Data Transfer Length are 0, but they MUST NOT both be 0 when the Expected Data Transfer Length and/or Bidirectional Read Expected Data Transfer Length are not 0 (i.e., when some data transfer is expected, the transfer direction is indicated by the R and/or W bit).

当预期数据传输长度和/或双向读取预期数据传输长度为0时,R和W中的一个或两个可以为1,但当预期数据传输长度和/或双向读取预期数据传输长度不为0时,它们不能同时为0(即,当预期进行某些数据传输时,传输方向由R和/或W位指示)。

11.3.2. CmdSN - Command Sequence Number
11.3.2. CmdSN-命令序列号

The CmdSN enables ordered delivery across multiple connections in a single session.

CmdSN支持在单个会话中跨多个连接进行有序传递。

11.3.3. ExpStatSN
11.3.3. ExpStatSN

Command responses up to ExpStatSN - 1 (modulo 2**32) have been received (acknowledges status) on the connection.

已在连接上接收到ExpStatSN-1(模2**32)之前的命令响应(确认状态)。

11.3.4. Expected Data Transfer Length
11.3.4. 预期数据传输长度

For unidirectional operations, the Expected Data Transfer Length field contains the number of bytes of data involved in this SCSI operation. For a unidirectional write operation (W flag set to 1 and R flag set to 0), the initiator uses this field to specify the number of bytes of data it expects to transfer for this operation. For a unidirectional read operation (W flag set to 0 and R flag set to 1), the initiator uses this field to specify the number of bytes of data it expects the target to transfer to the initiator. It corresponds to the SAM-2 byte count.

对于单向操作,预期数据传输长度字段包含此SCSI操作中涉及的数据字节数。对于单向写入操作(W标志设置为1,R标志设置为0),启动器使用此字段指定它希望为此操作传输的数据字节数。对于单向读取操作(W标志设置为0,R标志设置为1),启动器使用此字段指定它希望目标传输到启动器的数据字节数。它对应于SAM-2字节计数。

For bidirectional operations (both R and W flags are set to 1), this field contains the number of data bytes involved in the write transfer. For bidirectional operations, an additional header segment MUST be present in the header sequence that indicates the Bidirectional Read Expected Data Transfer Length. The Expected Data Transfer Length field and the Bidirectional Read Expected Data Transfer Length field correspond to the SAM-2 byte count.

对于双向操作(R和W标志均设置为1),此字段包含写入传输中涉及的数据字节数。对于双向操作,报头序列中必须存在一个额外的报头段,用于指示双向读取预期的数据传输长度。预期数据传输长度字段和双向读取预期数据传输长度字段对应SAM-2字节计数。

If the Expected Data Transfer Length for a write and the length of the immediate data part that follows the command (if any) are the same, then no more data PDUs are expected to follow. In this case, the F bit MUST be set to 1.

如果写入的预期数据传输长度与该命令后面的立即数据部分(如果有)的长度相同,则预期不会有更多的数据PDU。在这种情况下,F位必须设置为1。

If the Expected Data Transfer Length is higher than the FirstBurstLength (the negotiated maximum amount of unsolicited data the target will accept), the initiator MUST send the maximum amount of unsolicited data OR ONLY the immediate data, if any.

如果预期数据传输长度高于FirstBurstLength(目标将接受的协商最大非请求数据量),则发起方必须发送最大非请求数据量或仅发送即时数据(如果有)。

Upon completion of a data transfer, the target informs the initiator (through residual counts) of how many bytes were actually processed (sent and/or received) by the target.

数据传输完成后,目标将通知启动器(通过剩余计数)目标实际处理(发送和/或接收)的字节数。

11.3.5. CDB - SCSI Command Descriptor Block
11.3.5. CDB-SCSI命令描述符块

There are 16 bytes in the CDB field to accommodate the commonly used CDBs. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS MUST be used to contain the CDB spillover.

CDB字段中有16个字节,用于容纳常用的CDB。每当CDB大于16字节时,必须使用扩展CDB AHS来控制CDB溢出。

11.3.6. Data Segment - Command Data
11.3.6. 数据段-命令数据

Some SCSI commands require additional parameter data to accompany the SCSI command. This data may be placed beyond the boundary of the iSCSI header in a data segment. Alternatively, user data (e.g., from a write operation) can be placed in the data segment (both cases are referred to as immediate data). These data are governed by the rules for solicited vs. unsolicited data outlined in Section 4.2.5.2.

某些SCSI命令需要额外的参数数据来伴随SCSI命令。此数据可能放置在数据段中iSCSI标头的边界之外。或者,用户数据(例如,来自写入操作的数据)可以放置在数据段中(这两种情况都称为即时数据)。这些数据受第4.2.5.2节中概述的请求与非请求数据规则的管辖。

11.4. SCSI Response
11.4. SCSI响应

The format of the SCSI Response PDU is:

SCSI响应PDU的格式为:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|.| 0x21      |1|. .|o|u|O|U|.| Response      | Status        |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Reserved                                                      |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| SNACK Tag or Reserved                                         |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36| ExpDataSN or Reserved                                         |
     +---------------+---------------+---------------+---------------+
   40| Bidirectional Read Residual Count or Reserved                 |
     +---------------+---------------+---------------+---------------+
   44| Residual Count or Reserved                                    |
     +---------------+---------------+---------------+---------------+
   48| Header-Digest (optional)                                      |
     +---------------+---------------+---------------+---------------+
     / Data Segment (optional)                                       /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
     | Data-Digest (optional)                                        |
     +---------------+---------------+---------------+---------------+
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|.| 0x21      |1|. .|o|u|O|U|.| Response      | Status        |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Reserved                                                      |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| SNACK Tag or Reserved                                         |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36| ExpDataSN or Reserved                                         |
     +---------------+---------------+---------------+---------------+
   40| Bidirectional Read Residual Count or Reserved                 |
     +---------------+---------------+---------------+---------------+
   44| Residual Count or Reserved                                    |
     +---------------+---------------+---------------+---------------+
   48| Header-Digest (optional)                                      |
     +---------------+---------------+---------------+---------------+
     / Data Segment (optional)                                       /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
     | Data-Digest (optional)                                        |
     +---------------+---------------+---------------+---------------+
        
11.4.1. Flags (Byte 1)
11.4.1. 标志(字节1)

bit 1-2 Reserved.

保留第1-2位。

bit 3 - (o) set for Bidirectional Read Residual Overflow. In this case, the Bidirectional Read Residual Count indicates the number of bytes that were not transferred to the initiator because the initiator's Bidirectional Read Expected Data Transfer Length was not sufficient.

位3-(o)设置为双向读取剩余溢出。在这种情况下,双向读取剩余计数表示由于启动器的双向读取预期数据传输长度不足而未传输到启动器的字节数。

bit 4 - (u) set for Bidirectional Read Residual Underflow. In this case, the Bidirectional Read Residual Count indicates the number of bytes that were not transferred to the initiator out of the number of bytes expected to be transferred.

位4-(u)设置为双向读取剩余下溢。在这种情况下,双向读取剩余计数表示预期传输的字节数中未传输到启动器的字节数。

bit 5 - (O) set for Residual Overflow. In this case, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. For a bidirectional operation, the Residual Count contains the residual for the write operation.

位5-(O)设置为剩余溢出。在这种情况下,剩余计数表示由于启动器的预期数据传输长度不足而未传输的字节数。对于双向操作,残差计数包含写入操作的残差。

bit 6 - (U) set for Residual Underflow. In this case, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes that were expected to be transferred. For a bidirectional operation, the Residual Count contains the residual for the write operation.

位6-(U)设置为剩余下溢。在这种情况下,剩余计数表示预期传输的字节数中未传输的字节数。对于双向操作,残差计数包含写入操作的残差。

bit 7 - (0) Reserved.

位7-(0)保留。

Bits O and U and bits o and u are mutually exclusive (i.e., having both o and u or O and U set to 1 is a protocol error).

位O和U以及位O和U是互斥的(即,将O和U或O和U都设置为1是协议错误)。

For a response other than "Command Completed at Target", bits 3-6 MUST be 0.

对于“在目标完成命令”以外的响应,位3-6必须为0。

11.4.2. Status
11.4.2. 地位

The Status field is used to report the SCSI status of the command (as specified in [SAM2]) and is only valid if the response code is Command Completed at Target.

Status字段用于报告命令的SCSI状态(如[SAM2]中所指定),并且仅当响应代码是在目标完成的命令时才有效。

Some of the status codes defined in [SAM2] are:

[SAM2]中定义的一些状态代码是:

0x00 GOOD

0x00良好

0x02 CHECK CONDITION

0x02检查条件

0x08 BUSY

0x08忙

0x18 RESERVATION CONFLICT

0x18保留冲突

0x28 TASK SET FULL

0x28任务集已满

0x30 ACA ACTIVE

0x30 ACA激活

0x40 TASK ABORTED

0x40任务已中止

See [SAM2] for the complete list and definitions.

有关完整列表和定义,请参见[SAM2]。

If a SCSI device error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a data PDU with the Final bit set), the target MUST wait until it receives a data PDU with the F bit set in the last expected sequence before sending the Response PDU.

如果在仍然需要来自启动器的数据时检测到SCSI设备错误(命令PDU未包含所有数据,且目标尚未接收到具有最终位集的数据PDU),则目标必须等到接收到具有最后预期顺序的F位集的数据PDU后再发送响应PDU。

11.4.3. Response
11.4.3. 回答

This field contains the iSCSI service response.

此字段包含iSCSI服务响应。

iSCSI service response codes defined in this specification are:

本规范中定义的iSCSI服务响应代码为:

0x00 - Command Completed at Target

0x00-命令在目标位置完成

0x01 - Target Failure

0x01-目标故障

0x80-0xff - Vendor specific

0x80-0xff-特定于供应商

All other response codes are reserved.

保留所有其他响应代码。

The Response field is used to report a service response. The mapping of the response code into a SCSI service response code value, if needed, is outside the scope of this document. However, in symbolic terms, response value 0x00 maps to the SCSI service response (see

响应字段用于报告服务响应。如果需要,将响应代码映射为SCSI服务响应代码值超出了本文档的范围。但是,用符号表示,响应值0x00映射到SCSI服务响应(请参阅

[SAM2] and [SPC3]) of TASK COMPLETE or LINKED COMMAND COMPLETE. All other Response values map to the SCSI service response of SERVICE DELIVERY OR TARGET FAILURE.

任务完成或链接命令完成的[SAM2]和[SPC3])。所有其他响应值映射到服务交付或目标故障的SCSI服务响应。

If a SCSI Response PDU does not arrive before the session is terminated, the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE.

如果SCSI响应PDU在会话终止之前未到达,则SCSI服务响应为服务交付或目标故障。

A non-zero response field indicates a failure to execute the command, in which case the Status and Flag fields are undefined and MUST be ignored on reception.

非零响应字段表示执行命令失败,在这种情况下,状态和标志字段未定义,接收时必须忽略。

11.4.4. SNACK Tag
11.4.4. 快餐标签

This field contains a copy of the SNACK Tag of the last SNACK Tag accepted by the target on the same connection and for the command for which the response is issued. Otherwise, it is reserved and should be set to 0.

此字段包含目标在同一连接上接受的最后一个SNACK标记的SNACK标记的副本,以及发出响应的命令的SNACK标记的副本。否则,它是保留的,应设置为0。

After issuing a R-Data SNACK, the initiator must discard any SCSI status unless contained in a SCSI Response PDU carrying the same SNACK Tag as the last issued R-Data SNACK for the SCSI command on the current connection.

发出R-Data快餐后,启动器必须放弃任何SCSI状态,除非包含在SCSI响应PDU中,该PDU带有与当前连接上SCSI命令的上次发出的R-Data快餐相同的快餐标签。

For a detailed discussion on R-Data SNACK, see Section 11.16.3.

有关R-Data Snapshot的详细讨论,请参见第11.16.3节。

11.4.5. Residual Count
11.4.5. 剩余计数
11.4.5.1. Field Semantics
11.4.5.1. 场语义

The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field MUST be ignored on reception and SHOULD be set to 0 when sending. Targets may set the residual count, and initiators may use it when the response code is Command Completed at Target (even if the status returned is not GOOD). If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred.

剩余计数字段必须在设置U位或O位的情况下有效。如果未设置任何一位,则接收时必须忽略剩余计数字段,发送时应将其设置为0。目标可以设置剩余计数,当响应代码在目标完成时(即使返回的状态不好),启动器也可以使用它。如果设置了O位,则剩余计数表示由于启动器的预期数据传输长度不足而未传输的字节数。如果设置了U位,则剩余计数表示预期传输的字节数中未传输的字节数。

11.4.5.2. Residuals Concepts Overview
11.4.5.2. 残差概念概述

"SCSI-Presented Data Transfer Length (SPDTL)" is the term this document uses (see Section 2.2 for definition) to represent the aggregate data length that the target SCSI layer attempts to transfer using the local iSCSI layer for a task. "Expected Data Transfer

“SCSI呈现数据传输长度(SPDTL)”是本文档使用的术语(定义见第2.2节),表示目标SCSI层尝试使用本地iSCSI层为任务传输的聚合数据长度。“预期的数据传输

Length (EDTL)" is the iSCSI term that represents the length of data that the iSCSI layer expects to transfer for a task. EDTL is specified in the SCSI Command PDU.

长度(EDTL)”是iSCSI术语,表示iSCSI层希望为任务传输的数据长度。EDTL在SCSI命令PDU中指定。

When SPDTL = EDTL for a task, the target iSCSI layer completes the task with no residuals. Whenever SPDTL differs from EDTL for a task, that task is said to have a residual.

当任务的SPDTL=EDTL时,目标iSCSI层将完成该任务,且无剩余。当任务的SPDTL与EDTL不同时,该任务被称为有剩余。

If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the SCSI Response PDU as specified in Section 11.4.5.1. The Residual Count MUST be set to the numerical value of (SPDTL - EDTL).

如果任务的SPDTL>EDTL,则必须按照第11.4.5.1节的规定在SCSI响应PDU中发出iSCSI溢出信号。剩余计数必须设置为(SPDTL-EDTL)的数值。

If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the SCSI Response PDU as specified in Section 11.4.5.1. The Residual Count MUST be set to the numerical value of (EDTL - SPDTL).

如果任务的SPDTL<EDTL,则必须按照第11.4.5.1节的规定在SCSI响应PDU中发出iSCSI下溢信号。剩余计数必须设置为(EDTL-SPDTL)的数值。

Note that the Overflow and Underflow scenarios are independent of Data-In and Data-Out. Either scenario is logically possible in either direction of data transfer.

请注意,溢出和下溢场景独立于数据输入和数据输出。这两种情况在逻辑上都可能发生在数据传输的任何一个方向上。

11.4.5.3. SCSI REPORT LUNS Command and Residual Overflow
11.4.5.3. SCSI报告LUN命令和剩余溢出

This section discusses the residual overflow issues, citing the example of the SCSI REPORT LUNS command. Note, however, that there are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH fields following the same underlying rules. The semantics in the rest of the section apply to all such SCSI commands.

本节以SCSI REPORT LUN命令为例,讨论剩余溢出问题。但是,请注意,有几个SCSI命令(例如查询)的分配长度字段遵循相同的基本规则。本节其余部分中的语义适用于所有此类SCSI命令。

The specification of the SCSI REPORT LUNS command requires that the SCSI target limit the amount of data transferred to a maximum size (ALLOCATION LENGTH) provided by the initiator in the REPORT LUNS CDB.

SCSI报告LUN命令的规范要求SCSI目标将传输的数据量限制为报告LUN CDB中启动器提供的最大大小(分配长度)。

If the Expected Data Transfer Length (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT LUNS command is set to at least as large as that ALLOCATION LENGTH, the SCSI-layer truncation prevents an iSCSI Residual Overflow from occurring. A SCSI initiator can detect that such truncation has occurred via other information at the SCSI layer. The rest of the section elaborates on this required behavior.

如果将报告LUN命令的SCSI命令PDU的iSCSI标头中的预期数据传输长度(EDTL)设置为至少与该分配长度相同,则SCSI层截断可防止发生iSCSI剩余溢出。SCSI启动器可以通过SCSI层的其他信息检测到发生了这种截断。本节的其余部分将详细介绍此所需的行为。

The SCSI REPORT LUNS command requests a target SCSI layer to return a LU inventory (LUN list) to the initiator SCSI layer (see Clause 6.21 of [SPC3]). The size of this LUN list may not be known to the initiator SCSI layer when it issues the REPORT LUNS command; to avoid transferring more LUN list data than the initiator is prepared for, the REPORT LUNS CDB contains an ALLOCATION LENGTH field to specify the maximum amount of data to be transferred to the initiator for this command. If the initiator SCSI layer has underestimated the

SCSI报告LUN命令请求目标SCSI层将LU资源清册(LUN列表)返回到启动器SCSI层(请参阅[SPC3]第6.21条)。启动器SCSI层在发出“报告LUN”命令时可能不知道此LUN列表的大小;为避免传输的LUN列表数据超过启动器准备的数量,报告LUN CDB包含一个分配长度字段,用于指定此命令传输到启动器的最大数据量。如果启动器SCSI层低估了

number of LUs at the target, it is possible that the complete LU inventory does not fit in the specified ALLOCATION LENGTH. In this situation, Clause 4.3.4.6 of [SPC3] requires that the target SCSI layer "shall terminate transfers to the Data-In Buffer" when the number of bytes specified by the ALLOCATION LENGTH field have been transferred.

目标位置的LU数,则完整的LU资源清册可能不适合指定的分配长度。在这种情况下,[SPC3]第4.3.4.6条要求目标SCSI层在传输分配长度字段指定的字节数时“应终止传输到缓冲区中的数据”。

Therefore, in response to a REPORT LUNS command, the SCSI layer at the target presents at most ALLOCATION LENGTH bytes of data (LU inventory) to iSCSI for transfer to the initiator. For a REPORT LUNS command, if the iSCSI EDTL is at least as large as the ALLOCATION LENGTH, the SCSI truncation ensures that the EDTL will accommodate all of the data to be transferred. If all of the LU inventory data presented to the iSCSI layer -- i.e., the data remaining after any SCSI truncation -- is transferred to the initiator by the iSCSI layer, an iSCSI Residual Overflow has not occurred and the iSCSI (O) bit MUST NOT be set in the SCSI Response or final SCSI Data-Out PDU. Note that this behavior is implied in Section 11.4.5.1, along with the specification of the REPORT LUNS command in [SPC3]. However, if the iSCSI EDTL is larger than the ALLOCATION LENGTH in this scenario, note that the iSCSI Underflow MUST be signaled in the SCSI Response PDU. An iSCSI Underflow MUST also be signaled when the iSCSI EDTL is equal to the ALLOCATION LENGTH but the LU inventory data presented to the iSCSI layer is smaller than the ALLOCATION LENGTH.

因此,作为对报告LUN命令的响应,目标的SCSI层向iSCSI提供最多分配长度字节的数据(LU资源清册),以便传输到启动器。对于报告LUN命令,如果iSCSI EDTL至少与分配长度一样大,SCSI截断将确保EDTL将容纳要传输的所有数据。如果提供给iSCSI层的所有LU资源清册数据(即任何SCSI截断后的剩余数据)都由iSCSI层传输到启动器,则iSCSI剩余溢出未发生,并且iSCSI(O)位不得在SCSI响应或最终SCSI数据输出PDU中设置。请注意,第11.4.5.1节以及[SPC3]中报告LUN命令的规范中暗示了此行为。但是,如果在此场景中iSCSI EDTL大于分配长度,请注意,iSCSI下溢必须在SCSI响应PDU中发出信号。当iSCSI EDTL等于分配长度,但呈现给iSCSI层的LU资源清册数据小于分配长度时,还必须发出iSCSI下溢信号。

The LUN LIST LENGTH field in the LU inventory (the first field in the inventory) is not affected by truncation of the inventory to fit in ALLOCATION LENGTH; this enables a SCSI initiator to determine that the received inventory is incomplete by noticing that the LUN LIST LENGTH in the inventory is larger than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A common initiator behavior in this situation is to reissue the REPORT LUNS command with a larger ALLOCATION LENGTH.

LU资源清册中的LUN列表长度字段(资源清册中的第一个字段)不受截断资源清册以适应分配长度的影响;这使SCSI启动器能够通过注意到资源清册中的LUN列表长度大于报告LUN CDB中发送的分配长度来确定收到的资源清册是否不完整。这种情况下的常见启动器行为是以更大的分配长度重新发出REPORT LUNS命令。

11.4.6. Bidirectional Read Residual Count
11.4.6. 双向读取剩余计数

The Bidirectional Read Residual Count field MUST be valid in the case where either the u bit or the o bit is set. If neither bit is set, the Bidirectional Read Residual Count field is reserved. Targets may set the Bidirectional Read Residual Count, and initiators may use it when the response code is Command Completed at Target. If the o bit is set, the Bidirectional Read Residual Count indicates the number of bytes that were not transferred to the initiator because the initiator's Bidirectional Read Expected Data Transfer Length was not sufficient. If the u bit is set, the Bidirectional Read Residual Count indicates the number of bytes that were not transferred to the initiator out of the number of bytes expected to be transferred.

双向读取剩余计数字段必须在设置u位或o位的情况下有效。如果未设置任何一位,则保留双向读取剩余计数字段。目标可以设置双向读取剩余计数,当响应代码在目标完成时,启动器可以使用它。如果设置了o位,则双向读取剩余计数表示由于启动器的双向读取预期数据传输长度不足而未传输到启动器的字节数。如果设置了u位,则双向读取剩余计数表示预期传输的字节数中未传输到启动器的字节数。

11.4.7. Data Segment - Sense and Response Data Segment
11.4.7. 数据段-感测和响应数据段

iSCSI targets MUST support and enable Autosense. If Status is CHECK CONDITION (0x02), then the data segment MUST contain sense data for the failed command.

iSCSI目标必须支持并启用Autosense。如果状态为检查条件(0x02),则数据段必须包含失败命令的检测数据。

For some iSCSI responses, the response data segment MAY contain some response-related information (e.g., for a target failure, it may contain a vendor-specific detailed description of the failure).

对于某些iSCSI响应,响应数据段可能包含一些响应相关信息(例如,对于目标故障,它可能包含特定于供应商的故障详细描述)。

If the DataSegmentLength is not 0, the format of the data segment is as follows:

如果DataSegmentLength不是0,则数据段的格式如下:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|SenseLength                    | Sense Data                    |
     +---------------+---------------+---------------+---------------+
    x/ Sense Data                                                    /
     +---------------+---------------+---------------+---------------+
    y/ Response Data                                                 /
     /                                                               /
     +---------------+---------------+---------------+---------------+
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|SenseLength                    | Sense Data                    |
     +---------------+---------------+---------------+---------------+
    x/ Sense Data                                                    /
     +---------------+---------------+---------------+---------------+
    y/ Response Data                                                 /
     /                                                               /
     +---------------+---------------+---------------+---------------+
        
11.4.7.1. SenseLength
11.4.7.1. 传感长度

This field indicates the length of Sense Data.

此字段表示检测数据的长度。

11.4.7.2. Sense Data
11.4.7.2. 传感数据

The Sense Data contains detailed information about a CHECK CONDITION. [SPC3] specifies the format and content of the Sense Data.

检测数据包含有关检查条件的详细信息。[SPC3]指定检测数据的格式和内容。

Certain iSCSI conditions result in the command being terminated at the target (response code of Command Completed at Target) with a SCSI CHECK CONDITION Status as outlined in the next table:

某些iSCSI条件导致命令在目标端终止(在目标端完成命令的响应代码),SCSI检查条件状态如下表所示:

   +--------------------------+-----------+---------------------------+
   | iSCSI Condition          |Sense      | Additional Sense Code and |
   |                          |Key        | Qualifier                 |
   +--------------------------+-----------+---------------------------+
   | Unexpected unsolicited   |Aborted    | ASC = 0x0c ASCQ = 0x0c    |
   | data                     |Command-0B | Write Error               |
   +--------------------------+-----------+---------------------------+
   | Incorrect amount of data |Aborted    | ASC = 0x0c ASCQ = 0x0d    |
   |                          |Command-0B | Write Error               |
   +--------------------------+-----------+---------------------------+
   | Protocol Service CRC     |Aborted    | ASC = 0x47 ASCQ = 0x05    |
   | error                    |Command-0B | CRC Error Detected        |
   +--------------------------+-----------+---------------------------+
   | SNACK rejected           |Aborted    | ASC = 0x11 ASCQ = 0x13    |
   |                          |Command-0B | Read Error                |
   +--------------------------+-----------+---------------------------+
        
   +--------------------------+-----------+---------------------------+
   | iSCSI Condition          |Sense      | Additional Sense Code and |
   |                          |Key        | Qualifier                 |
   +--------------------------+-----------+---------------------------+
   | Unexpected unsolicited   |Aborted    | ASC = 0x0c ASCQ = 0x0c    |
   | data                     |Command-0B | Write Error               |
   +--------------------------+-----------+---------------------------+
   | Incorrect amount of data |Aborted    | ASC = 0x0c ASCQ = 0x0d    |
   |                          |Command-0B | Write Error               |
   +--------------------------+-----------+---------------------------+
   | Protocol Service CRC     |Aborted    | ASC = 0x47 ASCQ = 0x05    |
   | error                    |Command-0B | CRC Error Detected        |
   +--------------------------+-----------+---------------------------+
   | SNACK rejected           |Aborted    | ASC = 0x11 ASCQ = 0x13    |
   |                          |Command-0B | Read Error                |
   +--------------------------+-----------+---------------------------+
        

The target reports the "Incorrect amount of data" condition if, during data output, the total data length to output is greater than FirstBurstLength and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurstLength. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested.

如果在数据输出过程中,要输出的总数据长度大于FirstBurstLength,并且启动器发送了未经请求的非即时数据,但未经请求的数据总量不同于FirstBurstLength,则目标会报告“数据量不正确”情况。当作为答复发送给R2T的数据量与请求的数据量不匹配时,目标会报告相同的错误。

11.4.8. ExpDataSN
11.4.8. ExpDataSN

This field indicates the number of Data-In (read) PDUs the target has sent for the command.

此字段表示目标为命令发送的(读取)PDU中的数据数。

This field MUST be 0 if the response code is not Command Completed at Target or the target sent no Data-In PDUs for the command.

如果响应代码未在目标处完成,或者目标在PDU中未发送命令的数据,则此字段必须为0。

11.4.9. StatSN - Status Sequence Number
11.4.9. StatSN-状态序列号

The StatSN is a sequence number that the target iSCSI layer generates per connection and that in turn enables the initiator to acknowledge status reception. The StatSN is incremented by 1 for every response/status sent on a connection, except for responses sent as a

StatSN是目标iSCSI层为每个连接生成的序列号,它反过来使启动器能够确认接收状态。对于连接上发送的每个响应/状态,StatSN都会增加1,但作为连接发送的响应除外

result of a retry or SNACK. In the case of responses sent due to a retransmission request, the StatSN MUST be the same as the first time the PDU was sent, unless the connection has since been restarted.

重试或重试的结果。在由于重传请求而发送响应的情况下,StatSN必须与第一次发送PDU时相同,除非此后重新启动了连接。

11.4.10. ExpCmdSN - Next Expected CmdSN from This Initiator
11.4.10. ExpCmdSN-此启动器的下一个预期CmdSN

The ExpCmdSN is a sequence number that the target iSCSI returns to the initiator to acknowledge command reception. It is used to update a local variable with the same name. An ExpCmdSN equal to MaxCmdSN + 1 indicates that the target cannot accept new commands.

ExpCmdSN是一个序列号,目标iSCSI返回给启动器以确认接收到命令。它用于更新具有相同名称的局部变量。等于MaxCmdSN+1的ExpCmdSN表示目标无法接受新命令。

11.4.11. MaxCmdSN - Maximum CmdSN from This Initiator
11.4.11. MaxCmdSN-此启动器的最大CmdSN

The MaxCmdSN is a sequence number that the target iSCSI returns to the initiator to indicate the maximum CmdSN the initiator can send. It is used to update a local variable with the same name. If the MaxCmdSN is equal to ExpCmdSN - 1, this indicates to the initiator that the target cannot receive any additional commands. When the MaxCmdSN changes at the target while the target has no pending PDUs to convey this information to the initiator, it MUST generate a NOP-In to carry the new MaxCmdSN.

MaxCmdSN是目标iSCSI返回给启动器的序列号,以指示启动器可以发送的最大CmdSN。它用于更新具有相同名称的局部变量。如果MaxCmdSN等于ExpCmdSN-1,则向启动器指示目标无法接收任何其他命令。当MaxCmdSN在目标更改,而目标没有挂起的PDU将此信息传递给启动器时,它必须生成一个NOP In以承载新的MaxCmdSN。

11.5. Task Management Function Request
11.5. 任务管理功能请求
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|I| 0x02      |1| Function    | Reserved                      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Logical Unit Number (LUN) or Reserved                         |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Referenced Task Tag or 0xffffffff                             |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32| RefCmdSN or Reserved                                          |
     +---------------+---------------+---------------+---------------+
   36| ExpDataSN or Reserved                                         |
     +---------------+---------------+---------------+---------------+
   40/ Reserved                                                      /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Header-Digest (optional)                                      |
     +---------------+---------------+---------------+---------------+
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|I| 0x02      |1| Function    | Reserved                      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Logical Unit Number (LUN) or Reserved                         |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Referenced Task Tag or 0xffffffff                             |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32| RefCmdSN or Reserved                                          |
     +---------------+---------------+---------------+---------------+
   36| ExpDataSN or Reserved                                         |
     +---------------+---------------+---------------+---------------+
   40/ Reserved                                                      /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Header-Digest (optional)                                      |
     +---------------+---------------+---------------+---------------+
        
11.5.1. Function
11.5.1. 作用

The task management functions provide an initiator with a way to explicitly control the execution of one or more tasks (SCSI and iSCSI tasks). The task management function codes are listed below. For a more detailed description of SCSI task management, see [SAM2].

任务管理功能为启动器提供了显式控制一个或多个任务(SCSI和iSCSI任务)执行的方法。任务管理功能代码如下所示。有关SCSI任务管理的更详细说明,请参阅[SAM2]。

1 ABORT TASK - aborts the task identified by the Referenced Task Tag field.

1中止任务-中止由引用的任务标记字段标识的任务。

2 ABORT TASK SET - aborts all tasks issued via this session on the LU.

2中止任务集-中止通过LU上的此会话发出的所有任务。

3 CLEAR ACA - clears the Auto Contingent Allegiance condition.

3清除ACA-清除自动或有效忠条件。

4 CLEAR TASK SET - aborts all tasks in the appropriate task set as defined by the TST field in the Control mode page (see [SPC3]).

4清除任务集-中止控制模式页面中TST字段定义的相应任务集中的所有任务(参见[SPC3])。

5 LOGICAL UNIT RESET

5逻辑单元复位

6 TARGET WARM RESET

6目标温度重置

7 TARGET COLD RESET

7目标冷复位

8 TASK REASSIGN - reassigns connection allegiance for the task identified by the Initiator Task Tag field to this connection, thus resuming the iSCSI exchanges for the task.

8任务重新分配-将启动器任务标记字段标识的任务的连接忠诚重新分配到此连接,从而恢复该任务的iSCSI交换。

Values 9-12 are assigned in [RFC7144]. All other possible values for the Function field are unassigned.

[RFC7144]中指定了值9-12。函数字段的所有其他可能值均未赋值。

For all these functions, the Task Management Function Response MUST be returned as detailed in Section 11.6. All these functions apply to the referenced tasks, regardless of whether they are proper SCSI tasks or tagged iSCSI operations. Task management requests must act on all the commands from the same session having a CmdSN lower than the task management CmdSN. LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET may affect commands from other sessions or commands from the same session, regardless of their CmdSN value.

对于所有这些功能,必须返回任务管理功能响应,详见第11.6节。所有这些函数都适用于引用的任务,无论它们是正确的SCSI任务还是标记的iSCSI操作。任务管理请求必须作用于同一会话中CmdSN低于任务管理CmdSN的所有命令。逻辑单元重置、目标热重置和目标冷重置可能会影响来自其他会话的命令或来自同一会话的命令,无论其CmdSN值如何。

If the task management request is marked for immediate delivery, it must be considered immediately for execution, but the operations involved (all or part of them) may be postponed to allow the target to receive all relevant tasks. According to [SAM2], for all the tasks covered by the task management response (i.e., with a CmdSN lower than the task management command CmdSN), except for the task management response to a TASK REASSIGN, additional responses MUST NOT be delivered to the SCSI layer after the task management response. The iSCSI initiator MAY deliver to the SCSI layer all responses received before the task management response (i.e., it is a matter of implementation if the SCSI responses that are received before the task management response but after the task management request was issued are delivered to the SCSI layer by the iSCSI layer in the initiator). The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI initiator after the task management response, except for a task covered by a TASK REASSIGN.

如果任务管理请求被标记为立即交付,则必须立即考虑执行,但所涉及的操作(全部或部分)可能会被推迟,以允许目标接收所有相关任务。根据[SAM2],对于任务管理响应所涵盖的所有任务(即,CmdSN低于任务管理命令CmdSN),除任务重新分配的任务管理响应外,任务管理响应后不得将其他响应传递到SCSI层。iSCSI启动器可以将在任务管理响应之前收到的所有响应传递到SCSI层(即,如果在任务管理响应之前但在发出任务管理请求之后收到的SCSI响应由启动器中的iSCSI层传递到SCSI层,则这是一个实现问题)。iSCSI目标必须确保在任务管理响应之后,不会向iSCSI启动器发送任务管理功能所涵盖任务的响应,但任务重新分配所涵盖的任务除外。

For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to respond to all valid Target Transfer Tags (received via R2T, Text Response, NOP-In, or SCSI Data-In PDUs) related to the affected task set, even after issuing the task management request.

对于中止任务集和清除任务集,发出的启动器必须继续响应与受影响任务集相关的所有有效目标传输标记(通过R2T、文本响应、NOP In或PDU中的SCSI数据接收),即使在发出任务管理请求之后也是如此。

The issuing initiator SHOULD, however, terminate (i.e., by setting the F bit to 1) these response sequences as quickly as possible. The target for its part MUST wait for responses on all affected Target Transfer Tags before acting on either of these two task management requests. If all or part of the response sequence is not received (due to digest errors) for a valid TTT, the target MAY treat it as a case of a within-command error recovery class (see Section 7.1.4.1) if it is supporting ErrorRecoveryLevel >= 1 or, alternatively, may drop the connection to complete the requested task set function.

但是,发出的启动器应尽快终止(即,通过将F位设置为1)这些响应序列。目标本身必须等待所有受影响的目标传输标记的响应,然后才能对这两个任务管理请求中的任何一个执行操作。如果有效TTT未接收到全部或部分响应序列(由于摘要错误),则目标可将其视为命令内错误恢复类(参见第7.1.4.1节),前提是其支持ErrorRecoveryLevel>=1,或者,可以断开连接以完成请求的任务集功能。

If an ABORT TASK is issued for a task created by an immediate command, then the RefCmdSN MUST be that of the task management request itself (i.e., the CmdSN and RefCmdSN are equal); otherwise, the RefCmdSN MUST be set to the CmdSN of the task to be aborted (lower than the CmdSN).

如果为立即命令创建的任务发出中止任务,则RefCmdSN必须是任务管理请求本身的任务(即,CmdSN和RefCmdSN相等);否则,必须将RefCmdSN设置为要中止的任务的CmdSN(低于CmdSN)。

If the connection is still active (i.e., it is not undergoing an implicit or explicit logout), an ABORT TASK MUST be issued on the same connection to which the task to be aborted is allegiant at the time the task management request is issued. If the connection is implicitly or explicitly logged out (i.e., no other request will be issued on the failing connection and no other response will be received on the failing connection), then an ABORT TASK function request may be issued on another connection. This task management request will then establish a new allegiance for the command to be aborted as well as abort it (i.e., the task to be aborted will not have to be retried or reassigned, and its status, if sent but not acknowledged, will be resent followed by the task management response).

如果连接仍处于活动状态(即,未进行隐式或显式注销),则在发出任务管理请求时,必须在要中止的任务为allegiant的同一连接上发出中止任务。如果连接隐式或显式注销(即,故障连接上不会发出其他请求,故障连接上也不会收到其他响应),则可能会在另一个连接上发出中止任务功能请求。然后,此任务管理请求将为要中止的命令建立新的效忠关系,并中止该命令(即,要中止的任务将不必重试或重新分配,其状态(如果已发送但未确认),将在任务管理响应后重新发送)。

At the target, an ABORT TASK function MUST NOT be executed on a task management request; such a request MUST result in a task management response of "Function rejected".

在目标位置,不能对任务管理请求执行中止任务功能;此类请求必须导致任务管理响应“功能被拒绝”。

For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2].

对于逻辑单元重置功能,目标必须按照[SAM2]中逻辑单元重置功能的指示进行操作。

The implementation of the TARGET WARM RESET function and the TARGET COLD RESET function is OPTIONAL and, when implemented, should act as described below. The TARGET WARM RESET is also subject to SCSI access controls on the requesting initiator as defined in [SPC3]. When authorization fails at the target, the appropriate response as described in Section 11.6.1 MUST be returned by the target. The TARGET COLD RESET function is not subject to SCSI access controls, but its execution privileges may be managed by iSCSI mechanisms such as login authentication.

目标温复位功能和目标冷复位功能的实现是可选的,在实现时,应如下所述。目标热重设还受[SPC3]中定义的请求启动器上的SCSI访问控制的约束。当目标公司授权失败时,目标公司必须返回第11.6.1节所述的适当响应。目标冷重设功能不受SCSI访问控制,但其执行权限可由iSCSI机制(如登录验证)管理。

When executing the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations on all LUs known by the issuing initiator. Both functions are equivalent to the TARGET RESET function specified by [SAM2]. They can affect many other initiators logged in with the servicing SCSI target port.

在执行目标热重设和目标冷重设功能时,目标会取消发出启动器已知的所有LU上的所有挂起操作。这两个功能相当于[SAM2]指定的目标重置功能。它们可能会影响使用SCSI目标端口登录的许多其他启动器。

Additionally, the target MUST treat the TARGET COLD RESET function as a power-on event, thus terminating all of its TCP connections to all initiators (all sessions are terminated). For this reason, the service response (defined by [SAM2]) for this SCSI task management function may not be reliably delivered to the issuing initiator port.

此外,目标必须将目标冷复位功能视为通电事件,从而终止其与所有启动器的所有TCP连接(所有会话均已终止)。因此,此SCSI任务管理功能的服务响应(由[SAM2]定义)可能无法可靠地传递到发出的启动器端口。

For the TASK REASSIGN function, the target should reassign the connection allegiance to this new connection (and thus resume iSCSI exchanges for the task). TASK REASSIGN MUST ONLY be received by the target after the connection on which the command was previously executing has been successfully logged out. The task management response MUST be issued before the reassignment becomes effective.

对于任务重新分配功能,目标应将连接忠诚度重新分配给此新连接(从而恢复任务的iSCSI交换)。只有在先前执行命令的连接成功注销后,目标才能接收任务重新分配。任务管理响应必须在重新分配生效之前发出。

For additional usage semantics, see Section 7.2.

有关其他用法语义,请参见第7.2节。

At the target, a TASK REASSIGN function request MUST NOT be executed to reassign the connection allegiance of a Task Management Function Request, an active text negotiation task, or a Logout task; such a request MUST result in a task management response of "Function rejected".

在目标位置,不得执行任务重新分配功能请求来重新分配任务管理功能请求、活动文本协商任务或注销任务的连接忠诚;此类请求必须导致任务管理响应“功能被拒绝”。

TASK REASSIGN MUST be issued as an immediate command.

任务重新分配必须作为即时命令发出。

11.5.2. TotalAHSLength and DataSegmentLength
11.5.2. 总长度和数据段长度

For this PDU, TotalAHSLength and DataSegmentLength MUST be 0.

对于此PDU,TotalAHSLength和DataSegmentLength必须为0。

11.5.3. LUN
11.5.3. 伦

This field is required for functions that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all others.

处理特定LU(中止任务、清除任务集、中止任务集、清除ACA、逻辑单元重置)的功能需要此字段,并且在所有其他功能中保留此字段。

11.5.4. Referenced Task Tag
11.5.4. 引用的任务标记

This is the Initiator Task Tag of the task to be aborted for the ABORT TASK function or reassigned for the TASK REASSIGN function. For all the other functions, this field MUST be set to the reserved value 0xffffffff.

这是要为中止任务功能中止或为任务重新分配功能重新分配的任务的启动器任务标记。对于所有其他函数,此字段必须设置为保留值0xFFFFFF。

11.5.5. RefCmdSN
11.5.5. RefCmdSN

If an ABORT TASK is issued for a task created by an immediate command, then the RefCmdSN MUST be that of the task management request itself (i.e., the CmdSN and RefCmdSN are equal).

如果为立即命令创建的任务发出中止任务,则RefCmdSN必须是任务管理请求本身的任务(即,CmdSN和RefCmdSN相等)。

For an ABORT TASK of a task created by a non-immediate command, the RefCmdSN MUST be set to the CmdSN of the task identified by the Referenced Task Tag field. Targets must use this field as described in Section 11.6.1 when the task identified by the Referenced Task Tag field is not with the target.

对于由非即时命令创建的任务的中止任务,必须将RefCmdSN设置为由引用的任务标记字段标识的任务的CmdSN。当引用的任务标记字段标识的任务与目标不在一起时,目标必须使用第11.6.1节所述的该字段。

Otherwise, this field is reserved.

否则,此字段将保留。

11.5.6. ExpDataSN
11.5.6. ExpDataSN

For recovery purposes, the iSCSI target and initiator maintain a data acknowledgment reference number -- the first input DataSN number unacknowledged by the initiator. When issuing a new command, this number is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued read or bidirectional command, the ExpDataSN will contain an updated data acknowledgment reference number or the value 0; the latter indicates that the data acknowledgment reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge, and the target MUST transmit all Data-In PDUs (if any) starting with the data acknowledgment reference number. The number of retransmitted PDUs may or may not be the same as the original transmission, depending on if there was a change in MaxRecvDataSegmentLength in the reassignment. The target MAY also send no more Data-In PDUs if all data has been acknowledged.

出于恢复目的,iSCSI目标和启动器保留一个数据确认参考号——启动器未确认的第一个输入数据编号。发出新命令时,此数字设置为0。如果功能为任务重新分配,为先前发出的读取或双向命令建立新的连接效忠,EXPDASCN将包含更新的数据确认参考号或值0;后者表示数据确认参考号不变。发起方必须丢弃上次执行中未确认的任何数据PDU,并且目标方必须传输PDU中的所有数据(如果有),从数据确认参考号开始。重新传输的PDU的数量可能与原始传输相同,也可能不同,这取决于重新分配中MaxRecvDataSegmentLength是否有更改。如果已确认所有数据,则目标也可能不会在PDU中发送更多数据。

The value of ExpDataSN MUST be 0 or higher than the DataSN of the last acknowledged Data-In PDU, but not larger than DataSN + 1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target.

ExpDataSN的值必须为0或高于PDU中最后确认数据的DataSN,但不得大于目标发送的PDU中最后一个数据的DataSN+1。目标必须忽略任何其他值。

For other functions, this field is reserved.

对于其他功能,此字段是保留的。

11.6. Task Management Function Response
11.6. 任务管理功能响应
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|.| 0x22      |1| Reserved    | Response      | Reserved      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------------------------------------------------------+
    8/ Reserved                                                      /
     /                                                               /
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved                                                      |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36/ Reserved                                                      /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Header-Digest (optional)                                      |
     +---------------+---------------+---------------+---------------+
        
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|.| 0x22      |1| Reserved    | Response      | Reserved      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------------------------------------------------------+
    8/ Reserved                                                      /
     /                                                               /
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved                                                      |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36/ Reserved                                                      /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Header-Digest (optional)                                      |
     +---------------+---------------+---------------+---------------+
        

For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET COLD RESET, TARGET WARM RESET, and TASK REASSIGN, the target performs the requested task management function and sends a task management response back to the initiator. For TASK REASSIGN, the new connection allegiance MUST ONLY become effective at the target after the target issues the task management response.

对于功能ABORT TASK、ABORT TASK SET、CLEAR ACA、CLEAR TASK SET、逻辑单元重置、目标冷重置、目标热重置和任务重新分配,目标执行请求的任务管理功能,并将任务管理响应发送回启动器。对于任务重新分配,新的连接忠诚必须在目标发出任务管理响应后在目标处生效。

11.6.1. Response
11.6.1. 回答

The target provides a response, which may take on the following values:

目标提供的响应可能具有以下值:

0 - Function complete 1 - Task does not exist 2 - LUN does not exist 3 - Task still allegiant 4 - Task allegiance reassignment not supported 5 - Task management function not supported 6 - Function authorization failed 255 - Function rejected

0-功能完成1-任务不存在2-LUN不存在3-任务仍然保持一致4-任务一致性重新分配不受支持5-任务管理功能不受支持6-功能授权失败255-功能被拒绝

In addition to the above values, the value 7 is defined by [RFC7144].

除上述值外,值7由[RFC7144]定义。

For a discussion on the usage of response codes 3 and 4, see Section 7.2.2.

有关使用响应代码3和4的讨论,请参见第7.2.2节。

For the TARGET COLD RESET and TARGET WARM RESET functions, the target cancels all pending operations across all LUs known to the issuing initiator. For the TARGET COLD RESET function, the target MUST then close all of its TCP connections to all initiators (terminates all sessions).

对于目标冷重设和目标温重设功能,目标取消发出启动器已知的所有LU中所有挂起的操作。对于目标冷重置功能,目标必须关闭其与所有启动器的所有TCP连接(终止所有会话)。

The mapping of the response code into a SCSI service response code value, if needed, is outside the scope of this document. However, in symbolic terms, Response values 0 and 1 map to the SCSI service response of FUNCTION COMPLETE. Response value 2 maps to the SCSI service response of INCORRECT LOGICAL UNIT NUMBER. All other Response values map to the SCSI service response of FUNCTION REJECTED. If a Task Management Function Response PDU does not arrive before the session is terminated, the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE.

如果需要,将响应代码映射为SCSI服务响应代码值超出了本文档的范围。但是,用符号表示,响应值0和1映射到函数COMPLETE的SCSI服务响应。响应值2映射到错误逻辑单元号的SCSI服务响应。所有其他响应值映射到函数拒绝的SCSI服务响应。如果任务管理功能响应PDU在会话终止前未到达,则SCSI服务