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
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管理设施和解决距离限制。
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工作组
- 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的值，该值由启动器保留并用于指示新会话。在同一会话的附加连接建立过程中，会将其提供给目标。
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）。
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]中所述进行解释。
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绘图，本节的其余部分将介绍本文档中使用的符号约定。
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）。
+--------------+ +--------------+ +--------------+
| 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.
上图是一个类的示例，该类的属性具有指定的多重性和操作。
+-----------------+
| 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类。
+---------------+ +--------------+
| 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）脚注描述了约束。
+---------------+
| 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).
上图是一个例子，其中子类是一种超类。子类共享超类的所有属性和操作（即，子类继承自超类）。
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标准定义。
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命令”、“请求”或（不合格）命令具有相同的含义。此外，除非另有规定，否则状态、响应或编号响应具有相同的含义。
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连接，并且可以在一个会话中支持多个连接。出于错误恢复目的，支持会话中单个活动连接的目标和启动器在恢复期间应支持两个连接。
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]。
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中的数据中。
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.
启动器和目标必须支持响应编号方案。
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响应消息的语义。
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层的顺序。
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层排队，直到清除隔离。
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”值来评估响应防护行为。
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。
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.
在这些功能类型中，中止任务和任务重新分配功能管理单个活动任务，而中止任务集、清除任务集、逻辑单元重置、目标热重置和目标冷重置功能都可能影响多个活动任务。
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节中定义的“中止任务集”。其他范围描述也采用类似用法。
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）之后仍有这些未完成的数据传输。
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）指定一个事件以释放可能已保留以支持未完成数据传输的任何此类资源。
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。请注意，即使会话是单个连接会话，启动器也可能因此在受影响的第三方会话上接收这些异步消息。
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层只看到有序的命令。
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，则必须立即终止连接。
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命令和数据。
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数据和响应。
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之前发送）。接收到无序数据的目标可能会终止会话。
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相同）。使用不一致的字段值被视为协议错误。
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视图所需的协议机制和实施要求。
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。
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的发现互操作性。
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]。
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名称“规范化”，就可以安全地逐字节比较它们。
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 | |
+----------------------------+-------+-----+----+
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
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]中讨论了名称构造的更多示例。
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节点名称的最大大小。
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节。
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序列号用于确定缓冲区内的偏移量。
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长度。
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参数定义的。
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) |
+-----------------------------------+
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) |
+---------------------------------------------------------------+
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。
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值。
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连接的数据。
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保留和释放行为的例外情况”的讨论。
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节中的相关要求。
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字节。
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的一部分作为数据段发送。
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
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.
对于任务管理功能，受影响任务的响应与任务管理功能响应之间的协调由目标完成。
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.
在任务管理功能响应指示任务管理功能完成后，启动器将不会收到来自受影响任务的任何其他响应。
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数据也可能包含状态。
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
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时，事件详细信息作为数据段中的检测数据报告。
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.
虽然完整的交换总是由启动器启动，但特定的参数协商可能由启动器或目标启动。
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）以及识别旧连接关联的会话元素的相同会话来指示要登录的连接的隐含注销（清除）（连接重新启动）。
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字段中继续恢复之前必须等待的时间。
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中已确认数据的数量）的快餐请求传递此肯定确认。
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的完整头。
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还可以“单向”方式使用，以在没有其他“载体”且需要更新启动器/目标时向启动器/目标传送命令、状态或数据计数器值。
There are no iSCSI-specific mode pages.
没有特定于iSCSI的模式页面。
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.
本节详细介绍了使用的键和值的类型、参数形成的语法规则以及与不同类型的参数一起使用的协商方案。
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数据。
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）次交换。
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.
如果接受程序不理解列表中的任何特定值，则必须忽略该值。如果承兑人不支持、不理解或不允许对特定发起人使用任何提议的选项，则可使用常量“拒绝”或终止谈判。未提议值的选择必须由发起人作为协议错误处理。
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.
在所有其他情况下都需要回复，并且由接受方选择和发送的值成为协商的结果。
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）。发起者和目标必须检测到重新协商/重新声明不允许的参数的尝试。如果目标检测到此类尝试，目标必须以登录拒绝（启动器错误）响应；如果启动器检测到，则启动器必须断开连接。
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启动器应使用此密钥来确定它确实已使用目标门户组启动了登录阶段。
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。
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节。
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.
实际上，除了隐式注销旧连接外，恢复相当于新连接登录。
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节中的会话状态图）。
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中所述。
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）开始等待任务重新分配的事件。
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.
文本交换协商序列协商的参数只有在协商序列完成后才生效。
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。兼容的实现不必与所呈现的模型的实现细节相匹配，但此类实现的外部行为必须与所呈现模型的外部可观察特征相对应。
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。例如，启动器和目标之间必须有明确的“错误恢复功能分布”。
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.
同意支持数据重传的目标应准备根据请求重传传出数据（即数据输入），直到确认已完成命令的状态或单独确认相关数据。
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节），则要执行的规范性行动。
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.
启动器和目标使用的超时值超出了本文档的范围。序列接收超时通常是一个足够大的值，以允许完成数据序列传输。
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.
启动器和目标使用的超时值超出了本文档的范围。
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连接失败：目标必须关闭连接，如果有多个连接可用，目标应发送一条异步消息，指示其已断开连接。然后，目标将等待启动器继续恢复。
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。
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 |
+-------------------+--------------------------------------------+
This section summarizes two important and somewhat related iSCSI protocol features used in error recovery.
本节总结了错误恢复中使用的两个重要且有些相关的iSCSI协议功能。
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。重试的命令必须在与原始命令相同的连接上发送，除非原始连接已成功注销。
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。
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。
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节对发现会话施加的功能约束。
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.
以下两部分分别描述未命名发现会话和命名发现会话。
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>，则必须恢复现有的未命名发现会话。因此请注意，只有未命名的发现会话可以恢复另一个未命名的发现会话。
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会话。
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.
实现说明：当目标在正常会话上通过异步消息请求注销时，它可以在发现会话中简单地断开连接。
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秒内完成。
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节）文本键的协商值。
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.
这些超时值仅适用于受影响的连接以及该连接上活动的任务。这些超时值与已在与该会话关联的连接或任务上运行的启动器计时器（如果有）无关。
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]）。
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
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的丢失。
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。
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实施是否符合协议要求。
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接收到该命令，并发出响应管理代码“函数完成”的任务管理响应。此响应结束了两端的任务。如果接收到中止请求，并且目标可以确定（基于引用的任务标记）已接收并执行命令，并且在中止之前已发送响应，则目标必须使用响应代码“任务不存在”进行响应。
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) 在全功能阶段协商失败将终止整个协商序列，该序列可能由使用相同启动器任务标记的一系列文本请求组成。会话或连接的操作参数必须继续为先前成功协商期间商定的值（即，此不成功协商的任何部分结果不得生效，必须丢弃）。
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定义拒绝和响应代码以启用此功能。
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).
任何一方都可以选择升级到会话恢复（通过发起方放弃所有连接或通过异步消息从目标方宣布类似意图），另一方必须给予它优先权。在连接失败时，目标必须终止和/或放弃所有活动的立即命令，而不管使用了上述哪个选项（即，立即命令在连接失败时不可恢复）。
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.
目标还必须准备好处理发起者可能正在处理会话错误的会话恢复请求。
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.
状态和转换在文本、表格和图表中描述。这些图表用于说明。正文和表格为适用规范。
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的清理进程启动。
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任务。
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| - |- |- | - | - | - | - |
---+----+---+---+---+---+----+---+
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| - |- |- | - | - | - | - |
---+----+---+---+---+---+----+---+
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 | - | - | - |
-----+----+----+----+
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的结束状态。
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保持登录状态，并收到指示成功注销处理的内部事件，或收到针对“关闭会话”注销请求在不同连接上发送注销响应（成功）的内部事件。
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 | - |
-----+---+---+---+
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 | - |
-----+----+----+----+----+----+
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.
- 目标：等待会话继续尝试得出结论。
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.
- 目标：成功的会话恢复干净地关闭了会话。
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实现提供的安全机制。
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]。
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连接，该会话可以同时或顺序添加到会话中。
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身份验证机制的更新版本。
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组列表。
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节中指定的目的。
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]中的要求适用。
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规定了作为安全关联建立一部分的扩展序列号协商。
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.
还必须实现空加密算法。
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。
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启动器，每个启动器都运行一个通用操作系统：每个节点的资产级别被视为较低，因为刀片是可更换的且成本较低。但是，由于该通用操作系统可能存在许多众所周知的漏洞，因此漏洞级别被视为很高。对于这个目标，一个合适的实现可能是记录接收到的键值，但不传输键值。对于该启动器，适当的实现可能是传输密钥，但不记录接收到的密钥值。
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连接和数据包保护机制实现的安全问题已在前面章节中讨论过。
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节中概述的。
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.
但是，某些任务管理命令可能需要某种松散形式的协作或复制，至少在目标系统上是这样。
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端口。实际上，它可以识别来自同一源的多条路径。
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有可供所有传输使用的访问控制替代方案，它们的安全性不依赖于严格的命名协调。
"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。
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。在这些情况下，实现者可能希望降低超时值，以便更快地启动恢复过程。
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）。因为错误被认为是罕见的事件，所以这种技术可能是最有效的，因为它在发出命令时不涉及启动器的额外检查。
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操作的设备可能需要在命令运行时（例如，在扩展复制操作期间）启用连接替换的机制。
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。
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资源。
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”（保留）的缩写，或在技术上不可行的情况下，用“.”标记单个位。
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发送。
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段。
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
For Request PDUs, the I bit set to 1 is an immediate delivery marker.
对于请求PDU，设置为1的I位是立即传递标记。
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.
所有其他操作码均未分配。
When set to 1 it indicates the final (or only) PDU of a sequence.
当设置为1时，表示序列的最终（或唯一）PDU。
These fields have different meanings for different Opcode types.
对于不同的操作码类型，这些字段具有不同的含义。
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。
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。
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。
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的启动器响应（如有必要）。
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
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保留
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个填充字节）。
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。
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
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.
零长度数据段也意味着零长度数据摘要。
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字节字的整数。
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) /
+---------------+---------------+---------------+---------------+
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位指示）。
The CmdSN enables ordered delivery across multiple connections in a single session.
CmdSN支持在单个会话中跨多个连接进行有序传递。
Command responses up to ExpStatSN - 1 (modulo 2**32) have been received (acknowledges status) on the connection.
已在连接上接收到ExpStatSN-1（模2**32）之前的命令响应（确认状态）。
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.
数据传输完成后，目标将通知启动器（通过剩余计数）目标实际处理（发送和/或接收）的字节数。
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溢出。
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节中概述的请求与非请求数据规则的管辖。
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) |
+---------------+---------------+---------------+---------------+
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。
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。
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.
非零响应字段表示执行命令失败，在这种情况下，状态和标志字段未定义，接收时必须忽略。
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节。
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位，则剩余计数表示预期传输的字节数中未传输的字节数。
"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.
请注意，溢出和下溢场景独立于数据输入和数据输出。这两种情况在逻辑上都可能发生在数据传输的任何一个方向上。
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命令。
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位，则双向读取剩余计数表示预期传输的字节数中未传输到启动器的字节数。
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 /
/ /
+---------------+---------------+---------------+---------------+
This field indicates the length of Sense Data.
此字段表示检测数据的长度。
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的数据量与请求的数据量不匹配时，目标会报告相同的错误。
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。
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时相同，除非此后重新启动了连接。
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表示目标无法接受新命令。
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。
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) |
+---------------+---------------+---------------+---------------+
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.
任务重新分配必须作为即时命令发出。
For this PDU, TotalAHSLength and DataSegmentLength MUST be 0.
对于此PDU，TotalAHSLength和DataSegmentLength必须为0。
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、逻辑单元重置）的功能需要此字段，并且在所有其他功能中保留此字段。
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。
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.
否则，此字段将保留。
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.
对于其他功能，此字段是保留的。
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、逻辑单元重置、目标冷重置、目标热重置和任务重新分配，目标执行请求的任务管理功能，并将任务管理响应发送回启动器。对于任务重新分配，新的连接忠诚必须在目标发出任务管理响应后在目标处生效。
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服务响应为服务交付或目标故障。
The response to ABORT TASK SET and CLEAR TASK SET MUST only be issued by the target after all of the commands affected have been received by the target, the corresponding task management functions have been executed by the SCSI target, and the delivery of all responses delivered until the task management function completion has been confirmed (acknowledged through the ExpStatSN) by the initiator on all connections of this session. For the exact timeline of events, refer to Sections 4.2.3.3 and 4.2.3.4.
只有在目标接收到所有受影响的命令，SCSI目标执行了相应的任务管理功能，并且在确认任务管理功能完成之前，才可由目标发出对中止任务集和清除任务集的响应（通过ExpStatSN确认）由发起人在此会话的所有连接上进行。有关事件的确切时间线，请参阅第4.2.3.3节和第4.2.3.4节。
For the ABORT TASK function,
对于中止任务功能，
a) if the Referenced Task Tag identifies a valid task leading to a successful termination, then targets must return the "Function complete" response.
a) 如果引用的任务标记标识导致成功终止的有效任务，则目标必须返回“功能完成”响应。
b) if the Referenced Task Tag does not identify an existing task but the CmdSN indicated by the RefCmdSN field in the Task Management Function Request is within the valid CmdSN window and less than the CmdSN of the Task Management Function Request itself, then targets must consider the CmdSN as received and return the "Function complete" response.
b) 如果所引用的任务标记不标识现有任务，但任务管理功能请求中的ReCMCMN字段所指示的CMDSN位于有效CMDSN窗口内且小于任务管理功能请求本身的CmdSN，则目标必须考虑CMDSN作为接收并返回“函数完成”响应。
c) if the Referenced Task Tag does not identify an existing task and the CmdSN indicated by the RefCmdSN field in the Task Management Function Request is outside the valid CmdSN window, then targets must return the "Task does not exist" response.
c) 如果引用的任务标记未标识现有任务，且任务管理功能请求中RefCmdSN字段指示的CmdSN在有效的CmdSN窗口之外，则目标必须返回“任务不存在”响应。
For response semantics on function types that can potentially impact multiple active tasks on the target, see Section 4.2.3.
有关可能影响目标上多个活动任务的功能类型的响应语义，请参见第4.2.3节。
For this PDU, TotalAHSLength and DataSegmentLength MUST be 0.
对于此PDU，TotalAHSLength和DataSegmentLength必须为0。
The SCSI Data-Out PDU for write operations has the following format:
用于写入操作的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|.|.| 0x05 |F| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| Reserved |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32| Reserved |
+---------------+---------------+---------------+---------------+
36| DataSN |
+---------------+---------------+---------------+---------------+
40| Buffer Offset |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment /
+/ /
+---------------+---------------+---------------+---------------+
| 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|.|.| 0x05 |F| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| Reserved |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32| Reserved |
+---------------+---------------+---------------+---------------+
36| DataSN |
+---------------+---------------+---------------+---------------+
40| Buffer Offset |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (optional) |
+---------------+---------------+---------------+---------------+
The SCSI Data-In PDU for read operations has the following format:
PDU中用于读取操作的SCSI数据具有以下格式：
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|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| StatSN or Reserved |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| DataSN |
+---------------+---------------+---------------+---------------+
40| Buffer Offset |
+---------------+---------------+---------------+---------------+
44| Residual Count |
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment /
+/ /
+---------------+---------------+---------------+---------------+
| 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|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| StatSN or Reserved |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| DataSN |
+---------------+---------------+---------------+---------------+
40| Buffer Offset |
+---------------+---------------+---------------+---------------+
44| Residual Count |
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (optional) |
+---------------+---------------+---------------+---------------+
Status can accompany the last Data-In PDU if the command did not end with an exception (i.e., the status is "good status" -- GOOD, CONDITION MET, or INTERMEDIATE-CONDITION MET). The presence of status (and of a residual count) is signaled via the S flag bit. Although targets MAY choose to send even non-exception status in separate responses, initiators MUST support non-exception status in Data-In PDUs.
如果命令没有以异常结束（即状态为“良好状态”--良好、条件满足或中间条件满足），状态可以伴随PDU中的最后一个数据。状态（和剩余计数）的存在通过S标志位发出信号。尽管目标可以选择在单独的响应中发送非异常状态，但启动器必须支持PDU中数据的非异常状态。
For outgoing data, this bit is 1 for the last PDU of unsolicited data or the last PDU of a sequence that answers an R2T.
对于传出数据，对于非请求数据的最后一个PDU或应答R2T的序列的最后一个PDU，该位为1。
For incoming data, this bit is 1 for the last input (read) data PDU of a sequence. Input can be split into several sequences, each having its own F bit. Splitting the data stream into sequences does not affect DataSN counting on Data-In PDUs. It MAY be used as a "change direction" indication for bidirectional operations that need such a change.
对于输入数据，该位对于序列的最后一个输入（读取）数据PDU为1。输入可以分成几个序列，每个序列都有自己的F位。将数据流拆分为序列不会影响PDU中数据的DataSN计数。它可用作需要这种改变的双向操作的“改变方向”指示。
DataSegmentLength MUST NOT exceed MaxRecvDataSegmentLength for the direction it is sent, and the total of all the DataSegmentLength of all PDUs in a sequence MUST NOT exceed MaxBurstLength (or FirstBurstLength for unsolicited data). However, the number of individual PDUs in a sequence (or in total) may be higher than the ratio of MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength (as PDUs may be limited in length by the capabilities of the sender). Using a DataSegmentLength of 0 may increase beyond what is reasonable for the number of PDUs and should therefore be avoided.
DataSegmentLength不得超过发送方向的MaxRecvDataSegmentLength，并且序列中所有PDU的所有DataSegmentLength的总和不得超过MaxBurstLength（对于未经请求的数据，不得超过FirstBurstLength）。但是，一个序列中的单个PDU的数量（或总数）可能高于MaxBurstLength（或FirstBurstLength）与MaxRecvDataSegmentLength的比率（因为PDU的长度可能受到发送方能力的限制）。使用DataSegmentLength 0可能会增加超过PDU数量的合理值，因此应避免使用。
For bidirectional operations, the F bit is 1 for both the end of the input sequences and the end of the output sequences.
对于双向操作，输入序列末端和输出序列末端的F位均为1。
For sessions with ErrorRecoveryLevel=1 or higher, the target sets this bit to 1 to indicate that it requests a positive acknowledgment from the initiator for the data received. The target should use the A bit moderately; it MAY only set the A bit to 1 once every MaxBurstLength bytes, or on the last Data-In PDU that concludes the entire requested read data transfer for the task from the target's perspective, and it MUST NOT do so more frequently. The target MUST NOT set to 1 the A bit for sessions with ErrorRecoveryLevel=0. The initiator MUST ignore the A bit set to 1 for sessions with ErrorRecoveryLevel=0.
对于ErrorRecoveryLevel=1或更高的会话，目标将此位设置为1，以指示它请求启动器对接收到的数据进行肯定确认。目标公司应适度使用bit；它可能只会将A位设置为1，每MaxBurstLength字节一次，或者在PDU中的最后一个数据上设置一次，从目标的角度结束任务的整个请求读取数据传输，并且不能更频繁地这样做。对于ErrorRecoveryLevel=0的会话，目标不能设置为1位。对于ErrorRecoveryLevel=0的会话，启动器必须忽略设置为1的A位。
On receiving a Data-In PDU with the A bit set to 1 on a session with ErrorRecoveryLevel greater than 0, if there are no holes in the read data until that Data-In PDU, the initiator MUST issue a SNACK of type DataACK, except when it is able to acknowledge the status for the task immediately via the ExpStatSN on other outbound PDUs if the status for the task is also received. In the latter case (acknowledgment through the ExpStatSN), sending a SNACK of type DataACK in response to the A bit is OPTIONAL, but if it is done, it must not be sent after the status acknowledgment through the
在ErrorRecoveryLevel大于0的会话中，当在PDU中接收到位设置为1的数据时，若在PDU中读取该数据之前，读取数据中并没有漏洞，则发起方必须发出DataACK类型的零食，除非它能够通过其他出站PDU上的ExpStatSN立即确认任务的状态（如果还接收到任务的状态）。在后一种情况下（通过ExpStatSN确认），发送DataACK类型的零食以响应a位是可选的，但如果完成了，则在通过a位的状态确认之后不得发送
ExpStatSN. If the initiator has detected holes in the read data prior to that Data-In PDU, it MUST postpone issuing the SNACK of type DataACK until the holes are filled. An initiator also MUST NOT acknowledge the status for the task before those holes are filled. A status acknowledgment for a task that generated the Data-In PDUs is considered by the target as an implicit acknowledgment of the Data-In PDUs if such an acknowledgment was requested by the target.
ExpStatSN。如果启动器在PDU中的数据之前在读取数据中检测到漏洞，则必须推迟发出DataACK类型的零食，直到漏洞被填满。在填补这些漏洞之前，启动器也不得确认任务的状态。如果目标请求对在PDU中生成数据的任务的状态确认，则目标将其视为对PDU中数据的隐式确认。
The last SCSI data packet sent from a target to an initiator for a SCSI command that completed successfully (with a status of GOOD, CONDITION MET, INTERMEDIATE, or INTERMEDIATE-CONDITION MET) may also optionally contain the Status for the data transfer. In this case, Sense Data cannot be sent together with the Command Status. If the command is completed with an error, then the response and sense data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be sent in a SCSI data packet). For bidirectional commands, the status MUST be sent in a SCSI Response PDU.
成功完成SCSI命令（状态为“良好”、“满足条件”、“中间”或“满足中间条件”）后，从目标发送到启动器的最后一个SCSI数据包也可以选择包含数据传输的状态。在这种情况下，检测数据不能与命令状态一起发送。如果命令完成时出现错误，则响应和检测数据必须在SCSI响应PDU中发送（即，不得在SCSI数据包中发送）。对于双向命令，状态必须在SCSI响应PDU中发送。
bit 2-4 - Reserved.
第2-4位-保留。
bit 5-6 - used the same as in a SCSI Response. These bits are only valid when S is set to 1. For details, see Section 11.4.1.
位5-6-与SCSI响应中使用的相同。这些位仅在S设置为1时有效。有关详细信息，请参见第11.4.1节。
bit 7 S (status) - set to indicate that the Command Status field contains status. If this bit is set to 1, the F bit MUST also be set to 1.
位7 S（状态）-设置为指示命令状态字段包含状态。如果此位设置为1，则F位也必须设置为1。
The fields StatSN, Status, and Residual Count only have meaningful content if the S bit is set to 1. The values for these fields are defined in Section 11.4.
仅当S位设置为1时，StatSN、Status和残差计数字段才具有有意义的内容。第11.4节定义了这些字段的值。
On outgoing data, the Target Transfer Tag is provided to the target if the transfer is honoring an R2T. In this case, the Target Transfer Tag field is a replica of the Target Transfer Tag provided with the R2T.
对于传出数据，如果传输符合R2T，则向目标提供目标传输标签。在这种情况下，目标传输标签字段是R2T提供的目标传输标签的副本。
On incoming data, the Target Transfer Tag and LUN MUST be provided by the target if the A bit is set to 1; otherwise, they are reserved. The Target Transfer Tag and LUN are copied by the initiator into the SNACK of type DataACK that it issues as a result of receiving a SCSI Data-In PDU with the A bit set to 1.
对于传入数据，如果A位设置为1，则目标必须提供目标传输标签和LUN；否则，它们将被保留。目标传输标记和LUN由启动器复制到DataACK类型的零食中，该零食是在PDU中接收到位设置为1的SCSI数据时发出的。
The Target Transfer Tag values are not specified by this protocol, except that the value 0xffffffff is reserved and means that the Target Transfer Tag is not supplied. If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command; otherwise, the LUN field is reserved.
此协议未指定目标传输标记值，但保留值0xffffffff，表示未提供目标传输标记。如果提供了目标传输标记，则LUN字段必须包含有效值，并与命令中指定的内容一致；否则，LUN字段将保留。
For input (read) or bidirectional Data-In PDUs, the DataSN is the input PDU number within the data transfer for the command identified by the Initiator Task Tag.
对于PDU中的输入（读取）或双向数据，DataSN是启动器任务标记标识的命令的数据传输中的输入PDU编号。
R2T and Data-In PDUs, in the context of bidirectional commands, share the numbering sequence (see Section 4.2.2.4).
在双向命令的上下文中，R2T和PDU中的数据共享编号顺序（见第4.2.2.4节）。
For output (write) data PDUs, the DataSN is the Data-Out PDU number within the current output sequence. Either the current output sequence is identified by the Initiator Task Tag (for unsolicited data) or it is a data sequence generated for one R2T (for data solicited through R2T).
对于输出（写入）数据PDU，DataSN是当前输出序列中的数据输出PDU编号。当前输出序列由启动器任务标记标识（对于未经请求的数据），或者是为一个R2T生成的数据序列（对于通过R2T请求的数据）。
The Buffer Offset field contains the offset of this PDU payload data within the complete data transfer. The sum of the buffer offset and length should not exceed the expected transfer length for the command.
缓冲区偏移量字段包含完整数据传输中此PDU有效负载数据的偏移量。缓冲区偏移量和长度之和不应超过命令的预期传输长度。
The order of data PDUs within a sequence is determined by DataPDUInOrder. When set to Yes, it means that PDUs have to be in increasing buffer offset order and overlays are forbidden.
序列中数据PDU的顺序由DataPDUInOrder确定。当设置为“是”时，这意味着PDU必须处于递增的缓冲区偏移顺序，并且禁止覆盖。
The ordering between sequences is determined by DataSequenceInOrder. When set to Yes, it means that sequences have to be in increasing buffer offset order and overlays are forbidden.
序列之间的顺序由DataSequenceInOrder确定。当设置为“是”时，这意味着序列必须以递增的缓冲区偏移顺序进行，并且禁止重叠。
This is the data payload length of a SCSI Data-In or SCSI Data-Out PDU. The sending of 0-length data segments should be avoided, but initiators and targets MUST be able to properly receive 0-length data segments.
这是SCSI数据输入或SCSI数据输出PDU的数据有效负载长度。应避免发送0长度数据段，但启动器和目标必须能够正确接收0长度数据段。
The data segments of Data-In and Data-Out PDUs SHOULD be filled to the integer number of 4-byte words (real payload), unless the F bit is set to 1.
除非F位设置为1，否则数据输入和数据输出PDU的数据段应填充为4字节字的整数（实际有效负载）。
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|.|.| 0x31 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| R2TSN |
+---------------+---------------+---------------+---------------+
40| Buffer Offset |
+---------------+---------------+---------------+---------------+
44| Desired Data Transfer Length |
+---------------------------------------------------------------+
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|.|.| 0x31 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| R2TSN |
+---------------+---------------+---------------+---------------+
40| Buffer Offset |
+---------------+---------------+---------------+---------------+
44| Desired Data Transfer Length |
+---------------------------------------------------------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
When an initiator has submitted a SCSI command with data that passes from the initiator to the target (write), the target may specify which blocks of data it is ready to receive. The target may request that the data blocks be delivered in whichever order is convenient for the target at that particular instant. This information is passed from the target to the initiator in the Ready To Transfer (R2T) PDU.
当启动器提交了SCSI命令，其中包含从启动器传递到目标（写入）的数据时，目标可能会指定准备接收的数据块。目标可以请求在该特定时刻以对目标方便的任何顺序交付数据块。此信息在准备传输（R2T）PDU中从目标传递到启动器。
In order to allow write operations without an explicit initial R2T, the initiator and target MUST have negotiated the key InitialR2T to No during login.
为了允许在没有显式初始R2T的情况下执行写操作，启动器和目标必须在登录期间将密钥初始R2T协商为No。
An R2T MAY be answered with one or more SCSI Data-Out PDUs with a matching Target Transfer Tag. If an R2T is answered with a single Data-Out PDU, the buffer offset in the data PDU MUST be the same as
R2T可以使用一个或多个SCSI数据输出PDU以及匹配的目标传输标记进行应答。如果R2T由单个数据输出PDU应答，则数据PDU中的缓冲区偏移量必须与
the one specified by the R2T, and the data length of the data PDU MUST be the same as the Desired Data Transfer Length specified in the R2T. If the R2T is answered with a sequence of data PDUs, the buffer offset and length MUST be within the range of those specified by the R2T, and the last PDU MUST have the F bit set to 1. If the last PDU (marked with the F bit) is received before the Desired Data Transfer Length is transferred, a target MAY choose to reject that PDU with the "Protocol Error" reason code. DataPDUInOrder governs the Data-Out PDU ordering. If DataPDUInOrder is set to Yes, the buffer offsets and lengths for consecutive PDUs MUST form a continuous non-overlapping range, and the PDUs MUST be sent in increasing offset order.
R2T指定的数据传输长度，并且数据PDU的数据长度必须与R2T中指定的所需数据传输长度相同。如果R2T由一系列数据PDU应答，则缓冲区偏移量和长度必须在R2T指定的范围内，并且最后一个PDU的F位必须设置为1。如果在传输所需数据传输长度之前接收到最后一个PDU（用F位标记），则目标可以选择使用“协议错误”原因码拒绝该PDU。DataPDUInOrder控制数据输出PDU顺序。如果DataPDUInOrder设置为Yes，则连续PDU的缓冲区偏移量和长度必须形成连续的非重叠范围，并且必须以递增的偏移量顺序发送PDU。
The target may send several R2T PDUs. It therefore can have a number of pending data transfers. The number of outstanding R2T PDUs is limited by the value of the negotiated key MaxOutstandingR2T. Within a task, outstanding R2Ts MUST be fulfilled by the initiator in the order in which they were received.
目标可以发送多个R2T PDU。因此，它可以有许多挂起的数据传输。未完成R2T PDU的数量受协商密钥MaxOutstandingR2T的值限制。在任务中，未完成的R2T必须由发起者按照接收顺序完成。
R2T PDUs MAY also be used to recover Data-Out PDUs. Such an R2T (Recovery-R2T) is generated by a target upon detecting the loss of one or more Data-Out PDUs due to:
R2T PDU也可用于从PDU中恢复数据。这样的R2T（Recovery-R2T）由目标在检测到PDU中的一个或多个数据丢失时生成，原因是：
- Digest error
- 摘要错误
- Sequence error
- 序列错误
- Sequence reception timeout
- 序列接收超时
A Recovery-R2T carries the next unused R2TSN but requests part of or the entire data burst that an earlier R2T (with a lower R2TSN) had already requested.
Recovery-R2T携带下一个未使用的R2TSN，但请求早期R2T（具有较低的R2TSN）已经请求的部分或全部数据突发。
DataSequenceInOrder governs the buffer offset ordering in consecutive R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts MUST refer to continuous non-overlapping ranges, except for Recovery-R2Ts.
DataSequenceInOrder控制连续R2T中的缓冲区偏移量顺序。如果DataSequenceInOrder为是，则连续R2T必须指连续的非重叠范围，Recovery-R2T除外。
For this PDU, TotalAHSLength and DataSegmentLength MUST be 0.
对于此PDU，TotalAHSLength和DataSegmentLength必须为0。
R2TSN is the R2T PDU input PDU number within the command identified by the Initiator Task Tag.
R2TSN是启动器任务标记标识的命令中的R2T PDU输入PDU编号。
For bidirectional commands, R2T and Data-In PDUs share the input PDU numbering sequence (see Section 4.2.2.4).
对于双向命令，R2T和PDU中的数据共享输入PDU编号顺序（见第4.2.2.4节）。
The StatSN field will contain the next StatSN. The StatSN for this connection is not advanced after this PDU is sent.
StatSN字段将包含下一个StatSN。发送此PDU后，此连接的StatSN不高级。
The target specifies how many bytes it wants the initiator to send because of this R2T PDU. The target may request the data from the initiator in several chunks, not necessarily in the original order of the data. The target therefore also specifies a buffer offset that indicates the point at which the data transfer should begin, relative to the beginning of the total data transfer. The Desired Data Transfer Length MUST NOT be 0 and MUST NOT exceed MaxBurstLength.
目标指定由于此R2T PDU而希望启动器发送的字节数。目标可以以几个块的形式从发起方请求数据，不一定按照数据的原始顺序。因此，目标还指定一个缓冲区偏移量，该偏移量指示相对于总数据传输的开始，数据传输应开始的点。所需的数据传输长度不得为0，且不得超过MaxBurstLength。
The target assigns its own tag to each R2T request that it sends to the initiator. This tag can be used by the target to easily identify the data it receives. The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are only used by the target. There is no protocol rule about the Target Transfer Tag except that the value 0xffffffff is reserved and MUST NOT be sent by a target in an R2T.
目标将自己的标记分配给它发送给启动器的每个R2T请求。目标可以使用此标记轻松识别其接收的数据。目标传输标记和LUN复制到传出数据PDU中，并且仅由目标使用。关于目标传输标记没有协议规则，除了值0xffffffff是保留的，并且不能由R2T中的目标发送。
An Asynchronous Message may be sent from the target to the initiator without corresponding to a particular command. The target specifies the reason for the event and sense 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|.|.| 0x32 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| AsyncEvent | AsyncVCode | Parameter1 or Reserved |
+---------------+---------------+---------------+---------------+
40| Parameter2 or Reserved | Parameter3 or Reserved |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment - Sense Data and iSCSI Event Data /
+/ /
+---------------+---------------+---------------+---------------+
| 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|.|.| 0x32 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| AsyncEvent | AsyncVCode | Parameter1 or Reserved |
+---------------+---------------+---------------+---------------+
40| Parameter2 or Reserved | Parameter3 or Reserved |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment - Sense Data and iSCSI Event Data /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (optional) |
+---------------+---------------+---------------+---------------+
Some Asynchronous Messages are strictly related to iSCSI, while others are related to SCSI [SAM2].
有些异步消息严格与iSCSI相关，而另一些则与SCSI[SAM2]相关。
The StatSN counts this PDU as an acknowledgeable event (the StatSN is advanced), which allows for initiator and target state synchronization.
StatSN将此PDU统计为可确认事件（StatSN为高级），这允许启动器和目标状态同步。
The codes used for iSCSI Asynchronous Messages (events) are:
用于iSCSI异步消息（事件）的代码为：
0 (SCSI Async Event) - a SCSI asynchronous event is reported in the sense data. Sense Data that accompanies the report, in the data segment, identifies the condition. The sending of a SCSI event ("asynchronous event reporting" in SCSI terminology) is dependent on the target support for SCSI asynchronous event reporting (see [SAM2]) as indicated in the standard INQUIRY data (see [SPC3]). Its use may be enabled by parameters in the SCSI Control mode page (see [SPC3]).
0（SCSI异步事件）-在检测数据中报告SCSI异步事件。在数据段中，检测报告随附的数据，以识别状况。SCSI事件的发送（SCSI术语中的“异步事件报告”）取决于对SCSI异步事件报告的目标支持（参见[SAM2]），如标准查询数据（参见[SPC3]）中所示。它的使用可以通过SCSI控制模式页面中的参数启用（请参见[SPC3]）。
1 (Logout Request) - the target requests Logout. This Async Message MUST be sent on the same connection as the one requesting to be logged out. The initiator MUST honor this request by issuing a Logout as early as possible but no later than Parameter3 seconds. The initiator MUST send a Logout with a reason code of "close the connection" OR "close the session" to close all the connections. Once this message is received, the initiator SHOULD NOT issue new iSCSI commands on the connection to be logged out. The target MAY reject any new I/O requests that it receives after this message with the reason code "Waiting for Logout". If the initiator does not log out in Parameter3 seconds, the target should send an Async PDU with iSCSI event code "Dropped the connection" if possible or simply terminate the transport connection. Parameter1 and Parameter2 are reserved.
1（注销请求）-目标请求注销。此异步消息必须在请求注销的连接上发送。发起者必须通过尽早但不迟于Parameter3秒发出注销来满足此请求。发起者必须发送一个带有“关闭连接”或“关闭会话”原因码的注销，以关闭所有连接。收到此消息后，启动器不应在要注销的连接上发出新的iSCSI命令。目标可能会拒绝在此消息之后收到的任何新I/O请求，原因码为“等待注销”。如果启动器未在参数3秒内注销，则目标应发送一个异步PDU，其中包含iSCSI事件代码“已断开连接”（如果可能），或者干脆终止传输连接。参数1和参数2是保留的。
2 (Connection Drop Notification) - the target indicates that it will drop the connection.
2（连接断开通知）-目标表示它将断开连接。
The Parameter1 field indicates the CID of the connection that is going to be dropped.
Parameter1字段表示要断开的连接的CID。
The Parameter2 field (Time2Wait) indicates, in seconds, the minimum time to wait before attempting to reconnect or reassign.
Parameter2字段（Time2Wait）以秒为单位指示尝试重新连接或重新分配前的最短等待时间。
The Parameter3 field (Time2Retain) indicates the maximum time allowed to reassign commands after the initial wait (in Parameter2).
Parameter3字段（Time2Retain）表示初始等待（在Parameter2中）后重新分配命令所允许的最长时间。
If the initiator does not attempt to reconnect and/or reassign the outstanding commands within the time specified by Parameter3, or if Parameter3 is 0, the target will terminate
如果启动器未在参数3指定的时间内尝试重新连接和/或重新分配未完成的命令，或者如果参数3为0，则目标将终止
all outstanding commands on this connection. In this case, no other responses should be expected from the target for the outstanding commands on this connection.
此连接上所有未完成的命令。在这种情况下，对于此连接上的未完成命令，不应期望目标做出其他响应。
A value of 0 for Parameter2 indicates that reconnect can be attempted immediately.
参数2的值为0表示可以立即尝试重新连接。
3 (Session Drop Notification) - the target indicates that it will drop all the connections of this session.
3（会话删除通知）-目标表示它将删除此会话的所有连接。
The Parameter1 field is reserved.
参数1字段是保留的。
The Parameter2 field (Time2Wait) indicates, in seconds, the minimum time to wait before attempting to reconnect.
Parameter2字段（Time2Wait）以秒为单位指示尝试重新连接前的最短等待时间。
The Parameter3 field (Time2Retain) indicates the maximum time allowed to reassign commands after the initial wait (in Parameter2).
Parameter3字段（Time2Retain）表示初始等待（在Parameter2中）后重新分配命令所允许的最长时间。
If the initiator does not attempt to reconnect and/or reassign the outstanding commands within the time specified by Parameter3, or if Parameter3 is 0, the session is terminated. In this case, the target will terminate all outstanding commands in this session; no other responses should be expected from the target for the outstanding commands in this session. A value of 0 for Parameter2 indicates that reconnect can be attempted immediately.
如果启动器未在参数3指定的时间内尝试重新连接和/或重新分配未完成的命令，或者如果参数3为0，则会话终止。在这种情况下，目标将终止此会话中所有未完成的命令；对于此会话中未完成的命令，不应期望目标做出其他响应。参数2的值为0表示可以立即尝试重新连接。
4 (Negotiation Request) - the target requests parameter negotiation on this connection. The initiator MUST honor this request by issuing a Text Request (that can be empty) on the same connection as early as possible, but no later than Parameter3 seconds, unless a Text Request is already pending on the connection, or by issuing a Logout Request. If the initiator does not issue a Text Request, the target may reissue the Asynchronous Message requesting parameter negotiation.
4（协商请求）-目标请求在此连接上进行参数协商。发起者必须尽可能早地在同一连接上发出文本请求（可以为空），但不得晚于Parameter3秒，以满足此请求，除非文本请求已在连接上挂起，或者发出注销请求。如果发起方未发出文本请求，则目标方可重新发出请求参数协商的异步消息。
5 (Task Termination) - all active tasks for a LU with a matching LUN field in the Async Message PDU are being terminated. The receiving initiator iSCSI layer MUST respond to this message by taking the following steps, in order:
5（任务终止）-正在终止异步消息PDU中具有匹配LUN字段的LU的所有活动任务。接收启动器iSCSI层必须通过以下步骤响应此消息：
- Stop Data-Out transfers on that connection for all active TTTs for the affected LUN quoted in the Async Message PDU.
- 停止异步消息PDU中引用的受影响LUN的所有活动TTT在该连接上的数据输出传输。
- Acknowledge the StatSN of the Async Message PDU via a NOP-Out PDU with ITT=0xffffffff (i.e., non-ping flavor), while copying the LUN field from the Async Message to NOP-Out.
- 通过NOP Out PDU确认异步消息PDU的StatSN，ITT=0xFFFFFF（即非ping风格），同时将LUN字段从异步消息复制到NOP Out。
This value of AsyncEvent, however, MUST NOT be used on an iSCSI session unless the new TaskReporting text key defined in Section 13.23 was negotiated to FastAbort on the session.
但是，除非第13.23节中定义的新TaskReporting文本键在会话上协商为FastAbort，否则不得在iSCSI会话上使用AsyncEvent的此值。
248-255 (Vendor-unique) - vendor-specific iSCSI event. The AsyncVCode details the vendor code, and data MAY accompany the report.
248-255（供应商唯一）-特定于供应商的iSCSI事件。AsyncVCode详细说明了供应商代码，报告中可能附带数据。
All other event codes are unassigned.
所有其他事件代码均未分配。
AsyncVCode is a vendor-specific detail code that is only valid if the AsyncEvent field indicates a vendor-specific event. Otherwise, it is reserved.
AsyncVCode是特定于供应商的详细信息代码，仅当AsyncEvent字段指示特定于供应商的事件时才有效。否则，它是保留的。
The LUN field MUST be valid if AsyncEvent is 0. Otherwise, this field is reserved.
如果AsyncEvent为0，则LUN字段必须有效。否则，此字段将保留。
For a SCSI event, this data accompanies the report in the data segment and identifies the condition.
对于SCSI事件，此数据伴随数据段中的报告，并标识状态。
For an iSCSI event, additional vendor-unique data MAY accompany the Async event. Initiators MAY ignore the data when not understood, while processing the rest of the PDU.
对于iSCSI事件，异步事件可能附带其他供应商唯一数据。在处理PDU的其余部分时，启动器可能会忽略未理解的数据。
If the DataSegmentLength is not 0, the format of the DataSegment is as follows:
如果DataSegmentLength不是0，则DataSegment的格式如下：
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/ iSCSI Event Data /
/ /
+---------------+---------------+---------------+---------------+
z|
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/ iSCSI Event Data /
/ /
+---------------+---------------+---------------+---------------+
z|
This is the length of Sense Data. When the Sense Data field is empty (e.g., the event is not a SCSI event), SenseLength is 0.
这是检测数据的长度。当检测数据字段为空（例如，事件不是SCSI事件）时，SenseLength为0。
The Text Request is provided to allow for the exchange of information and for future extensions. It permits the initiator to inform a target of its capabilities or request some special operations.
提供文本请求是为了便于交换信息和今后的扩展。它允许发起者通知目标其能力或请求某些特殊操作。
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| 0x04 |F|C| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment (Text) /
+/ /
+---------------+---------------+---------------+---------------+
| 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| 0x04 |F|C| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment (Text) /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (optional) |
+---------------+---------------+---------------+---------------+
An initiator MUST NOT have more than one outstanding Text Request on a connection at any given time.
在任何给定时间，启动器在连接上的未完成文本请求不得超过一个。
On a connection failure, an initiator must either explicitly abort any active allegiant text negotiation task or cause such a task to be implicitly terminated by the target.
在连接失败时，启动器必须显式中止任何活动的allegiant文本协商任务，或使目标隐式终止此类任务。
When set to 1, this bit indicates that this is the last or only Text Request in a sequence of Text Requests; otherwise, it indicates that more Text Requests will follow.
当设置为1时，该位表示这是文本请求序列中的最后一个或唯一一个文本请求；否则，它表示将有更多的文本请求。
When set to 1, this bit indicates that the text (set of key=value pairs) in this Text Request is not complete (it will be continued on subsequent Text Requests); otherwise, it indicates that this Text Request ends a set of key=value pairs. A Text Request with the C bit set to 1 MUST have the F bit set to 0.
当设置为1时，此位表示此文本请求中的文本（键集=值对）不完整（将在后续文本请求中继续）；否则，它表示此文本请求结束一组键=值对。C位设置为1的文本请求必须将F位设置为0。
This is the initiator-assigned identifier for this Text Request. If the command is sent as part of a sequence of Text Requests and responses, the Initiator Task Tag MUST be the same for all the requests within the sequence (similar to linked SCSI commands). The I bit for all requests in a sequence also MUST be the same.
这是为该文本请求分配的启动器标识符。如果命令作为文本请求和响应序列的一部分发送，则序列中所有请求的启动器任务标记必须相同（类似于链接的SCSI命令）。序列中所有请求的I位也必须相同。
When the Target Transfer Tag is set to the reserved value 0xffffffff, it tells the target that this is a new request, and the target resets any internal state associated with the Initiator Task Tag (resets the current negotiation state).
当目标传输标记设置为保留值0xFFFFFF时，它会告诉目标这是一个新请求，并且目标会重置与启动器任务标记关联的任何内部状态（重置当前协商状态）。
The target sets the Target Transfer Tag in a Text Response to a value other than the reserved value 0xffffffff whenever it indicates that it has more data to send or more operations to perform that are associated with the specified Initiator Task Tag. It MUST do so whenever it sets the F bit to 0 in the response. By copying the Target Transfer Tag from the response to the next Text Request, the initiator tells the target to continue the operation for the specific Initiator Task Tag. The initiator MUST ignore the Target Transfer Tag in the Text Response when the F bit is set to 1.
目标在文本响应中将目标传输标记设置为保留值0xffffffff以外的值，只要它指示有更多数据要发送，或有更多操作要执行且与指定的启动器任务标记关联。每当它在响应中将F位设置为0时，它都必须这样做。通过将目标传输标记从响应复制到下一个文本请求，启动器告知目标继续特定启动器任务标记的操作。当F位设置为1时，启动器必须忽略文本响应中的目标传输标记。
This mechanism allows the initiator and target to transfer a large amount of textual data over a sequence of text-command/text-response exchanges or to perform extended negotiation sequences.
该机制允许发起方和目标方通过一系列文本命令/文本响应交换传输大量文本数据，或执行扩展协商序列。
If the Target Transfer Tag is not 0xffffffff, the LUN field MUST be sent by the target in the Text Response.
如果目标传输标记不是0xFFFFFF，则目标必须在文本响应中发送LUN字段。
A target MAY reset its internal negotiation state if an exchange is stalled by the initiator for a long time or if it is running out of resources.
如果发起方长时间暂停交换或资源不足，目标可能会重置其内部协商状态。
Long Text Responses are handled as shown in the following example:
长文本响应的处理如以下示例所示：
I->T Text SendTargets=All (F = 1, TTT = 0xffffffff)
I->T Text SendTargets=All (F = 1, TTT = 0xffffffff)
T->I Text <part 1> (F = 0, TTT = 0x12345678)
T->I Text <part 1> (F = 0, TTT = 0x12345678)
I->T Text <empty> (F = 1, TTT = 0x12345678)
I->T Text <empty> (F = 1, TTT = 0x12345678)
T->I Text <part 2> (F = 0, TTT = 0x12345678)
T->I Text <part 2> (F = 0, TTT = 0x12345678)
I->T Text <empty> (F = 1, TTT = 0x12345678)
I->T Text <empty> (F = 1, TTT = 0x12345678)
...
...
T->I Text <part n> (F = 1, TTT = 0xffffffff)
T->I Text <part n> (F = 1, TTT = 0xffffffff)
The data lengths of a Text Request MUST NOT exceed the iSCSI target MaxRecvDataSegmentLength (a parameter that is negotiated per connection and per direction). The text format is specified in Section 6.2.
文本请求的数据长度不得超过iSCSI目标MaxRecvDataSegmentLength（一个根据连接和方向协商的参数）。第6.2节规定了文本格式。
Sections 12 and 13 list some basic Text key=value pairs, some of which can be used in Login Requests/Responses and some in Text Requests/Responses.
第12节和第13节列出了一些基本的文本键=值对，其中一些可用于登录请求/响应，另一些可用于文本请求/响应。
A key=value pair can span Text Request or Text Response boundaries. A key=value pair can start in one PDU and continue on the next. In other words, the end of a PDU does not necessarily signal the end of a key=value pair.
键=值对可以跨越文本请求或文本响应边界。键=值对可以在一个PDU中开始，并在下一个PDU中继续。换句话说，PDU的结束不一定表示key=value对的结束。
The target responds by sending its response back to the initiator. The response text format is similar to the request text format. The Text Response MAY refer to key=value pairs presented in an earlier Text Request, and the text in the request may refer to earlier responses.
目标通过将其响应发送回启动器进行响应。响应文本格式类似于请求文本格式。文本响应可能引用先前文本请求中呈现的键=值对，请求中的文本可能引用先前的响应。
Section 6.2 details the rules for the Text Requests and Responses.
第6.2节详细说明了文本请求和响应的规则。
Text operations are usually meant for parameter setting/negotiations but can also be used to perform some long-lasting operations.
文本操作通常用于参数设置/协商，但也可用于执行一些长期操作。
Text operations that take a long time should be placed in their own Text Request.
需要很长时间的文本操作应该放在它们自己的文本请求中。
The Text Response PDU contains the target's responses to the initiator's Text Request. The format of the Text field matches that of the Text Request.
文本响应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|.|.| 0x24 |F|C| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment (Text) /
+/ /
+---------------+---------------+---------------+---------------+
| 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|.|.| 0x24 |F|C| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment (Text) /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (optional) |
+---------------+---------------+---------------+---------------+
When set to 1, in response to a Text Request with the Final bit set to 1, the F bit indicates that the target has finished the whole operation. Otherwise, if set to 0 in response to a Text Request with the Final Bit set to 1, it indicates that the target has more work to
当设置为1时，为了响应文本请求（最后一位设置为1），F位表示目标已完成整个操作。否则，如果为响应文本请求而将最后一位设置为1而将其设置为0，则表示目标有更多的工作要做
do (invites a follow-on Text Request). A Text Response with the F bit set to 1 in response to a Text Request with the F bit set to 0 is a protocol error.
do（邀请后续文本请求）。响应F位设置为0的文本请求时，F位设置为1的文本响应是协议错误。
A Text Response with the F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator.
F位设置为1的文本响应不得包含可能需要启动器提供额外答案的键=值对。
A Text Response with the F bit set to 1 MUST have a Target Transfer Tag field set to the reserved value 0xffffffff.
F位设置为1的文本响应必须将目标传输标记字段设置为保留值0xFFFFFF。
A Text Response with the F bit set to 0 MUST have a Target Transfer Tag field set to a value other than the reserved value 0xffffffff.
F位设置为0的文本响应必须将目标传输标记字段设置为保留值0xFFFFFF以外的值。
When set to 1, this bit indicates that the text (set of key=value pairs) in this Text Response is not complete (it will be continued on subsequent Text Responses); otherwise, it indicates that this Text Response ends a set of key=value pairs. A Text Response with the C bit set to 1 MUST have the F bit set to 0.
当设置为1时，此位表示此文本响应中的文本（键集=值对）不完整（将在后续文本响应中继续）；否则，它表示此文本响应结束一组键=值对。C位设置为1的文本响应必须将F位设置为0。
The Initiator Task Tag matches the tag used in the initial Text Request.
启动器任务标记与初始文本请求中使用的标记匹配。
When a target has more work to do (e.g., cannot transfer all the remaining text data in a single Text Response or has to continue the negotiation) and has enough resources to proceed, it MUST set the Target Transfer Tag to a value other than the reserved value 0xffffffff. Otherwise, the Target Transfer Tag MUST be set to 0xffffffff.
当目标有更多的工作要做（例如，无法在单个文本响应中传输所有剩余的文本数据或必须继续协商）并且有足够的资源继续进行时，它必须将目标传输标记设置为保留值0xFFFFFF以外的值。否则，目标传输标记必须设置为0xffffffff。
When the Target Transfer Tag is not 0xffffffff, the LUN field may be significant.
当目标传输标记不是0xFFFFFF时，LUN字段可能是有效的。
The initiator MUST copy the Target Transfer Tag and LUN in its next request to indicate that it wants the rest of the data.
启动器必须在其下一个请求中复制目标传输标记和LUN，以表明它需要其余的数据。
When the target receives a Text Request with the Target Transfer Tag set to the reserved value 0xffffffff, it resets its internal information (resets state) associated with the given Initiator Task Tag (restarts the negotiation).
当目标接收到文本请求且目标传输标记设置为保留值0xFFFFFF时，它将重置与给定启动器任务标记关联的内部信息（重置状态）（重新启动协商）。
When a target cannot finish the operation in a single Text Response and does not have enough resources to continue, it rejects the Text Request with the appropriate Reject code.
当目标无法在单个文本响应中完成操作且没有足够的资源继续时，它将使用适当的拒绝代码拒绝文本请求。
A target may reset its internal state associated with an Initiator Task Tag (the current negotiation state) as expressed through the Target Transfer Tag if the initiator fails to continue the exchange for some time. The target may reject subsequent Text Requests with the Target Transfer Tag set to the "stale" value.
如果启动器未能继续交换一段时间，则目标可以重置其与启动器任务标记（当前协商状态）关联的内部状态，如通过目标传输标记表示的。目标可能会拒绝将目标传输标记设置为“stale”值的后续文本请求。
The target StatSN variable is advanced by each Text Response sent.
目标StatSN变量由发送的每个文本响应推进。
The data lengths of a Text Response MUST NOT exceed the iSCSI initiator MaxRecvDataSegmentLength (a parameter that is negotiated per connection and per direction).
文本响应的数据长度不得超过iSCSI启动器MaxRecvDataSegmentLength（一个参数，可根据连接和方向协商）。
The text in the Text Response Data is governed by the same rules as the text in the Text Request Data (see Section 11.11.2).
文本响应数据中的文本受与文本请求数据中的文本相同的规则管辖（见第11.11.2节）。
Although the initiator is the requesting party and controls the request-response initiation and termination, the target can offer key=value pairs of its own as part of a sequence and not only in response to the initiator.
尽管发起方是请求方并控制请求-响应的启动和终止，但目标方可以提供自己的键=值对作为序列的一部分，而不仅仅是响应发起方。
After establishing a TCP connection between an initiator and a target, the initiator MUST start a Login Phase to gain further access to the target's resources.
在启动器和目标之间建立TCP连接后，启动器必须启动登录阶段以进一步访问目标的资源。
The Login Phase (see Section 6.3) consists of a sequence of Login Requests and Login Responses that carry the same Initiator Task Tag.
登录阶段（见第6.3节）由一系列带有相同启动器任务标记的登录请求和登录响应组成。
Login Requests are always considered as immediate.
登录请求总是被认为是立即的。
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|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| ISID |
+ +---------------+---------------+
12| | TSIH |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| CID | Reserved |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN or Reserved |
+---------------+---------------+---------------+---------------+
32| Reserved |
+---------------+---------------+---------------+---------------+
36| Reserved |
+---------------+---------------+---------------+---------------+
40/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48/ DataSegment - Login Parameters in Text Request Format /
+/ /
+---------------+---------------+---------------+---------------+
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|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| ISID |
+ +---------------+---------------+
12| | TSIH |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| CID | Reserved |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN or Reserved |
+---------------+---------------+---------------+---------------+
32| Reserved |
+---------------+---------------+---------------+---------------+
36| Reserved |
+---------------+---------------+---------------+---------------+
40/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48/ DataSegment - Login Parameters in Text Request Format /
+/ /
+---------------+---------------+---------------+---------------+
When set to 1, this bit indicates that the initiator is ready to transit to the next stage.
当设置为1时，此位表示启动器已准备好传输到下一阶段。
If the T bit is set to 1 and the NSG is set to FullFeaturePhase, then this also indicates that the initiator is ready for the Login Final-Response (see Section 6.3).
如果T位设置为1，且NSG设置为FullFeaturePhase，则这也表示启动器已准备好进行登录最终响应（参见第6.3节）。
When set to 1, this bit indicates that the text (set of key=value pairs) in this Login Request is not complete (it will be continued on subsequent Login Requests); otherwise, it indicates that this Login Request ends a set of key=value pairs. A Login Request with the C bit set to 1 MUST have the T bit set to 0.
当设置为1时，此位表示此登录请求中的文本（密钥集=值对）不完整（将在后续登录请求中继续）；否则，它表示此登录请求结束一组key=value对。C位设置为1的登录请求必须将T位设置为0。
Through these fields -- Current Stage (CSG) and Next Stage (NSG) -- the Login negotiation requests and responses are associated with a specific stage in the session (SecurityNegotiation, LoginOperationalNegotiation, FullFeaturePhase) and may indicate the next stage to which they want to move (see Section 6.3). The Next Stage value is only valid when the T bit is 1; otherwise, it is reserved.
通过这些字段——当前阶段（CSG）和下一阶段（NSG）——登录协商请求和响应与会话中的特定阶段（SecurityNegotiation、LoginOperationalNegotiation、FullFeaturePhase）相关联，并可能指示他们要移动到的下一阶段（参见第6.3节）。下一级值仅在T位为1时有效；否则，它是保留的。
The stage codes are:
阶段代码为：
0 - SecurityNegotiation
0-安全协商
1 - LoginOperationalNegotiation
1-物流运营谈判
3 - FullFeaturePhase
3-全功能阶段
All other codes are reserved.
所有其他代码均保留。
The version number for this document is 0x00. Therefore, both Version-min and Version-max MUST be set to 0x00.
此文档的版本号为0x00。因此，版本最小值和版本最大值都必须设置为0x00。
Version-max indicates the maximum version number supported.
Version max表示支持的最大版本号。
All Login Requests within the Login Phase MUST carry the same Version-max.
登录阶段中的所有登录请求都必须具有相同的版本max。
The target MUST use the value presented with the first Login Request.
目标必须使用第一个登录请求中提供的值。
All Login Requests within the Login Phase MUST carry the same Version-min. The target MUST use the value presented with the first Login Request.
登录阶段中的所有登录请求必须具有相同的Version-min。目标必须使用第一个登录请求中显示的值。
This is an initiator-defined component of the session identifier and is structured as follows (see Section 10.1.1 for details):
这是由启动器定义的会话标识符组件，其结构如下（详见第10.1.1节）：
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|
+---------------+---------------+---------------+---------------+
8| T | A | B | C |
+---------------+---------------+---------------+---------------+
12| D |
+---------------+---------------+
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|
+---------------+---------------+---------------+---------------+
8| T | A | B | C |
+---------------+---------------+---------------+---------------+
12| D |
+---------------+---------------+
The T field identifies the format and usage of A, B, C, and D as indicated below:
T字段标识A、B、C和D的格式和用法，如下所示：
T
T
00b OUI-Format
00b OUI格式
A and B: 22-bit OUI
A和B:22位OUI
(the I/G and U/L bits are omitted)
（省略I/G和U/L位）
C and D: 24-bit Qualifier
C和D:24位限定符
01b EN: Format (IANA Enterprise Number)
01b EN：格式（IANA企业编号）
A: Reserved
A:保留
B and C: EN (IANA Enterprise Number)
B和C:EN（IANA企业编号）
D: Qualifier
D:限定符
10b "Random"
10b“随机”
A: Reserved
A:保留
B and C: Random
B和C：随机的
D: Qualifier
D:限定符
11b A, B, C, and D: Reserved
11b A、B、C和D：保留
For the T field values 00b and 01b, a combination of A and B (for 00b) or B and C (for 01b) identifies the vendor or organization whose component (software or hardware) generates this ISID. A vendor or
对于T字段值00b和01b，a和B（对于00b）或B和C（对于01b）的组合标识其组件（软件或硬件）生成此ISID的供应商或组织。卖主
organization with one or more OUIs, or one or more Enterprise Numbers, MUST use at least one of these numbers and select the appropriate value for the T field when its components generate ISIDs. An OUI or EN MUST be set in the corresponding fields in network byte order (byte big-endian).
具有一个或多个OUI或一个或多个企业编号的组织必须至少使用其中一个编号，并在其组件生成ISID时为T字段选择适当的值。必须按照网络字节顺序（字节big-endian）在相应字段中设置OUI或EN。
If the T field is 10b, B and C are set to a random 24-bit unsigned integer value in network byte order (byte big-endian). See [RFC3721] for how this affects the principle of "conservative reuse".
如果T字段为10b，则B和C被设置为网络字节顺序（字节big-endian）的随机24位无符号整数值。参见[RFC3721]了解这对“保守重用”原则的影响。
The Qualifier field is a 16-bit or 24-bit unsigned integer value that provides a range of possible values for the ISID within the selected namespace. It may be set to any value within the constraints specified in the iSCSI protocol (see Sections 4.4.3 and 10.1.1).
限定符字段是一个16位或24位无符号整数值，它为选定命名空间内的ISID提供一系列可能的值。可以将其设置为iSCSI协议中规定的约束范围内的任何值（请参见第4.4.3节和第10.1.1节）。
The T field value of 11b is reserved.
保留11b的T字段值。
If the ISID is derived from something assigned to a hardware adapter or interface by a vendor as a preset default value, it MUST be configurable to a value assigned according to the SCSI port behavior desired by the system in which it is installed (see Sections 10.1.1 and 10.1.2). The resultant ISID MUST also be persistent over power cycles, reboot, card swap, etc.
如果ISID源于供应商作为预设默认值分配给硬件适配器或接口的某个内容，则它必须可配置为根据安装它的系统所需的SCSI端口行为分配的值（参见第10.1.1节和第10.1.2节）。生成的ISID还必须在电源循环、重新启动、卡交换等过程中保持不变。
The TSIH must be set in the first Login Request. The reserved value 0 MUST be used on the first connection for a new session. Otherwise, the TSIH sent by the target at the conclusion of the successful login of the first connection for this session MUST be used. The TSIH identifies to the target the associated existing session for this new connection.
必须在第一个登录请求中设置TSIH。新会话的第一个连接必须使用保留值0。否则，必须使用目标在成功登录此会话的第一个连接时发送的TSIH。TSIH向目标标识此新连接的关联现有会话。
All Login Requests within a Login Phase MUST carry the same TSIH.
登录阶段内的所有登录请求必须携带相同的TSIH。
The target MUST check the value presented with the first Login Request and act as specified in Section 6.3.1.
目标公司必须检查第一次登录请求中显示的值，并按照第6.3.1节的规定行事。
The CID provides a unique ID for this connection within the session.
CID为会话中的此连接提供唯一ID。
All Login Requests within the Login Phase MUST carry the same CID.
登录阶段中的所有登录请求必须携带相同的CID。
The target MUST use the value presented with the first Login Request.
目标必须使用第一个登录请求中提供的值。
A Login Request with a non-zero TSIH and a CID equal to that of an existing connection implies a logout of the connection followed by a login (see Section 6.3.4). For details regarding the implicit Logout Request, see Section 11.14.
具有非零TSIH和等于现有连接的CID的登录请求意味着先注销连接，然后再登录（参见第6.3.4节）。有关隐式注销请求的详细信息，请参阅第11.14节。
The CmdSN is either the initial command sequence number of a session (for the first Login Request of a session -- the "leading" login) or the command sequence number in the command stream if the login is for a new connection in an existing session.
CmdSN是会话的初始命令序列号（用于会话的第一个登录请求——“前导”登录），或者是命令流中的命令序列号（如果登录是用于现有会话中的新连接）。
Examples:
示例：
- Login on a leading connection: If the leading login carries the CmdSN 123, all other Login Requests in the same Login Phase carry the CmdSN 123, and the first non-immediate command in the Full Feature Phase also carries the CmdSN 123.
- 领先连接上的登录：如果领先登录携带CmdSN 123，则同一登录阶段中的所有其他登录请求都携带CmdSN 123，并且完整功能阶段中的第一个非即时命令也携带CmdSN 123。
- Login on other than a leading connection: If the current CmdSN at the time the first login on the connection is issued is 500, then that PDU carries CmdSN=500. Subsequent Login Requests that are needed to complete this Login Phase may carry a CmdSN higher than 500 if non-immediate requests that were issued on other connections in the same session advance the CmdSN.
- 在前导连接以外的其他连接上登录：如果在连接上发出第一次登录时的当前CmdSN为500，则该PDU携带CmdSN=500。如果在同一会话中的其他连接上发出的非即时请求使CmdSN提前，则完成此登录阶段所需的后续登录请求可能携带高于500的CmdSN。
If the Login Request is a leading Login Request, the target MUST use the value presented in the CmdSN as the target value for the ExpCmdSN.
如果登录请求是前导登录请求，则目标必须使用CmdSN中显示的值作为ExpCmdSN的目标值。
For the first Login Request on a connection, this is the ExpStatSN for the old connection, and this field is only valid if the Login Request restarts a connection (see Section 6.3.4).
对于连接上的第一个登录请求，这是旧连接的ExpStatSN，并且此字段仅在登录请求重新启动连接时有效（请参阅第6.3.4节）。
For subsequent Login Requests, it is used to acknowledge the Login Responses with their increasing StatSN values.
对于后续登录请求，它用于确认登录响应及其递增的StatSN值。
The initiator MUST provide some basic parameters in order to enable the target to determine if the initiator may use the target's resources and the initial text parameters for the security exchange.
启动器必须提供一些基本参数，以便使目标能够确定启动器是否可以使用目标的资源和安全交换的初始文本参数。
All the rules specified in Section 11.10.5 for Text Requests also hold for Login Requests. Keys and their explanations are listed in Section 12 (security negotiation keys) and in Section 13 (operational
第11.10.5节中规定的所有文本请求规则也适用于登录请求。第12节（安全协商密钥）和第13节（操作密钥）中列出了密钥及其说明
parameter negotiation keys). All keys listed in Section 13, except for the X extension formats, MUST be supported by iSCSI initiators and targets. Keys listed in Section 12 only need to be supported when the function to which they refer is mandatory to implement.
参数协商密钥）。第13节中列出的所有密钥（X扩展格式除外）必须由iSCSI启动器和目标支持。第12节中列出的键仅在它们所指的功能必须实现时才需要支持。
The Login Response indicates the progress and/or end of the Login Phase.
登录响应指示登录阶段的进度和/或结束。
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|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max |Version-active |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| ISID |
+ +---------------+---------------+
12| | TSIH |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| Status-Class | Status-Detail | Reserved |
+---------------+---------------+---------------+---------------+
40/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48/ DataSegment - Login Parameters in Text Request Format /
+/ /
+---------------+---------------+---------------+---------------+
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|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max |Version-active |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| ISID |
+ +---------------+---------------+
12| | TSIH |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| Status-Class | Status-Detail | Reserved |
+---------------+---------------+---------------+---------------+
40/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48/ DataSegment - Login Parameters in Text Request Format /
+/ /
+---------------+---------------+---------------+---------------+
This is the highest version number supported by the target.
这是目标支持的最高版本号。
All Login Responses within the Login Phase MUST carry the same Version-max.
登录阶段中的所有登录响应都必须具有相同的版本max。
The initiator MUST use the value presented as a response to the first Login Request.
启动器必须使用作为对第一个登录请求的响应而显示的值。
Version-active indicates the highest version supported by the target and initiator. If the target does not support a version within the range specified by the initiator, the target rejects the login and this field indicates the lowest version supported by the target.
Version active表示目标和启动器支持的最高版本。如果目标不支持启动器指定范围内的版本，则目标拒绝登录，此字段表示目标支持的最低版本。
All Login Responses within the Login Phase MUST carry the same Version-active.
登录阶段内的所有登录响应必须具有相同的活动版本。
The initiator MUST use the value presented as a response to the first Login Request.
启动器必须使用作为对第一个登录请求的响应而显示的值。
The TSIH is the target-assigned session-identifying handle. Its internal format and content are not defined by this protocol, except for the value 0, which is reserved. With the exception of the Login Final-Response in a new session, this field should be set to the TSIH provided by the initiator in the Login Request. For a new session, the target MUST generate a non-zero TSIH and ONLY return it in the Login Final-Response (see Section 6.3).
TSIH是目标分配的会话标识句柄。该协议未定义其内部格式和内容，但保留值0除外。除新会话中的登录最终响应外，此字段应设置为发起人在登录请求中提供的TSIH。对于新会话，目标必须生成非零TSIH，并且仅在登录最终响应中返回它（请参见第6.3节）。
For the first Login Response (the response to the first Login Request), this is the starting status sequence number for the connection. The next response of any kind -- including the next Login Response, if any, in the same Login Phase -- will carry this number + 1. This field is only valid if the Status-Class is 0.
对于第一个登录响应（对第一个登录请求的响应），这是连接的开始状态序列号。任何类型的下一个响应——包括同一登录阶段中的下一个登录响应（如果有）——都将携带这个数字+1。仅当状态类为0时，此字段才有效。
The Status returned in a Login Response indicates the execution status of the Login Phase. The status includes:
登录响应中返回的状态指示登录阶段的执行状态。状态包括：
Status-Class
地位等级
Status-Detail
状态详细信息
A Status-Class of 0 indicates success.
状态类为0表示成功。
A non-zero Status-Class indicates an exception. In this case, Status-Class is sufficient for a simple initiator to use when handling exceptions, without having to look at the Status-Detail.
非零状态类表示异常。在这种情况下，Status类足以让简单的启动器在处理异常时使用，而无需查看状态详细信息。
The Status-Detail allows finer-grained exception handling for more sophisticated initiators and for better information for logging.
状态详细信息允许对更复杂的启动器进行更细粒度的异常处理，并为日志记录提供更好的信息。
The Status-Classes are as follows:
状态类别如下所示：
0 Success - indicates that the iSCSI target successfully received, understood, and accepted the request. The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if Status-Class is 0.
0成功-表示iSCSI目标已成功接收、理解和接受请求。仅当状态类为0时，编号字段（StatSN、ExpCmdSN、MaxCmdSN）才有效。
1 Redirection - indicates that the initiator must take further action to complete the request. This is usually due to the target moving to a different address. All of the redirection Status-Class responses MUST return one or more text key parameters of the type "TargetAddress", which indicates the target's new address. A redirection response MAY be issued by a target prior to or after completing a security negotiation if a security negotiation is required. A redirection SHOULD be accepted by an initiator, even without having the target complete a security negotiation if any security negotiation is required, and MUST be accepted by the initiator after the completion of the security negotiation if any security negotiation is required.
1重定向-表示启动器必须采取进一步的操作来完成请求。这通常是由于目标移动到不同的地址。所有重定向状态类响应必须返回一个或多个类型为“TargetAddress”的文本键参数，该参数指示目标的新地址。如果需要安全协商，则目标可以在完成安全协商之前或之后发出重定向响应。如果需要任何安全协商，则即使目标没有完成安全协商，发起方也应接受重定向；如果需要任何安全协商，则重定向必须在安全协商完成后被发起方接受。
2 Initiator Error (not a format error) - indicates that the initiator most likely caused the error. This MAY be due to a request for a resource for which the initiator does not have permission. The request should not be tried again.
2启动器错误（不是格式错误）-表示最有可能是启动器导致错误。这可能是由于请求了启动器没有权限的资源。不应再次尝试该请求。
3 Target Error - indicates that the target sees no errors in the initiator's Login Request but is currently incapable of fulfilling the request. The initiator may retry the same Login Request later.
3目标错误-表示目标在启动器的登录请求中未发现错误，但当前无法完成请求。启动器稍后可能会重试相同的登录请求。
The table below shows all of the currently allocated status codes. The codes are in hexadecimal; the first byte is the Status-Class, and the second byte is the status detail.
下表显示了当前分配的所有状态代码。代码是十六进制的；第一个字节是状态类，第二个字节是状态详细信息。
-----------------------------------------------------------------
Status | Code | Description
|(hex) |
-----------------------------------------------------------------
Success | 0000 | Login is proceeding OK (*1).
-----------------------------------------------------------------
Target moved | 0101 | The requested iSCSI Target Name (ITN)
temporarily | | has temporarily moved
| | to the address provided.
-----------------------------------------------------------------
Target moved | 0102 | The requested ITN has permanently moved
permanently | | to the address provided.
-----------------------------------------------------------------
Initiator | 0200 | Miscellaneous iSCSI initiator
error | | errors.
-----------------------------------------------------------------
Authentication| 0201 | The initiator could not be
failure | | successfully authenticated or target
| | authentication is not supported.
-----------------------------------------------------------------
Authorization | 0202 | The initiator is not allowed access
failure | | to the given target.
-----------------------------------------------------------------
Not found | 0203 | The requested ITN does not
| | exist at this address.
-----------------------------------------------------------------
Target removed| 0204 | The requested ITN has been removed, and
| | no forwarding address is provided.
-----------------------------------------------------------------
Unsupported | 0205 | The requested iSCSI version range is
version | | not supported by the target.
-----------------------------------------------------------------
Too many | 0206 | Too many connections on this SSID.
connections | |
-----------------------------------------------------------------
Missing | 0207 | Missing parameters (e.g., iSCSI
parameter | | Initiator Name and/or Target Name).
-----------------------------------------------------------------
Can't include | 0208 | Target does not support session
in session | | spanning to this connection (address).
-----------------------------------------------------------------
Session type | 0209 | Target does not support this type of
not supported | | session or not from this initiator.
-----------------------------------------------------------------
-----------------------------------------------------------------
Status | Code | Description
|(hex) |
-----------------------------------------------------------------
Success | 0000 | Login is proceeding OK (*1).
-----------------------------------------------------------------
Target moved | 0101 | The requested iSCSI Target Name (ITN)
temporarily | | has temporarily moved
| | to the address provided.
-----------------------------------------------------------------
Target moved | 0102 | The requested ITN has permanently moved
permanently | | to the address provided.
-----------------------------------------------------------------
Initiator | 0200 | Miscellaneous iSCSI initiator
error | | errors.
-----------------------------------------------------------------
Authentication| 0201 | The initiator could not be
failure | | successfully authenticated or target
| | authentication is not supported.
-----------------------------------------------------------------
Authorization | 0202 | The initiator is not allowed access
failure | | to the given target.
-----------------------------------------------------------------
Not found | 0203 | The requested ITN does not
| | exist at this address.
-----------------------------------------------------------------
Target removed| 0204 | The requested ITN has been removed, and
| | no forwarding address is provided.
-----------------------------------------------------------------
Unsupported | 0205 | The requested iSCSI version range is
version | | not supported by the target.
-----------------------------------------------------------------
Too many | 0206 | Too many connections on this SSID.
connections | |
-----------------------------------------------------------------
Missing | 0207 | Missing parameters (e.g., iSCSI
parameter | | Initiator Name and/or Target Name).
-----------------------------------------------------------------
Can't include | 0208 | Target does not support session
in session | | spanning to this connection (address).
-----------------------------------------------------------------
Session type | 0209 | Target does not support this type of
not supported | | session or not from this initiator.
-----------------------------------------------------------------
Session does | 020a | Attempt to add a connection
not exist | | to a non-existent session.
-----------------------------------------------------------------
Invalid during| 020b | Invalid request type during login.
login | |
-----------------------------------------------------------------
Target error | 0300 | Target hardware or software error.
-----------------------------------------------------------------
Service | 0301 | The iSCSI service or target is not
unavailable | | currently operational.
-----------------------------------------------------------------
Out of | 0302 | The target has insufficient session,
resources | | connection, or other resources.
-----------------------------------------------------------------
Session does | 020a | Attempt to add a connection
not exist | | to a non-existent session.
-----------------------------------------------------------------
Invalid during| 020b | Invalid request type during login.
login | |
-----------------------------------------------------------------
Target error | 0300 | Target hardware or software error.
-----------------------------------------------------------------
Service | 0301 | The iSCSI service or target is not
unavailable | | currently operational.
-----------------------------------------------------------------
Out of | 0302 | The target has insufficient session,
resources | | connection, or other resources.
-----------------------------------------------------------------
(*1) If the response T bit is set to 1 in both the request and the matching response, and the NSG is set to FullFeaturePhase in both the request and the matching response, the Login Phase is finished, and the initiator may proceed to issue SCSI commands.
（*1）如果响应T位在请求和匹配响应中均设置为1，且NSG在请求和匹配响应中均设置为FullFeaturePhase，则登录阶段结束，启动器可继续发出SCSI命令。
If the Status-Class is not 0, the initiator and target MUST close the TCP connection.
如果状态类不是0，则启动器和目标必须关闭TCP连接。
If the target wishes to reject the Login Request for more than one reason, it should return the primary reason for the rejection.
如果目标公司希望出于多个原因拒绝登录请求，则应返回拒绝的主要原因。
The T bit is set to 1 as an indicator of the end of the stage. If the T bit is set to 1 and the NSG is set to FullFeaturePhase, then this is also the Login Final-Response (see Section 6.3). A T bit of 0 indicates a "partial" response, which means "more negotiation needed".
T位设置为1，作为阶段结束的指示器。如果T位设置为1，NSG设置为FullFeaturePhase，则这也是登录的最终响应（参见第6.3节）。T位为0表示“部分”响应，表示“需要更多协商”。
A Login Response with the T bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator within the same stage.
T位设置为1的登录响应不得包含可能需要启动器在同一阶段提供额外答案的key=value对。
If the Status-Class is 0, the T bit MUST NOT be set to 1 if the T bit in the request was set to 0.
如果状态类为0，则如果请求中的T位设置为0，则T位不得设置为1。
When set to 1, this bit indicates that the text (set of key=value pairs) in this Login Response is not complete (it will be continued on subsequent Login Responses); otherwise, it indicates that this Login Response ends a set of key=value pairs. A Login Response with the C bit set to 1 MUST have the T bit set to 0.
当设置为1时，此位表示此登录响应中的文本（密钥集=值对）不完整（将在后续登录响应中继续）；否则，它表示此登录响应结束一组key=value对。C位设置为1的登录响应必须将T位设置为0。
The target MUST provide some basic parameters in order to enable the initiator to determine if it is connected to the correct port and the initial text parameters for the security exchange.
目标必须提供一些基本参数，以便使启动器能够确定它是否连接到正确的端口以及安全交换的初始文本参数。
All the rules specified in Section 11.11.6 for Text Responses also hold for Login Responses. Keys and their explanations are listed in Section 12 (security negotiation keys) and in Section 13 (operational parameter negotiation keys). All keys listed in Section 13, except for the X extension formats, MUST be supported by iSCSI initiators and targets. Keys listed in Section 12 only need to be supported when the function to which they refer is mandatory to implement.
第11.11.6节中为文本响应指定的所有规则也适用于登录响应。第12节（安全协商密钥）和第13节（操作参数协商密钥）中列出了密钥及其说明。第13节中列出的所有密钥（X扩展格式除外）必须由iSCSI启动器和目标支持。第12节中列出的键仅在它们所指的功能必须实现时才需要支持。
The Logout Request is used to perform a controlled closing of a connection.
注销请求用于执行连接的受控关闭。
An initiator MAY use a Logout Request to remove a connection from a session or to close an entire session.
启动器可以使用注销请求从会话中删除连接或关闭整个会话。
After sending the Logout Request PDU, an initiator MUST NOT send any new iSCSI requests on the closing connection. If the Logout Request is intended to close the session, new iSCSI requests MUST NOT be sent on any of the connections participating in the session.
发送注销请求PDU后，启动器不得在关闭的连接上发送任何新的iSCSI请求。如果注销请求旨在关闭会话，则不得在参与会话的任何连接上发送新的iSCSI请求。
When receiving a Logout Request with the reason code "close the connection" or "close the session", the target MUST terminate all pending commands, whether acknowledged via the ExpCmdSN or not, on that connection or session, respectively.
当接收到原因码为“关闭连接”或“关闭会话”的注销请求时，目标必须分别终止该连接或会话上的所有挂起命令，无论是否通过ExpCmdSN确认。
When receiving a Logout Request with the reason code "remove the connection for recovery", the target MUST discard all requests not yet acknowledged via the ExpCmdSN that were issued on the specified connection and suspend all data/status/R2T transfers on behalf of pending commands on the specified connection.
当接收到原因码为“remove the connection for recovery”的注销请求时，目标必须放弃在指定连接上发出的所有尚未通过ExpCmdSN确认的请求，并代表指定连接上的挂起命令暂停所有数据/状态/R2T传输。
The target then issues the Logout Response and half-closes the TCP connection (sends FIN). After receiving the Logout Response and attempting to receive the FIN (if still possible), the initiator MUST completely close the logging-out connection. For the terminated commands, no additional responses should be expected.
然后，目标发出注销响应，一半关闭TCP连接（发送FIN）。在收到注销响应并尝试接收FIN（如果仍然可能）后，启动器必须完全关闭注销连接。对于终止的命令，不应期望有其他响应。
A Logout for a CID may be performed on a different transport connection when the TCP connection for the CID has already been terminated. In such a case, only a logical "closing" of the iSCSI connection for the CID is implied with a Logout.
当CID的TCP连接已经终止时，可以在不同的传输连接上执行CID的注销。在这种情况下，注销仅意味着对CID的iSCSI连接进行逻辑“关闭”。
All commands that were not terminated or not completed (with status) and acknowledged when the connection is closed completely can be reassigned to a new connection if the target supports connection recovery.
如果目标支持连接恢复，则可以将所有未终止或未完成（状态为）并在连接完全关闭时确认的命令重新分配给新连接。
If an initiator intends to start recovery for a failing connection, it MUST use the Logout Request to "clean up" the target end of a failing connection and enable recovery to start, or use the Login Request with a non-zero TSIH and the same CID on a new connection for the same effect. In sessions with a single connection, the connection can be closed and then a new connection reopened. A connection reinstatement login can be used for recovery (see Section 6.3.4).
如果启动器打算为故障连接启动恢复，则必须使用注销请求“清理”故障连接的目标端并启用恢复启动，或者在新连接上使用具有非零TSIH和相同CID的登录请求以实现相同效果。在具有单个连接的会话中，可以关闭连接，然后重新打开新连接。连接恢复登录可用于恢复（见第6.3.4节）。
A successful completion of a Logout Request with the reason code "close the connection" or "remove the connection for recovery" results at the target in the discarding of unacknowledged commands received on the connection being logged out. These are commands that have arrived on the connection being logged out but that have not been delivered to SCSI because one or more commands with a smaller CmdSN have not been received by iSCSI. See Section 4.2.2.1. The resulting holes in the command sequence numbers will have to be handled by appropriate recovery (see Section 7), unless the session is also closed.
成功完成注销请求（原因码为“关闭连接”或“删除连接以便恢复”）会导致目标放弃注销连接时收到的未确认命令。这些是在注销连接时到达的命令，但由于iSCSI未接收到一个或多个具有较小CmdSN的命令，因此尚未传递到SCSI。见第4.2.2.1节。命令序列号中产生的漏洞必须通过适当的恢复处理（见第7节），除非会话也关闭。
The entire logout discussion in this section is also applicable for an implicit Logout realized by way of a connection reinstatement or session reinstatement. When a Login Request performs an implicit Logout, the implicit Logout is performed as if having the reason codes specified below:
本节中的整个注销讨论也适用于通过连接恢复或会话恢复实现的隐式注销。当登录请求执行隐式注销时，隐式注销的执行就好像具有以下指定的原因代码一样：
Reason Code Type of Implicit Logout
-------------------------------------------------------------
Reason Code Type of Implicit Logout
-------------------------------------------------------------
0 session reinstatement
0会话恢复
1 connection reinstatement when the operational ErrorRecoveryLevel < 2
1当操作错误恢复级别<2时，连接恢复
2 connection reinstatement when the operational ErrorRecoveryLevel = 2
2当操作错误RecoveryLevel=2时恢复连接
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| 0x06 |1| Reason Code | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------------------------------------------------------+
8/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| CID or Reserved | Reserved |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ 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| 0x06 |1| Reason Code | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------------------------------------------------------+
8/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| CID or Reserved | Reserved |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
The Reason Code field indicates the reason for Logout as follows:
原因代码字段指示注销原因，如下所示：
0 - close the session. All commands associated with the session (if any) are terminated.
0-关闭会话。与会话（如果有）关联的所有命令都将终止。
1 - close the connection. All commands associated with the connection (if any) are terminated.
1-关闭连接。与连接（如果有）关联的所有命令都将终止。
2 - remove the connection for recovery. The connection is closed, and all commands associated with it, if any, are to be prepared for a new allegiance.
2-卸下连接以进行恢复。连接已关闭，所有与其相关的命令（如果有）都将为新的效忠做好准备。
All other values are reserved.
所有其他值均保留。
For this PDU, TotalAHSLength and DataSegmentLength MUST be 0.
对于此PDU，TotalAHSLength和DataSegmentLength必须为0。
This is the connection ID of the connection to be closed (including closing the TCP stream). This field is only valid if the reason code is not "close the session".
这是要关闭的连接的连接ID（包括关闭TCP流）。仅当原因代码不是“关闭会话”时，此字段才有效。
This is the last ExpStatSN value for the connection to be closed.
这是要关闭的连接的最后一个ExpStatSN值。
A target implicitly terminates the active tasks due to the iSCSI protocol 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 recovery Logout 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时段后最终超时，而不重新分配allegiant。
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 any of the above cases 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) above). After the tasks are terminated, the target MUST report a Unit Attention condition on the next command processed on any connection for each affected I_T_L nexus with the status of CHECK CONDITION, the ASC/ASCQ value of 47h/7Fh ("SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT"), etc.; see [SPC3].
如果在上述任何情况下终止的任务是SCSI任务，则它们必须在内部终止，就像使用检查条件状态一样。此状态仅对适当处理内部SCSI状态和与订购有关的SCSI副作用有意义，因为此状态永远不会作为终止状态传回启动器。但是，根据SCSI标准定义的SCSI上下文（例如，排队命令和ACA；情况a）、b和c中I_T nexus上下一个命令的UA），可能必须在SCSI级别采取其他操作。任务终止后，目标必须在每个受影响的I_T_L nexus的任何连接上处理的下一个命令上报告单位注意情况，状态为检查状态，ASC/ASCQ值为47h/7Fh（“某些命令被ISCSI协议事件清除”），等等。；见[SPC3]。
The Logout Response is used by the target to indicate if the cleanup operation for the connection(s) has completed.
目标使用注销响应指示连接的清理操作是否已完成。
After Logout, the TCP connection referred by the CID MUST be closed at both ends (or all connections must be closed if the logout reason was session close).
注销后，CID引用的TCP连接必须在两端关闭（或者，如果注销原因是会话关闭，则必须关闭所有连接）。
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|.|.| 0x26 |1| Reserved | Response | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------------------------------------------------------+
8/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| Reserved |
+---------------------------------------------------------------+
40| Time2Wait | Time2Retain |
+---------------+---------------+---------------+---------------+
44| 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|.|.| 0x26 |1| Reserved | Response | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------------------------------------------------------+
8/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| Reserved |
+---------------------------------------------------------------+
40| Time2Wait | Time2Retain |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
Response field settings are as follows:
响应字段设置如下所示：
0 - connection or session closed successfully.
0-连接或会话已成功关闭。
1 - CID not found.
1-找不到CID。
2 - connection recovery is not supported (i.e., the Logout reason code was "remove the connection for recovery" and the target does not support it as indicated by the operational ErrorRecoveryLevel).
2-不支持连接恢复（即，注销原因代码为“删除连接以进行恢复”，并且目标不支持操作错误恢复级别指示的连接恢复）。
3 - cleanup failed for various reasons.
3-由于各种原因，清理失败。
For this PDU, TotalAHSLength and DataSegmentLength MUST be 0.
对于此PDU，TotalAHSLength和DataSegmentLength必须为0。
If the Logout response code is 0 and the operational ErrorRecoveryLevel is 2, this is the minimum amount of time, in seconds, to wait before attempting task reassignment. If the Logout response code is 0 and the operational ErrorRecoveryLevel is less than 2, this field is to be ignored.
如果注销响应代码为0且操作错误RecoveryLevel为2，则这是尝试重新分配任务之前等待的最短时间（以秒为单位）。如果注销响应代码为0且操作错误RecoveryLevel小于2，则忽略此字段。
This field is invalid if the Logout response code is 1.
如果注销响应代码为1，则此字段无效。
If the Logout response code is 2 or 3, this field specifies the minimum time to wait before attempting a new implicit or explicit logout.
如果注销响应代码为2或3，则此字段指定在尝试新的隐式或显式注销之前等待的最短时间。
If Time2Wait is 0, the reassignment or a new Logout may be attempted immediately.
如果Time2Wait为0，则可以立即尝试重新分配或重新注销。
If the Logout response code is 0 and the operational ErrorRecoveryLevel is 2, this is the maximum amount of time, in seconds, after the initial wait (Time2Wait) that the target waits for the allegiance reassignment for any active task, after which the task state is discarded. If the Logout response code is 0 and the operational ErrorRecoveryLevel is less than 2, this field is to be ignored.
如果注销响应代码为0且operational ErrorRecoveryLevel为2，则这是目标在初始等待（Time2Wait）之后等待任何活动任务的忠诚重新分配的最大时间量（以秒为单位），在此之后，任务状态将被丢弃。如果注销响应代码为0且操作错误RecoveryLevel小于2，则忽略此字段。
This field is invalid if the Logout response code is 1.
如果注销响应代码为1，则此字段无效。
If the Logout response code is 2 or 3, this field specifies the maximum amount of time, in seconds, after the initial wait (Time2Wait) that the target waits for a new implicit or explicit logout.
如果注销响应代码为2或3，则此字段指定目标在初始等待（Time2Wait）后等待新的隐式或显式注销的最长时间（以秒为单位）。
If it is the last connection of a session, the whole session state is discarded after Time2Retain.
如果它是会话的最后一个连接，则在Time2Retain之后将丢弃整个会话状态。
If Time2Retain is 0, the target has already discarded the connection (and possibly the session) state along with the task states. No reassignment or Logout is required in this case.
如果Time2Retain为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|.|.| 0x10 |1|.|.|.| Type | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or SNACK Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| Reserved |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
40| BegRun |
+---------------------------------------------------------------+
44| RunLength |
+---------------------------------------------------------------+
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|.|.| 0x10 |1|.|.|.| Type | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or SNACK Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| Reserved |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
40| BegRun |
+---------------------------------------------------------------+
44| RunLength |
+---------------------------------------------------------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
If the implementation supports ErrorRecoveryLevel greater than zero, it MUST support all SNACK types.
如果实现支持ErrorRecoveryLevel大于零，则它必须支持所有零食类型。
The SNACK is used by the initiator to request the retransmission of numbered responses, data, or R2T PDUs from the target. The SNACK Request indicates the numbered responses or data "runs" whose retransmission is requested, where the run starts with the first StatSN, DataSN, or R2TSN whose retransmission is requested and indicates the number of Status, Data, or R2T PDUs requested, including the first. 0 has special meaning when used as a starting number and length:
发起者使用SNACK请求重新传输来自目标的编号响应、数据或R2T PDU。SNACK请求表示请求重传的编号响应或数据“运行”，其中运行从请求重传的第一个StatSN、DataSN或R2TSN开始，并表示请求的状态、数据或R2T pdu的数量，包括第一个。0用作起始数字和长度时具有特殊意义：
- When used in RunLength, it means all PDUs starting with the initial.
- 在RunLength中使用时，它意味着所有PDU都以初始值开始。
- When used in both BegRun and RunLength, it means all unacknowledged PDUs.
- 在BegRun和RunLength中使用时，它表示所有未确认的PDU。
The numbered response(s) or R2T(s) requested by a SNACK MUST be delivered as exact replicas of the ones that the target transmitted originally, except for the fields ExpCmdSN, MaxCmdSN, and ExpDataSN, which MUST carry the current values. R2T(s)requested by SNACK MUST also carry the current value of the StatSN.
SNAKT请求的编号响应或R2T必须作为目标最初传输的响应的精确副本交付，但ExpCmdSN、MaxCmdSN和EXPDASSN字段除外，这些字段必须包含当前值。零食请求的R2T也必须带有StatSN的当前值。
The numbered Data-In PDUs requested by a Data SNACK MUST be delivered as exact replicas of the ones that the target transmitted originally, except for the fields ExpCmdSN and MaxCmdSN, which MUST carry the current values; and except for resegmentation (see Section 11.16.3).
数据快餐请求的PDU中的编号数据必须作为目标最初传输的数据的精确副本交付，ExpCmdSN和MaxCmdSN字段除外，这两个字段必须携带当前值；除重新分段外（见第11.16.3节）。
Any SNACK that requests a numbered response, data, or R2T that was not sent by the target or was already acknowledged by the initiator MUST be rejected with a reason code of "Protocol Error".
任何请求编号响应、数据或R2T（目标未发送或发起者已确认）的零食都必须被拒绝，原因码为“协议错误”。
This field encodes the SNACK function as follows:
此字段对零食功能进行编码，如下所示：
0 - Data/R2T SNACK: requesting retransmission of one or more Data-In or R2T PDUs.
0-数据/R2T快照：请求在或R2T PDU中重新传输一个或多个数据。
1 - Status SNACK: requesting retransmission of one or more numbered responses.
1-状态：请求重新传输一个或多个编号响应。
2 - DataACK: positively acknowledges Data-In PDUs.
2-数据确认：积极确认PDU中的数据。
3 - R-Data SNACK: requesting retransmission of Data-In PDUs with possible resegmentation and status tagging.
3-R-Data Snapshot：请求在PDU中重新传输数据，并可能进行重新分段和状态标记。
All other values are reserved.
所有其他值均保留。
Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST precede status acknowledgment for the given command.
命令的数据/R2T快取、状态快取或R-Data快取必须在给定命令的状态确认之前。
If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the A bit set to 1. However, if the initiator has detected holes in the input sequence, it MUST postpone issuing the SNACK of type DataACK until the holes are filled. An initiator MAY ignore the A bit if it deems that the bit is being set aggressively by the target (i.e., before the MaxBurstLength limit is reached).
若启动器在ErrorRecoveryLevel 1或更高级别上运行，则在PDU中接收到位设置为1的数据后，它必须发出DataACK类型的SNACK。但是，如果启动器在输入序列中检测到漏洞，则必须推迟发出DataACK类型的零食，直到漏洞被填满。如果启动器认为目标正在积极设置位（即，在达到MaxBurstLength限制之前），则可以忽略该位。
The DataACK is used to free resources at the target and not to request or imply data retransmission.
DataACK用于释放目标上的资源，而不是请求或暗示数据重新传输。
An initiator MUST NOT request retransmission for any data it had already acknowledged.
启动器不得请求重新传输其已确认的任何数据。
If the initiator MaxRecvDataSegmentLength changed between the original transmission and the time the initiator requests retransmission, the initiator MUST issue a R-Data SNACK (see Section 11.16.1). With R-Data SNACK, the initiator indicates that it discards all the unacknowledged data and expects the target to resend it. It also expects resegmentation. In this case, the retransmitted Data-In PDUs MAY be different from the ones originally sent in order to reflect changes in MaxRecvDataSegmentLength. Their DataSN starts with the BegRun of the last DataACK received by the target if any was received; otherwise, it starts with 0 and is increased by 1 for each resent Data-In PDU.
如果发起方MaxRecvDataSegmentLength在原始传输和发起方请求重新传输之间发生变化，则发起方必须发出R-Data快照（见第11.16.1节）。对于R-Data Snapshot，启动器表示它丢弃所有未确认的数据，并期望目标重新发送该数据。它还期望重新分段。在这种情况下，为了反映MaxRecvDataSegmentLength的变化，PDU中重新传输的数据可能与最初发送的数据不同。如果接收到任何数据包，则其DataSN从目标接收到的最后一个数据包的BegRun开始；否则，它将从0开始，并且对于PDU中的每个重新发送数据，它将增加1。
A target that has received a R-Data SNACK MUST return a SCSI Response that contains a copy of the SNACK Tag field from the R-Data SNACK in the SCSI Response SNACK Tag field as its last or only Response. For example, if it has already sent a response containing another value in the SNACK Tag field or had the status included in the last Data-In PDU, it must send a new SCSI Response PDU. If a target sends more than one SCSI Response PDU due to this rule, all SCSI Response PDUs must carry the same StatSN (see Section 11.4.4). If an initiator attempts to recover a lost SCSI Response (with a Status-SNACK; see Section 11.16.1) when more than one response has been sent, the target will send the SCSI Response with the latest content known to the target, including the last SNACK Tag for the command.
接收到R-Data Snapshot的目标必须返回一个SCSI响应，该响应包含SCSI响应Snapshot标记字段中R-Data Snapshot标记字段的副本，作为其最后一个或唯一的响应。例如，如果它已经发送了一个响应，其中包含SNACK Tag字段中的另一个值，或者状态包含在PDU中的最后一个数据中，那么它必须发送一个新的SCSI响应PDU。如果由于此规则，目标发送多个SCSI响应PDU，则所有SCSI响应PDU必须携带相同的StatSN（请参阅第11.4.4节）。当发送了多个响应时，如果启动器尝试恢复丢失的SCSI响应（带有状态快餐；请参阅第11.16.1节），目标将发送SCSI响应，其中包含目标已知的最新内容，包括命令的最后一个快餐标记。
For considerations in allegiance reassignment of a task to a connection with a different MaxRecvDataSegmentLength, refer to Section 7.2.2.
有关将任务重新分配到具有不同MaxRecvDataSegmentLength的连接的忠诚考虑，请参阅第7.2.2节。
For a Status SNACK and DataACK, the Initiator Task Tag MUST be set to the reserved value 0xffffffff. In all other cases, the Initiator Task Tag field MUST be set to the Initiator Task Tag of the referenced command.
对于状态快照和数据确认，必须将启动器任务标记设置为保留值0xFFFFFF。在所有其他情况下，启动器任务标记字段必须设置为引用命令的启动器任务标记。
For a R-Data SNACK, this field MUST contain a value that is different from 0 or 0xffffffff and is unique for the task (identified by the Initiator Task Tag). This value MUST be copied by the iSCSI target in the last or only SCSI Response PDU it issues for the command.
对于R-Data快餐，此字段必须包含不同于0或0xffffffff的值，并且对于任务是唯一的（由启动器任务标记标识）。iSCSI目标必须在为命令发出的最后一个或唯一一个SCSI响应PDU中复制此值。
For DataACK, the Target Transfer Tag MUST contain a copy of the Target Transfer Tag and LUN provided with the SCSI Data-In PDU with the A bit set to 1.
对于DataACK，目标传输标记必须包含目标传输标记和PDU中SCSI数据提供的LUN的副本，位设置为1。
In all other cases, the Target Transfer Tag field MUST be set to the reserved value 0xffffffff.
在所有其他情况下，目标传输标记字段必须设置为保留值0xFFFFFF。
This field indicates the DataSN, R2TSN, or StatSN of the first PDU whose retransmission is requested (Data/R2T and Status SNACK), or the next expected DataSN (DataACK SNACK).
此字段表示请求重传的第一个PDU（数据/R2T和状态快件）的DataSN、R2TSN或StatSN，或下一个预期的DATASK快件。
A BegRun of 0, when used in conjunction with a RunLength of 0, means "resend all unacknowledged Data-In, R2T or Response PDUs".
当与运行长度0一起使用时，BegRun为0表示“在、R2T或响应PDU中重新发送所有未确认的数据”。
BegRun MUST be 0 for a R-Data SNACK.
对于R-Data Snapshot，BegRun必须为0。
This field indicates the number of PDUs whose retransmission is requested.
此字段表示请求重新传输的PDU数量。
A RunLength of 0 signals that all Data-In, R2T, or Response PDUs carrying the numbers equal to or greater than BegRun have to be resent.
运行长度为0表示必须重新发送、R2T或响应PDU中的所有数据，这些数据中的数字等于或大于BegRun。
The RunLength MUST also be 0 for a DataACK SNACK in addition to a R-Data SNACK.
除了R-Data快取之外，数据包快取的运行长度也必须为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|.|.| 0x3f |1| Reserved | Reason | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
16| 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| DataSN/R2TSN or Reserved |
+---------------+---------------+---------------+---------------+
40| Reserved |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
xx/ Complete Header of Bad PDU /
+/ /
+---------------+---------------+---------------+---------------+
yy/Vendor-specific data (if any) /
/ /
+---------------+---------------+---------------+---------------+
zz| 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|.|.| 0x3f |1| Reserved | Reason | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
16| 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| DataSN/R2TSN or Reserved |
+---------------+---------------+---------------+---------------+
40| Reserved |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
xx/ Complete Header of Bad PDU /
+/ /
+---------------+---------------+---------------+---------------+
yy/Vendor-specific data (if any) /
/ /
+---------------+---------------+---------------+---------------+
zz| Data-Digest (optional) |
+---------------+---------------+---------------+---------------+
Reject is used to indicate an iSCSI error condition (protocol, unsupported option, etc.).
拒绝用于指示iSCSI错误情况（协议、不支持的选项等）。
The reject Reason is coded as follows:
拒收原因编码如下：
+------+----------------------------------------+----------------+
| Code | Explanation |Can the original|
| (hex)| |PDU be resent? |
+------+----------------------------------------+----------------+
| 0x01 | Reserved | no |
| | | |
| 0x02 | Data (payload) digest error | yes (Note 1) |
| | | |
| 0x03 | SNACK Reject | yes |
| | | |
| 0x04 | Protocol Error (e.g., SNACK Request for| no |
| | a status that was already acknowledged)| |
| | | |
| 0x05 | Command not supported | no |
| | | |
| 0x06 | Immediate command reject - too many | yes |
| | immediate commands | |
| | | |
| 0x07 | Task in progress | no |
| | | |
| 0x08 | Invalid data ack | no |
| | | |
| 0x09 | Invalid PDU field | no (Note 2) |
| | | |
| 0x0a | Long op reject - Can't generate Target | yes |
| | Transfer Tag - out of resources | |
| | | |
| 0x0b | Deprecated; MUST NOT be used | N/A (Note 3) |
| | | |
| 0x0c | Waiting for Logout | no |
+------+----------------------------------------+----------------+
+------+----------------------------------------+----------------+
| Code | Explanation |Can the original|
| (hex)| |PDU be resent? |
+------+----------------------------------------+----------------+
| 0x01 | Reserved | no |
| | | |
| 0x02 | Data (payload) digest error | yes (Note 1) |
| | | |
| 0x03 | SNACK Reject | yes |
| | | |
| 0x04 | Protocol Error (e.g., SNACK Request for| no |
| | a status that was already acknowledged)| |
| | | |
| 0x05 | Command not supported | no |
| | | |
| 0x06 | Immediate command reject - too many | yes |
| | immediate commands | |
| | | |
| 0x07 | Task in progress | no |
| | | |
| 0x08 | Invalid data ack | no |
| | | |
| 0x09 | Invalid PDU field | no (Note 2) |
| | | |
| 0x0a | Long op reject - Can't generate Target | yes |
| | Transfer Tag - out of resources | |
| | | |
| 0x0b | Deprecated; MUST NOT be used | N/A (Note 3) |
| | | |
| 0x0c | Waiting for Logout | no |
+------+----------------------------------------+----------------+
Note 1: For iSCSI, Data-Out PDU retransmission is only done if the target requests retransmission with a recovery R2T. However, if this is the data digest error on immediate data, the initiator may choose to retransmit the whole PDU, including the immediate data.
注意1：对于iSCSI，仅当目标请求使用恢复R2T重新传输时，才会执行数据输出PDU重新传输。但是，如果这是即时数据的数据摘要错误，则发起方可以选择重新传输整个PDU，包括即时数据。
Note 2: A target should use this reason code for all invalid values of PDU fields that are meant to describe a task, a response, or a data transfer. Some examples are invalid TTT/ITT, buffer offset, LUN qualifying a TTT, and an invalid sequence number in a SNACK.
注2：对于用于描述任务、响应或数据传输的PDU字段的所有无效值，目标应使用此原因码。一些示例包括无效的TTT/ITT、缓冲区偏移量、限定TTT的LUN，以及快照中的无效序列号。
Note 3: Reason code 0x0b ("Negotiation Reset") as defined in Section 10.17.1 of [RFC3720] is deprecated and MUST NOT be used by implementations. An implementation receiving reason code 0x0b MUST treat it as a negotiation failure that terminates the Login Phase and the TCP connection, as specified in Section 7.12.
注3:[RFC3720]第10.17.1节中定义的原因代码0x0b（“协商重置”）已被弃用，不得用于实施。如第7.12节所述，接收原因代码0x0b的实现必须将其视为终止登录阶段和TCP连接的协商失败。
All other values for Reason are unassigned.
所有其他合理值均未赋值。
In all the cases in which a pre-instantiated SCSI task is terminated because of the reject, the target MUST issue a proper SCSI command response with CHECK CONDITION as described in Section 11.4.3. In these cases in which a status for the SCSI task was already sent before the reject, no additional status is required. If the error is detected while data from the initiator is still expected (i.e., the command PDU did not contain all the data and the target has not received a Data-Out PDU with the Final bit set to 1 for the unsolicited data, if any, and all outstanding R2Ts, if any), the target MUST wait until it receives the last expected Data-Out PDUs with the F bit set to 1 before sending the Response PDU.
在所有因拒绝而终止预实例化SCSI任务的情况下，目标必须发出正确的SCSI命令响应，并带有第11.4.3节所述的检查条件。在这些情况下，如果SCSI任务的状态在拒绝之前已发送，则不需要其他状态。如果在仍然预期来自启动器的数据时检测到错误（即，命令PDU未包含所有数据，且目标尚未接收到数据输出PDU，未经请求的数据（如有）的最终位设置为1，以及所有未完成的R2T（如有）），在发送响应PDU之前，目标必须等待直到收到最后一个预期的数据输出PDU（F位设置为1）。
For additional usage semantics of the Reject PDU, see Section 7.3.
有关拒绝PDU的其他用法语义，请参见第7.3节。
This field is only valid if the rejected PDU is a Data/R2T SNACK and the Reject reason code is "Protocol Error" (see Section 11.16). The DataSN/R2TSN is the next Data/R2T sequence number that the target would send for the task, if any.
仅当被拒绝的PDU为数据/R2T零食且拒绝原因代码为“协议错误”（见第11.16节）时，此字段才有效。DataSN/R2TSN是目标将为任务发送的下一个Data/R2T序列号（如果有）。
These fields carry their usual values and are not related to the rejected command. The StatSN is advanced after a Reject.
这些字段带有它们的常规值，与被拒绝的命令无关。StatSN在拒绝后提前。
The target returns the header (not including the digest) of the PDU in error as the data of the response.
目标返回错误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| 0x00 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment - Ping Data (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|.|I| 0x00 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment - Ping Data (optional) /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (optional) |
+---------------+---------------+---------------+---------------+
NOP-Out may be used by an initiator as a "ping request" to verify that a connection/session is still active and all its components are operational. The NOP-In response is the "ping echo".
NOP Out可被启动器用作“ping请求”，以验证连接/会话是否仍然处于活动状态，以及其所有组件是否都可以运行。响应的NOP是“ping-echo”。
A NOP-Out is also sent by an initiator in response to a NOP-In.
NOP Out也由启动器发送，以响应NOP in。
A NOP-Out may also be used to confirm a changed ExpStatSN if another PDU will not be available for a long time.
如果另一个PDU长时间不可用，NOP Out也可用于确认更改的ExpStatSN。
Upon receipt of a NOP-In with the Target Transfer Tag set to a valid value (not the reserved value 0xffffffff), the initiator MUST respond with a NOP-Out. In this case, the NOP-Out Target Transfer Tag MUST contain a copy of the NOP-In Target Transfer Tag. The initiator
收到NOP In且目标传输标记设置为有效值（而不是保留值0xFFFFFF）时，启动器必须以NOP Out响应。在这种情况下，NOP Out目标传输标记必须包含NOP In目标传输标记的副本。发起者
SHOULD NOT send a NOP-Out in response to any other received NOP-In, in order to avoid lengthy sequences of NOP-In and NOP-Out PDUs sent in response to each other.
不应发送NOP Out以响应任何其他接收到的NOP in，以避免为响应彼此而发送的NOP in和NOP Out PDU的冗长序列。
The NOP-Out MUST have the Initiator Task Tag set to a valid value only if a response in the form of a NOP-In is requested (i.e., the NOP-Out is used as a ping request). Otherwise, the Initiator Task Tag MUST be set to 0xffffffff.
只有在请求NOP in形式的响应时（即NOP Out用作ping请求），NOP Out必须将启动器任务标记设置为有效值。否则，启动器任务标记必须设置为0xffffffff。
When a target receives the NOP-Out with a valid Initiator Task Tag, it MUST respond with a NOP-In Response (see Section 4.6.3.6).
当目标接收到带有有效启动器任务标记的NOP Out时，它必须以NOP响应（见第4.6.3.6节）。
If the Initiator Task Tag contains 0xffffffff, the I bit MUST be set to 1, and the CmdSN is not advanced after this PDU is sent.
如果启动器任务标记包含0xFFFFFF，则I位必须设置为1，并且在发送此PDU后，CmdSN不会处于高级状态。
The Target Transfer Tag is a target-assigned identifier for the operation.
目标传输标记是为操作分配的目标标识符。
The NOP-Out MUST only have the Target Transfer Tag set if it is issued in response to a NOP-In with a valid Target Transfer Tag. In this case, it copies the Target Transfer Tag from the NOP-In PDU. Otherwise, the Target Transfer Tag MUST be set to 0xffffffff.
如果NOP Out是响应NOP in而发出的，且带有有效的目标传输标记，则NOP Out必须设置目标传输标记。在这种情况下，它从PDU中的NOP复制目标传输标签。否则，目标传输标记必须设置为0xffffffff。
When the Target Transfer Tag is set to a value other than 0xffffffff, the LUN field MUST also be copied from the NOP-In.
如果将目标传输标记设置为0xffffffff以外的值，则还必须从中的NOP复制LUN字段。
Ping data is reflected in the NOP-In Response. The length of the reflected data is limited to MaxRecvDataSegmentLength. The length of ping data is indicated by the DataSegmentLength. 0 is a valid value for the DataSegmentLength and indicates the absence of ping data.
Ping数据反映在NOP中作为响应。反射数据的长度限制为MaxRecvDataSegmentLength。ping数据的长度由DataSegmentLength表示。0是DataSegmentLength的有效值，表示没有ping数据。
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|.|.| 0x20 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment - Return Ping Data /
+/ /
+---------------+---------------+---------------+---------------+
| 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|.|.| 0x20 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment - Return Ping Data /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (optional) |
+---------------+---------------+---------------+---------------+
NOP-In is sent by a target as either a response to a NOP-Out, a "ping" to an initiator, or a means to carry a changed ExpCmdSN and/or MaxCmdSN if another PDU will not be available for a long time (as determined by the target).
NOP In由目标发送，作为对NOP Out的响应、对启动器的“ping”或在另一个PDU长时间不可用（由目标确定）时携带更改的ExpCmdSN和/或MaxCmdSN的方法。
When a target receives the NOP-Out with a valid Initiator Task Tag (not the reserved value 0xffffffff), it MUST respond with a NOP-In with the same Initiator Task Tag that was provided in the NOP-Out request. It MUST also duplicate up to the first MaxRecvDataSegmentLength bytes of the initiator-provided Ping Data. For such a response, the Target Transfer Tag MUST be 0xffffffff. The
当目标接收到带有有效启动器任务标记（不是保留值0xFFFFFF）的NOP Out时，它必须使用NOP In和NOP Out请求中提供的相同启动器任务标记进行响应。它还必须复制到启动器提供的Ping数据的第一个MaxRecvDataSegmentLength字节。对于这样的响应，目标传输标记必须是0xFFFFFF。这个
target SHOULD NOT send a NOP-In in response to any other received NOP-Out in order to avoid lengthy sequences of NOP-In and NOP-Out PDUs sent in response to each other.
目标不应发送NOP In以响应任何其他接收到的NOP Out，以避免为响应彼此而发送的NOP In和NOP Out PDU的冗长序列。
Otherwise, when a target sends a NOP-In that is not a response to a NOP-Out received from the initiator, the Initiator Task Tag MUST be set to 0xffffffff, and the data segment MUST NOT contain any data (DataSegmentLength MUST be 0).
否则，当目标发送的NOP In不是对从启动器接收的NOP Out的响应时，启动器任务标记必须设置为0xFFFFFF，并且数据段不得包含任何数据（DataSegmentLength必须为0）。
If the target is responding to a NOP-Out, this field is set to the reserved value 0xffffffff.
如果目标响应NOP Out，则此字段设置为保留值0xFFFFFF。
If the target is sending a NOP-In as a ping (intending to receive a corresponding NOP-Out), this field is set to a valid value (not the reserved value 0xffffffff).
如果目标以ping方式发送NOP In（打算接收相应的NOP Out），则此字段设置为有效值（而不是保留值0xFFFFFF）。
If the target is initiating a NOP-In without wanting to receive a corresponding NOP-Out, this field MUST hold the reserved value 0xffffffff.
如果目标启动NOP In而不希望接收相应的NOP Out，则此字段必须保留保留值0xFFFFFF。
The StatSN field will always contain the next StatSN. However, when the Initiator Task Tag is set to 0xffffffff, the StatSN for the connection is not advanced after this PDU is sent.
StatSN字段将始终包含下一个StatSN。但是，当启动器任务标记设置为0xffffffff时，在发送此PDU后，连接的StatSN不会提前。
A LUN MUST be set to a correct value when the Target Transfer Tag is valid (not the reserved value 0xffffffff).
当目标传输标记有效时，必须将LUN设置为正确的值（不是保留值0xFFFFFF）。
Only the following keys are used during the SecurityNegotiation stage of the Login Phase:
登录阶段的SecurityNegotiation阶段仅使用以下密钥：
SessionType
会话类型
InitiatorName
启动器名称
TargetName
目标名
TargetAddress
目标地址
InitiatorAlias
发起者
TargetAlias
塔吉塔利亚斯
TargetPortalGroupTag
TargetPortalGroupTag
AuthMethod and the keys used by the authentication methods specified in Section 12.1, along with all of their associated keys, as well as Vendor-Specific Authentication Methods.
AuthMethod和第12.1节中规定的认证方法使用的密钥，以及所有相关密钥，以及特定于供应商的认证方法。
Other keys MUST NOT be used.
不得使用其他钥匙。
SessionType, InitiatorName, TargetName, InitiatorAlias, TargetAlias, and TargetPortalGroupTag are described in Section 13 as they can be used in the OperationalNegotiation stage as well.
SessionType、InitiatorName、TargetName、InitiatorAlias、TargetAlias和TargetPortalGroupTag在第13节中进行了描述，因为它们也可以在操作协商阶段使用。
All security keys have connection-wide applicability.
所有安全密钥都具有广泛的适用性。
Use: During Login - Security Negotiation Senders: Initiator and target Scope: connection
用法：登录期间-安全协商发件人：启动器和目标作用域：连接
AuthMethod = <list-of-values>
AuthMethod = <list-of-values>
The main item of security negotiation is the authentication method (AuthMethod).
安全协商的主要项目是身份验证方法（AuthMethod）。
The authentication methods that can be used (appear in the list-of-values) are either vendor-unique methods or those listed in the following table:
可以使用的身份验证方法（显示在值列表中）是供应商独有的方法或下表中列出的方法：
+--------------------------------------------------------------+
| Name | Description |
+--------------------------------------------------------------+
| KRB5 | Kerberos V5 - defined in [RFC4120] |
+--------------------------------------------------------------+
| SRP | Secure Remote Password - |
| | defined in [RFC2945] |
+--------------------------------------------------------------+
| CHAP | Challenge Handshake Authentication Protocol - |
| | defined in [RFC1994] |
+--------------------------------------------------------------+
| None | No authentication |
+--------------------------------------------------------------+
+--------------------------------------------------------------+
| Name | Description |
+--------------------------------------------------------------+
| KRB5 | Kerberos V5 - defined in [RFC4120] |
+--------------------------------------------------------------+
| SRP | Secure Remote Password - |
| | defined in [RFC2945] |
+--------------------------------------------------------------+
| CHAP | Challenge Handshake Authentication Protocol - |
| | defined in [RFC1994] |
+--------------------------------------------------------------+
| None | No authentication |
+--------------------------------------------------------------+
The AuthMethod selection is followed by an "authentication exchange" specific to the authentication method selected.
AuthMethod选择之后是特定于所选身份验证方法的“身份验证交换”。
The authentication method proposal may be made by either the initiator or the target. However, the initiator MUST make the first step specific to the selected authentication method as soon as it is selected. It follows that if the target makes the authentication method proposal, the initiator sends the first key(s) of the exchange together with its authentication method selection.
认证方法建议可由发起方或目标方提出。但是，一旦选择了所选身份验证方法，启动器必须使第一步特定于该方法。因此，如果目标提出身份验证方法建议，则发起方将发送交换的第一个密钥及其身份验证方法选择。
The authentication exchange authenticates the initiator to the target and, optionally, the target to the initiator. Authentication is OPTIONAL to use but MUST be supported by the target and initiator.
身份验证交换将启动器身份验证为目标，并且（可选）将目标身份验证为启动器。身份验证是可选的，但必须由目标和启动器支持。
The initiator and target MUST implement CHAP. All other authentication methods are OPTIONAL.
启动器和目标必须实现CHAP。所有其他身份验证方法都是可选的。
Private or public extension algorithms MAY also be negotiated for authentication methods. Whenever a private or public extension algorithm is part of the default offer (the offer made in the absence of explicit administrative action), the implementer MUST ensure that CHAP is listed as an alternative in the default offer and "None" is not part of the default offer.
还可以为认证方法协商私有或公共扩展算法。每当私有或公共扩展算法是默认提议的一部分（在没有明确管理措施的情况下提出的提议）时，实现者必须确保在默认提议中列出CHAP作为备选方案，并且“无”不是默认提议的一部分。
Extension authentication methods MUST be named using one of the following two formats:
扩展身份验证方法必须使用以下两种格式之一命名：
1) Z-reversed.vendor.dns_name.do_something=
1) Z-inversed.vendor.dns\u name.do\u=
2) New public key with no name prefix constraints
2) 没有名称前缀约束的新公钥
Authentication methods named using the Z- format are used as private extensions. New public keys must be registered with IANA using the IETF Review process ([RFC5226]). New public extensions for authentication methods MUST NOT use the Z# name prefix.
使用Z格式命名的身份验证方法用作私有扩展。新公钥必须使用IETF审查流程（[RFC5226]）向IANA注册。身份验证方法的新公共扩展不能使用Z#name前缀。
For all of the public or private extension authentication methods, the method-specific keys MUST conform to the format specified in Section 6.1 for standard-label.
对于所有公共或私有扩展验证方法，方法特定密钥必须符合第6.1节中规定的标准标签格式。
To identify the vendor for private extension authentication methods, we suggest using the reversed DNS-name as a prefix to the proper digest names.
为了确定私有扩展身份验证方法的供应商，我们建议使用反向DNS名称作为正确摘要名称的前缀。
The part of digest-name following Z- MUST conform to the format for standard-label specified in Section 6.1.
摘要名称Z-后面的部分必须符合第6.1节中规定的标准标签格式。
Support for public or private extension authentication methods is OPTIONAL.
对公共或私有扩展身份验证方法的支持是可选的。
The following subsections define the specific exchanges for each of the standardized authentication methods. As mentioned earlier, the first step is always done by the initiator.
以下小节定义了每种标准化身份验证方法的具体交换。如前所述，第一步始终由启动器完成。
For KRB5 (Kerberos V5) [RFC4120] [RFC1964], the initiator MUST use:
对于KRB5（Kerberos V5）[RFC4120][RFC1964]，启动器必须使用：
KRB_AP_REQ=<KRB_AP_REQ>
KRB_AP_REQ=<KRB_AP_REQ>
where KRB_AP_REQ is the client message as defined in [RFC4120].
其中KRB_AP_REQ是[RFC4120]中定义的客户端消息。
The default principal name assumed by an iSCSI initiator or target (prior to any administrative configuration action) MUST be the iSCSI Initiator Name or iSCSI Target Name, respectively, prefixed by the string "iscsi/".
iSCSI启动器或目标（在执行任何管理配置操作之前）采用的默认主体名称必须分别为iSCSI启动器名称或iSCSI目标名称，前缀为字符串“iSCSI/”。
If the initiator authentication fails, the target MUST respond with a Login reject with "Authentication Failure" status. Otherwise, if the initiator has selected the mutual authentication option (by setting MUTUAL-REQUIRED in the ap-options field of the KRB_AP_REQ), the target MUST reply with:
如果启动器身份验证失败，目标必须以“身份验证失败”状态的登录拒绝响应。否则，如果发起方选择了相互认证选项（通过在KRB_ap_REQ的ap选项字段中设置MULTARE-REQUIRED），则目标方必须回复：
KRB_AP_REP=<KRB_AP_REP>
KRB_AP_REP=<KRB_AP_REP>
where KRB_AP_REP is the server's response message as defined in [RFC4120].
其中KRB_AP_REP是[RFC4120]中定义的服务器响应消息。
If mutual authentication was selected and target authentication fails, the initiator MUST close the connection.
如果选择了相互身份验证且目标身份验证失败，则启动器必须关闭连接。
KRB_AP_REQ and KRB_AP_REP are binary-values, and their binary length (not the length of the character string that represents them in encoded form) MUST NOT exceed 65536 bytes. Hex or Base64 encoding may be used for KRB_AP_REQ and KRB_AP_REP; see Section 6.1.
KRB_AP_REQ和KRB_AP_REP是二进制值，它们的二进制长度（不是以编码形式表示它们的字符串长度）不得超过65536字节。十六进制或Base64编码可用于KRB_AP_REQ和KRB_AP_REP；见第6.1节。
For SRP [RFC2945], the initiator MUST use:
对于SRP[RFC2945]，启动器必须使用：
SRP_U=<U> TargetAuth=Yes /* or TargetAuth=No */
SRP_U=<U> TargetAuth=Yes /* or TargetAuth=No */
The target MUST answer with a Login reject with the "Authorization Failure" status or reply with:
目标必须以“授权失败”状态回答登录拒绝，或回答：
SRP_GROUP=<G1,G2...> SRP_s=<s>
SRP_GROUP=<G1,G2...> SRP_s=<s>
where G1,G2... are proposed groups, in order of preference.
其中G1，G2。。。是按优先顺序建议的组。
The initiator MUST either close the connection or continue with:
启动器必须关闭连接或继续执行以下操作：
SRP_A=<A> SRP_GROUP=<G>
SRP_A=<A> SRP_GROUP=<G>
where G is one of G1,G2... that were proposed by the target.
其中G是G1，G2中的一个。。。这是目标提出的。
The target MUST answer with a Login reject with the "Authentication Failure" status or reply with:
目标必须以“身份验证失败”状态拒绝登录或以以下方式回复：
SRP_B=<B>
SRP_B=<B>
The initiator MUST close the connection or continue with:
启动器必须关闭连接或继续执行以下操作：
SRP_M=<M>
SRP_M=<M>
If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator sent TargetAuth=Yes in the first message (requiring target authentication), the target MUST reply with:
如果启动器身份验证失败，目标必须以“身份验证失败”状态的登录拒绝应答。否则，如果启动器在第一条消息中发送了TargetAuth=Yes（需要目标身份验证），则目标必须回复：
SRP_HM=<H(A | M | K)>
SRP_HM=<H(A | M | K)>
If the target authentication fails, the initiator MUST close the connection:
如果目标身份验证失败，则启动器必须关闭连接：
where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] (using the SHA1 hash function, such as SRP-SHA1)
其中U、s、A、B、M和H（A | M | K）在[RFC2945]中定义（使用SHA1散列函数，如SRP-SHA1）
and
和
G,Gn ("Gn" stands for G1,G2...) are identifiers of SRP groups specified in [RFC3723].
G、 Gn（“Gn”代表G1，G2…）是[RFC3723]中规定的SRP组的标识符。
G, Gn, and U are text strings; s,A,B,M, and H(A | M | K) are binary-values. The length of s,A,B,M and H(A | M | K) in binary form (not the length of the character string that represents them in encoded form) MUST NOT exceed 1024 bytes. Hex or Base64 encoding may be used for s,A,B,M and H(A | M | K); see Section 6.1.
G、 Gn和U是文本字符串；s、 A、B、M和H（A | M | K）是二进制值。二进制形式的s、A、B、M和H（A | M | K）的长度（而不是以编码形式表示它们的字符串长度）不得超过1024字节。十六进制或Base64编码可用于s、A、B、M和H（A | M | K）；见第6.1节。
See Appendix B for the related login example.
有关登录示例，请参见附录B。
For the SRP_GROUP, all the groups specified in [RFC3723] up to 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be supported by initiators and targets. To guarantee interoperability, targets MUST always offer "SRP-1536" as one of the proposed groups.
对于SRP_组，[RFC3723]中指定的所有组（最多1536位）（即SRP-768、SRP-1024、SRP-1280、SRP-1536）必须由启动器和目标支持。为保证互操作性，目标公司必须始终将“SRP-1536”作为提议的小组之一。
For CHAP [RFC1994], the initiator MUST use:
对于CHAP[RFC1994]，启动器必须使用：
CHAP_A=<A1,A2...>
CHAP_A=<A1,A2...>
where A1,A2... are proposed algorithms, in order of preference.
其中A1，A2。。。这些算法是按优先顺序提出的。
The target MUST answer with a Login reject with the "Authentication Failure" status or reply with:
目标必须以“身份验证失败”状态拒绝登录或以以下方式回复：
CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>
CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>
where A is one of A1,A2... that were proposed by the initiator.
其中A是A1，A2。。。这是发起者提出的。
The initiator MUST continue with:
启动器必须继续执行以下操作：
CHAP_N=<N> CHAP_R=<R>
CHAP_N=<N> CHAP_R=<R>
or, if it requires target authentication, with:
或者，如果需要目标身份验证，则使用：
CHAP_N=<N> CHAP_R=<R> CHAP_I=<I> CHAP_C=<C>
CHAP_N=<N> CHAP_R=<R> CHAP_I=<I> CHAP_C=<C>
If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator required target authentication, the target MUST either answer with a Login reject with "Authentication Failure" or reply with:
如果启动器身份验证失败，目标必须以“身份验证失败”状态的登录拒绝应答。否则，如果启动器需要目标身份验证，则目标必须回答“身份验证失败”的登录拒绝或回答：
CHAP_N=<N> CHAP_R=<R>
CHAP_N=<N> CHAP_R=<R>
If the target authentication fails, the initiator MUST close the connection:
如果目标身份验证失败，则启动器必须关闭连接：
where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, Algorithm, Identifier, Challenge, and Response as defined in [RFC1994].
其中，N，（A，A1，A2），I，C和R（相应地）是[RFC1994]中定义的名称、算法、标识符、质询和响应。
N is a text string; A,A1,A2, and I are numbers; C and R are binary-values. Their binary length (not the length of the character string that represents them in encoded form) MUST NOT exceed 1024 bytes. Hex or Base64 encoding may be used for C and R; see Section 6.1.
N是文本字符串；A、 A1、A2和I是数字；C和R是二进制值。它们的二进制长度（不是以编码形式表示它们的字符串长度）不得超过1024字节。十六进制或Base64编码可用于C和R；见第6.1节。
See Appendix B for the related login example.
有关登录示例，请参见附录B。
For the Algorithm, as stated in [RFC1994], one value is required to be implemented:
对于算法，如[RFC1994]所述，需要实现一个值：
5 (CHAP with MD5)
第五章（第五章）
To guarantee interoperability, initiators MUST always offer it as one of the proposed algorithms.
为了保证互操作性，发起者必须始终将其作为提议的算法之一提供。
Some session-specific parameters MUST only be carried on the leading connection and cannot be changed after the leading connection login (e.g., MaxConnections -- the maximum number of connections). This holds for a single connection session with regard to connection restart. The keys that fall into this category have the "use: LO" (Leading Only).
某些特定于会话的参数只能在前导连接上进行，并且在前导连接登录后不能更改（例如，MaxConnections—最大连接数）。这适用于与连接重新启动有关的单个连接会话。属于此类别的键具有“use:LO”（仅前导）。
Keys that can only be used during login have the "use: IO" (Initialize Only), while those that can be used in both the Login Phase and Full Feature Phase have the "use: ALL".
只能在登录期间使用的密钥具有“use:IO”（仅初始化），而可以在登录阶段和完整功能阶段使用的密钥具有“use:ALL”。
Keys that can only be used during the Full Feature Phase use FFPO (Full Feature Phase Only).
只能在全功能阶段使用的键使用FFPO（仅限全功能阶段）。
Keys marked as Any-Stage may also appear in the SecurityNegotiation stage, while all other keys described in this section are operational keys.
标记为任何阶段的密钥也可能出现在SecurityNegotiation阶段，而本节中描述的所有其他密钥都是操作密钥。
Keys that do not require an answer are marked as Declarative.
不需要回答的键被标记为声明性键。
Key scope is indicated as session-wide (SW) or connection-only (CO).
关键范围表示为会话范围（SW）或仅连接（CO）。
"Result function", wherever mentioned, states the function that can be applied to check the validity of the responder selection. "Minimum" means that the selected value cannot exceed the offered value. "Maximum" means that the selected value cannot be lower than the offered value. "AND" means that the selected value must be a possible result of a Boolean "and" function with an arbitrary Boolean value (e.g., if the offered value is No the selected value must be No). "OR" means that the selected value must be a possible result of a Boolean "or" function with an arbitrary Boolean value (e.g., if the offered value is Yes the selected value must be Yes).
“结果函数”，无论在何处提及，都说明了可用于检查响应者选择有效性的函数。“最小值”表示所选值不能超过提供值。“最大值”表示所选值不能低于提供值。“和”表示所选值必须是具有任意布尔值的布尔“和”函数的可能结果（例如，如果提供的值为“否”，则所选值必须为“否”）。“或”表示所选值必须是具有任意布尔值的布尔“或”函数的可能结果（例如，如果提供的值为“是”，则所选值必须为“是”）。
Use: IO
Senders: Initiator and target
Scope: CO
HeaderDigest = <list-of-values>
DataDigest = <list-of-values>
Use: IO
Senders: Initiator and target
Scope: CO
HeaderDigest = <list-of-values>
DataDigest = <list-of-values>
Default is None for both HeaderDigest and DataDigest.
HeaderDigest和DataDigest的默认值均为无。
Digests enable the checking of end-to-end, non-cryptographic data integrity beyond the integrity checks provided by the link layers and the covering of the whole communication path, including all elements that may change the network-level PDUs, such as routers, switches, and proxies.
摘要允许在链路层提供的完整性检查之外，检查端到端的非加密数据完整性，并覆盖整个通信路径，包括可能改变网络级PDU的所有元素，如路由器、交换机和代理。
The following table lists cyclic integrity checksums that can be negotiated for the digests and MUST be implemented by every iSCSI initiator and target. These digest options only have error detection significance.
下表列出了可为摘要协商且必须由每个iSCSI启动器和目标实现的循环完整性校验和。这些摘要选项仅具有错误检测意义。
+---------------------------------------------+
| Name | Description | Generator |
+---------------------------------------------+
| CRC32C | 32-bit CRC |0x11edc6f41|
+---------------------------------------------+
| None | no digest |
+---------------------------------------------+
+---------------------------------------------+
| Name | Description | Generator |
+---------------------------------------------+
| CRC32C | 32-bit CRC |0x11edc6f41|
+---------------------------------------------+
| None | no digest |
+---------------------------------------------+
The generator polynomial G(x) for this digest is given in hexadecimal notation (e.g., "0x3b" stands for 0011 1011, and the polynomial is x**5 + x**4 + x**3 + x + 1).
本摘要的生成器多项式G（x）以十六进制表示法给出（例如，“0x3b”表示0011011，多项式为x**5+x**4+x**3+x+1）。
When the initiator and target agree on a digest, this digest MUST be used for every PDU in the Full Feature Phase.
当发起方和目标方就摘要达成一致时，此摘要必须用于完整功能阶段的每个PDU。
Padding bytes, when present in a segment covered by a CRC, SHOULD be set to 0 and are included in the CRC.
当存在于CRC覆盖的段中时，填充字节应设置为0，并包含在CRC中。
The CRC MUST be calculated by a method that produces the same results as the following process:
CRC的计算方法必须产生与以下过程相同的结果：
- The PDU bits are considered as the coefficients of a polynomial M(x) of degree n - 1; bit 7 of the lowest numbered byte is considered the most significant bit (x**n - 1), followed by bit 6 of the lowest numbered byte through bit 0 of the highest numbered byte (x**0).
- 将PDU比特视为n-1次多项式M（x）的系数；最低编号字节的第7位被视为最高有效位（x**n-1），然后是最低编号字节的第6位到最高编号字节（x**0）的第0位。
- The most significant 32 bits are complemented.
- 最高有效的32位被补充。
- The polynomial is multiplied by x**32, then divided by G(x). The generator polynomial produces a remainder R(x) of degree <= 31.
- 多项式乘以x**32，然后除以G（x）。生成器多项式生成次数<=31的余数R（x）。
- The coefficients of R(x) are formed into a 32-bit sequence.
- R（x）的系数形成32位序列。
- The bit sequence is complemented, and the result is the CRC.
- 位序列被补充，结果是CRC。
- The CRC bits are mapped into the digest word. The x**31 coefficient is mapped to bit 7 of the lowest numbered byte of the digest, and the mapping continues with successive coefficients and bits so that the x**24 coefficient is mapped to bit 0 of the lowest numbered byte. The mapping continues further with the x**23 coefficient mapped to bit 7 of the next byte in the digest until the x**0 coefficient is mapped to bit 0 of the highest numbered byte of the digest.
- CRC位被映射到摘要字中。x**31系数被映射到摘要中编号最低的字节的第7位，并且映射以连续的系数和位继续，以便x**24系数被映射到编号最低的字节的第0位。映射继续进行，将x**23系数映射到摘要中下一个字节的位7，直到x**0系数映射到摘要中编号最高的字节的位0。
- Computing the CRC over any segment (data or header) extended to include the CRC built using the generator 0x11edc6f41 will always get the value 0x1c2d19ed as its final remainder (R(x)). This value is given here in its polynomial form (i.e., not mapped as the digest word).
- 计算扩展到包括使用生成器0x11edc6f41构建的CRC的任何段（数据或报头）上的CRC将始终得到值0x1C2D19D作为其最终余数（R（x））。该值在此以多项式形式给出（即，未映射为摘要词）。
For a discussion about selection criteria for the CRC, see [RFC3385]. For a detailed analysis of the iSCSI polynomial, see [Castagnoli93].
有关CRC选择标准的讨论，请参阅[RFC3385]。有关iSCSI多项式的详细分析，请参见[Castagnoli93]。
Private or public extension algorithms MAY also be negotiated for digests. Whenever a private or public digest extension algorithm is part of the default offer (the offer made in the absence of explicit administrative action), the implementer MUST ensure that CRC32C is listed as an alternative in the default offer and "None" is not part of the default offer.
私有或公共扩展算法也可以协商摘要。每当私有或公共摘要扩展算法是默认提议的一部分（在没有明确管理措施的情况下提出的提议）时，实施者必须确保CRC32C被列为默认提议中的备选方案，并且“无”不是默认提议的一部分。
Extension digest algorithms MUST be named using one of the following two formats:
扩展摘要算法必须使用以下两种格式之一命名：
1) Y-reversed.vendor.dns_name.do_something=
1) Y-inversed.vendor.dns\u name.do\u=
2) New public key with no name prefix constraints
2) 没有名称前缀约束的新公钥
Digests named using the Y- format are used for private purposes (unregistered). New public keys must be registered with IANA using the IETF Review process ([RFC5226]). New public extensions for digests MUST NOT use the Y# name prefix.
使用Y格式命名的摘要用于私人目的（未注册）。新公钥必须使用IETF审查流程（[RFC5226]）向IANA注册。摘要的新公共扩展不能使用Y#name前缀。
For private extension digests, to identify the vendor we suggest using the reversed DNS-name as a prefix to the proper digest names.
对于私有扩展摘要，为了识别供应商，我们建议使用反向DNS名称作为正确摘要名称的前缀。
The part of digest-name following Y- MUST conform to the format for standard-label specified in Section 6.1.
摘要名称中Y-后面的部分必须符合第6.1节中规定的标准标签格式。
Support for public or private extension digests is OPTIONAL.
对公共或私有扩展摘要的支持是可选的。
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery
当：SessionType=Discovery时，使用：LO发送方：启动器和目标作用域：SW无关
MaxConnections=<numerical-value-from-1-to-65535>
MaxConnections=<numerical-value-from-1-to-65535>
Default is 1. Result function is Minimum.
默认值为1。结果函数是最小的。
The initiator and target negotiate the maximum number of connections requested/acceptable.
启动器和目标协商请求/可接受的最大连接数。
Use: FFPO Senders: Initiator Scope: SW
用途：FFPO发送者：启动器范围：SW
For a complete description, see Appendix C.
有关完整说明，请参见附录C。
Use: IO by initiator, FFPO by target -- only as response to a SendTargets, Declarative, Any-Stage Senders: Initiator and target Scope: SW
使用：IO按启动器，FFPO按目标--仅作为对SendTargets、Declarative、任意阶段的响应发件人：启动器和目标作用域：SW
TargetName=<iSCSI-name-value>
TargetName=<iSCSI-name-value>
Examples:
示例：
TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678
TargetName=iqn.1993-11.com.磁盘供应商：diskarrays.sn.45678
TargetName=eui.020000023B040506
TargetName=eui.020000023B040506
TargetName=naa.62004567BA64678D0123456789ABCDEF
TargetName=naa.62004567BA64678D0123456789ABCDEF
The initiator of the TCP connection MUST provide this key to the remote endpoint in the first Login Request if the initiator is not establishing a Discovery session. The iSCSI Target Name specifies the worldwide unique name of the target.
如果TCP连接的发起方未建立发现会话，则该发起方必须在第一个登录请求中向远程端点提供该密钥。iSCSI目标名称指定目标的全球唯一名称。
The TargetName key may also be returned by the SendTargets Text Request (which is its only use when issued by a target).
TargetName键也可以由SendTargets文本请求返回（这是它在由目标发出时的唯一用途）。
The TargetName MUST NOT be redeclared within the Login Phase.
登录阶段内不得重新声明TargetName。
Use: IO, Declarative, Any-Stage Senders: Initiator Scope: SW
使用：IO、声明性、任意阶段发送者：启动器范围：SW
InitiatorName=<iSCSI-name-value>
InitiatorName=<iSCSI-name-value>
Examples:
示例：
InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345
InitiatorName=iqn.1992-04.com.os供应商计划9:cdrom.12345
InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90
InitiatorName=iqn.2001-02.com.ssp.用户：customer235.host90
InitiatorName=naa.52004567BA64678D
启动器名称=naa.52004567BA64678D
The initiator of the TCP connection MUST provide this key to the remote endpoint at the first login of the Login Phase for every connection. The InitiatorName key enables the initiator to identify itself to the remote endpoint.
TCP连接的发起方必须在每个连接的登录阶段的第一次登录时向远程端点提供此密钥。InitiatorName键使启动器能够向远程端点标识自己。
The InitiatorName MUST NOT be redeclared within the Login Phase.
不得在登录阶段重新声明InitiatorName。
Use: ALL, Declarative, Any-Stage Senders: Target Scope: SW
使用：全部、声明性、任意阶段发送者：目标范围：SW
TargetAlias=<iSCSI-local-name-value>
TargetAlias=<iSCSI-local-name-value>
Examples:
示例：
TargetAlias=Bob-s Disk
TargetAlias=Bob-s磁盘
TargetAlias=Database Server 1 Log Disk
TargetAlias=数据库服务器1日志磁盘
TargetAlias=Web Server 3 Disk 20
TargetAlias=Web服务器3磁盘20
If a target has been configured with a human-readable name or description, this name SHOULD be communicated to the initiator during a Login Response PDU if SessionType=Normal (see Section 13.21). This string is not used as an identifier, nor is it meant to be used for authentication or authorization decisions. It can be displayed by the initiator's user interface in a list of targets to which it is connected.
如果目标配置了人类可读的名称或描述，则在登录响应PDU期间，如果SessionType=Normal，则应将该名称告知发起人（参见第13.21节）。此字符串不用作标识符，也不用于身份验证或授权决策。它可以由启动器的用户界面在其连接的目标列表中显示。
Use: ALL, Declarative, Any-Stage Senders: Initiator Scope: SW
使用：全部、声明性、任意阶段发送者：启动器范围：SW
InitiatorAlias=<iSCSI-local-name-value>
InitiatorAlias=<iSCSI-local-name-value>
Examples:
示例：
InitiatorAlias=Web Server 4
InitiatorAlias=Web服务器4
InitiatorAlias=spyalley.nsa.gov
InitiatorAlias=spyalley.nsa.gov
InitiatorAlias=Exchange Server
InitiatorAlias=Exchange服务器
If an initiator has been configured with a human-readable name or description, it SHOULD be communicated to the target during a Login Request PDU. If not, the host name can be used instead. This string is not used as an identifier, nor is it meant to be used for authentication or authorization decisions. It can be displayed by the target's user interface in a list of initiators to which it is connected.
如果已使用人类可读的名称或描述配置了启动器，则应在登录请求PDU期间将其告知目标。如果不是，则可以使用主机名。此字符串不用作标识符，也不用于身份验证或授权决策。它可以由目标的用户界面在其所连接的启动器列表中显示。
Use: ALL, Declarative, Any-Stage Senders: Target Scope: SW
使用：全部、声明性、任意阶段发送者：目标范围：SW
TargetAddress=domainname[:port][,portal-group-tag]
TargetAddress=域名[：端口][，门户组标记]
The domainname can be specified as either a DNS host name, a dotted-decimal IPv4 address, or a bracketed IPv6 address as specified in [RFC3986].
domainname可以指定为DNS主机名、虚线十进制IPv4地址或括号内的IPv6地址，如[RFC3986]中所述。
If the TCP port is not specified, it is assumed to be the IANA-assigned default port for iSCSI (see Section 14).
如果未指定TCP端口，则假定它是IANA为iSCSI分配的默认端口（请参阅第14节）。
If the TargetAddress is returned as the result of a redirect status in a Login Response, the comma and portal-group-tag MUST be omitted.
如果由于登录响应中的重定向状态而返回TargetAddress，则必须省略逗号和门户组标记。
If the TargetAddress is returned within a SendTargets response, the portal-group-tag MUST be included.
如果在SendTargets响应中返回TargetAddress，则必须包括门户组标记。
Examples:
示例：
TargetAddress=10.0.0.1:5003,1
TargetAddress=10.0.0.1:5003,1
TargetAddress=[1080:0:0:0:8:800:200C:417A],65
TargetAddress=[1080:0:0:0:8:800:200C:417A],65
TargetAddress=[1080::8:800:200C:417A]:5003,1
TargetAddress=[1080::8:800:200C:417A]:5003,1
TargetAddress=computingcenter.example.com,23
TargetAddress=computingcenter.example.com，23
The use of the portal-group-tag is described in Appendix C. The formats for the port and portal-group-tag are the same as the one specified in TargetPortalGroupTag.
门户组标记的使用在附录C中进行了说明。端口和门户组标记的格式与TargetPortalGroupTag中指定的格式相同。
Use: IO by target, Declarative, Any-Stage Senders: Target Scope: SW
使用：目标IO、声明性、任何阶段发送者：目标范围：SW
TargetPortalGroupTag=<16-bit-binary-value>
TargetPortalGroupTag=<16-bit-binary-value>
Example:
例子：
TargetPortalGroupTag=1
TargetPortalGroupTag=1
The TargetPortalGroupTag key is a 16-bit binary-value that uniquely identifies a portal group within an iSCSI target node. This key carries the value of the tag of the portal group that is servicing the Login Request. The iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has the C bit set to 0 when TargetName is given by the initiator.
TargetPortalGroupTag密钥是一个16位二进制值，用于唯一标识iSCSI目标节点内的门户组。此键包含为登录请求提供服务的门户组的标记的值。iSCSI目标在第一个登录请求PDU的登录响应PDU中将此密钥返回给启动器，当启动器提供TargetName时，该PDU的C位设置为0。
[SAM2] notes in its informative text that the TPGT value should be non-zero; note that this is incorrect. A zero value is allowed as a legal value for the TPGT. This discrepancy currently stands corrected in [SAM4].
[SAM2]在其资料性文本中指出，TPGT值应为非零；请注意，这是不正确的。TPGT的法定值允许为零值。该差异目前在[SAM4]中得到纠正。
For the complete usage expectations of this key, see Section 6.3.
有关此密钥的完整使用预期，请参见第6.3节。
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery
当：SessionType=Discovery时，使用：LO发送方：启动器和目标作用域：SW无关
InitialR2T=<boolean-value>
InitialR2T=<boolean-value>
Examples:
示例：
I->InitialR2T=No
I->InitialR2T=否
T->InitialR2T=No
T->InitialR2T=否
Default is Yes. Result function is OR.
默认值是Yes。结果函数是OR。
The InitialR2T key is used to turn off the default use of R2T for unidirectional operations and the output part of bidirectional commands, thus allowing an initiator to start sending data to a target as if it has received an initial R2T with Buffer Offset=Immediate Data Length and Desired Data Transfer Length=(min(FirstBurstLength, Expected Data Transfer Length) - Received Immediate Data Length).
InitialR2T键用于关闭单向操作和双向命令输出部分R2T的默认使用，从而允许启动器开始向目标发送数据，就好像它已收到缓冲区偏移=即时数据长度和所需数据传输长度=（min）的初始R2T一样（FirstBurstLength，预期数据传输长度）-收到的即时数据长度）。
The default action is that R2T is required, unless both the initiator and the target send this key-pair attribute specifying InitialR2T=No. Only the first outgoing data burst (immediate data and/or separate PDUs) can be sent unsolicited (i.e., not requiring an explicit R2T).
默认操作是需要R2T，除非发起者和目标都发送指定InitialR2T=No的密钥对属性。只有第一个传出数据突发（即时数据和/或单独的PDU）可以主动发送（即不需要显式R2T）。
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery
当：SessionType=Discovery时，使用：LO发送方：启动器和目标作用域：SW无关
ImmediateData=<boolean-value>
ImmediateData=<boolean-value>
Default is Yes. Result function is AND.
默认值是Yes。结果函数为和。
The initiator and target negotiate support for immediate data. To turn immediate data off, the initiator or target must state its desire to do so. ImmediateData can be turned on if both the initiator and target have ImmediateData=Yes.
发起方和目标方协商对即时数据的支持。若要关闭即时数据，发起方或目标方必须声明其希望关闭即时数据。如果启动器和目标都具有ImmediateData=Yes，则可以打开ImmediateData。
If ImmediateData is set to Yes and InitialR2T is set to Yes (default), then only immediate data are accepted in the first burst.
如果ImmediateData设置为Yes，InitialR2T设置为Yes（默认），则在第一次突发中仅接受即时数据。
If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send unsolicited data and the target MUST reject unsolicited data with the corresponding response code.
如果ImmediateData设置为No，InitialR2T设置为Yes，则发起方不得发送未经请求的数据，目标方必须使用相应的响应代码拒绝未经请求的数据。
If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data but MAY send one unsolicited burst of Data-OUT PDUs.
如果ImmediateData设置为No，InitialR2T设置为No，则发起方不得发送未经请求的即时数据，但可以将一个未经请求的数据突发发送到PDU。
If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-OUT PDUs.
如果ImmediateData设置为Yes（是），InitialR2T设置为No（否），则发起方可以发送未经请求的即时数据和/或一个未经请求的数据突发到PDU。
The following table is a summary of unsolicited data options:
下表汇总了未经请求的数据选项：
+----------+-------------+------------------+-------------+
|InitialR2T|ImmediateData| Unsolicited |ImmediateData|
| | | Data-Out PDUs | |
+----------+-------------+------------------+-------------+
| No | No | Yes | No |
+----------+-------------+------------------+-------------+
| No | Yes | Yes | Yes |
+----------+-------------+------------------+-------------+
| Yes | No | No | No |
+----------+-------------+------------------+-------------+
| Yes | Yes | No | Yes |
+----------+-------------+------------------+-------------+
+----------+-------------+------------------+-------------+
|InitialR2T|ImmediateData| Unsolicited |ImmediateData|
| | | Data-Out PDUs | |
+----------+-------------+------------------+-------------+
| No | No | Yes | No |
+----------+-------------+------------------+-------------+
| No | Yes | Yes | Yes |
+----------+-------------+------------------+-------------+
| Yes | No | No | No |
+----------+-------------+------------------+-------------+
| Yes | Yes | No | Yes |
+----------+-------------+------------------+-------------+
Use: ALL, Declarative Senders: Initiator and target Scope: CO
用法：ALL，声明性发送者：启动器和目标作用域：CO
MaxRecvDataSegmentLength=<numerical-value-512-to-(2**24 - 1)>
MaxRecvDataSegmentLength=<numerical-value-512-to-(2**24 - 1)>
Default is 8192 bytes.
默认值为8192字节。
The initiator or target declares the maximum data segment length in bytes it can receive in an iSCSI PDU.
启动器或目标以字节为单位声明它可以在iSCSI PDU中接收的最大数据段长度。
The transmitter (initiator or target) is required to send PDUs with a data segment that does not exceed MaxRecvDataSegmentLength of the receiver.
发射机（启动器或目标）需要发送数据段不超过接收机MaxRecvDataSegmentLength的PDU。
A target receiver is additionally limited by MaxBurstLength for solicited data and FirstBurstLength for unsolicited data. An initiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor unsolicited PDUs exceeding FirstBurstLength (or FirstBurstLength-Immediate Data Length if immediate data were sent).
对于请求的数据，目标接收机还受到MaxBurstLength的限制，对于非请求的数据，目标接收机受到FirstBurstLength的限制。发起人不得发送超过MaxBurstLength的请求PDU，也不得发送超过FirstBurstLength（或如果发送了即时数据，则为FirstBurstLength即时数据长度）的非请求PDU。
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery
当：SessionType=Discovery时，使用：LO发送方：启动器和目标作用域：SW无关
MaxBurstLength=<numerical-value-512-to-(2**24 - 1)>
MaxBurstLength=<numerical-value-512-to-(2**24 - 1)>
Default is 262144 (256 KB). Result function is Minimum.
默认值为262144（256 KB）。结果函数是最小的。
The initiator and target negotiate the maximum SCSI data payload in bytes in a Data-In or a solicited Data-Out iSCSI sequence. A sequence consists of one or more consecutive Data-In or Data-Out PDUs that end with a Data-In or Data-Out PDU with the F bit set to 1.
启动器和目标在数据输入或请求的数据输出iSCSI序列中协商以字节为单位的最大SCSI数据有效负载。序列由一个或多个连续的数据输入或数据输出PDU组成，以F位设置为1的数据输入或数据输出PDU结束。
Use: LO
Senders: Initiator and target
Scope: SW
Irrelevant when: SessionType=Discovery
Irrelevant when: ( InitialR2T=Yes and ImmediateData=No )
Use: LO
Senders: Initiator and target
Scope: SW
Irrelevant when: SessionType=Discovery
Irrelevant when: ( InitialR2T=Yes and ImmediateData=No )
FirstBurstLength=<numerical-value-512-to-(2**24 - 1)>
FirstBurstLength=<numerical-value-512-to-(2**24 - 1)>
Default is 65536 (64 KB). Result function is Minimum.
默认值为65536（64 KB）。结果函数是最小的。
The initiator and target negotiate the maximum amount in bytes of unsolicited data an iSCSI initiator may send to the target during the execution of a single SCSI command. This covers the immediate data (if any) and the sequence of unsolicited Data-Out PDUs (if any) that follow the command.
启动器和目标协商iSCSI启动器在执行单个SCSI命令期间可以发送给目标的未经请求的最大数据量（以字节为单位）。这包括即时数据（如果有）和命令后面的未经请求的数据输出PDU（如果有）序列。
FirstBurstLength MUST NOT exceed MaxBurstLength.
FirstBurstLength不得超过MaxBurstLength。
Use: LO Senders: Initiator and target Scope: SW
使用：本地发送器：启动器和目标作用域：SW
DefaultTime2Wait=<numerical-value-0-to-3600>
DefaultTime2Wait=<numerical-value-0-to-3600>
Default is 2. Result function is Maximum.
默认值为2。结果函数最大。
The initiator and target negotiate the minimum time, in seconds, to wait before attempting an explicit/implicit logout or an active task reassignment after an unexpected connection termination or a connection reset.
在意外连接终止或连接重置后，启动器和目标协商尝试显式/隐式注销或活动任务重新分配之前的最短等待时间（秒）。
A value of 0 indicates that logout or active task reassignment can be attempted immediately.
值0表示可以立即尝试注销或活动任务重新分配。
Use: LO Senders: Initiator and target Scope: SW
使用：本地发送器：启动器和目标作用域：SW
DefaultTime2Retain=<numerical-value-0-to-3600>
DefaultTime2Retain=<numerical-value-0-to-3600>
Default is 20. Result function is Minimum.
默认值为20。结果函数是最小的。
The initiator and target negotiate the maximum time, in seconds, after an initial wait (Time2Wait), before which an active task reassignment is still possible after an unexpected connection termination or a connection reset.
发起方和目标协商初始等待（Time2Wait）后的最长时间（以秒为单位），在此之前，在意外连接终止或连接重置后仍然可以重新分配活动任务。
This value is also the session state timeout if the connection in question is the last LOGGED_IN connection in the session.
如果相关连接是会话中最后一个登录的连接，则此值也是会话状态超时。
A value of 0 indicates that connection/task state is immediately discarded by the target.
值0表示目标立即放弃连接/任务状态。
Use: LO Senders: Initiator and target Scope: SW
使用：本地发送器：启动器和目标作用域：SW
MaxOutstandingR2T=<numerical-value-from-1-to-65535>
MaxOutstandingR2T=<numerical-value-from-1-to-65535>
Irrelevant when: SessionType=Discovery
当：SessionType=Discovery时不相关
Default is 1. Result function is Minimum.
默认值为1。结果函数是最小的。
The initiator and target negotiate the maximum number of outstanding R2Ts per task, excluding any implied initial R2T that might be part of that task. An R2T is considered outstanding until the last data PDU (with the F bit set to 1) is transferred or a sequence reception timeout (Section 7.1.4.1) is encountered for that data sequence.
发起方和目标方协商每个任务未完成R2T的最大数量，不包括可能是该任务一部分的任何隐含初始R2T。在传输最后一个数据PDU（F位设置为1）或该数据序列遇到序列接收超时（第7.1.4.1节）之前，R2T被视为未完成。
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery
当：SessionType=Discovery时，使用：LO发送方：启动器和目标作用域：SW无关
DataPDUInOrder=<boolean-value>
DataPDUInOrder=<boolean-value>
Default is Yes. Result function is OR.
默认值是Yes。结果函数是OR。
"No" is used by iSCSI to indicate that the data PDUs within sequences can be in any order. "Yes" is used to indicate that data PDUs within sequences have to be at continuously increasing addresses and overlays are forbidden.
iSCSI使用“否”表示序列中的数据PDU可以是任意顺序。“是”用于表示序列中的数据PDU必须位于不断增加的地址，并且禁止重叠。
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery
当：SessionType=Discovery时，使用：LO发送方：启动器和目标作用域：SW无关
DataSequenceInOrder=<boolean-value>
DataSequenceInOrder=<boolean-value>
Default is Yes. Result function is OR.
默认值是Yes。结果函数是OR。
A data sequence is a sequence of Data-In or Data-Out PDUs that end with a Data-In or Data-Out PDU with the F bit set to 1. A Data-Out sequence is sent either unsolicited or in response to an R2T. Sequences cover an offset-range.
数据序列是以F位设置为1的数据输入或数据输出PDU结束的数据输入或数据输出PDU序列。未经请求或响应R2T发送数据输出序列。序列覆盖偏移范围。
If DataSequenceInOrder is set to No, data PDU sequences may be transferred in any order.
如果DataSequenceInOrder设置为No，则数据PDU序列可以按任何顺序传输。
If DataSequenceInOrder is set to Yes, data sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).
如果DataSequenceInOrder设置为Yes，则必须使用连续非递减的序列偏移量（用于写入的R2T缓冲区偏移量，或读取数据序列中缓冲区中最小的SCSI数据偏移量）传输数据序列。
If DataSequenceInOrder is set to Yes, a target may retry at most the last R2T, and an initiator may at most request retransmission for the last read data sequence. For this reason, if ErrorRecoveryLevel is not 0 and DataSequenceInOrder is set to Yes, then MaxOutstandingR2T MUST be set to 1.
如果DataSequenceInOrder设置为Yes，则目标最多可以重试最后一个R2T，而启动器最多可以请求重新传输最后一个读取的数据序列。因此，如果ErrorRecoveryLevel不为0且DataSequenceInOrder设置为Yes，则MaxOutstandingR2T必须设置为1。
Use: LO Senders: Initiator and target Scope: SW
使用：本地发送器：启动器和目标作用域：SW
ErrorRecoveryLevel=<numerical-value-0-to-2>
ErrorRecoveryLevel=<numerical-value-0-to-2>
Default is 0. Result function is Minimum.
默认值为0。结果函数是最小的。
The initiator and target negotiate the recovery level supported.
启动器和目标协商支持的恢复级别。
Recovery levels represent a combination of recovery capabilities. Each recovery level includes all the capabilities of the lower recovery levels and adds some new ones to them.
恢复级别表示恢复功能的组合。每个恢复级别都包括较低恢复级别的所有功能，并为其添加了一些新功能。
In the description of recovery mechanisms, certain recovery classes are specified. Section 7.1.5 describes the mapping between the classes and the levels.
在恢复机制的描述中，指定了某些恢复类。第7.1.5节描述了类别和级别之间的映射。
Use: LO, Declarative, Any-Stage Senders: Initiator Scope: SW
使用：LO，声明性，任何阶段发送器：启动器范围：SW
SessionType=<Discovery|Normal>
SessionType=<Discovery|Normal>
Default is Normal.
违约是正常的。
The initiator indicates the type of session it wants to create. The target can either accept it or reject it.
启动器指示要创建的会话类型。目标可以接受它，也可以拒绝它。
A Discovery session indicates to the target that the only purpose of this session is discovery. The only requests a target accepts in this type of session are a Text Request with a SendTargets key and a Logout Request with reason "close the session".
发现会话向目标指示此会话的唯一目的是发现。目标在此类会话中接受的唯一请求是带有SendTargets键的文本请求和带有“关闭会话”原因的注销请求。
The Discovery session implies MaxConnections = 1 and overrides both the default and an explicit setting. As Section 7.4.1 states, ErrorRecoveryLevel MUST be 0 (zero) for Discovery sessions.
发现会话意味着MaxConnections=1，并覆盖默认设置和显式设置。正如第7.4.1节所述，对于发现会话，ErrorRecoveryLevel必须为0（零）。
Depending on the type of session, a target may decide on resources to allocate, the security to enforce, etc., for the session. If the SessionType key is thus going to be offered as "Discovery", it SHOULD be offered in the initial Login Request by the initiator.
根据会话的类型，目标可能决定会话要分配的资源、要实施的安全性等。如果SessionType密钥因此将作为“发现”提供，则发起人应在初始登录请求中提供该密钥。
Use: ALL Senders: Initiator and target Scope: specific key dependent
用法：所有发件人：启动器和目标作用域：特定密钥相关
X-reversed.vendor.dns_name.do_something=
X-inversed.vendor.dns\u name.do\u=
Keys with this format are used for private extension purposes. These keys always start with X- if unregistered with IANA (private). New public keys (if registered with IANA via an IETF Review [RFC5226]) no longer have an X# name prefix requirement; implementers may propose any intuitive unique name.
具有此格式的密钥用于专用扩展目的。如果未注册IANA（专用），这些密钥始终以X开头。新公钥（如果通过IETF审查[RFC5226]向IANA注册）不再有X#名称前缀要求；实施者可以提出任何直观的唯一名称。
For unregistered keys, to identify the vendor we suggest using the reversed DNS-name as a prefix to the key-proper.
对于未注册的密钥，为了识别供应商，我们建议使用反向DNS名称作为密钥的前缀。
The part of key-name following X- MUST conform to the format for key-name specified in Section 6.1.
X-之后的密钥名称部分必须符合第6.1节中规定的密钥名称格式。
Vendor-specific keys MUST ONLY be used in Normal sessions.
供应商特定密钥只能在正常会话中使用。
Support for public or private extension keys is OPTIONAL.
对公共或私有扩展密钥的支持是可选的。
Use: LO
Senders: Initiator and target
Scope: SW
Irrelevant when: SessionType=Discovery
TaskReporting=<list-of-values>
Use: LO
Senders: Initiator and target
Scope: SW
Irrelevant when: SessionType=Discovery
TaskReporting=<list-of-values>
Default is RFC3720.
默认值为RFC3720。
This key is used to negotiate the task completion reporting semantics from the SCSI target. The following table describes the semantics that an iSCSI target MUST support for respective negotiated key values. Whenever this key is negotiated, at least the RFC3720 and ResponseFence values MUST be offered as options by the negotiation originator.
此键用于协商SCSI目标的任务完成报告语义。下表描述了iSCSI目标必须支持各自协商键值的语义。每当协商此密钥时，协商发起人必须至少提供RFC3720和ResponseFence值作为选项。
+--------------+------------------------------------------+
| Name | Description |
+--------------+------------------------------------------+
| RFC3720 | RFC 3720-compliant semantics. Response |
| | fencing is not guaranteed, and fast |
| | completion of multi-task aborting is not |
| | supported. |
+--------------+------------------------------------------+
| ResponseFence| Response Fence (Section 4.2.2.3.3) |
| | semantics MUST be supported in reporting |
| | task completions. |
+--------------+------------------------------------------+
| FastAbort | Updated fast multi-task abort semantics |
| | defined in Section 4.2.3.4 MUST be |
| | supported. Support for the Response |
| | Fence is implied -- i.e., semantics as |
| | described in Section 4.2.2.3.3 MUST be |
| | supported as well. |
+--------------+------------------------------------------+
+--------------+------------------------------------------+
| Name | Description |
+--------------+------------------------------------------+
| RFC3720 | RFC 3720-compliant semantics. Response |
| | fencing is not guaranteed, and fast |
| | completion of multi-task aborting is not |
| | supported. |
+--------------+------------------------------------------+
| ResponseFence| Response Fence (Section 4.2.2.3.3) |
| | semantics MUST be supported in reporting |
| | task completions. |
+--------------+------------------------------------------+
| FastAbort | Updated fast multi-task abort semantics |
| | defined in Section 4.2.3.4 MUST be |
| | supported. Support for the Response |
| | Fence is implied -- i.e., semantics as |
| | described in Section 4.2.2.3.3 MUST be |
| | supported as well. |
+--------------+------------------------------------------+
When TaskReporting is not negotiated to FastAbort, the standard multi-task abort semantics in Section 4.2.3.3 MUST be used.
如果TaskReporting未协商为FastAbort，则必须使用第4.2.3.3节中的标准多任务中止语义。
The iSCSIProtocolLevel associated with this document is "1". As a responder or an originator in a negotiation of this key, an iSCSI implementation compliant to this document alone, without any future protocol extensions, MUST use this value as defined by [RFC7144].
与本文档关联的iSCSIProtocolLevel为“1”。作为此密钥协商中的响应者或发起人，仅符合本文档的iSCSI实现（无任何未来的协议扩展）必须使用[RFC7144]定义的此值。
This document obsoletes the following keys defined in [RFC3720]: IFMarker, OFMarker, OFMarkInt, and IFMarkInt. However, iSCSI implementations compliant to this document may still receive these obsoleted keys -- i.e., in a responder role -- in a text negotiation.
本文档废弃了[RFC3720]中定义的以下键：IFMarker、OFMarker、OFMarkInt和IFMarkInt。但是，符合本文档要求的iSCSI实施可能仍会在文本协商中接收这些过时的密钥（即，处于响应者角色）。
When an IFMarker or OFMarker key is received, a compliant iSCSI implementation SHOULD respond with the constant "Reject" value. The implementation MAY alternatively respond with a "No" value.
当收到IFMarker或OFMarker密钥时，符合要求的iSCSI实现应以恒定的“拒绝”值响应。该实现可替换地以“否”值响应。
However, the implementation MUST NOT respond with a "NotUnderstood" value for either of these keys.
但是，对于这两个键，实现都不能使用“NotUnderstanding”值进行响应。
When an IFMarkInt or OFMarkInt key is received, a compliant iSCSI implementation MUST respond with the constant "Reject" value. The implementation MUST NOT respond with a "NotUnderstood" value for either of these keys.
当接收到IFMarkInt或OFMarkInt密钥时，符合要求的iSCSI实现必须以常量“Reject”值响应。对于这两个键，实现都不能使用“NotUnderstanding”值进行响应。
Use: LO, Declarative Senders: Initiator and target Scope: SW
用法：LO，声明性发送方：启动器和目标作用域：SW
X#NodeArchitecture=<list-of-values>
X#NodeArchitecture=<list-of-values>
Default is None.
默认值为“无”。
Examples:
示例：
X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a
X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a
X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5
X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5
X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686
X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686
This document does not define the structure or content of the list of values.
本文档未定义值列表的结构或内容。
The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, iSCSI vendor software, firmware, or hardware versions; the OS version; or hardware architecture. This key may be declared on a Discovery session or a Normal session.
启动器或目标向远程端点声明其iSCSI节点体系结构的详细信息。这些详细信息可能包括但不限于iSCSI供应商软件、固件或硬件版本；操作系统版本；或硬件架构。此密钥可以在发现会话或正常会话上声明。
The length of the key value (total length of the list-of-values) MUST NOT be greater than 255 bytes.
键值的长度（值列表的总长度）不得大于255字节。
X#NodeArchitecture MUST NOT be redeclared during the Login Phase.
在登录阶段，不得重新声明X#节点体系结构。
Functional behavior of the iSCSI node (this includes the iSCSI protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT depend on the presence, absence, or content of the X#NodeArchitecture key. The key MUST NOT be used by iSCSI nodes for interoperability or
iSCSI节点的功能行为（包括iSCSI协议逻辑——SCSI、iSCSI和TCP/IP协议）不得依赖于X节点体系结构密钥的存在、不存在或内容。iSCSI节点不得将密钥用于互操作性或
for exclusion of other nodes. To ensure proper use, key values SHOULD be set by the node itself, and there SHOULD NOT be provisions for the key values to contain user-defined text.
用于排除其他节点。为确保正确使用，键值应由节点本身设置，并且不应规定键值包含用户定义的文本。
Nodes implementing this key MUST choose one of the following implementation options:
实现此键的节点必须选择以下实现选项之一：
- only transmit the key,
- 只传送钥匙,，
- only log the key values received from other nodes, or
- 仅记录从其他节点接收的键值，或
- both transmit and log the key values.
- 传输和记录键值。
Each node choosing to implement transmission of the key values MUST be prepared to handle the response of iSCSI nodes that do not understand the key.
选择实现密钥值传输的每个节点都必须准备好处理不理解密钥的iSCSI节点的响应。
Nodes that implement transmission and/or logging of the key values may also implement administrative mechanisms that disable and/or change the logging and key transmission details (see Section 9.4). Thus, a valid behavior for this key may be that a node is completely silent (the node does not transmit any key value and simply discards any key values it receives without issuing a NotUnderstood response).
实现键值传输和/或记录的节点也可以实现禁用和/或更改记录和键值传输详细信息的管理机制（见第9.4节）。因此，该密钥的有效行为可能是节点完全静默（该节点不发送任何键值，只是丢弃它接收到的任何键值而不发出NotUnderstanding响应）。
This document makes rather significant changes in this area, and this section outlines the reasons behind the changes. As previously specified in [RFC3720], iSCSI had used text string prefixes, such as X- and X#, to distinguish extended login/text keys, digest algorithms, and authentication methods from their standardized counterparts. Based on experience with other protocols, [RFC6648], however, strongly recommends against this practice, in large part because extensions that use such prefixes may become standard over time, at which point it can be infeasible to change their text string names due to widespread usage under the existing text string name.
本文件在这方面做出了相当重要的更改，本节概述了更改背后的原因。正如之前在[RFC3720]中所述，iSCSI使用了文本字符串前缀，如X-和X#，以将扩展登录/文本密钥、摘要算法和身份验证方法与其标准化的对应方法区分开来。然而，根据其他协议的经验，[RFC6648]强烈建议反对这种做法，这在很大程度上是因为使用此类前缀的扩展可能会随着时间的推移而成为标准，在这一点上，由于在现有文本字符串名称下的广泛使用，更改其文本字符串名称是不可行的。
iSCSI's experience with public extensions supports the recommendations in [RFC6648], as the only extension item ever registered with IANA, the X#NodeArchitecture key, was specified as a standard key in a Standards Track RFC [RFC4850] and hence did not require the X# prefix. In addition, that key is the only public iSCSI extension that has been registered with IANA since RFC 3720 was originally published, so there has been effectively no use of the X#, Y#, and Z# public extension formats.
iSCSI在公共扩展方面的经验支持[RFC6648]中的建议，因为X#节点体系结构密钥是唯一一个在IANA注册的扩展项，在标准跟踪RFC[RFC4850]中被指定为标准密钥，因此不需要X#前缀。此外，该密钥是自RFC 3720最初发布以来唯一在IANA注册的公共iSCSI扩展，因此实际上没有使用X、Y和Z公共扩展格式。
Therefore, this document makes the following changes to the IANA registration procedures for iSCSI:
因此，本文档对iSCSI的IANA注册过程进行了以下更改：
1) The separate registries for X#, Y#, and Z# public extensions are removed. The single entry in the registry for X# login/text keys (X#NodeArchitecture) is transferred to the main "iSCSI Login/Text Keys" registry. IANA has never created the latter two registries because there have been no registration requests for them. These public extension formats (X#, Y#, Z#) MUST NOT be used, with the exception of the existing X#NodeArchitecture key.
1) 将删除X#、Y#和Z#公共扩展的单独注册表。注册表中X#登录/文本键（X#NodeArchitecture）的单个条目被传输到主“iSCSI登录/文本键”注册表。IANA从未创建后两个注册中心，因为没有针对它们的注册请求。不得使用这些公共扩展格式（X#，Y#，Z#），现有X#节点体系结构键除外。
2) The registration procedures for the main "iSCSI Login/Text Keys", "iSCSI digests", and "iSCSI authentication methods" IANA registries are changed to IETF Review [RFC5226] for possible future extensions to iSCSI. This change includes a deliberate decision to remove the possibility of specifying an IANA-registered iSCSI extension in an RFC published via an RFC Editor Independent Submission, as the level of review in that process is insufficient for iSCSI extensions.
2) 主要“iSCSI登录/文本密钥”、“iSCSI摘要”和“iSCSI身份验证方法”IANA注册表的注册程序更改为IETF Review[RFC5226]，以便将来可能扩展到iSCSI。此更改包括一项深思熟虑的决定，即取消在通过RFC编辑器独立提交发布的RFC中指定IANA注册的iSCSI扩展的可能性，因为该过程中的审查级别不足以支持iSCSI扩展。
3) The restriction against registering items using the private extension formats (X-, Y-, Z-) in the main IANA registries is removed. Extensions using these formats MAY be registered under the IETF Review registration procedures, but each format is restricted to the type of extension for which it is specified in this RFC and MUST NOT be used for other types. For example, the X- extension format for extension login/text keys MUST NOT be used for digest algorithms or authentication methods.
3) 取消了在IANA主注册表中使用专用扩展格式（X-、Y-、Z-）注册项目的限制。使用这些格式的扩展可根据IETF审查注册程序进行注册，但每种格式仅限于本RFC中规定的扩展类型，不得用于其他类型。例如，扩展登录/文本键的X扩展格式不能用于摘要算法或身份验证方法。
The well-known TCP port number for iSCSI connections assigned by IANA is 3260, and this is the default iSCSI port. Implementations needing a system TCP port number may use port 860, the port assigned by IANA as the iSCSI system port; however, in order to use port 860, it MUST be explicitly specified -- implementations MUST NOT default to the use of port 860, as 3260 is the only allowed default.
IANA为iSCSI连接分配的众所周知的TCP端口号为3260，这是默认的iSCSI端口。需要系统TCP端口号的实现可以使用端口860，IANA分配的端口作为iSCSI系统端口；但是，为了使用端口860，必须明确指定它——实现不能默认使用端口860，因为3260是唯一允许的默认值。
IANA has replaced the references for ports 860 and 3260, both TCP and UDP, with references to this document. Please see http://www.iana.org/assignments/service-names-port-numbers.
IANA已将端口860和3260（TCP和UDP）的引用替换为本文档的引用。请看http://www.iana.org/assignments/service-names-port-numbers.
IANA has updated all references to RFC 3720, RFC 4850, and RFC 5048 to instead reference this RFC in all of the iSCSI registries that are part of the "Internet Small Computer System Interface (iSCSI) Parameters" set of registries. This change reflects the fact that
IANA已更新了对RFC 3720、RFC 4850和RFC 5048的所有引用，以代替在作为“Internet小型计算机系统接口（iSCSI）参数”注册表集一部分的所有iSCSI注册表中引用此RFC。这一变化反映了以下事实：
those three RFCs are obsoleted by this RFC. References to other RFCs that are not being obsoleted (e.g., RFC 3723, RFC 5046) should not be changed.
这三个RFC已被本RFC淘汰。对未被淘汰的其他RFC（如RFC 3723、RFC 5046）的引用不应更改。
IANA has performed the following actions on the "iSCSI Login/Text Keys" registry:
IANA已在“iSCSI登录/文本键”注册表上执行了以下操作：
- Changed the registration procedure to IETF Review from Standard Required.
- 将注册程序从标准要求更改为IETF审查。
- Changed the RFC 5048 reference for the registry to reference this RFC.
- 将注册表的RFC 5048引用更改为引用此RFC。
- Added the X#NodeArchitecture key from the "iSCSI extended key" registry, and changed its reference to this RFC.
- 从“iSCSI扩展密钥”注册表中添加了X#NodeArchitecture密钥，并将其引用更改为此RFC。
- Changed all references to RFC 3720 and RFC 5048 to instead reference this RFC.
- 将对RFC 3720和RFC 5048的所有引用更改为引用此RFC。
IANA has changed the registration procedures for the "iSCSI authentication methods" and "iSCSI digests" registries to IETF Review from RFC Required.
IANA已将“iSCSI身份验证方法”和“iSCSI摘要”注册的注册程序从RFC更改为IETF审查。
IANA has removed the "iSCSI extended key" registry, as its one entry has been added to the "iSCSI Login/Text Keys" registry.
IANA已删除“iSCSI扩展密钥”注册表，因为它的一个条目已添加到“iSCSI登录/文本密钥”注册表中。
IANA has marked as obsolete the values 4 and 5 for SPKM1 and SPKM2, respectively, in the "iSCSI authentication methods" subregistry of the "Internet Small Computer System Interface (iSCSI) Parameters" set of registries.
IANA已将“Internet小型计算机系统接口（iSCSI）参数”注册表集的“iSCSI身份验证方法”子区中SPKM1和SPKM2的值4和5分别标记为已过时。
IANA has added this document to the "iSCSI Protocol Level" registry with value 1, as mentioned in Section 13.24.
IANA已将此文档添加到“iSCSI协议级别”注册表中，值为1，如第13.24节所述。
All the other IANA considerations stated in [RFC3720] and [RFC5048] remain unchanged. The assignments contained in the following subregistries are not repeated in this document:
[RFC3720]和[RFC5048]中规定的所有其他IANA注意事项保持不变。本文件不重复以下分区域中包含的任务：
- iSCSI authentication methods (from Section 13 of [RFC3720])
- iSCSI身份验证方法（来自[RFC3720]第13节）
- iSCSI digests (from Section 13 of [RFC3720])
- iSCSI摘要（摘自[RFC3720]第13节）
This document obsoletes the SPKM1 and SPKM2 key values for the AuthMethod text key. Consequently, the SPKM_ text key prefix MUST be treated as obsolete and not be reused.
本文档将废弃AuthMethod文本键的SPKM1和SPKM2键值。因此，SPKM_uu文本键前缀必须视为已过时，不能重复使用。
[EUI] "Guidelines for 64-bit Global Identifier (EUI-64(TM))", <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[EUI]“64位全局标识符（EUI-64（TM））指南”<http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>。
[FC-FS3] INCITS Technical Committee T11, "Fibre Channel - Framing and Signaling - 3 (FC-FS-3)", ANSI INCITS 470-2011, 2011.
[FC-FS3]INCITS技术委员会T11，“光纤通道-成帧和信令-3（FC-FS-3）”，ANSI INCITS 470-2011，2011。
[OUI] "IEEE OUI and "company_id" Assignments", <http://standards.ieee.org/regauth/oui>.
[OUI]“IEEE OUI和“公司id”分配”<http://standards.ieee.org/regauth/oui>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，1996年8月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945]Wu，T.，“SRP认证和密钥交换系统”，RFC 29452000年9月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[RFC3722]Bakke，M.，“互联网小型计算机系统接口（iSCSI）名称的字符串配置文件”，RFC 3722，2004年4月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723]Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.，和F.Travostino，“通过IP保护块存储协议”，RFC 37232004年4月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4171] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.
[RFC4171]Tseng，J.，Gibbons，K.，Travostino，F.，Du Laney，C.，和J.Souza，“互联网存储名称服务（iSNS）”，RFC 41712005年9月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, December 2005.
[RFC4304]Kent，S.，“互联网安全关联和密钥管理协议（ISAKMP）IPsec解释域（DOI）的扩展序列号（ESN）附录”，RFC 43042005年12月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543]McGrew，D.和J.Viega，“Galois消息认证码（GMAC）在IPsec ESP和AH中的使用”，RFC 4543，2006年5月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 69602013年6月。
[RFC7144] Knight, F. and M. Chadalapaka, "Internet Small Computer System Interface (iSCSI) SCSI Features Update", RFC 7144, April 2014.
[RFC7144]Knight，F.和M.Chadalapaka，“互联网小型计算机系统接口（iSCSI）SCSI功能更新”，RFC 7144，2014年4月。
[RFC7145] Ko, M. and A. Nezhinsky, "Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification", RFC 7145, April 2014.
[RFC7145]Ko，M.和A.Nezhinsky，“远程直接内存访问（RDMA）规范的互联网小型计算机系统接口（iSCSI）扩展”，RFC 71452014年4月。
[RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3", RFC 7146, April 2014.
[RFC7146]Black，D.和P.Koning，“通过IP保护块存储协议：IPsec v3的RFC 3723要求更新”，RFC 7146，2014年4月。
[SAM2] INCITS Technical Committee T10, "SCSI Architecture Model - 2 (SAM-2)", ANSI INCITS 366-2003, ISO/IEC 14776-412, 2003.
[SAM2]INCITS技术委员会T10，“SCSI体系结构模型-2（SAM-2）”，ANSI INCITS 366-2003，ISO/IEC 14776-4122003。
[SAM4] INCITS Technical Committee T10, "SCSI Architecture Model - 4 (SAM-4)", ANSI INCITS 447-2008, ISO/IEC 14776-414, 2008.
[SAM4]INCITS技术委员会T10，“SCSI体系结构模型-4（SAM-4）”，ANSI INCITS 447-2008，ISO/IEC 14776-4142008。
[SPC2] INCITS Technical Committee T10, "SCSI Primary Commands - 2", ANSI INCITS 351-2001, ISO/IEC 14776-452, 2001.
[SPC2]INCITS技术委员会T10，“SCSI主要命令-2”，ANSI INCITS 351-2001，ISO/IEC 14776-4522001。
[SPC3] INCITS Technical Committee T10, "SCSI Primary Commands - 3", ANSI INCITS 408-2005, ISO/IEC 14776-453, 2005.
[SPC3]INCITS技术委员会T10，“SCSI主要命令-3”，ANSI INCITS 408-2005，ISO/IEC 14776-453，2005。
[UML] ISO, "Unified Modeling Language (UML) Version 1.4.2", ISO/IEC 19501:2005.
[UML]ISO，“统一建模语言（UML）1.4.2版”，ISO/IEC 19501:2005。
[UNICODE] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", 2013, <http://www.unicode.org/unicode/reports/tr15>.
[UNICODE]UNICODE联盟，“UNICODE标准附录#15：UNICODE规范化格式”，2013年<http://www.unicode.org/unicode/reports/tr15>.
[Castagnoli93] Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE Transact. on Communications, Vol. 41, No. 6, June 1993.
[Castagnoli93]Castagnoli，G.，Brauer，S.，和M.Herrmann，“具有24和32奇偶校验位的循环冗余校验码的优化”，IEEE Transact。《来文》，第41卷，第6期，1993年6月。
[FC-SP-2] INCITS Technical Committee T11, "Fibre Channel Security Protocols 2", ANSI INCITS 496-2012, 2012.
[FC-SP-2]INCITS技术委员会T11，“光纤通道安全协议2”，ANSI INCITS 496-2012，2012年。
[IB] InfiniBand, "InfiniBand(TM) Architecture Specification", Vol. 1, Rel. 1.2.1, InfiniBand Trade Association, <http://www.infinibandta.org>.
[IB]InfiniBand，“InfiniBand（TM）体系结构规范”，第1卷，相关内容。1.2.1，InfiniBand贸易协会<http://www.infinibandta.org>.
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[RFC1737]Sollins，K.和L.Masinter，“统一资源名称的功能要求”，RFC 1737，1994年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]Guttman，E.，Perkins，C.，Veizades，J.，和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update ", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新”，RFC 2743，2000年1月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", RFC 3385, September 2002.
[RFC3385]Sheinwald，D.，Satran，J.，Thaler，P.，和V.Cavanna，“互联网协议小型计算机系统接口（iSCSI）循环冗余校验（CRC）/校验和注意事项”，RFC 33852002年9月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720]Satran，J.，Meth，K.，Sapuntzakis，C.，Chadalapaka，M.，和E.Zeidner，“互联网小型计算机系统接口（iSCSI）”，RFC 3720，2004年4月。
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[RFC3721]Bakke，M.，Hafner，J.，Hufferd，J.，Voruganti，K.，和M.Krueger，“互联网小型计算机系统接口（iSCSI）命名和发现”，RFC 37212004年4月。
[RFC3783] Chadalapaka, M. and R. Elliott, "Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI", RFC 3783, May 2004.
[RFC3783]Chadalapaka，M.和R.Elliott，“使用iSCSI的小型计算机系统接口（SCSI）命令排序注意事项”，RFC 3783，2004年5月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 41212005年7月。
[RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote Direct Memory Access (RDMA) over IP Problem Statement", RFC 4297, December 2005.
[RFC4297]Romanow，A.，Mogul，J.，Talpey，T.，和S.Bailey，“IP上的远程直接内存访问（RDMA）问题陈述”，RFC 42972005年12月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806]Myers，M.和H.Tschofenig，“IKEv2的在线证书状态协议（OCSP）扩展”，RFC 4806，2007年2月。
[RFC4850] Wysochanski, D., "Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture", RFC 4850, April 2007.
[RFC4850]Wysochanski，D.，“互联网小型计算机系统接口（iSCSI）节点体系结构的声明性公共扩展密钥”，RFC 48502007年4月。
[RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
[RFC5046]Ko，M.，Chadalapaka，M.，Hufferd，J.，Elzur，U.，Shah，H.，和P.Thaler，“远程直接内存访问（RDMA）的互联网小型计算机系统接口（iSCSI）扩展”，RFC 5046，2007年10月。
[RFC5048] Chadalapaka, M., Ed., "Internet Small Computer System Interface (iSCSI) Corrections and Clarifications", RFC 5048, October 2007.
[RFC5048]Chadalapaka，M.，编辑，“互联网小型计算机系统接口（iSCSI）更正和澄清”，RFC 5048，2007年10月。
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009.
[RFC5433]Clancy，T.和H.Tschofenig，“可扩展认证协议-通用预共享密钥（EAP-GPSK）方法”，RFC 5433，2009年2月。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.
[RFC6648]圣安德烈，P.，克罗克，D.，和M.诺丁汉，“反对应用协议中的“X-”前缀和类似结构”，BCP 178，RFC 6648，2012年6月。
[SAS] INCITS Technical Committee T10, "Serial Attached SCSI - 2.1 (SAS-2.1)", ANSI INCITS 457-2010, 2010.
[SAS]INCITS技术委员会T10，“串行连接SCSI-2.1（SAS-2.1）”，ANSI INCITS 457-2010，2010年。
[SBC2] INCITS Technical Committee T10, "SCSI Block Commands - 2 (SBC-2)", ANSI INCITS 405-2005, ISO/IEC 14776-322, 2005.
[SBC2]INCITS技术委员会T10，“SCSI块命令-2（SBC-2）”，ANSI INCITS 405-2005，ISO/IEC 14776-322，2005。
[SPC4] INCITS Technical Committee T10, "SCSI Primary Commands - 4", ANSI INCITS 513-201x.
[SPC4]INCITS技术委员会T10，“SCSI主要命令-4”，ANSI INCITS 513-201x。
[SPL] INCITS Technical Committee T10, "SAS Protocol Layer - 2 (SPL-2)", ANSI INCITS 505-2013, ISO/IEC 14776-262, 2013.
[SPL]INCITS技术委员会T10，“SAS协议层-2（SPL-2）”，ANSI INCITS 505-2013，ISO/IEC 14776-262，2013。
+------------------+-----------------------+---------------------+
|Initiator Function| PDU Type | Target Function |
+------------------+-----------------------+---------------------+
| Command request |SCSI Command (read)>>> | |
| (read) | | |
+------------------+-----------------------+---------------------+
| | |Prepare Data Transfer|
+------------------+-----------------------+---------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
+------------------+-----------------------+---------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
+------------------+-----------------------+---------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
+------------------+-----------------------+---------------------+
| | <<< SCSI Response |Send Status and Sense|
+------------------+-----------------------+---------------------+
| Command Complete | | |
+------------------+-----------------------+---------------------+
+------------------+-----------------------+---------------------+
|Initiator Function| PDU Type | Target Function |
+------------------+-----------------------+---------------------+
| Command request |SCSI Command (read)>>> | |
| (read) | | |
+------------------+-----------------------+---------------------+
| | |Prepare Data Transfer|
+------------------+-----------------------+---------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
+------------------+-----------------------+---------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
+------------------+-----------------------+---------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
+------------------+-----------------------+---------------------+
| | <<< SCSI Response |Send Status and Sense|
+------------------+-----------------------+---------------------+
| Command Complete | | |
+------------------+-----------------------+---------------------+
+------------------+-----------------------+---------------------+
|Initiator Function| PDU Type | Target Function |
+------------------+-----------------------+---------------------+
| Command request |SCSI Command (write)>>>| Receive command |
| (write) | | and queue it |
+------------------+-----------------------+---------------------+
| | | Process old commands|
+------------------+-----------------------+---------------------+
| | | Ready to process |
| | <<< R2T | write command |
+------------------+-----------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
+------------------+-----------------------+---------------------+
| | <<< R2T | Ready for data |
+------------------+-----------------------+---------------------+
| | <<< R2T | Ready for data |
+------------------+-----------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
+------------------+-----------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
+------------------+-----------------------+---------------------+
| | <<< SCSI Response |Send Status and Sense|
+------------------+-----------------------+---------------------+
| Command Complete | | |
+------------------+-----------------------+---------------------+
+------------------+-----------------------+---------------------+
|Initiator Function| PDU Type | Target Function |
+------------------+-----------------------+---------------------+
| Command request |SCSI Command (write)>>>| Receive command |
| (write) | | and queue it |
+------------------+-----------------------+---------------------+
| | | Process old commands|
+------------------+-----------------------+---------------------+
| | | Ready to process |
| | <<< R2T | write command |
+------------------+-----------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
+------------------+-----------------------+---------------------+
| | <<< R2T | Ready for data |
+------------------+-----------------------+---------------------+
| | <<< R2T | Ready for data |
+------------------+-----------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
+------------------+-----------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
+------------------+-----------------------+---------------------+
| | <<< SCSI Response |Send Status and Sense|
+------------------+-----------------------+---------------------+
| Command Complete | | |
+------------------+-----------------------+---------------------+
+-------------------+------------------------+---------------------+
|Initiator Function | PDU Type and Content | Target Function |
+-------------------+------------------------+---------------------+
| Command request |SCSI Command (write)>>> | Receive command |
| (write) | | and queue it |
+-------------------+------------------------+---------------------+
| | | Process old commands|
+-------------------+------------------------+---------------------+
| | <<< R2T | Ready for data |
| | R2TSN = 0 | |
+-------------------+------------------------+---------------------+
| | <<< R2T | Ready for more data |
| | R2TSN = 1 | |
+-------------------+------------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
| for R2TSN 0 | DataSN = 0, F = 0 | |
+-------------------+------------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
| for R2TSN 0 | DataSN = 1, F = 1 | |
+-------------------+------------------------+---------------------+
| Send Data | SCSI Data >>> | Receive Data |
| for R2TSN 1 | DataSN = 0, F = 1 | |
+-------------------+------------------------+---------------------+
| | <<< SCSI Response |Send Status and Sense|
| | ExpDataSN = 0 | |
+-------------------+------------------------+---------------------+
| Command Complete | | |
+-------------------+------------------------+---------------------+
+-------------------+------------------------+---------------------+
|Initiator Function | PDU Type and Content | Target Function |
+-------------------+------------------------+---------------------+
| Command request |SCSI Command (write)>>> | Receive command |
| (write) | | and queue it |
+-------------------+------------------------+---------------------+
| | | Process old commands|
+-------------------+------------------------+---------------------+
| | <<< R2T | Ready for data |
| | R2TSN = 0 | |
+-------------------+------------------------+---------------------+
| | <<< R2T | Ready for more data |
| | R2TSN = 1 | |
+-------------------+------------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
| for R2TSN 0 | DataSN = 0, F = 0 | |
+-------------------+------------------------+---------------------+
| Send Data | SCSI Data-Out >>> | Receive Data |
| for R2TSN 0 | DataSN = 1, F = 1 | |
+-------------------+------------------------+---------------------+
| Send Data | SCSI Data >>> | Receive Data |
| for R2TSN 1 | DataSN = 0, F = 1 | |
+-------------------+------------------------+---------------------+
| | <<< SCSI Response |Send Status and Sense|
| | ExpDataSN = 0 | |
+-------------------+------------------------+---------------------+
| Command Complete | | |
+-------------------+------------------------+---------------------+
+------------------+-----------------------+----------------------+
|Initiator Function| PDU Type | Target Function |
+------------------+-----------------------+----------------------+
| Command request |SCSI Command (read)>>> | |
| (read) | | |
+------------------+-----------------------+----------------------+
| | |Prepare Data Transfer |
+------------------+-----------------------+----------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 0, F = 0 | |
+------------------+-----------------------+----------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 1, F = 0 | |
+------------------+-----------------------+----------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 2, F = 1 | |
+------------------+-----------------------+----------------------+
| | <<< SCSI Response |Send Status and Sense |
| | ExpDataSN = 3 | |
+------------------+-----------------------+----------------------+
| Command Complete | | |
+------------------+-----------------------+----------------------+
+------------------+-----------------------+----------------------+
|Initiator Function| PDU Type | Target Function |
+------------------+-----------------------+----------------------+
| Command request |SCSI Command (read)>>> | |
| (read) | | |
+------------------+-----------------------+----------------------+
| | |Prepare Data Transfer |
+------------------+-----------------------+----------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 0, F = 0 | |
+------------------+-----------------------+----------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 1, F = 0 | |
+------------------+-----------------------+----------------------+
| Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 2, F = 1 | |
+------------------+-----------------------+----------------------+
| | <<< SCSI Response |Send Status and Sense |
| | ExpDataSN = 3 | |
+------------------+-----------------------+----------------------+
| Command Complete | | |
+------------------+-----------------------+----------------------+
+------------------+-----------------------+---------------------+
|Initiator Function| PDU Type | Target Function |
+------------------+-----------------------+---------------------+
| Command request |SCSI Command >>> | |
| (Read-Write) | Read-Write | |
+------------------+-----------------------+---------------------+
| | | Process old commands|
+------------------+-----------------------+---------------------+
| | <<< R2T | Ready to process |
| | R2TSN = 0 | write command |
+------------------+-----------------------+---------------------+
| * Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 0, F = 0 | |
+------------------+-----------------------+---------------------+
| * Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 1, F = 1 | |
+------------------+-----------------------+---------------------+
| * Send Data | SCSI Data-Out >>> | Receive Data |
| for R2TSN 0 | DataSN = 0, F = 1 | |
+------------------+-----------------------+---------------------+
| | <<< SCSI Response |Send Status and Sense|
| | ExpDataSN = 2 | |
+------------------+-----------------------+---------------------+
| Command Complete | | |
+------------------+-----------------------+---------------------+
+------------------+-----------------------+---------------------+
|Initiator Function| PDU Type | Target Function |
+------------------+-----------------------+---------------------+
| Command request |SCSI Command >>> | |
| (Read-Write) | Read-Write | |
+------------------+-----------------------+---------------------+
| | | Process old commands|
+------------------+-----------------------+---------------------+
| | <<< R2T | Ready to process |
| | R2TSN = 0 | write command |
+------------------+-----------------------+---------------------+
| * Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 0, F = 0 | |
+------------------+-----------------------+---------------------+
| * Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 1, F = 1 | |
+------------------+-----------------------+---------------------+
| * Send Data | SCSI Data-Out >>> | Receive Data |
| for R2TSN 0 | DataSN = 0, F = 1 | |
+------------------+-----------------------+---------------------+
| | <<< SCSI Response |Send Status and Sense|
| | ExpDataSN = 2 | |
+------------------+-----------------------+---------------------+
| Command Complete | | |
+------------------+-----------------------+---------------------+
* Send Data and Receive Data may be transferred simultaneously as in an atomic Read-Old-Write-New or sequentially as in an atomic Read-Update-Write (in the latter case, the R2T may follow the received data).
* 发送数据和接收数据可以像在原子读-旧-写-新中一样同时传输，或者像在原子读-更新-写中一样顺序传输（在后一种情况下，R2T可以跟随接收的数据）。
A.3.4. Unsolicited and Immediate Output (Write) Data with DataSN Example
A.3.4. 非请求和即时输出（写入）数据，带有DataSN示例
+------------------+------------------------+----------------------+
|Initiator Function| PDU Type and Content | Target Function |
+------------------+------------------------+----------------------+
| Command request |SCSI Command (write)>>> | Receive command |
| (write) |F = 0 | and data |
|+ immediate data | | and queue it |
+------------------+------------------------+----------------------+
| Send Unsolicited | SCSI Write Data >>> | Receive more Data |
| Data | DataSN = 0, F = 1 | |
+------------------+------------------------+----------------------+
| | | Process old commands |
+------------------+------------------------+----------------------+
| | <<< R2T | Ready for more data |
| | R2TSN = 0 | |
+------------------+------------------------+----------------------+
| Send Data | SCSI Write Data >>> | Receive Data |
| for R2TSN 0 | DataSN = 0, F = 1 | |
+------------------+------------------------+----------------------+
| | <<< SCSI Response |Send Status and Sense |
| | | |
+------------------+------------------------+----------------------+
| Command Complete | | |
+------------------+------------------------+----------------------+
+------------------+------------------------+----------------------+
|Initiator Function| PDU Type and Content | Target Function |
+------------------+------------------------+----------------------+
| Command request |SCSI Command (write)>>> | Receive command |
| (write) |F = 0 | and data |
|+ immediate data | | and queue it |
+------------------+------------------------+----------------------+
| Send Unsolicited | SCSI Write Data >>> | Receive more Data |
| Data | DataSN = 0, F = 1 | |
+------------------+------------------------+----------------------+
| | | Process old commands |
+------------------+------------------------+----------------------+
| | <<< R2T | Ready for more data |
| | R2TSN = 0 | |
+------------------+------------------------+----------------------+
| Send Data | SCSI Write Data >>> | Receive Data |
| for R2TSN 0 | DataSN = 0, F = 1 | |
+------------------+------------------------+----------------------+
| | <<< SCSI Response |Send Status and Sense |
| | | |
+------------------+------------------------+----------------------+
| Command Complete | | |
+------------------+------------------------+----------------------+
Note: All values are hexadecimal.
注：所有值均为十六进制。
32 bytes of zeroes:
32字节的零：
Byte: 0 1 2 3
字节：0 1 2 3
0: 00 00 00 00 ... 28: 00 00 00 00
0: 00 00 00 00 ... 28: 00 00 00 00
CRC: aa 36 91 8a
启联：机管局36 91 8a
32 bytes of ones:
32字节的1：
Byte: 0 1 2 3
字节：0 1 2 3
0: ff ff ff ff ... 28: ff ff ff ff
0:ff ff ff ff。。。28:ff ff ff
CRC: 43 ab a8 62
启联：43 ab a8 62
32 bytes of incrementing 00..1f:
递增00..1f的32字节：
Byte: 0 1 2 3
字节：0 1 2 3
0: 00 01 02 03 ... 28: 1c 1d 1e 1f
0: 00 01 02 03 ... 28:1c 1d 1e 1f
CRC: 4e 79 dd 46
CRC:4e 79 dd 46
32 bytes of decrementing 1f..00:
递减1f..00的32字节：
Byte: 0 1 2 3
字节：0 1 2 3
0: 1f 1e 1d 1c ... 28: 03 02 01 00
0:1f 1e 1d 1c。。。28: 03 02 01 00
CRC: 5c db 3f 11
CRC:5c db 3f 11
An iSCSI - SCSI Read (10) Command PDU:
iSCSI-SCSI读取（10）命令PDU：
Byte: 0 1 2 3
字节：0 1 2 3
0: 01 c0 00 00 4: 00 00 00 00 8: 00 00 00 00 12: 00 00 00 00 16: 14 00 00 00 20: 00 00 04 00 24: 00 00 00 14 28: 00 00 00 18 32: 28 00 00 00 36: 00 00 00 00 40: 02 00 00 00 44: 00 00 00 00
0:01 C000 00 00 4:00 00 00 00 08:00 00 00 00 16:14 00 00 00 20:00 00 00 04 00 24:00 00 00 00 14 28:00 00 00 00 18 32:28 00 00 00 36:00 00 00 40:02 00 00 44:00 00 00 00 00 00
CRC: 56 3a 96 d9
启联：56 3a 96 d9
In the first example, the initiator and target authenticate each other via Kerberos:
在第一个示例中，启动器和目标通过Kerberos相互验证：
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,SRP,None
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,SRP,None
T-> Login (CSG,NSG=0,0 T=0)
AuthMethod=KRB5
T-> Login (CSG,NSG=0,0 T=0)
AuthMethod=KRB5
I-> Login (CSG,NSG=0,1 T=1)
KRB_AP_REQ=<krb_ap_req>
I-> Login (CSG,NSG=0,1 T=1)
KRB_AP_REQ=<krb_ap_req>
(krb_ap_req contains the Kerberos V5 ticket and authenticator with MUTUAL-REQUIRED set in the ap-options field)
（krb_ap_req包含Kerberos V5票证和身份验证器，在ap选项字段中设置了相互必需）
If the authentication is successful, the target proceeds with:
如果身份验证成功，目标将继续执行以下操作：
T-> Login (CSG,NSG=0,1 T=1)
KRB_AP_REP=<krb_ap_rep>
T-> Login (CSG,NSG=0,1 T=1)
KRB_AP_REP=<krb_ap_rep>
(krb_ap_rep is the Kerberos V5 mutual authentication reply)
（krb_ap_rep是Kerberos V5相互身份验证回复）
If the authentication is successful, the initiator may proceed with:
如果身份验证成功，则发起方可以继续：
I-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=8192
I-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=8192
T-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=4096
MaxBurstLength=8192
T-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=4096
MaxBurstLength=8192
I-> Login (CSG,NSG=1,0 T=0) MaxBurstLength=8192
... more iSCSI Operational Parameters
I-> Login (CSG,NSG=1,0 T=0) MaxBurstLength=8192
... more iSCSI Operational Parameters
T-> Login (CSG,NSG=1,0 T=0) ... more iSCSI Operational Parameters
T->登录（CSG，NSG=1,0T=0）。。。更多iSCSI操作参数
And at the end:
最后：
I-> Login (CSG,NSG=1,3 T=1) optional iSCSI parameters
I->Login（CSG，NSG=1,3 T=1）可选iSCSI参数
T-> Login (CSG,NSG=1,3 T=1) "login accept"
T-> Login (CSG,NSG=1,3 T=1) "login accept"
If the initiator's authentication by the target is not successful, the target responds with:
如果目标对启动器的身份验证不成功，则目标会响应：
T-> Login "login reject"
T->登录“拒绝登录”
instead of the Login KRB_AP_REP message, and it terminates the connection.
而不是登录KRB_AP_REP消息，它会终止连接。
If the target's authentication by the initiator is not successful, the initiator terminates the connection (without responding to the Login KRB_AP_REP message).
如果启动器对目标的身份验证不成功，则启动器会终止连接（不响应登录KRB_AP_REP消息）。
In the next example, only the initiator is authenticated by the target via Kerberos:
在下一个示例中，目标仅通过Kerberos对启动器进行身份验证：
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=SRP,KRB5,None
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=SRP,KRB5,None
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=KRB5
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=KRB5
I-> Login (CSG,NSG=0,1 T=1)
KRB_AP_REQ=krb_ap_req
I-> Login (CSG,NSG=0,1 T=1)
KRB_AP_REQ=krb_ap_req
(MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req)
（krb_ap_req的ap选项字段中未设置相互要求）
If the authentication is successful, the target proceeds with:
如果身份验证成功，目标将继续执行以下操作：
T-> Login (CSG,NSG=0,1 T=1)
T-> Login (CSG,NSG=0,1 T=1)
I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
I->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
T->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
. . .
. . .
T-> Login (CSG,NSG=1,3 T=1)"login accept"
T-> Login (CSG,NSG=1,3 T=1)"login accept"
In the next example, the initiator and target authenticate each other via SRP:
在下一个示例中，启动器和目标通过SRP相互验证：
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,SRP,None
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,SRP,None
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=SRP
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=SRP
I-> Login (CSG,NSG=0,0 T=0)
SRP_U=<user>
TargetAuth=Yes
I-> Login (CSG,NSG=0,0 T=0)
SRP_U=<user>
TargetAuth=Yes
T-> Login (CSG,NSG=0,0 T=0)
SRP_N=<N>
SRP_g=<g>
SRP_s=<s>
T-> Login (CSG,NSG=0,0 T=0)
SRP_N=<N>
SRP_g=<g>
SRP_s=<s>
I-> Login (CSG,NSG=0,0 T=0)
SRP_A=<A>
I-> Login (CSG,NSG=0,0 T=0)
SRP_A=<A>
T-> Login (CSG,NSG=0,0 T=0)
SRP_B=<B>
T-> Login (CSG,NSG=0,0 T=0)
SRP_B=<B>
I-> Login (CSG,NSG=0,1 T=1)
SRP_M=<M>
I-> Login (CSG,NSG=0,1 T=1)
SRP_M=<M>
If the initiator authentication is successful, the target proceeds with:
如果启动器身份验证成功，目标将继续执行：
T-> Login (CSG,NSG=0,1 T=1)
SRP_HM=<H(A | M | K)>
T-> Login (CSG,NSG=0,1 T=1)
SRP_HM=<H(A | M | K)>
where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945].
其中[RFC2945]中定义了N、g、s、A、B、M和H（A | M | K）。
If the target authentication is not successful, the initiator terminates the connection; otherwise, it proceeds.
如果目标身份验证不成功，则发起方终止连接；否则，它将继续。
I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
I->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
T->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
And at the end:
最后：
I-> Login (CSG,NSG=1,3 T=1) optional iSCSI parameters
I->Login（CSG，NSG=1,3 T=1）可选iSCSI参数
T-> Login (CSG,NSG=1,3 T=1) "login accept"
T-> Login (CSG,NSG=1,3 T=1) "login accept"
If the initiator authentication is not successful, the target responds with:
如果启动器身份验证未成功，目标系统将响应：
T-> Login "login reject"
T->登录“拒绝登录”
instead of the T-> Login SRP_HM=<H(A | M | K)> message, and it terminates the connection.
而不是T->Login SRP_HM=<H（A | M | K）>消息，它会终止连接。
In the next example, only the initiator is authenticated by the target via SRP:
在下一个示例中，目标仅通过SRP对启动器进行身份验证：
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,SRP,None
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,SRP,None
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=SRP
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=SRP
I-> Login (CSG,NSG=0,0 T=0)
SRP_U=<user>
TargetAuth=No
I-> Login (CSG,NSG=0,0 T=0)
SRP_U=<user>
TargetAuth=No
T-> Login (CSG,NSG=0,0 T=0)
SRP_N=<N>
SRP_g=<g>
SRP_s=<s>
T-> Login (CSG,NSG=0,0 T=0)
SRP_N=<N>
SRP_g=<g>
SRP_s=<s>
I-> Login (CSG,NSG=0,0 T=0)
SRP_A=<A>
I-> Login (CSG,NSG=0,0 T=0)
SRP_A=<A>
T-> Login (CSG,NSG=0,0 T=0)
SRP_B=<B>
T-> Login (CSG,NSG=0,0 T=0)
SRP_B=<B>
I-> Login (CSG,NSG=0,1 T=1)
SRP_M=<M>
I-> Login (CSG,NSG=0,1 T=1)
SRP_M=<M>
If the initiator authentication is successful, the target proceeds with:
如果启动器身份验证成功，目标将继续执行：
T-> Login (CSG,NSG=0,1 T=1)
T-> Login (CSG,NSG=0,1 T=1)
I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
I->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
T->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
And at the end:
最后：
I-> Login (CSG,NSG=1,3 T=1) optional iSCSI parameters
I->Login（CSG，NSG=1,3 T=1）可选iSCSI参数
T-> Login (CSG,NSG=1,3 T=1) "login accept"
T-> Login (CSG,NSG=1,3 T=1) "login accept"
In the next example, the initiator and target authenticate each other via CHAP:
在下一个示例中，启动器和目标通过CHAP相互验证：
I-> Login (CSG,NSG=0,0 T=0)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,CHAP,None
I-> Login (CSG,NSG=0,0 T=0)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,CHAP,None
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=CHAP
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=CHAP
I-> Login (CSG,NSG=0,0 T=0)
CHAP_A=<A1,A2>
I-> Login (CSG,NSG=0,0 T=0)
CHAP_A=<A1,A2>
T-> Login (CSG,NSG=0,0 T=0)
CHAP_A=<A1>
CHAP_I=<I>
CHAP_C=<C>
T-> Login (CSG,NSG=0,0 T=0)
CHAP_A=<A1>
CHAP_I=<I>
CHAP_C=<C>
I-> Login (CSG,NSG=0,1 T=1)
CHAP_N=<N>
CHAP_R=<R>
CHAP_I=<I>
CHAP_C=<C>
I-> Login (CSG,NSG=0,1 T=1)
CHAP_N=<N>
CHAP_R=<R>
CHAP_I=<I>
CHAP_C=<C>
If the initiator authentication is successful, the target proceeds with:
如果启动器身份验证成功，目标将继续执行：
T-> Login (CSG,NSG=0,1 T=1)
CHAP_N=<N>
CHAP_R=<R>
T-> Login (CSG,NSG=0,1 T=1)
CHAP_N=<N>
CHAP_R=<R>
If the target authentication is not successful, the initiator aborts the connection; otherwise, it proceeds.
如果目标身份验证不成功，则发起方中止连接；否则，它将继续。
I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
I->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
T->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
And at the end:
最后：
I-> Login (CSG,NSG=1,3 T=1) optional iSCSI parameters
I->Login（CSG，NSG=1,3 T=1）可选iSCSI参数
T-> Login (CSG,NSG=1,3 T=1) "login accept"
T-> Login (CSG,NSG=1,3 T=1) "login accept"
If the initiator authentication is not successful, the target responds with:
如果启动器身份验证未成功，目标系统将响应：
T-> Login "login reject"
T->登录“拒绝登录”
instead of the Login CHAP_R=<response> "proceed and change stage" message, and it terminates the connection.
而不是登录CHAP_R=<response>“继续并更改阶段”消息，它将终止连接。
In the next example, only the initiator is authenticated by the target via CHAP:
在下一个示例中，目标仅通过CHAP对启动器进行身份验证：
I-> Login (CSG,NSG=0,1 T=0)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,CHAP,None
I-> Login (CSG,NSG=0,1 T=0)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,CHAP,None
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=CHAP
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=CHAP
I-> Login (CSG,NSG=0,0 T=0)
CHAP_A=<A1,A2>
I-> Login (CSG,NSG=0,0 T=0)
CHAP_A=<A1,A2>
T-> Login (CSG,NSG=0,0 T=0)
CHAP_A=<A1>
CHAP_I=<I>
CHAP_C=<C>
T-> Login (CSG,NSG=0,0 T=0)
CHAP_A=<A1>
CHAP_I=<I>
CHAP_C=<C>
I-> Login (CSG,NSG=0,1 T=1)
CHAP_N=<N>
CHAP_R=<R>
I-> Login (CSG,NSG=0,1 T=1)
CHAP_N=<N>
CHAP_R=<R>
If the initiator authentication is successful, the target proceeds with:
如果启动器身份验证成功，目标将继续执行：
T-> Login (CSG,NSG=0,1 T=1)
T-> Login (CSG,NSG=0,1 T=1)
I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
I->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
T->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
And at the end:
最后：
I-> Login (CSG,NSG=1,3 T=1) optional iSCSI parameters
I->Login（CSG，NSG=1,3 T=1）可选iSCSI参数
T-> Login (CSG,NSG=1,3 T=1) "login accept"
T-> Login (CSG,NSG=1,3 T=1) "login accept"
In the next example, the initiator does not offer any security parameters. It therefore may offer iSCSI parameters on the Login PDU with the T bit set to 1, and the target may respond with a final Login Response PDU immediately:
在下一个示例中，启动器不提供任何安全参数。因此，它可以在登录PDU上提供iSCSI参数，T位设置为1，并且目标可以立即使用最终登录响应PDU进行响应：
I-> Login (CSG,NSG=1,3 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
... iSCSI parameters
I-> Login (CSG,NSG=1,3 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
... iSCSI parameters
T-> Login (CSG,NSG=1,3 T=1) "login accept" ... ISCSI parameters
T->登录（CSG，NSG=1,3 T=1）“登录接受”。。。ISCSI参数
In the next example, the initiator does offer security parameters on the Login PDU, but the target does not choose any (i.e., chooses the "None" values):
在下一个示例中，发起方确实在登录PDU上提供了安全参数，但目标方没有选择任何安全参数（即选择“无”值）：
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,SRP,None
I-> Login (CSG,NSG=0,1 T=1)
InitiatorName=iqn.1999-07.com.os:hostid.77
TargetName=iqn.1999-07.com.example:diskarray.sn.88
AuthMethod=KRB5,SRP,None
T-> Login-PR (CSG,NSG=0,1 T=1)
AuthMethod=None
T-> Login-PR (CSG,NSG=0,1 T=1)
AuthMethod=None
I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
I->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
T->登录（CSG，NSG=1,0T=0）。。。iSCSI参数
And at the end:
最后：
I-> Login (CSG,NSG=1,3 T=1) optional iSCSI parameters
I->Login（CSG，NSG=1,3 T=1）可选iSCSI参数
T-> Login (CSG,NSG=1,3 T=1) "login accept"
T-> Login (CSG,NSG=1,3 T=1) "login accept"
The text in this appendix is a normative part of this document.
本附录中的文本是本文件的规范性部分。
To reduce the amount of configuration required on an initiator, iSCSI provides the SendTargets Text Request. The initiator uses the SendTargets request to get a list of targets to which it may have access, as well as the list of addresses (IP address and TCP port) on which these targets may be accessed.
为了减少启动器上所需的配置量，iSCSI提供SendTargets文本请求。启动器使用SendTargets请求获取其可以访问的目标列表，以及可以访问这些目标的地址列表（IP地址和TCP端口）。
To make use of SendTargets, an initiator must first establish one of two types of sessions. If the initiator establishes the session using the key "SessionType=Discovery", the session is a Discovery session, and a target name does not need to be specified. Otherwise, the session is a Normal operational session. The SendTargets command MUST only be sent during the Full Feature Phase of a Normal or Discovery session.
要使用SendTargets，启动器必须首先建立两种类型的会话之一。如果启动器使用键“SessionType=Discovery”建立会话，则该会话为发现会话，无需指定目标名称。否则，会话为正常操作会话。SendTargets命令只能在正常会话或查找会话的完整功能阶段发送。
A system that contains targets MUST support Discovery sessions on each of its iSCSI IP address-port pairs and MUST support the SendTargets command on the Discovery session. In a Discovery session, a target MUST return all path information (IP address-port pairs and Target Portal Group Tags) for the targets on the target Network Entity that the requesting initiator is authorized to access.
包含目标的系统必须在其每个iSCSI IP地址端口对上支持发现会话，并且必须在发现会话上支持SendTargets命令。在发现会话中，目标必须返回请求启动器有权访问的目标网络实体上目标的所有路径信息（IP地址端口对和目标门户组标记）。
A target MUST support the SendTargets command on operational sessions; these will only return path information about the target to which the session is connected and do not need to return information about other target names that may be defined in the responding system.
目标必须在操作会话上支持SendTargets命令；它们只返回会话连接到的目标的路径信息，不需要返回响应系统中定义的其他目标名称的信息。
An initiator MAY make use of the SendTargets command as it sees fit.
启动器可以在其认为合适的情况下使用SendTargets命令。
A SendTargets command consists of a single Text Request PDU. This PDU contains exactly one text key and value. The text key MUST be SendTargets. The expected response depends upon the value, as well as whether the session is a Discovery session or an operational session.
SendTargets命令由单个文本请求PDU组成。此PDU仅包含一个文本键和值。文本键必须是SendTargets。预期的响应取决于该值，以及该会话是发现会话还是操作会话。
The value must be one of:
该值必须是以下值之一：
All
全部的
The initiator is requesting that information on all relevant targets known to the implementation be returned. This value MUST be supported on a Discovery session and MUST NOT be supported on an operational session.
发起人请求返回有关实现已知的所有相关目标的信息。发现会话必须支持此值，而操作会话则不支持此值。
<iSCSI-target-name>
<iSCSI目标名称>
If an iSCSI Target Name is specified, the session should respond with addresses for only the named target, if possible. This value MUST be supported on Discovery sessions. A Discovery session MUST be capable of returning addresses for those targets that would have been returned had value=All been designated.
如果指定了iSCSI目标名称，会话应尽可能仅使用指定目标的地址进行响应。发现会话必须支持此值。发现会话必须能够返回在value=All被指定时本应返回的那些目标的地址。
<nothing>
<nothing>
The session should only respond with addresses for the target to which the session is logged in. This MUST be supported on operational sessions and MUST NOT return targets other than the one to which the session is logged in.
会话应仅使用会话登录到的目标的地址进行响应。这必须在操作会话上得到支持，并且不能返回除会话登录目标之外的其他目标。
The response to this command is a Text Response that contains a list of zero or more targets and, optionally, their addresses. Each target is returned as a target record. A target record begins with the TargetName text key, followed by a list of TargetAddress text keys, and bounded by the end of the Text Response or the next TargetName key, which begins a new record. No text keys other than TargetName and TargetAddress are permitted within a SendTargets response.
对该命令的响应是一个文本响应，其中包含零个或多个目标以及（可选）它们的地址的列表。每个目标都作为目标记录返回。目标记录以TargetName文本键开始，后跟TargetAddress文本键列表，并以文本响应的结尾或下一个TargetName键为边界，该键开始一个新记录。SendTargets响应中不允许使用除TargetName和TargetAddress之外的文本键。
For the format of the TargetName, see Section 13.4.
有关TargetName的格式，请参见第13.4节。
A Discovery session MAY respond to a SendTargets request with its complete list of targets, or with a list of targets that is based on the name of the initiator logged in to the session.
发现会话可以使用完整的目标列表或基于登录到会话的启动器名称的目标列表响应SendTargets请求。
A SendTargets response MUST NOT contain target names if there are no targets for the requesting initiator to access.
如果没有可供请求启动器访问的目标，则SendTargets响应不得包含目标名称。
Each target record returned includes zero or more TargetAddress fields.
返回的每个目标记录包含零个或多个TargetAddress字段。
Each target record starts with one text key of the form:
每个目标记录以表单的一个文本键开始：
TargetName=<target-name-goes-here>
TargetName=<target-name-goes-here>
followed by zero or more address keys of the form:
后跟零个或多个地址键：
TargetAddress=<hostname-or-ipaddress>[:<tcp-port>],
<portal-group-tag>
TargetAddress=<hostname-or-ipaddress>[:<tcp-port>],
<portal-group-tag>
The hostname-or-ipaddress contains a domain name, IPv4 address, or IPv6 address ([RFC4291]), as specified for the TargetAddress key.
主机名或IP地址包含为TargetAddress密钥指定的域名、IPv4地址或IPv6地址（[RFC4291]）。
A hostname-or-ipaddress duplicated in TargetAddress responses for a given node (the port is absent or equal) would probably indicate that multiple address families are in use at once (IPv6 and IPv4).
给定节点的TargetAddress响应中重复的主机名或IP地址（端口不存在或相等）可能表示同时使用多个地址族（IPv6和IPv4）。
Each TargetAddress belongs to a portal group, identified by its numeric Target Portal Group Tag (see Section 13.9). The iSCSI Target Name, together with this tag, constitutes the SCSI port identifier; the tag only needs to be unique within a given target's name list of addresses.
每个TargetAddress都属于一个门户组，由其数字目标门户组标记标识（请参见第13.9节）。iSCSI目标名称与此标记一起构成SCSI端口标识符；标记只需要在给定目标的地址列表中是唯一的。
Multiple-connection sessions can span iSCSI addresses that belong to the same portal group.
多个连接会话可以跨越属于同一门户组的iSCSI地址。
Multiple-connection sessions cannot span iSCSI addresses that belong to different portal groups.
多个连接会话不能跨越属于不同门户组的iSCSI地址。
If a SendTargets response reports an iSCSI address for a target, it SHOULD also report all other addresses in its portal group in the same response.
如果SendTargets响应报告目标的iSCSI地址，则还应在同一响应中报告其门户组中的所有其他地址。
A SendTargets Text Response can be longer than a single Text Response PDU and makes use of the long Text Responses as specified.
SendTargets文本响应可以比单个文本响应PDU长，并使用指定的长文本响应。
After obtaining a list of targets from the Discovery session, an iSCSI initiator may initiate new sessions to log in to the discovered targets for full operation. The initiator MAY keep the Discovery session open and MAY send subsequent SendTargets commands to discover new targets.
从发现会话获取目标列表后，iSCSI启动器可能会启动新会话以登录到发现的目标以进行完整操作。发起方可以保持发现会话打开，并可以发送后续SendTargets命令以发现新目标。
Examples:
示例：
This example is the SendTargets response from a single target that has no other interface ports.
此示例是来自没有其他接口端口的单个目标的SendTargets响应。
The initiator sends a Text Request that contains:
启动器发送一个文本请求，其中包含：
SendTargets=All
SendTargets=All
The target sends a Text Response that contains:
目标发送包含以下内容的文本响应：
TargetName=iqn.1993-11.com.example:diskarray.sn.8675309
TargetName=iqn.1993-11.com。示例：diskarray.sn.8675309
All the target had to return in this simple case was the target name. It is assumed by the initiator that the IP address and TCP port for this target are the same as those used on the current connection to the default iSCSI target.
在这个简单的例子中，所有目标必须返回的就是目标名称。启动器假定此目标的IP地址和TCP端口与默认iSCSI目标的当前连接上使用的IP地址和TCP端口相同。
The next example has two internal iSCSI targets, each accessible via two different ports with different IP addresses. The following is the Text Response:
下一个示例有两个内部iSCSI目标，每个目标都可以通过具有不同IP地址的两个不同端口访问。以下是文本答复：
TargetName=iqn.1993-11.com.example:diskarray.sn.8675309
TargetName=iqn.1993-11.com。示例：diskarray.sn.8675309
TargetAddress=10.1.0.45:3000,1
TargetAddress=10.1.0.45:3000,1
TargetAddress=10.1.1.45:3000,2
TargetAddress=10.1.1.45:3000,2
TargetName=iqn.1993-11.com.example:diskarray.sn.1234567
TargetName=iqn.1993-11.com。示例：diskarray.sn.1234567
TargetAddress=10.1.0.45:3000,1
TargetAddress=10.1.0.45:3000,1
TargetAddress=10.1.1.45:3000,2
TargetAddress=10.1.1.45:3000,2
Both targets share both addresses; the multiple addresses are likely used to provide multi-path support. The initiator may connect to either target name on either address. Each of the addresses has its own Target Portal Group Tag; they do not support spanning multiple-connection sessions with each other. Keep in mind that the Target Portal Group Tags for the two named targets are independent of one another; portal group "1" on the first target is not necessarily the same as portal group "1" on the second target.
两个目标共享两个地址；多个地址可能用于提供多路径支持。启动器可以连接到任一地址上的任一目标名称。每个地址都有自己的目标门户组标签；它们不支持相互跨越多个连接会话。请记住，两个命名目标的目标门户组标记彼此独立；第一个目标上的门户组“1”不一定与第二个目标上的门户组“1”相同。
In the above example, a DNS host name or an IPv6 address could have been returned instead of an IPv4 address.
在上面的示例中，可能返回了DNS主机名或IPv6地址，而不是IPv4地址。
The next Text Response shows a target that supports spanning sessions across multiple addresses and further illustrates the use of the Target Portal Group Tags:
下一个文本响应显示了支持跨多个地址跨会话的目标，并进一步说明了目标门户组标记的使用：
TargetName=iqn.1993-11.com.example:diskarray.sn.8675309
TargetName=iqn.1993-11.com。示例：diskarray.sn.8675309
TargetAddress=10.1.0.45:3000,1
TargetAddress=10.1.0.45:3000,1
TargetAddress=10.1.1.46:3000,1
TargetAddress=10.1.1.46:3000,1
TargetAddress=10.1.0.47:3000,2
TargetAddress=10.1.0.47:3000,2
TargetAddress=10.1.1.48:3000,2
TargetAddress=10.1.1.48:3000,2
TargetAddress=10.1.1.49:3000,3
TargetAddress=10.1.1.49:3000,3
In this example, any of the target addresses can be used to reach the same target. A single-connection session can be established to any of these TCP addresses. A multiple-connection session could span addresses .45 and .46 or .47 and .48 but cannot span any other combination. A TargetAddress with its own tag (.49) cannot be combined with any other address within the same session.
在此示例中，任何目标地址都可用于到达同一目标。可以与这些TCP地址中的任何一个建立单个连接会话。多连接会话可以跨越地址.45和.46或.47和.48，但不能跨越任何其他组合。具有自己标记（.49）的TargetAddress不能与同一会话中的任何其他地址组合。
This SendTargets response does not indicate whether .49 supports multiple connections per session; it is communicated via the MaxConnections text key upon login to the target.
此SendTargets响应不指示.49是否支持每个会话的多个连接；登录到目标时，通过MaxConnections文本键进行通信。
This appendix illustrates the error recovery classes using a pseudo-programming language. The procedure names are chosen to be obvious to most implementers. Each of the recovery classes described has initiator procedures as well as target procedures. These algorithms focus on outlining the mechanics of error recovery classes and do not exhaustively describe all other aspects/cases. Examples of this approach are as follows:
本附录说明了使用伪编程语言的错误恢复类。过程名称的选择对大多数实现者来说是显而易见的。所描述的每个恢复类都有启动器过程和目标过程。这些算法侧重于概述错误恢复类的机制，而不是详尽地描述所有其他方面/情况。这种方法的例子如下：
- Handling for only certain Opcode types is shown.
- 仅显示特定操作码类型的处理。
- Only certain reason codes (e.g., Recovery in Logout command) are outlined.
- 仅列出了某些原因代码（如注销命令中的恢复）。
- Resultant cases, such as recovery of Synchronization on a header digest error, are considered out of scope in these algorithms. In this particular example, a header digest error may lead to connection recovery if some type of Sync and Steering layer is not implemented.
- 在这些算法中，所产生的情况（例如在报头摘要错误上恢复同步）被认为超出了范围。在此特定示例中，如果未实现某种类型的同步和指导层，则报头摘要错误可能导致连接恢复。
These algorithms strive to convey the iSCSI error recovery concepts in the simplest terms and are not designed to be optimal.
这些算法力求以最简单的方式传达iSCSI错误恢复概念，而不是为了达到最佳效果而设计的。
This section defines the procedures and data structures that are commonly used by all the error recovery algorithms. The structures may not be the exhaustive representations of what is required for a typical implementation.
本节定义了所有错误恢复算法常用的过程和数据结构。这些结构可能不是典型实现所需内容的详尽表示。
Data structure definitions:
数据结构定义：
struct TransferContext {
int TargetTransferTag;
int ExpectedDataSN;
};
struct TransferContext {
int TargetTransferTag;
int ExpectedDataSN;
};
struct TCB { /* task control block */
Boolean SoFarInOrder;
int ExpectedDataSN; /* used for both R2Ts and Data */
int MissingDataSNList[MaxMissingDPDU];
Boolean FbitReceived;
Boolean StatusXferd;
Boolean CurrentlyAllegiant;
int ActiveR2Ts;
int Response;
char *Reason;
struct TransferContext
TransferContextList[MaxOutstandingR2T];
int InitiatorTaskTag;
int CmdSN;
int SNACK_Tag;
};
struct TCB { /* task control block */
Boolean SoFarInOrder;
int ExpectedDataSN; /* used for both R2Ts and Data */
int MissingDataSNList[MaxMissingDPDU];
Boolean FbitReceived;
Boolean StatusXferd;
Boolean CurrentlyAllegiant;
int ActiveR2Ts;
int Response;
char *Reason;
struct TransferContext
TransferContextList[MaxOutstandingR2T];
int InitiatorTaskTag;
int CmdSN;
int SNACK_Tag;
};
struct Connection {
struct Session SessionReference;
Boolean SoFarInOrder;
int CID;
int State;
int CurrentTimeout;
int ExpectedStatSN;
int MissingStatSNList[MaxMissingSPDU];
Boolean PerformConnectionCleanup;
};
struct Connection {
struct Session SessionReference;
Boolean SoFarInOrder;
int CID;
int State;
int CurrentTimeout;
int ExpectedStatSN;
int MissingStatSNList[MaxMissingSPDU];
Boolean PerformConnectionCleanup;
};
struct Session {
int NumConnections;
int CmdSN;
int Maxconnections;
int ErrorRecoveryLevel;
struct iSCSIEndpoint OtherEndInfo;
struct Connection ConnectionList[MaxSupportedConns];
};
struct Session {
int NumConnections;
int CmdSN;
int Maxconnections;
int ErrorRecoveryLevel;
struct iSCSIEndpoint OtherEndInfo;
struct Connection ConnectionList[MaxSupportedConns];
};
Procedure descriptions:
程序说明：
Receive-an-In-PDU(transport connection, inbound PDU);
check-basic-validity(inbound PDU);
Start-Timer(timeout handler, argument, timeout value);
Build-And-Send-Reject(transport connection, bad PDU, reason code);
Receive-an-In-PDU(transport connection, inbound PDU);
check-basic-validity(inbound PDU);
Start-Timer(timeout handler, argument, timeout value);
Build-And-Send-Reject(transport connection, bad PDU, reason code);
Recover-Data-if-Possible(last required DataSN, task control block);
Build-And-Send-DSnack(task control block);
Build-And-Send-RDSnack(task control block);
Build-And-Send-Abort(task control block);
SCSI-Task-Completion(task control block);
Build-And-Send-A-Data-Burst(transport connection, data-descriptor,
task control block);
Build-And-Send-R2T(transport connection, data-descriptor,
task control block);
Build-And-Send-Status(transport connection, task control block);
Transfer-Context-Timeout-Handler(transfer context);
Recover-Data-if-Possible(last required DataSN, task control block);
Build-And-Send-DSnack(task control block);
Build-And-Send-RDSnack(task control block);
Build-And-Send-Abort(task control block);
SCSI-Task-Completion(task control block);
Build-And-Send-A-Data-Burst(transport connection, data-descriptor,
task control block);
Build-And-Send-R2T(transport connection, data-descriptor,
task control block);
Build-And-Send-Status(transport connection, task control block);
Transfer-Context-Timeout-Handler(transfer context);
Notes:
笔记：
- One procedure used in this section: the Handle-Status-SNACK-request is defined in Appendix D.3.
- 本节中使用的一个程序：句柄状态请求在附录D.3中定义。
- The response-processing pseudocode shown in the target algorithms applies to all solicited PDUs that carry the StatSN -- SCSI Response, Text Response, etc.
- 目标算法中显示的响应处理伪代码适用于所有携带StatSN（SCSI响应、文本响应等）的请求PDU。
Recover-Data-if-Possible(LastRequiredDataSN, TCB)
{
if (operational ErrorRecoveryLevel > 0) {
if (# of missing PDUs is trackable) {
Note the missing DataSNs in TCB.
if (the task spanned a change in
MaxRecvDataSegmentLength) {
if (TCB.StatusXferd is TRUE)
drop the status PDU;
Build-And-Send-RDSnack(TCB);
} else {
Build-And-Send-DSnack(TCB);
}
Recover-Data-if-Possible(LastRequiredDataSN, TCB)
{
if (operational ErrorRecoveryLevel > 0) {
if (# of missing PDUs is trackable) {
Note the missing DataSNs in TCB.
if (the task spanned a change in
MaxRecvDataSegmentLength) {
if (TCB.StatusXferd is TRUE)
drop the status PDU;
Build-And-Send-RDSnack(TCB);
} else {
Build-And-Send-DSnack(TCB);
}
} else {
TCB.Reason = "Protocol Service CRC error";
}
} else {
TCB.Reason = "Protocol Service CRC error";
}
if (TCB.Reason == "Protocol Service CRC error") {
Clear the missing PDU list in the TCB.
if (TCB.StatusXferd is not TRUE)
Build-And-Send-Abort(TCB);
}
}
} else {
TCB.Reason = "Protocol Service CRC error";
}
} else {
TCB.Reason = "Protocol Service CRC error";
}
if (TCB.Reason == "Protocol Service CRC error") {
Clear the missing PDU list in the TCB.
if (TCB.StatusXferd is not TRUE)
Build-And-Send-Abort(TCB);
}
}
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Retrieve TCB for CurrentPDU.InitiatorTaskTag.
if ((CurrentPDU.type == Data)
or (CurrentPDU.type = R2T)) {
if (Data-Digest-Bad for Data) {
send-data-SNACK = TRUE;
LastRequiredDataSN = CurrentPDU.DataSN;
} else {
if (TCB.SoFarInOrder = TRUE) {
if (current DataSN is expected) {
Increment TCB.ExpectedDataSN.
} else {
TCB.SoFarInOrder = FALSE;
send-data-SNACK = TRUE;
}
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Retrieve TCB for CurrentPDU.InitiatorTaskTag.
if ((CurrentPDU.type == Data)
or (CurrentPDU.type = R2T)) {
if (Data-Digest-Bad for Data) {
send-data-SNACK = TRUE;
LastRequiredDataSN = CurrentPDU.DataSN;
} else {
if (TCB.SoFarInOrder = TRUE) {
if (current DataSN is expected) {
Increment TCB.ExpectedDataSN.
} else {
TCB.SoFarInOrder = FALSE;
send-data-SNACK = TRUE;
}
} else {
if (current DataSN was considered missing) {
remove current DataSN from missing PDU list.
} else if (current DataSN is higher than expected) {
send-data-SNACK = TRUE;
} else {
discard, return;
}
Adjust TCB.ExpectedDataSN if appropriate.
}
LastRequiredDataSN = CurrentPDU.DataSN - 1;
}
if (send-data-SNACK is TRUE and
task is not already considered failed) {
Recover-Data-if-Possible(LastRequiredDataSN, TCB);
}
if (missing data PDU list is empty) {
TCB.SoFarInOrder = TRUE;
}
if (CurrentPDU.type == R2T) {
Increment ActiveR2Ts for this task.
Create a data-descriptor for the data burst.
Build-And-Send-A-Data-Burst(Connection, data-descriptor, TCB);
}
} else if (CurrentPDU.type == Response) {
if (Data-Digest-Bad) {
send-status-SNACK = TRUE;
} else {
TCB.StatusXferd = TRUE;
Store the status information in TCB.
if (ExpDataSN does not match) {
TCB.SoFarInOrder = FALSE;
Recover-Data-if-Possible(current DataSN, TCB);
}
if (missing data PDU list is empty) {
TCB.SoFarInOrder = TRUE;
}
}
} else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT SHOWN */
}
if ((TCB.SoFarInOrder == TRUE) and
(TCB.StatusXferd == TRUE)) {
SCSI-Task-Completion(TCB);
}
}
} else {
if (current DataSN was considered missing) {
remove current DataSN from missing PDU list.
} else if (current DataSN is higher than expected) {
send-data-SNACK = TRUE;
} else {
discard, return;
}
Adjust TCB.ExpectedDataSN if appropriate.
}
LastRequiredDataSN = CurrentPDU.DataSN - 1;
}
if (send-data-SNACK is TRUE and
task is not already considered failed) {
Recover-Data-if-Possible(LastRequiredDataSN, TCB);
}
if (missing data PDU list is empty) {
TCB.SoFarInOrder = TRUE;
}
if (CurrentPDU.type == R2T) {
Increment ActiveR2Ts for this task.
Create a data-descriptor for the data burst.
Build-And-Send-A-Data-Burst(Connection, data-descriptor, TCB);
}
} else if (CurrentPDU.type == Response) {
if (Data-Digest-Bad) {
send-status-SNACK = TRUE;
} else {
TCB.StatusXferd = TRUE;
Store the status information in TCB.
if (ExpDataSN does not match) {
TCB.SoFarInOrder = FALSE;
Recover-Data-if-Possible(current DataSN, TCB);
}
if (missing data PDU list is empty) {
TCB.SoFarInOrder = TRUE;
}
}
} else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT SHOWN */
}
if ((TCB.SoFarInOrder == TRUE) and
(TCB.StatusXferd == TRUE)) {
SCSI-Task-Completion(TCB);
}
}
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Retrieve TCB for CurrentPDU.InitiatorTaskTag.
if (CurrentPDU.type == Data) {
Retrieve TContext from CurrentPDU.TargetTransferTag;
if (Data-Digest-Bad) {
Build-And-Send-Reject(Connection, CurrentPDU,
Payload-Digest-Error);
Note the missing data PDUs in MissingDataRange[].
send-recovery-R2T = TRUE;
} else {
if (current DataSN is not expected) {
Note the missing data PDUs in MissingDataRange[].
send-recovery-R2T = TRUE;
}
if (CurrentPDU.Fbit == TRUE) {
if (current PDU is solicited) {
Decrement TCB.ActiveR2Ts.
}
if ((current PDU is unsolicited and
data received is less than I/O length and
data received is less than FirstBurstLength)
or (current PDU is solicited and the length of
this burst is less than expected)) {
send-recovery-R2T = TRUE;
Note the missing data in MissingDataRange[].
}
}
}
Increment TContext.ExpectedDataSN.
if (send-recovery-R2T is TRUE and
task is not already considered failed) {
if (operational ErrorRecoveryLevel > 0) {
Increment TCB.ActiveR2Ts.
Create a data-descriptor for the data burst
from MissingDataRange.
Build-And-Send-R2T(Connection, data-descriptor, TCB);
} else {
if (current PDU is the last unsolicited)
TCB.Reason = "Not enough unsolicited data";
else
TCB.Reason = "Protocol Service CRC error";
}
}
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Retrieve TCB for CurrentPDU.InitiatorTaskTag.
if (CurrentPDU.type == Data) {
Retrieve TContext from CurrentPDU.TargetTransferTag;
if (Data-Digest-Bad) {
Build-And-Send-Reject(Connection, CurrentPDU,
Payload-Digest-Error);
Note the missing data PDUs in MissingDataRange[].
send-recovery-R2T = TRUE;
} else {
if (current DataSN is not expected) {
Note the missing data PDUs in MissingDataRange[].
send-recovery-R2T = TRUE;
}
if (CurrentPDU.Fbit == TRUE) {
if (current PDU is solicited) {
Decrement TCB.ActiveR2Ts.
}
if ((current PDU is unsolicited and
data received is less than I/O length and
data received is less than FirstBurstLength)
or (current PDU is solicited and the length of
this burst is less than expected)) {
send-recovery-R2T = TRUE;
Note the missing data in MissingDataRange[].
}
}
}
Increment TContext.ExpectedDataSN.
if (send-recovery-R2T is TRUE and
task is not already considered failed) {
if (operational ErrorRecoveryLevel > 0) {
Increment TCB.ActiveR2Ts.
Create a data-descriptor for the data burst
from MissingDataRange.
Build-And-Send-R2T(Connection, data-descriptor, TCB);
} else {
if (current PDU is the last unsolicited)
TCB.Reason = "Not enough unsolicited data";
else
TCB.Reason = "Protocol Service CRC error";
}
}
if (TCB.ActiveR2Ts == 0) {
Build-And-Send-Status(Connection, TCB);
}
} else if (CurrentPDU.type == SNACK) {
snack-failure = FALSE;
if (operational ErrorRecoveryLevel > 0) {
if (CurrentPDU.type == Data/R2T) {
if (the request is satisfiable) {
if (request for Data) {
Create a data-descriptor for the data burst
from BegRun and RunLength.
Build-And-Send-A-Data-Burst(Connection,
data-descriptor, TCB);
} else { /* R2T */
Create a data-descriptor for the data burst
from BegRun and RunLength.
Build-And-Send-R2T(Connection, data-descriptor,
TCB);
}
} else {
snack-failure = TRUE;
}
} else if (CurrentPDU.type == status) {
Handle-Status-SNACK-request(Connection, CurrentPDU);
} else if (CurrentPDU.type == DataACK) {
Consider all data up to CurrentPDU.BegRun as
acknowledged.
Free up the retransmission resources for that data.
} else if (CurrentPDU.type == R-Data SNACK) {
Create a data descriptor for a data burst
covering all unacknowledged data.
Build-And-Send-A-Data-Burst(Connection,
data-descriptor, TCB);
TCB.SNACK_Tag = CurrentPDU.SNACK_Tag;
if (there's no more data to send) {
Build-And-Send-Status(Connection, TCB);
}
}
} else { /* operational ErrorRecoveryLevel = 0 */
snack-failure = TRUE;
}
if (snack-failure == TRUE) {
Build-And-Send-Reject(Connection, CurrentPDU,
SNACK-Reject);
if (TCB.StatusXferd != TRUE) {
TCB.Reason = "SNACK rejected";
Build-And-Send-Status(Connection, TCB);
}
if (TCB.ActiveR2Ts == 0) {
Build-And-Send-Status(Connection, TCB);
}
} else if (CurrentPDU.type == SNACK) {
snack-failure = FALSE;
if (operational ErrorRecoveryLevel > 0) {
if (CurrentPDU.type == Data/R2T) {
if (the request is satisfiable) {
if (request for Data) {
Create a data-descriptor for the data burst
from BegRun and RunLength.
Build-And-Send-A-Data-Burst(Connection,
data-descriptor, TCB);
} else { /* R2T */
Create a data-descriptor for the data burst
from BegRun and RunLength.
Build-And-Send-R2T(Connection, data-descriptor,
TCB);
}
} else {
snack-failure = TRUE;
}
} else if (CurrentPDU.type == status) {
Handle-Status-SNACK-request(Connection, CurrentPDU);
} else if (CurrentPDU.type == DataACK) {
Consider all data up to CurrentPDU.BegRun as
acknowledged.
Free up the retransmission resources for that data.
} else if (CurrentPDU.type == R-Data SNACK) {
Create a data descriptor for a data burst
covering all unacknowledged data.
Build-And-Send-A-Data-Burst(Connection,
data-descriptor, TCB);
TCB.SNACK_Tag = CurrentPDU.SNACK_Tag;
if (there's no more data to send) {
Build-And-Send-Status(Connection, TCB);
}
}
} else { /* operational ErrorRecoveryLevel = 0 */
snack-failure = TRUE;
}
if (snack-failure == TRUE) {
Build-And-Send-Reject(Connection, CurrentPDU,
SNACK-Reject);
if (TCB.StatusXferd != TRUE) {
TCB.Reason = "SNACK rejected";
Build-And-Send-Status(Connection, TCB);
}
}
}
} else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT SHOWN */
}
}
} else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT SHOWN */
}
}
Transfer-Context-Timeout-Handler(TContext)
{
Retrieve TCB and Connection from TContext.
Decrement TCB.ActiveR2Ts.
if (operational ErrorRecoveryLevel > 0 and
task is not already considered failed) {
Note the missing data PDUs in MissingDataRange[].
Create a data-descriptor for the data burst
from MissingDataRange[].
Build-And-Send-R2T(Connection, data-descriptor, TCB);
Transfer-Context-Timeout-Handler(TContext)
{
Retrieve TCB and Connection from TContext.
Decrement TCB.ActiveR2Ts.
if (operational ErrorRecoveryLevel > 0 and
task is not already considered failed) {
Note the missing data PDUs in MissingDataRange[].
Create a data-descriptor for the data burst
from MissingDataRange[].
Build-And-Send-R2T(Connection, data-descriptor, TCB);
} else {
TCB.Reason = "Protocol Service CRC error";
if (TCB.ActiveR2Ts = 0) {
Build-And-Send-Status(Connection, TCB);
}
}
}
} else {
TCB.Reason = "Protocol Service CRC error";
if (TCB.ActiveR2Ts = 0) {
Build-And-Send-Status(Connection, TCB);
}
}
}
Procedure descriptions:
程序说明：
Recover-Status-if-Possible(transport connection,
currently received PDU);
Evaluate-a-StatSN(transport connection, currently received PDU);
Retransmit-Command-if-Possible(transport connection, CmdSN);
Build-And-Send-SSnack(transport connection);
Build-And-Send-Command(transport connection,
task control block);
Command-Acknowledge-Timeout-Handler(task control block);
Status-Expect-Timeout-Handler(transport connection);
Build-And-Send-NOP-Out(transport connection);
Handle-Status-SNACK-request(transport connection,
Status SNACK PDU);
Retransmit-Status-Burst(Status SNACK, task control block);
Is-Acknowledged(beginning StatSN, run length);
Recover-Status-if-Possible(transport connection,
currently received PDU);
Evaluate-a-StatSN(transport connection, currently received PDU);
Retransmit-Command-if-Possible(transport connection, CmdSN);
Build-And-Send-SSnack(transport connection);
Build-And-Send-Command(transport connection,
task control block);
Command-Acknowledge-Timeout-Handler(task control block);
Status-Expect-Timeout-Handler(transport connection);
Build-And-Send-NOP-Out(transport connection);
Handle-Status-SNACK-request(transport connection,
Status SNACK PDU);
Retransmit-Status-Burst(Status SNACK, task control block);
Is-Acknowledged(beginning StatSN, run length);
Implementation-specific parameters that are tunable:
可调的特定于实现的参数：
InitiatorProactiveSNACKEnabled
已启用启动器权限活动
Notes:
笔记：
- The initiator algorithms only deal with unsolicited NOP-In PDUs for generating Status SNACKs. A solicited NOP-In PDU has an assigned StatSN that, when out of order, could trigger the out-of-order StatSN handling in within-command algorithms, again leading to Recover-Status-if-Possible.
- 发起算法只处理PDU中未经请求的NOP以生成状态零食。PDU中请求的NOP具有分配的StatSN，当出现故障时，该StatSN可能触发命令算法中的故障StatSN处理，如果可能，再次导致恢复状态。
- The pseudocode shown may result in the retransmission of unacknowledged commands in more cases than necessary. This will not, however, affect the correctness of the operation because the target is required to discard the duplicate CmdSNs.
- 所示伪码可能导致在超过必要的情况下重新传输未确认的命令。但是，这不会影响操作的正确性，因为需要目标放弃重复的CMDSN。
- The procedure Build-And-Send-Async is defined in the connection recovery algorithms.
- 在连接恢复算法中定义了Build和Send Async过程。
- The procedure Status-Expect-Timeout-Handler describes how initiators may proactively attempt to retrieve the Status if they so choose. This procedure is assumed to be triggered much before the standard ULP timeout.
- 过程状态预期超时处理程序描述了启动器如何主动尝试检索状态（如果他们选择）。假定此过程在标准ULP超时之前触发。
Recover-Status-if-Possible(Connection, CurrentPDU)
{
if ((Connection.state == LOGGED_IN) and
connection is not already considered failed) {
if (operational ErrorRecoveryLevel > 0) {
if (# of missing PDUs is trackable) {
Note the missing StatSNs in Connection
that were not already requested with SNACK;
Build-And-Send-SSnack(Connection);
} else {
Connection.PerformConnectionCleanup = TRUE;
}
} else {
Connection.PerformConnectionCleanup = TRUE;
}
if (Connection.PerformConnectionCleanup == TRUE) {
Start-Timer(Connection-Cleanup-Handler, Connection, 0);
}
}
Recover-Status-if-Possible(Connection, CurrentPDU)
{
if ((Connection.state == LOGGED_IN) and
connection is not already considered failed) {
if (operational ErrorRecoveryLevel > 0) {
if (# of missing PDUs is trackable) {
Note the missing StatSNs in Connection
that were not already requested with SNACK;
Build-And-Send-SSnack(Connection);
} else {
Connection.PerformConnectionCleanup = TRUE;
}
} else {
Connection.PerformConnectionCleanup = TRUE;
}
if (Connection.PerformConnectionCleanup == TRUE) {
Start-Timer(Connection-Cleanup-Handler, Connection, 0);
}
}
}
}
Retransmit-Command-if-Possible(Connection, CmdSN)
{
if (operational ErrorRecoveryLevel > 0) {
Retrieve the InitiatorTaskTag, and thus TCB for the CmdSN.
Build-And-Send-Command(Connection, TCB);
}
}
Retransmit-Command-if-Possible(Connection, CmdSN)
{
if (operational ErrorRecoveryLevel > 0) {
Retrieve the InitiatorTaskTag, and thus TCB for the CmdSN.
Build-And-Send-Command(Connection, TCB);
}
}
Evaluate-a-StatSN(Connection, CurrentPDU)
{
send-status-SNACK = FALSE;
if (Connection.SoFarInOrder == TRUE) {
if (current StatSN is the expected) {
Increment Connection.ExpectedStatSN.
} else {
Connection.SoFarInOrder = FALSE;
send-status-SNACK = TRUE;
}
} else {
if (current StatSN was considered missing) {
remove current StatSN from the missing list.
} else {
if (current StatSN is higher than expected){
send-status-SNACK = TRUE;
} else {
send-status-SNACK = FALSE;
discard the PDU;
}
}
Adjust Connection.ExpectedStatSN if appropriate.
if (missing StatSN list is empty) {
Connection.SoFarInOrder = TRUE;
}
}
return send-status-SNACK;
}
Evaluate-a-StatSN(Connection, CurrentPDU)
{
send-status-SNACK = FALSE;
if (Connection.SoFarInOrder == TRUE) {
if (current StatSN is the expected) {
Increment Connection.ExpectedStatSN.
} else {
Connection.SoFarInOrder = FALSE;
send-status-SNACK = TRUE;
}
} else {
if (current StatSN was considered missing) {
remove current StatSN from the missing list.
} else {
if (current StatSN is higher than expected){
send-status-SNACK = TRUE;
} else {
send-status-SNACK = FALSE;
discard the PDU;
}
}
Adjust Connection.ExpectedStatSN if appropriate.
if (missing StatSN list is empty) {
Connection.SoFarInOrder = TRUE;
}
}
return send-status-SNACK;
}
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Retrieve TCB for CurrentPDU.InitiatorTaskTag.
if (CurrentPDU.type == NOP-In) {
if (the PDU is unsolicited) {
if (current StatSN is not expected) {
Recover-Status-if-Possible(Connection,
CurrentPDU);
}
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Retrieve TCB for CurrentPDU.InitiatorTaskTag.
if (CurrentPDU.type == NOP-In) {
if (the PDU is unsolicited) {
if (current StatSN is not expected) {
Recover-Status-if-Possible(Connection,
CurrentPDU);
}
if (current ExpCmdSN is not Session.CmdSN) {
Retransmit-Command-if-Possible(Connection,
CurrentPDU.ExpCmdSN);
}
}
} else if (CurrentPDU.type == Reject) {
if (it is a data digest error on immediate data) {
Retransmit-Command-if-Possible(Connection,
CurrentPDU.BadPDUHeader.CmdSN);
}
} else if (CurrentPDU.type == Response) {
send-status-SNACK = Evaluate-a-StatSN(Connection,
CurrentPDU);
if (send-status-SNACK == TRUE)
Recover-Status-if-Possible(Connection, CurrentPDU);
} else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOVERY,
* NOT SHOWN */
}
}
if (current ExpCmdSN is not Session.CmdSN) {
Retransmit-Command-if-Possible(Connection,
CurrentPDU.ExpCmdSN);
}
}
} else if (CurrentPDU.type == Reject) {
if (it is a data digest error on immediate data) {
Retransmit-Command-if-Possible(Connection,
CurrentPDU.BadPDUHeader.CmdSN);
}
} else if (CurrentPDU.type == Response) {
send-status-SNACK = Evaluate-a-StatSN(Connection,
CurrentPDU);
if (send-status-SNACK == TRUE)
Recover-Status-if-Possible(Connection, CurrentPDU);
} else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOVERY,
* NOT SHOWN */
}
}
Command-Acknowledge-Timeout-Handler(TCB)
{
Retrieve the Connection for TCB.
Retransmit-Command-if-Possible(Connection, TCB.CmdSN);
}
Command-Acknowledge-Timeout-Handler(TCB)
{
Retrieve the Connection for TCB.
Retransmit-Command-if-Possible(Connection, TCB.CmdSN);
}
Status-Expect-Timeout-Handler(Connection) {
状态预期超时处理程序（连接）{
if (operational ErrorRecoveryLevel > 0) {
Build-And-Send-NOP-Out(Connection);
} else if (InitiatorProactiveSNACKEnabled){
if ((Connection.state == LOGGED_IN) and
connection is not already considered failed) {
Build-And-Send-SSnack(Connection);
}
}
}
if (operational ErrorRecoveryLevel > 0) {
Build-And-Send-NOP-Out(Connection);
} else if (InitiatorProactiveSNACKEnabled){
if ((Connection.state == LOGGED_IN) and
connection is not already considered failed) {
Build-And-Send-SSnack(Connection);
}
}
}
Handle-Status-SNACK-request(Connection, CurrentPDU)
{
if (operational ErrorRecoveryLevel > 0) {
if (request for an acknowledged run) {
Build-And-Send-Reject(Connection, CurrentPDU,
Protocol-Error);
} else if (request for an untransmitted run) {
discard, return;
} else {
Retransmit-Status-Burst(CurrentPDU, TCB);
}
} else {
Build-And-Send-Async(Connection, DroppedConnection,
DefaultTime2Wait, DefaultTime2Retain);
}
}
Handle-Status-SNACK-request(Connection, CurrentPDU)
{
if (operational ErrorRecoveryLevel > 0) {
if (request for an acknowledged run) {
Build-And-Send-Reject(Connection, CurrentPDU,
Protocol-Error);
} else if (request for an untransmitted run) {
discard, return;
} else {
Retransmit-Status-Burst(CurrentPDU, TCB);
}
} else {
Build-And-Send-Async(Connection, DroppedConnection,
DefaultTime2Wait, DefaultTime2Retain);
}
}
Build-And-Send-Async(transport connection, reason code,
minimum time, maximum time);
Pick-A-Logged-In-Connection(session);
Build-And-Send-Logout(transport connection,
logout connection identifier, reason code);
PerformImplicitLogout(transport connection,
logout connection identifier, target information);
PerformLogin(transport connection, target information);
CreateNewTransportConnection(target information);
Build-And-Send-Command(transport connection, task control block);
Connection-Cleanup-Handler(transport connection);
Connection-Resource-Timeout-Handler(transport connection);
Quiesce-And-Prepare-for-New-Allegiance(session, task control block);
Build-And-Send-Logout-Response(transport connection,
CID of connection in recovery, reason code);
Build-And-Send-TaskMgmt-Response(transport connection,
task mgmt command PDU, response code);
Establish-New-Allegiance(task control block, transport connection);
Schedule-Command-To-Continue(task control block);
Build-And-Send-Async(transport connection, reason code,
minimum time, maximum time);
Pick-A-Logged-In-Connection(session);
Build-And-Send-Logout(transport connection,
logout connection identifier, reason code);
PerformImplicitLogout(transport connection,
logout connection identifier, target information);
PerformLogin(transport connection, target information);
CreateNewTransportConnection(target information);
Build-And-Send-Command(transport connection, task control block);
Connection-Cleanup-Handler(transport connection);
Connection-Resource-Timeout-Handler(transport connection);
Quiesce-And-Prepare-for-New-Allegiance(session, task control block);
Build-And-Send-Logout-Response(transport connection,
CID of connection in recovery, reason code);
Build-And-Send-TaskMgmt-Response(transport connection,
task mgmt command PDU, response code);
Establish-New-Allegiance(task control block, transport connection);
Schedule-Command-To-Continue(task control block);
Note:
注:
- Transport exception conditions such as unexpected connection termination, connection reset, and hung connection while the connection is in the Full Feature Phase are all assumed to be asynchronously signaled to the iSCSI layer using the Transport_Exception_Handler procedure.
- 在连接处于完整功能阶段时，传输异常情况（如意外连接终止、连接重置和挂起连接）都假定使用传输异常处理程序以异步方式通知iSCSI层。
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Retrieve TCB from CurrentPDU.InitiatorTaskTag.
if (CurrentPDU.type == Async) {
if (CurrentPDU.AsyncEvent == ConnectionDropped) {
Retrieve the AffectedConnection for
CurrentPDU.Parameter1.
AffectedConnection.CurrentTimeout =
CurrentPDU.Parameter3;
AffectedConnection.State = CLEANUP_WAIT;
Start-Timer(Connection-Cleanup-Handler,
AffectedConnection, CurrentPDU.Parameter2);
} else if (CurrentPDU.AsyncEvent == LogoutRequest)) {
AffectedConnection = Connection;
AffectedConnection.State = LOGOUT_REQUESTED;
AffectedConnection.PerformConnectionCleanup = TRUE;
AffectedConnection.CurrentTimeout =
CurrentPDU.Parameter3;
Start-Timer(Connection-Cleanup-Handler,
AffectedConnection, 0);
} else if (CurrentPDU.AsyncEvent == SessionDropped)) {
for (each Connection) {
Connection.State = CLEANUP_WAIT;
Connection.CurrentTimeout = CurrentPDU.Parameter3;
Start-Timer(Connection-Cleanup-Handler,
Connection, CurrentPDU.Parameter2);
}
Session.state = FAILED;
}
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Retrieve TCB from CurrentPDU.InitiatorTaskTag.
if (CurrentPDU.type == Async) {
if (CurrentPDU.AsyncEvent == ConnectionDropped) {
Retrieve the AffectedConnection for
CurrentPDU.Parameter1.
AffectedConnection.CurrentTimeout =
CurrentPDU.Parameter3;
AffectedConnection.State = CLEANUP_WAIT;
Start-Timer(Connection-Cleanup-Handler,
AffectedConnection, CurrentPDU.Parameter2);
} else if (CurrentPDU.AsyncEvent == LogoutRequest)) {
AffectedConnection = Connection;
AffectedConnection.State = LOGOUT_REQUESTED;
AffectedConnection.PerformConnectionCleanup = TRUE;
AffectedConnection.CurrentTimeout =
CurrentPDU.Parameter3;
Start-Timer(Connection-Cleanup-Handler,
AffectedConnection, 0);
} else if (CurrentPDU.AsyncEvent == SessionDropped)) {
for (each Connection) {
Connection.State = CLEANUP_WAIT;
Connection.CurrentTimeout = CurrentPDU.Parameter3;
Start-Timer(Connection-Cleanup-Handler,
Connection, CurrentPDU.Parameter2);
}
Session.state = FAILED;
}
} else if (CurrentPDU.type == LogoutResponse) {
Retrieve the CleanupConnection for CurrentPDU.CID.
if (CurrentPDU.Response = failure) {
CleanupConnection.State = CLEANUP_WAIT;
} else if (CurrentPDU.type == LogoutResponse) {
Retrieve the CleanupConnection for CurrentPDU.CID.
if (CurrentPDU.Response = failure) {
CleanupConnection.State = CLEANUP_WAIT;
} else {
CleanupConnection.State = FREE;
}
} else if (CurrentPDU.type == LoginResponse) {
if (this is a response to an implicit Logout) {
Retrieve the CleanupConnection.
if (successful) {
CleanupConnection.State = FREE;
Connection.State = LOGGED_IN;
} else {
CleanupConnection.State = CLEANUP_WAIT;
DestroyTransportConnection(Connection);
}
}
} else { /* REST UNRELATED TO CONNECTION-RECOVERY,
* NOT SHOWN */
}
if (CleanupConnection.State == FREE) {
for (each command that was active on CleanupConnection) {
/* Establish new connection allegiance */
NewConnection = Pick-A-Logged-In-Connection(Session);
Build-And-Send-Command(NewConnection, TCB);
}
}
}
} else {
CleanupConnection.State = FREE;
}
} else if (CurrentPDU.type == LoginResponse) {
if (this is a response to an implicit Logout) {
Retrieve the CleanupConnection.
if (successful) {
CleanupConnection.State = FREE;
Connection.State = LOGGED_IN;
} else {
CleanupConnection.State = CLEANUP_WAIT;
DestroyTransportConnection(Connection);
}
}
} else { /* REST UNRELATED TO CONNECTION-RECOVERY,
* NOT SHOWN */
}
if (CleanupConnection.State == FREE) {
for (each command that was active on CleanupConnection) {
/* Establish new connection allegiance */
NewConnection = Pick-A-Logged-In-Connection(Session);
Build-And-Send-Command(NewConnection, TCB);
}
}
}
Connection-Cleanup-Handler(Connection)
{
Retrieve Session from Connection.
if (Connection can still exchange iSCSI PDUs) {
NewConnection = Connection;
} else {
Start-Timer(Connection-Resource-Timeout-Handler,
Connection, Connection.CurrentTimeout);
if (there are other logged-in connections) {
NewConnection = Pick-A-Logged-In-Connection(Session);
} else {
NewConnection =
CreateTransportConnection(Session.OtherEndInfo);
Initiate an implicit Logout on NewConnection for
Connection.CID.
return;
}
}
Build-And-Send-Logout(NewConnection, Connection.CID,
RecoveryRemove);
}
Connection-Cleanup-Handler(Connection)
{
Retrieve Session from Connection.
if (Connection can still exchange iSCSI PDUs) {
NewConnection = Connection;
} else {
Start-Timer(Connection-Resource-Timeout-Handler,
Connection, Connection.CurrentTimeout);
if (there are other logged-in connections) {
NewConnection = Pick-A-Logged-In-Connection(Session);
} else {
NewConnection =
CreateTransportConnection(Session.OtherEndInfo);
Initiate an implicit Logout on NewConnection for
Connection.CID.
return;
}
}
Build-And-Send-Logout(NewConnection, Connection.CID,
RecoveryRemove);
}
Transport_Exception_Handler(Connection)
{
Connection.PerformConnectionCleanup = TRUE;
if (the event is an unexpected transport disconnect) {
Connection.State = CLEANUP_WAIT;
Connection.CurrentTimeout = DefaultTime2Retain;
Start-Timer(Connection-Cleanup-Handler, Connection,
DefaultTime2Wait);
} else {
Connection.State = FREE;
}
}
Transport_Exception_Handler(Connection)
{
Connection.PerformConnectionCleanup = TRUE;
if (the event is an unexpected transport disconnect) {
Connection.State = CLEANUP_WAIT;
Connection.CurrentTimeout = DefaultTime2Retain;
Start-Timer(Connection-Cleanup-Handler, Connection,
DefaultTime2Wait);
} else {
Connection.State = FREE;
}
}
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
else if (Data-Digest-Bad) {
Build-And-Send-Reject(Connection, CurrentPDU,
Payload-Digest-Error);
discard, return;
}
Retrieve TCB and Session.
if (CurrentPDU.type == Logout) {
if (CurrentPDU.ReasonCode = RecoveryRemove) {
Retrieve the CleanupConnection from CurrentPDU.CID).
for (each command active on CleanupConnection) {
Quiesce-And-Prepare-for-New-Allegiance(Session,
TCB);
TCB.CurrentlyAllegiant = FALSE;
}
Cleanup-Connection-State(CleanupConnection);
if ((quiescing successful) and (cleanup successful))
{
Build-And-Send-Logout-Response(Connection,
CleanupConnection.CID, Success);
} else {
Build-And-Send-Logout-Response(Connection,
CleanupConnection.CID, Failure);
}
Receive-an-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
else if (Data-Digest-Bad) {
Build-And-Send-Reject(Connection, CurrentPDU,
Payload-Digest-Error);
discard, return;
}
Retrieve TCB and Session.
if (CurrentPDU.type == Logout) {
if (CurrentPDU.ReasonCode = RecoveryRemove) {
Retrieve the CleanupConnection from CurrentPDU.CID).
for (each command active on CleanupConnection) {
Quiesce-And-Prepare-for-New-Allegiance(Session,
TCB);
TCB.CurrentlyAllegiant = FALSE;
}
Cleanup-Connection-State(CleanupConnection);
if ((quiescing successful) and (cleanup successful))
{
Build-And-Send-Logout-Response(Connection,
CleanupConnection.CID, Success);
} else {
Build-And-Send-Logout-Response(Connection,
CleanupConnection.CID, Failure);
}
}
}
} else if ((CurrentPDU.type == Login) and
operational ErrorRecoveryLevel == 2) {
Retrieve the CleanupConnection from CurrentPDU.CID).
for (each command active on CleanupConnection) {
Quiesce-And-Prepare-for-New-Allegiance(Session,
TCB);
TCB.CurrentlyAllegiant = FALSE;
}
Cleanup-Connection-State(CleanupConnection);
if ((quiescing successful) and (cleanup successful))
{
Continue with the rest of the login processing;
} else {
Build-And-Send-Login-Response(Connection,
CleanupConnection.CID, Target Error);
}
}
} else if (CurrentPDU.type == TaskManagement) {
if (CurrentPDU.function == "TaskReassign") {
if (Session.ErrorRecoveryLevel < 2) {
Build-And-Send-TaskMgmt-Response(Connection,
CurrentPDU,
"Task allegiance reassignment not
supported");
} else if (task is not found) {
Build-And-Send-TaskMgmt-Response(Connection,
CurrentPDU, "Task not in task set");
} else if (task is currently allegiant) {
Build-And-Send-TaskMgmt-Response(Connection,
CurrentPDU, "Task still allegiant");
} else {
Establish-New-Allegiance(TCB, Connection);
TCB.CurrentlyAllegiant = TRUE;
Schedule-Command-To-Continue(TCB);
}
}
} else { /* REST UNRELATED TO CONNECTION-RECOVERY,
* NOT SHOWN */
}
} else if ((CurrentPDU.type == Login) and
operational ErrorRecoveryLevel == 2) {
Retrieve the CleanupConnection from CurrentPDU.CID).
for (each command active on CleanupConnection) {
Quiesce-And-Prepare-for-New-Allegiance(Session,
TCB);
TCB.CurrentlyAllegiant = FALSE;
}
Cleanup-Connection-State(CleanupConnection);
if ((quiescing successful) and (cleanup successful))
{
Continue with the rest of the login processing;
} else {
Build-And-Send-Login-Response(Connection,
CleanupConnection.CID, Target Error);
}
}
} else if (CurrentPDU.type == TaskManagement) {
if (CurrentPDU.function == "TaskReassign") {
if (Session.ErrorRecoveryLevel < 2) {
Build-And-Send-TaskMgmt-Response(Connection,
CurrentPDU,
"Task allegiance reassignment not
supported");
} else if (task is not found) {
Build-And-Send-TaskMgmt-Response(Connection,
CurrentPDU, "Task not in task set");
} else if (task is currently allegiant) {
Build-And-Send-TaskMgmt-Response(Connection,
CurrentPDU, "Task still allegiant");
} else {
Establish-New-Allegiance(TCB, Connection);
TCB.CurrentlyAllegiant = TRUE;
Schedule-Command-To-Continue(TCB);
}
}
} else { /* REST UNRELATED TO CONNECTION-RECOVERY,
* NOT SHOWN */
}
}
}
Transport_Exception_Handler(Connection)
{
Connection.PerformConnectionCleanup = TRUE;
if (the event is an unexpected transport disconnect) {
Connection.State = CLEANUP_WAIT;
Start-Timer(Connection-Resource-Timeout-Handler,
Connection, (DefaultTime2Wait+DefaultTime2Retain));
if (this Session has Full Feature Phase connections
left) {
DifferentConnection =
Pick-A-Logged-In-Connection(Session);
Build-And-Send-Async(DifferentConnection,
DroppedConnection, DefaultTime2Wait,
DefaultTime2Retain);
}
} else {
Connection.State = FREE;
}
}
Transport_Exception_Handler(Connection)
{
Connection.PerformConnectionCleanup = TRUE;
if (the event is an unexpected transport disconnect) {
Connection.State = CLEANUP_WAIT;
Start-Timer(Connection-Resource-Timeout-Handler,
Connection, (DefaultTime2Wait+DefaultTime2Retain));
if (this Session has Full Feature Phase connections
left) {
DifferentConnection =
Pick-A-Logged-In-Connection(Session);
Build-And-Send-Async(DifferentConnection,
DroppedConnection, DefaultTime2Wait,
DefaultTime2Retain);
}
} else {
Connection.State = FREE;
}
}
The following tables describe the target behavior on receiving the events specified in the rows of the table. The second table is an extension of the first table and defines clearing actions for more objects on the same events. The legend is:
下表描述了接收表行中指定的事件时的目标行为。第二个表是第一个表的扩展，定义了对同一事件的更多对象的清除操作。传说是：
Y = Yes (cleared/discarded/reset on the event specified in the row). Unless otherwise noted, the clearing action is only applicable for the issuing initiator port.
Y=是（在行中指定的事件上清除/丢弃/重置）。除非另有说明，否则清除操作仅适用于发出启动器端口。
N = No (not affected on the event specified in the row, i.e., stays at previous value).
N=否（不受行中指定事件的影响，即保持在以前的值）。
NA = Not Applicable or Not Defined.
NA=不适用或未定义。
+------+------+------+------+------+
|IT (1)|IC (2)|CT (5)|ST (6)|PP (7)|
+----------------------+------+------+------+------+------+
|connection failure (8)|Y |Y |N |N |Y |
+----------------------+------+------+------+------+------+
|connection state |NA |NA |Y |N |NA |
|timeout (9) | | | | | |
+----------------------+------+------+------+------+------+
|session timeout/ |Y |Y |Y |Y |Y (14)|
|closure/reinstatement | | | | | |
|(10) | | | | | |
+----------------------+------+------+------+------+------+
|session continuation |NA |NA |N (11)|N |NA |
|(12) | | | | | |
+----------------------+------+------+------+------+------+
|successful connection |Y |Y |Y |N |Y (13)|
|close logout | | | | | |
+----------------------+------+------+------+------+------+
|session failure (18) |Y |Y |N |N |Y |
+----------------------+------+------+------+------+------+
|successful recovery |Y |Y |N |N |Y (13)|
|Logout | | | | | |
+----------------------+------+------+------+------+------+
|failed Logout |Y |Y |N |N |Y |
+----------------------+------+------+------+------+------+
|connection Login |NA |NA |NA |Y (15)|NA |
|(leading) | | | | | |
+----------------------+------+------+------+------+------+
|connection Login |NA |NA |N (11)|N |Y |
|(non-leading) | | | | | |
+----------------------+------+------+------+------+------+
|TARGET COLD RESET (16)|Y (20)|Y |Y |Y |Y |
+----------------------+------+------+------+------+------+
|TARGET WARM RESET (16)|Y (20)|Y |Y |Y |Y |
+----------------------+------+------+------+------+------+
|LU reset (19) |Y (20)|Y |Y |Y |Y |
+----------------------+------+------+------+------+------+
|power cycle (16) |Y |Y |Y |Y |Y |
+----------------------+------+------+------+------+------+
+------+------+------+------+------+
|IT (1)|IC (2)|CT (5)|ST (6)|PP (7)|
+----------------------+------+------+------+------+------+
|connection failure (8)|Y |Y |N |N |Y |
+----------------------+------+------+------+------+------+
|connection state |NA |NA |Y |N |NA |
|timeout (9) | | | | | |
+----------------------+------+------+------+------+------+
|session timeout/ |Y |Y |Y |Y |Y (14)|
|closure/reinstatement | | | | | |
|(10) | | | | | |
+----------------------+------+------+------+------+------+
|session continuation |NA |NA |N (11)|N |NA |
|(12) | | | | | |
+----------------------+------+------+------+------+------+
|successful connection |Y |Y |Y |N |Y (13)|
|close logout | | | | | |
+----------------------+------+------+------+------+------+
|session failure (18) |Y |Y |N |N |Y |
+----------------------+------+------+------+------+------+
|successful recovery |Y |Y |N |N |Y (13)|
|Logout | | | | | |
+----------------------+------+------+------+------+------+
|failed Logout |Y |Y |N |N |Y |
+----------------------+------+------+------+------+------+
|connection Login |NA |NA |NA |Y (15)|NA |
|(leading) | | | | | |
+----------------------+------+------+------+------+------+
|connection Login |NA |NA |N (11)|N |Y |
|(non-leading) | | | | | |
+----------------------+------+------+------+------+------+
|TARGET COLD RESET (16)|Y (20)|Y |Y |Y |Y |
+----------------------+------+------+------+------+------+
|TARGET WARM RESET (16)|Y (20)|Y |Y |Y |Y |
+----------------------+------+------+------+------+------+
|LU reset (19) |Y (20)|Y |Y |Y |Y |
+----------------------+------+------+------+------+------+
|power cycle (16) |Y |Y |Y |Y |Y |
+----------------------+------+------+------+------+------+
(1) Incomplete TTTs (IT) are Target Transfer Tags on which the target is still expecting PDUs to be received. Examples include TTTs received via R2T, NOP-In, etc.
(1) 不完整的TTT（IT）是目标传输标签，目标仍希望在其上接收PDU。示例包括通过R2T、NOP In等接收的TTT。
(2) Immediate Commands (IC) are immediate commands, but waiting for execution on a target (for example, ABORT TASK SET).
(2) 即时命令（IC）是即时命令，但等待在目标上执行（例如，中止任务集）。
(5) Connection Tasks (CT) are tasks that are active on the iSCSI connection in question.
(5) 连接任务（CT）是在相关iSCSI连接上处于活动状态的任务。
(6) Session Tasks (ST) are tasks that are active on the entire iSCSI session. A union of "connection tasks" on all participating connections.
(6) 会话任务（ST）是在整个iSCSI会话中处于活动状态的任务。所有参与连接上的“连接任务”的联合。
(7) Partial PDUs (PP) (if any) are PDUs that are partially sent and waiting for transport window credit to complete the transmission.
(7) 部分PDU（PP）（如果有）是部分发送并等待传输窗口信用完成传输的PDU。
(8) Connection failure is a connection exception condition - one of the transport connections shut down, transport connections reset, or transport connections timed out, which abruptly terminated the iSCSI Full Feature Phase connection. A connection failure always takes the connection state machine to the CLEANUP_WAIT state.
(8) 连接失败是一种连接异常情况—其中一个传输连接关闭、传输连接重置或传输连接超时，从而突然终止iSCSI全功能阶段连接。连接失败总是使连接状态机处于清除等待状态。
(9) Connection state timeout happens if a connection spends more time than agreed upon during login negotiation in the CLEANUP_WAIT state, and this takes the connection to the FREE state (M1 transition in connection cleanup state diagram; see Section 8.2).
(9) 如果连接在清除等待状态下的登录协商过程中花费的时间超过约定的时间，则会发生连接状态超时，这会使连接进入空闲状态（连接清除状态图中的M1转换；请参阅第8.2节）。
(10) Session timeout, closure, and reinstatement are defined in Section 6.3.5.
（10） 会话超时、关闭和恢复的定义见第6.3.5节。
(11) This clearing effect is "Y" only if it is a connection reinstatement and the operational ErrorRecoveryLevel is less than 2.
（11） 仅当连接恢复且操作ErrorRecoveryLevel小于2时，此清除效果为“Y”。
(12) Session continuation is defined in Section 6.3.6.
（12） 第6.3.6节对会话继续进行了定义。
(13) This clearing effect is only valid if the connection is being logged out on a different connection and when the connection being logged out on the target may have some partial PDUs pending to be sent. In all other cases, the effect is "NA".
（13） 只有当连接在另一个连接上注销，并且目标上注销的连接可能有一些部分PDU等待发送时，此清除效果才有效。在所有其他情况下，效果为“NA”。
(14) This clearing effect is only valid for a "close the session" logout in a multi-connection session. In all other cases, the effect is "NA".
（14） 此清除效果仅对多连接会话中的“关闭会话”注销有效。在所有其他情况下，效果为“NA”。
(15) Only applicable if this leading connection login is a session reinstatement. If this is not the case, it is "NA".
（15） 仅当此前导连接登录是会话恢复时适用。如果不是这样，则为“NA”。
(16) This operation affects all logged-in initiators.
（16） 此操作影响所有已登录的启动器。
(18) Session failure is defined in Section 6.3.6.
（18） 会话失败在第6.3.6节中定义。
(19) This operation affects all logged-in initiators, and the clearing effects are only applicable to the LU being reset.
（19） 此操作影响所有已登录的启动器，清除效果仅适用于正在重置的LU。
(20) With standard multi-task abort semantics (Section 4.2.3.3), a TARGET WARM RESET or a TARGET COLD RESET or a LU reset would clear the active TTTs upon completion. However, the FastAbort multi-task abort semantics defined by Section 4.2.3.4 do not guarantee that the active TTTs are cleared by the end of the reset operations. In fact, the FastAbort semantics are designed to allow clearing the TTTs in a "lazy" fashion after the TMF Response is delivered. Thus, when TaskReporting=FastAbort (Section 13.23) is operational on a session, the clearing effects of reset operations on "Incomplete TTTs" is "N".
（20） 使用标准多任务中止语义（第4.2.3.3节），目标温复位、目标冷复位或LU复位将在完成时清除活动TTT。但是，第4.2.3.4节定义的FastAbort多任务中止语义不能保证在重置操作结束时清除活动TTT。事实上，FastAbort语义旨在允许在TMF响应传递后以“惰性”方式清除TTT。因此，当TaskReporting=FastAbort（第13.23节）在会话上运行时，重置操作对“不完整TTT”的清除效果为“N”。
+------+-------+------+------+-------+
|DC (1)|DD (2) |SS (3)|CS (4)|DS (5) |
+---------------------+------+-------+------+------+-------+
|connection failure |N |Y |N |N |N |
+---------------------+------+-------+------+------+-------+
|connection state |Y |NA |Y |N |NA |
|timeout | | | | | |
+---------------------+------+-------+------+------+-------+
|session timeout/ |Y |Y |Y (7) |Y |NA |
|closure/reinstatement| | | | | |
+---------------------+------+-------+------+------+-------+
|session continuation |N (11)|NA (12)|NA |N |NA (13)|
+---------------------+------+-------+------+------+-------+
|successful connection|Y |Y |Y |N |NA |
|close Logout | | | | | |
+---------------------+------+-------+------+------+-------+
|session failure |N |Y |N |N |N |
+---------------------+------+-------+------+------+-------+
|successful recovery |Y |Y |Y |N |N |
|Logout | | | | | |
+---------------------+------+-------+------+------+-------+
|failed Logout |N |Y (9) |N |N |N |
+---------------------+------+-------+------+------+-------+
|connection Login |NA |NA |N (8) |N (8) |NA |
|(leading | | | | | |
+---------------------+------+-------+------+------+-------+
|connection Login |N (11)|NA (12)|N (8) |N |NA (13)|
|(non-leading) | | | | | |
+---------------------+------+-------+------+------+-------+
|TARGET COLD RESET |Y |Y |Y |Y (10)|NA |
+---------------------+------+-------+------+------+-------+
|TARGET WARM RESET |Y |Y |N |N |NA |
+---------------------+------+-------+------+------+-------+
|LU reset |N |Y |N |N |N |
+---------------------+------+-------+------+------+-------+
|power cycle |Y |Y |Y |Y (10)|NA |
+---------------------+------+-------+------+------+-------+
+------+-------+------+------+-------+
|DC (1)|DD (2) |SS (3)|CS (4)|DS (5) |
+---------------------+------+-------+------+------+-------+
|connection failure |N |Y |N |N |N |
+---------------------+------+-------+------+------+-------+
|connection state |Y |NA |Y |N |NA |
|timeout | | | | | |
+---------------------+------+-------+------+------+-------+
|session timeout/ |Y |Y |Y (7) |Y |NA |
|closure/reinstatement| | | | | |
+---------------------+------+-------+------+------+-------+
|session continuation |N (11)|NA (12)|NA |N |NA (13)|
+---------------------+------+-------+------+------+-------+
|successful connection|Y |Y |Y |N |NA |
|close Logout | | | | | |
+---------------------+------+-------+------+------+-------+
|session failure |N |Y |N |N |N |
+---------------------+------+-------+------+------+-------+
|successful recovery |Y |Y |Y |N |N |
|Logout | | | | | |
+---------------------+------+-------+------+------+-------+
|failed Logout |N |Y (9) |N |N |N |
+---------------------+------+-------+------+------+-------+
|connection Login |NA |NA |N (8) |N (8) |NA |
|(leading | | | | | |
+---------------------+------+-------+------+------+-------+
|connection Login |N (11)|NA (12)|N (8) |N |NA (13)|
|(non-leading) | | | | | |
+---------------------+------+-------+------+------+-------+
|TARGET COLD RESET |Y |Y |Y |Y (10)|NA |
+---------------------+------+-------+------+------+-------+
|TARGET WARM RESET |Y |Y |N |N |NA |
+---------------------+------+-------+------+------+-------+
|LU reset |N |Y |N |N |N |
+---------------------+------+-------+------+------+-------+
|power cycle |Y |Y |Y |Y (10)|NA |
+---------------------+------+-------+------+------+-------+
(1) Discontiguous Commands (DC) are commands allegiant to the connection in question and waiting to be reordered in the iSCSI layer. All "Y"s in this column assume that the task causing the event (if indeed the event is the result of a task) is issued as an immediate command, because the discontiguities can be ahead of the task.
(1) 不连续命令（DC）是指向相关连接的allegiant命令，正在iSCSI层中等待重新排序。此列中的所有“Y”都假定导致事件的任务（如果事件确实是任务的结果）是作为立即命令发出的，因为不连续性可能在任务之前。
(2) Discontiguous Data (DD) are data PDUs received for the task in question and waiting to be reordered due to prior discontiguities in the DataSN.
(2) 不连续数据（DD）是为相关任务接收的数据PDU，由于数据N中先前的不连续性而等待重新排序。
(3) "SS" refers to the StatSN.
(3) “SS”是指StatSN。
(4) "CS" refers to the CmdSN.
(4) “CS”指CmdSN。
(5) "DS" refers to the DataSN.
(5) “DS”指数据编号。
(7) This action clears the StatSN on all the connections.
(7) 此操作清除所有连接上的StatSN。
(8) This sequence number is instantiated on this event.
(8) 此序列号在此事件上实例化。
(9) A logout failure drives the connection state machine to the CLEANUP_WAIT state, similar to the connection failure event. Hence, it has a similar effect on this and several other protocol aspects.
(9) 注销失败会将连接状态机驱动到清除等待状态，类似于连接失败事件。因此，它在这方面和其他几个协议方面具有类似的效果。
(10) This is cleared by virtue of the fact that all sessions with all initiators are terminated.
（10） 这是由于与所有启动器的所有会话都已终止。
(11) This clearing effect is "Y" if it is a connection reinstatement.
（11） 如果是连接恢复，则此清除效果为“Y”。
(12) This clearing effect is "Y" only if it is a connection reinstatement and the operational ErrorRecoveryLevel is 2.
（12） 仅当连接恢复且操作ErrorRecoveryLevel为2时，此清除效果为“Y”。
(13) This clearing effect is "N" only if it is a connection reinstatement and the operational ErrorRecoveryLevel is 2.
（13） 仅当连接恢复且操作错误RecoveryLevel为2时，此清除效果为“N”。
The only iSCSI protocol action that can effect clearing actions on SCSI objects is the "I_T nexus loss" notification (Section 6.3.5.1 ("Loss of Nexus Notification")). [SPC3] describes the clearing effects of this notification on a variety of SCSI attributes. In addition, SCSI standards documents (such as [SAM2] and [SBC2]) define additional clearing actions that may take place for several SCSI objects on SCSI events such as LU resets and power-on resets.
唯一可以对SCSI对象执行清除操作的iSCSI协议操作是“I_T nexus丢失”通知（第6.3.5.1节（“nexus丢失通知”））。[SPC3]描述了此通知对各种SCSI属性的清除效果。此外，SCSI标准文档（如[SAM2]和[SBC2]）定义了在SCSI事件（如LU重置和通电重置）上可能对多个SCSI对象执行的其他清除操作。
Since iSCSI defines a TARGET COLD RESET as a "protocol-equivalent" to a target power-cycle, the iSCSI TARGET COLD RESET must also be considered as the power-on reset event in interpreting the actions defined in the SCSI standards.
由于iSCSI将目标冷重设定义为与目标电源循环“等效的协议”，因此在解释SCSI标准中定义的操作时，iSCSI目标冷重设还必须视为上电重设事件。
When the iSCSI session is reconstructed (between the same SCSI ports with the same nexus identifier) reestablishing the same I_T nexus, all SCSI objects that are defined to not clear on the "I_T nexus loss" notification event, such as persistent reservations, are automatically associated to this new session.
当重建iSCSI会话（在具有相同nexus标识符的相同SCSI端口之间）以重新建立相同的I_T nexus时，在“I_T nexus丢失”通知事件中定义为未清除的所有SCSI对象（如永久保留）将自动关联到此新会话。
Acknowledgments
致谢
Several individuals on the original IPS Working Group made significant contributions to the original RFCs 3720, 3980, 4850, and 5048.
最初的IPS工作组中的几个人对最初的RFC 3720、3980、4850和5048做出了重大贡献。
Specifically, the authors of the original RFCs -- which herein are consolidated into a single document -- were the following:
具体而言，原始RFC的作者（此处合并为一份文件）如下：
RFC 3720: Julian Satran, Kalman Meth, Costa Sapuntzakis, Mallikarjun Chadalapaka, Efri Zeidner
RFC 3720:Julian Satran、Kalman Meth、Costa Sapuntzakis、Mallikarjun Chadalapaka、Efra Zeidner
RFC 3980: Marjorie Krueger, Mallikarjun Chadalapaka, Rob Elliott
RFC 3980:Marjorie Krueger、Mallikarjun Chadalapaka、Rob Elliott
RFC 4850: David Wysochanski
RFC 4850:David Wysochanski
RFC 5048: Mallikarjun Chadalapaka
RFC 5048:Mallikarjun Chadalapaka
Many thanks to Fred Knight for contributing to the UML notations and drawings in this document.
非常感谢Fred Knight为本文档中的UML符号和图纸做出贡献。
We would in addition like to acknowledge the following individuals who contributed to this revised document: David Harrington, Paul Koning, Mark Edwards, Rob Elliott, and Martin Stiemerling.
此外，我们还要感谢以下为本修订文件做出贡献的个人：大卫·哈林顿、保罗·科宁、马克·爱德华兹、罗伯·艾略特和马丁·斯蒂梅林。
Thanks to Yi Zeng and Nico Williams for suggesting and/or reviewing Kerberos-related security considerations text.
感谢Yi Zeng和Nico Williams建议和/或审阅Kerberos相关安全注意事项文本。
The authors gratefully acknowledge the valuable feedback during the Last Call review process from a number of individuals; their feedback significantly improved this document. The individuals were Stephen Farrell, Brian Haberman, Barry Leiba, Pete Resnick, Sean Turner, Alexey Melnikov, Kathleen Moriarty, Fred Knight, Mike Christie, Qiang Wang, Shiv Rajpal, and Andy Banta.
作者衷心感谢许多人在最后一次电话审查过程中提供的宝贵反馈；他们的反馈大大改进了这份文件。这些人是斯蒂芬·法雷尔、布赖恩·哈伯曼、巴里·莱巴、皮特·雷斯尼克、肖恩·特纳、阿列克西·梅尔尼科夫、凯瑟琳·莫里亚蒂、弗雷德·奈特、迈克·克里斯蒂、王强、希夫·拉帕尔和安迪·班塔。
Finally, this document also benefited from significant review contributions from the Storm Working Group at large.
最后，本文件还得益于风暴工作组的重大审查贡献。
Comments may be sent to Mallikarjun Chadalapaka.
意见可发送至Mallikarjun Chadalapaka。
Authors' Addresses
作者地址
Mallikarjun Chadalapaka Microsoft One Microsoft Way Redmond, WA 98052 USA
Mallikarjun Chadalapaka Microsoft One Microsoft Way Redmond，WA 98052美国
EMail: cbm@chadalapaka.com
EMail: cbm@chadalapaka.com
Julian Satran Infinidat Ltd.
朱利安·萨特兰·英菲尼达有限公司。
EMail: julians@infinidat.com, julian@satran.net
EMail: julians@infinidat.com, julian@satran.net
Kalman Meth IBM Haifa Research Lab Haifa University Campus - Mount Carmel Haifa 31905, Israel
Kalman Meth IBM海法研究实验室海法大学校园-以色列海法卡梅尔山31905
Phone +972.4.829.6341 EMail: meth@il.ibm.com
电话+972.4.829.6341电子邮件：meth@il.ibm.com
David L. Black EMC Corporation 176 South St. Hopkinton, MA 01748 USA
David L.Black EMC公司美国马萨诸塞州霍普金顿南大街176号01748
Phone +1 (508) 293-7953 EMail: david.black@emc.com
电话+1（508）293-7953电子邮件：大卫。black@emc.com