Network Working Group J. Satran
Request for Comments: 3720 K. Meth
Category: Standards Track IBM
C. Sapuntzakis
Cisco Systems
M. Chadalapaka
Hewlett-Packard Co.
E. Zeidner
IBM
April 2004
Network Working Group J. Satran
Request for Comments: 3720 K. Meth
Category: Standards Track IBM
C. Sapuntzakis
Cisco Systems
M. Chadalapaka
Hewlett-Packard Co.
E. Zeidner
IBM
April 2004
Internet Small Computer Systems Interface (iSCSI)
Internet小型计算机系统接口（iSCSI）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model.
本文档描述了在TCP之上工作的Internet小型计算机系统接口（iSCSI）的传输协议。iSCSI协议旨在完全符合标准化SCSI体系结构模型。
SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.).
SCSI是一个流行的协议系列，它使系统能够与I/O设备（尤其是存储设备）通信。SCSI协议是请求/响应应用程序协议，具有通用的标准化体系结构模型和基本命令集，以及针对不同设备类别（磁盘、磁带、媒体转换器等）的标准化命令集。
As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI.
随着系统互连从传统的总线结构转移到网络结构，SCSI必须映射到网络传输协议。IP网络现在满足快速系统互连的性能要求，因此是“携带”SCSI的良好候选。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Definitions and Acronyms. . . . . . . . . . . . . . . . . . . 10
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . 10
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Conventions. . . . . . . . . . . . . . . . . . . . . . 16
2.3.1. Word Rule. . . . . . . . . . . . . . . . . . 16
2.3.2. Half-Word Rule . . . . . . . . . . . . . . . 17
2.3.3. Byte Rule. . . . . . . . . . . . . . . . . . 17
3. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. SCSI Concepts. . . . . . . . . . . . . . . . . . . . . 17
3.2. iSCSI Concepts and Functional Overview . . . . . . . . 18
3.2.1. Layers and Sessions. . . . . . . . . . . . . 19
3.2.2. Ordering and iSCSI Numbering . . . . . . . . 19
3.2.2.1. Command Numbering and
Acknowledging . . . . . . . . . . 20
3.2.2.2. Response/Status Numbering and
Acknowledging . . . . . . . . . . 23
3.2.2.3. Data Sequencing . . . . . . . . 24
3.2.3. iSCSI Login. . . . . . . . . . . . . . . . . 24
3.2.4. iSCSI Full Feature Phase . . . . . . . . . . 25
3.2.4.1. Command Connection Allegiance . . 26
3.2.4.2. Data Transfer Overview. . . . . . 27
3.2.4.3. Tags and Integrity Checks . . . . 28
3.2.4.4. Task Management . . . . . . . . . 28
3.2.5. iSCSI Connection Termination . . . . . . . . 29
3.2.6. iSCSI Names. . . . . . . . . . . . . . . . . 29
3.2.6.1. iSCSI Name Properties . . . . . . 30
3.2.6.2. iSCSI Name Encoding . . . . . . . 31
3.2.6.3. iSCSI Name Structure. . . . . . . 32
3.2.6.3.1. Type "iqn." (iSCSI
Qualified Name) . . . 32
3.2.6.3.2. Type "eui." (IEEE
EUI-64 format). . . . 34
3.2.7. Persistent State . . . . . . . . . . . . . . 34
3.2.8. Message Synchronization and Steering . . . . 35
3.2.8.1. Sync/Steering and iSCSI PDU
Length . . . . . . . . . . . . . 36
3.3. iSCSI Session Types. . . . . . . . . . . . . . . . . . 36
3.4. SCSI to iSCSI Concepts Mapping Model . . . . . . . . . 37
3.4.1. iSCSI Architecture Model . . . . . . . . . . 37
3.4.2. SCSI Architecture Model. . . . . . . . . . . 39
3.4.3. Consequences of the Model. . . . . . . . . . 41
3.4.3.1. I_T Nexus State . . . . . . . . . 42
3.5. Request/Response Summary . . . . . . . . . . . . . . . 42
3.5.1. Request/Response Types Carrying SCSI Payload 43
3.5.1.1. SCSI-Command . . . . . . . . . . 43
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Definitions and Acronyms. . . . . . . . . . . . . . . . . . . 10
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . 10
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Conventions. . . . . . . . . . . . . . . . . . . . . . 16
2.3.1. Word Rule. . . . . . . . . . . . . . . . . . 16
2.3.2. Half-Word Rule . . . . . . . . . . . . . . . 17
2.3.3. Byte Rule. . . . . . . . . . . . . . . . . . 17
3. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. SCSI Concepts. . . . . . . . . . . . . . . . . . . . . 17
3.2. iSCSI Concepts and Functional Overview . . . . . . . . 18
3.2.1. Layers and Sessions. . . . . . . . . . . . . 19
3.2.2. Ordering and iSCSI Numbering . . . . . . . . 19
3.2.2.1. Command Numbering and
Acknowledging . . . . . . . . . . 20
3.2.2.2. Response/Status Numbering and
Acknowledging . . . . . . . . . . 23
3.2.2.3. Data Sequencing . . . . . . . . 24
3.2.3. iSCSI Login. . . . . . . . . . . . . . . . . 24
3.2.4. iSCSI Full Feature Phase . . . . . . . . . . 25
3.2.4.1. Command Connection Allegiance . . 26
3.2.4.2. Data Transfer Overview. . . . . . 27
3.2.4.3. Tags and Integrity Checks . . . . 28
3.2.4.4. Task Management . . . . . . . . . 28
3.2.5. iSCSI Connection Termination . . . . . . . . 29
3.2.6. iSCSI Names. . . . . . . . . . . . . . . . . 29
3.2.6.1. iSCSI Name Properties . . . . . . 30
3.2.6.2. iSCSI Name Encoding . . . . . . . 31
3.2.6.3. iSCSI Name Structure. . . . . . . 32
3.2.6.3.1. Type "iqn." (iSCSI
Qualified Name) . . . 32
3.2.6.3.2. Type "eui." (IEEE
EUI-64 format). . . . 34
3.2.7. Persistent State . . . . . . . . . . . . . . 34
3.2.8. Message Synchronization and Steering . . . . 35
3.2.8.1. Sync/Steering and iSCSI PDU
Length . . . . . . . . . . . . . 36
3.3. iSCSI Session Types. . . . . . . . . . . . . . . . . . 36
3.4. SCSI to iSCSI Concepts Mapping Model . . . . . . . . . 37
3.4.1. iSCSI Architecture Model . . . . . . . . . . 37
3.4.2. SCSI Architecture Model. . . . . . . . . . . 39
3.4.3. Consequences of the Model. . . . . . . . . . 41
3.4.3.1. I_T Nexus State . . . . . . . . . 42
3.5. Request/Response Summary . . . . . . . . . . . . . . . 42
3.5.1. Request/Response Types Carrying SCSI Payload 43
3.5.1.1. SCSI-Command . . . . . . . . . . 43
3.5.1.2. SCSI-Response . . . . . . . . . 43
3.5.1.3. Task Management Function Request. 44
3.5.1.4. Task Management Function Response 44
3.5.1.5. SCSI Data-Out and SCSI Data-In. . 44
3.5.1.6. Ready To Transfer (R2T) . . . . . 45
3.5.2. Requests/Responses carrying SCSI and iSCSI
Payload. . . . . . . . . . . . . . . . . . . 46
3.5.2.1. Asynchronous Message. . . . . . . 46
3.5.3. Requests/Responses Carrying iSCSI Only
Payload. . . . . . . . . . . . . . . . . . . 46
3.5.3.1. Text Request and Text Response. . 46
3.5.3.2. Login Request and Login Response. 47
3.5.3.3. Logout Request and Response . . . 47
3.5.3.4. SNACK Request . . . . . . . . . . 48
3.5.3.5. Reject. . . . . . . . . . . . . . 48
3.5.3.6. NOP-Out Request and NOP-In
Response . . . . . . . . . . . . 48
4. SCSI Mode Parameters for iSCSI. . . . . . . . . . . . . . . . 48
5. Login and Full Feature Phase Negotiation. . . . . . . . . . . 48
5.1. Text Format. . . . . . . . . . . . . . . . . . . . . . 50
5.2. Text Mode Negotiation. . . . . . . . . . . . . . . . . 53
5.2.1. List negotiations. . . . . . . . . . . . . . 56
5.2.2. Simple-value Negotiations. . . . . . . . . . 56
5.3. Login Phase. . . . . . . . . . . . . . . . . . . . . . 57
5.3.1. Login Phase Start. . . . . . . . . . . . . . 60
5.3.2. iSCSI Security Negotiation . . . . . . . . . 62
5.3.3. Operational Parameter Negotiation During
the Login Phase. . . . . . . . . . . . . . . 63
5.3.4. Connection Reinstatement . . . . . . . . . . 64
5.3.5. Session Reinstatement, Closure, and Timeout. 64
5 5.3.5.1. Loss of Nexus
Notification. . . . . 65
5.3.6. Session Continuation and Failure . . . . . . 65
5.4. Operational Parameter Negotiation Outside the Login
Phase. . . . . . . . . . . . . . . . . . . . . . . . . 66
6. iSCSI Error Handling and Recovery . . . . . . . . . . . . . . 67
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 67
6.1.1. Background . . . . . . . . . . . . . . . . . 67
6.1.2. Goals. . . . . . . . . . . . . . . . . . . . 67
6.1.3. Protocol Features and State Expectations . . 68
6.1.4. Recovery Classes . . . . . . . . . . . . . . 69
6.1.4.1. Recovery Within-command . . . . . 69
6.1.4.2. Recovery Within-connection. . . . 70
6.1.4.3. Connection Recovery . . . . . . . 71
6.1.4.4. Session Recovery. . . . . . . . . 72
6.1.5. Error Recovery Hierarchy . . . . . . . . . . . 72
6.2. Retry and Reassign in Recovery . . . . . . . . . . . . 74
6.2.1. Usage of Retry . . . . . . . . . . . . . . . 74
3.5.1.2. SCSI-Response . . . . . . . . . 43
3.5.1.3. Task Management Function Request. 44
3.5.1.4. Task Management Function Response 44
3.5.1.5. SCSI Data-Out and SCSI Data-In. . 44
3.5.1.6. Ready To Transfer (R2T) . . . . . 45
3.5.2. Requests/Responses carrying SCSI and iSCSI
Payload. . . . . . . . . . . . . . . . . . . 46
3.5.2.1. Asynchronous Message. . . . . . . 46
3.5.3. Requests/Responses Carrying iSCSI Only
Payload. . . . . . . . . . . . . . . . . . . 46
3.5.3.1. Text Request and Text Response. . 46
3.5.3.2. Login Request and Login Response. 47
3.5.3.3. Logout Request and Response . . . 47
3.5.3.4. SNACK Request . . . . . . . . . . 48
3.5.3.5. Reject. . . . . . . . . . . . . . 48
3.5.3.6. NOP-Out Request and NOP-In
Response . . . . . . . . . . . . 48
4. SCSI Mode Parameters for iSCSI. . . . . . . . . . . . . . . . 48
5. Login and Full Feature Phase Negotiation. . . . . . . . . . . 48
5.1. Text Format. . . . . . . . . . . . . . . . . . . . . . 50
5.2. Text Mode Negotiation. . . . . . . . . . . . . . . . . 53
5.2.1. List negotiations. . . . . . . . . . . . . . 56
5.2.2. Simple-value Negotiations. . . . . . . . . . 56
5.3. Login Phase. . . . . . . . . . . . . . . . . . . . . . 57
5.3.1. Login Phase Start. . . . . . . . . . . . . . 60
5.3.2. iSCSI Security Negotiation . . . . . . . . . 62
5.3.3. Operational Parameter Negotiation During
the Login Phase. . . . . . . . . . . . . . . 63
5.3.4. Connection Reinstatement . . . . . . . . . . 64
5.3.5. Session Reinstatement, Closure, and Timeout. 64
5 5.3.5.1. Loss of Nexus
Notification. . . . . 65
5.3.6. Session Continuation and Failure . . . . . . 65
5.4. Operational Parameter Negotiation Outside the Login
Phase. . . . . . . . . . . . . . . . . . . . . . . . . 66
6. iSCSI Error Handling and Recovery . . . . . . . . . . . . . . 67
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 67
6.1.1. Background . . . . . . . . . . . . . . . . . 67
6.1.2. Goals. . . . . . . . . . . . . . . . . . . . 67
6.1.3. Protocol Features and State Expectations . . 68
6.1.4. Recovery Classes . . . . . . . . . . . . . . 69
6.1.4.1. Recovery Within-command . . . . . 69
6.1.4.2. Recovery Within-connection. . . . 70
6.1.4.3. Connection Recovery . . . . . . . 71
6.1.4.4. Session Recovery. . . . . . . . . 72
6.1.5. Error Recovery Hierarchy . . . . . . . . . . . 72
6.2. Retry and Reassign in Recovery . . . . . . . . . . . . 74
6.2.1. Usage of Retry . . . . . . . . . . . . . . . 74
6.2.2. Allegiance Reassignment. . . . . . . . . . . 75
6.3. Usage Of Reject PDU in Recovery. . . . . . . . . . . . 76
6.4. Connection Timeout Management. . . . . . . . . . . . . 76
6.4.1. Timeouts on Transport Exception Events . . . 77
6.4.2. Timeouts on Planned Decommissioning. . . . . 77
6.5. Implicit Termination of Tasks. . . . . . . . . . . . . 77
6.6. Format Errors. . . . . . . . . . . . . . . . . . . . . 78
6.7. Digest Errors. . . . . . . . . . . . . . . . . . . . . 78
6.8. Sequence Errors. . . . . . . . . . . . . . . . . . . . 80
6.9. SCSI Timeouts. . . . . . . . . . . . . . . . . . . . . 81
6.10. Negotiation Failures . . . . . . . . . . . . . . . . . 81
6.11. Protocol Errors. . . . . . . . . . . . . . . . . . . . 82
6.12. Connection Failures. . . . . . . . . . . . . . . . . . 82
6.13. Session Errors . . . . . . . . . . . . . . . . . . . . 83
7. State Transitions . . . . . . . . . . . . . . . . . . . . . . 84
7.1. Standard Connection State Diagrams . . . . . . . . . . 84
7.1.1. State Descriptions for Initiators and
Targets. . . . . . . . . . . . . . . . . . . 84
7.1.2. State Transition Descriptions for Initiators
and Targets. . . . . . . . . . . . . . . . . 85
7.1.3. Standard Connection State Diagram for an
Initiator. . . . . . . . . . . . . . . . . . 88
7.1.4. Standard Connection State Diagram for a
Target . . . . . . . . . . . . . . . . . . . 90
7.2. Connection Cleanup State Diagram for Initiators and
Targets. . . . . . . . . . . . . . . . . . . . . . . . 92
7.2.1. State Descriptions for Initiators and
Targets. . . . . . . . . . . . . . . . . . . 94
7.2.2. State Transition Descriptions for Initiators
and Targets. . . . . . . . . . . . . . . . . 94
7.3. Session State Diagrams . . . . . . . . . . . . . . . . 95
7.3.1. Session State Diagram for an Initiator . . . 95
7.3.2. Session State Diagram for a Target . . . . . 96
7.3.3. State Descriptions for Initiators and
Targets. . . . . . . . . . . . . . . . . . . 97
7.3.4. State Transition Descriptions for Initiators
and Targets. . . . . . . . . . . . . . . . . 98
8. Security Considerations . . . . . . . . . . . . . . . . . . . 99
8.1. iSCSI Security Mechanisms. . . . . . . . . . . . . . . 100
8.2. In-band Initiator-Target Authentication. . . . . . . . 100
8.2.1. CHAP Considerations. . . . . . . . . . . . . 101
8.2.2. SRP Considerations . . . . . . . . . . . . . 103
8.3. IPsec. . . . . . . . . . . . . . . . . . . . . . . . . 104
8.3.1. Data Integrity and Authentication. . . . . . 104
8.3.2. Confidentiality. . . . . . . . . . . . . . . 105
8.3.3. Policy, Security Associations, and
Cryptographic Key Management . . . . . . . . 105
9. Notes to Implementers . . . . . . . . . . . . . . . . . . . . 106
6.2.2. Allegiance Reassignment. . . . . . . . . . . 75
6.3. Usage Of Reject PDU in Recovery. . . . . . . . . . . . 76
6.4. Connection Timeout Management. . . . . . . . . . . . . 76
6.4.1. Timeouts on Transport Exception Events . . . 77
6.4.2. Timeouts on Planned Decommissioning. . . . . 77
6.5. Implicit Termination of Tasks. . . . . . . . . . . . . 77
6.6. Format Errors. . . . . . . . . . . . . . . . . . . . . 78
6.7. Digest Errors. . . . . . . . . . . . . . . . . . . . . 78
6.8. Sequence Errors. . . . . . . . . . . . . . . . . . . . 80
6.9. SCSI Timeouts. . . . . . . . . . . . . . . . . . . . . 81
6.10. Negotiation Failures . . . . . . . . . . . . . . . . . 81
6.11. Protocol Errors. . . . . . . . . . . . . . . . . . . . 82
6.12. Connection Failures. . . . . . . . . . . . . . . . . . 82
6.13. Session Errors . . . . . . . . . . . . . . . . . . . . 83
7. State Transitions . . . . . . . . . . . . . . . . . . . . . . 84
7.1. Standard Connection State Diagrams . . . . . . . . . . 84
7.1.1. State Descriptions for Initiators and
Targets. . . . . . . . . . . . . . . . . . . 84
7.1.2. State Transition Descriptions for Initiators
and Targets. . . . . . . . . . . . . . . . . 85
7.1.3. Standard Connection State Diagram for an
Initiator. . . . . . . . . . . . . . . . . . 88
7.1.4. Standard Connection State Diagram for a
Target . . . . . . . . . . . . . . . . . . . 90
7.2. Connection Cleanup State Diagram for Initiators and
Targets. . . . . . . . . . . . . . . . . . . . . . . . 92
7.2.1. State Descriptions for Initiators and
Targets. . . . . . . . . . . . . . . . . . . 94
7.2.2. State Transition Descriptions for Initiators
and Targets. . . . . . . . . . . . . . . . . 94
7.3. Session State Diagrams . . . . . . . . . . . . . . . . 95
7.3.1. Session State Diagram for an Initiator . . . 95
7.3.2. Session State Diagram for a Target . . . . . 96
7.3.3. State Descriptions for Initiators and
Targets. . . . . . . . . . . . . . . . . . . 97
7.3.4. State Transition Descriptions for Initiators
and Targets. . . . . . . . . . . . . . . . . 98
8. Security Considerations . . . . . . . . . . . . . . . . . . . 99
8.1. iSCSI Security Mechanisms. . . . . . . . . . . . . . . 100
8.2. In-band Initiator-Target Authentication. . . . . . . . 100
8.2.1. CHAP Considerations. . . . . . . . . . . . . 101
8.2.2. SRP Considerations . . . . . . . . . . . . . 103
8.3. IPsec. . . . . . . . . . . . . . . . . . . . . . . . . 104
8.3.1. Data Integrity and Authentication. . . . . . 104
8.3.2. Confidentiality. . . . . . . . . . . . . . . 105
8.3.3. Policy, Security Associations, and
Cryptographic Key Management . . . . . . . . 105
9. Notes to Implementers . . . . . . . . . . . . . . . . . . . . 106
9.1. Multiple Network Adapters. . . . . . . . . . . . . . . 106
9.1.1. Conservative Reuse of ISIDs. . . . . . . . . 107
9.1.2. iSCSI Name, ISID, and TPGT Use . . . . . . . 107
9.2. Autosense and Auto Contingent Allegiance (ACA) . . . . 109
9.3. iSCSI Timeouts . . . . . . . . . . . . . . . . . . . . 109
9.4. Command Retry and Cleaning Old Command Instances . . . 110
9.5. Synch and Steering Layer and Performance . . . . . . . 110
9.6. Considerations for State-dependent Devices and
Long-lasting SCSI Operations . . . . . . . . . . . . . 111
9.6.1. Determining the Proper ErrorRecoveryLevel. . 112
10. iSCSI PDU Formats . . . . . . . . . . . . . . . . . . . . . . 112
10.1. iSCSI PDU Length and Padding . . . . . . . . . . . . . 113
10.2. PDU Template, Header, and Opcodes. . . . . . . . . . . 113
10.2.1. Basic Header Segment (BHS) . . . . . . . . . 114
10.2.1.1. I . . . . . . . . . . . . . . . . 115
10.2.1.2. Opcode. . . . . . . . . . . . . . 115
10.2.1.3. Final (F) bit . . . . . . . . . . 116
10.2.1.4. Opcode-specific Fields. . . . . . 116
10.2.1.5. TotalAHSLength. . . . . . . . . . 116
10.2.1.6. DataSegmentLength . . . . . . . . 116
10.2.1.7. LUN . . . . . . . . . . . . . . . 116
10.2.1.8. Initiator Task Tag. . . . . . . . 117
10.2.2. Additional Header Segment (AHS) . . . . . . . 117
10.2.2.1. AHSType . . . . . . . . . . . . . 117
10.2.2.2. AHSLength . . . . . . . . . . . . 117
10.2.2.3. Extended CDB AHS. . . . . . . . . 118
10.2.2.4. Bidirectional Expected Read-Data
Length AHS. . . . . . . . . . . . 118
10.2.3. Header Digest and Data Digest. . . . . . . . 118
10.2.4. Data Segment . . . . . . . . . . . . . . . . 119
10.3. SCSI Command . . . . . . . . . . . . . . . . . . . . . 119
10.3.1. Flags and Task Attributes (byte 1) . . . . . 120
10.3.2. CmdSN - Command Sequence Number. . . . . . . 120
10.3.3. ExpStatSN. . . . . . . . . . . . . . . . . . 120
10.3.4. Expected Data Transfer Length. . . . . . . . 121
10.3.5. CDB - SCSI Command Descriptor Block. . . . . 121
10.3.6. Data Segment - Command Data. . . . . . . . . 121
10.4. SCSI Response. . . . . . . . . . . . . . . . . . . . . 122
10.4.1. Flags (byte 1) . . . . . . . . . . . . . . . 123
10.4.2. Status . . . . . . . . . . . . . . . . . . . 123
10.4.3. Response . . . . . . . . . . . . . . . . . . 124
10.4.4. SNACK Tag. . . . . . . . . . . . . . . . . . 125
10.4.5. Residual Count . . . . . . . . . . . . . . . 125
10.4.6. Bidirectional Read Residual Count. . . . . . 125
10.4.7. Data Segment - Sense and Response Data
Segment. . . . . . . . . . . . . . . . . . . 125
10.4.7.1. SenseLength . . . . . . . . . . . 126
10.4.7.2. Sense Data. . . . . . . . . . . . 126
9.1. Multiple Network Adapters. . . . . . . . . . . . . . . 106
9.1.1. Conservative Reuse of ISIDs. . . . . . . . . 107
9.1.2. iSCSI Name, ISID, and TPGT Use . . . . . . . 107
9.2. Autosense and Auto Contingent Allegiance (ACA) . . . . 109
9.3. iSCSI Timeouts . . . . . . . . . . . . . . . . . . . . 109
9.4. Command Retry and Cleaning Old Command Instances . . . 110
9.5. Synch and Steering Layer and Performance . . . . . . . 110
9.6. Considerations for State-dependent Devices and
Long-lasting SCSI Operations . . . . . . . . . . . . . 111
9.6.1. Determining the Proper ErrorRecoveryLevel. . 112
10. iSCSI PDU Formats . . . . . . . . . . . . . . . . . . . . . . 112
10.1. iSCSI PDU Length and Padding . . . . . . . . . . . . . 113
10.2. PDU Template, Header, and Opcodes. . . . . . . . . . . 113
10.2.1. Basic Header Segment (BHS) . . . . . . . . . 114
10.2.1.1. I . . . . . . . . . . . . . . . . 115
10.2.1.2. Opcode. . . . . . . . . . . . . . 115
10.2.1.3. Final (F) bit . . . . . . . . . . 116
10.2.1.4. Opcode-specific Fields. . . . . . 116
10.2.1.5. TotalAHSLength. . . . . . . . . . 116
10.2.1.6. DataSegmentLength . . . . . . . . 116
10.2.1.7. LUN . . . . . . . . . . . . . . . 116
10.2.1.8. Initiator Task Tag. . . . . . . . 117
10.2.2. Additional Header Segment (AHS) . . . . . . . 117
10.2.2.1. AHSType . . . . . . . . . . . . . 117
10.2.2.2. AHSLength . . . . . . . . . . . . 117
10.2.2.3. Extended CDB AHS. . . . . . . . . 118
10.2.2.4. Bidirectional Expected Read-Data
Length AHS. . . . . . . . . . . . 118
10.2.3. Header Digest and Data Digest. . . . . . . . 118
10.2.4. Data Segment . . . . . . . . . . . . . . . . 119
10.3. SCSI Command . . . . . . . . . . . . . . . . . . . . . 119
10.3.1. Flags and Task Attributes (byte 1) . . . . . 120
10.3.2. CmdSN - Command Sequence Number. . . . . . . 120
10.3.3. ExpStatSN. . . . . . . . . . . . . . . . . . 120
10.3.4. Expected Data Transfer Length. . . . . . . . 121
10.3.5. CDB - SCSI Command Descriptor Block. . . . . 121
10.3.6. Data Segment - Command Data. . . . . . . . . 121
10.4. SCSI Response. . . . . . . . . . . . . . . . . . . . . 122
10.4.1. Flags (byte 1) . . . . . . . . . . . . . . . 123
10.4.2. Status . . . . . . . . . . . . . . . . . . . 123
10.4.3. Response . . . . . . . . . . . . . . . . . . 124
10.4.4. SNACK Tag. . . . . . . . . . . . . . . . . . 125
10.4.5. Residual Count . . . . . . . . . . . . . . . 125
10.4.6. Bidirectional Read Residual Count. . . . . . 125
10.4.7. Data Segment - Sense and Response Data
Segment. . . . . . . . . . . . . . . . . . . 125
10.4.7.1. SenseLength . . . . . . . . . . . 126
10.4.7.2. Sense Data. . . . . . . . . . . . 126
10.4.8. ExpDataSN. . . . . . . . . . . . . . . . . . 127
10.4.9. StatSN - Status Sequence Number. . . . . . . 127
10.4.10. ExpCmdSN - Next Expected CmdSN from this
Initiator. . . . . . . . . . . . . . . . . . 128
10.4.11. MaxCmdSN - Maximum CmdSN from this Initiator 128
10.5. Task Management Function Request . . . . . . . . . . . 129
10.5.1. Function . . . . . . . . . . . . . . . . . . 129
10.5.2. TotalAHSLength and DataSegmentLength . . . . 132
10.5.3. LUN. . . . . . . . . . . . . . . . . . . . . 132
10.5.4. Referenced Task Tag. . . . . . . . . . . . . 132
10.5.5. RefCmdSN . . . . . . . . . . . . . . . . . . 132
10.5.6. ExpDataSN. . . . . . . . . . . . . . . . . . 133
10.6. Task Management Function Response. . . . . . . . . . . 134
10.6.1. Response . . . . . . . . . . . . . . . . . . 134
10.6.2. Task Management Actions on Task Sets . . . . 136
10.6.3. TotalAHSLength and DataSegmentLength . . . . 137
10.7. SCSI Data-Out & SCSI Data-In . . . . . . . . . . . . . 137
10.7.1. F (Final) Bit. . . . . . . . . . . . . . . . 139
10.7.2. A (Acknowledge) Bit. . . . . . . . . . . . . 139
10.7.3. Flags (byte 1) . . . . . . . . . . . . . . . 140
10.7.4. Target Transfer Tag and LUN. . . . . . . . . 140
10.7.5. DataSN . . . . . . . . . . . . . . . . . . . 141
10.7.6. Buffer Offset. . . . . . . . . . . . . . . . 141
10.7.7. DataSegmentLength. . . . . . . . . . . . . . 141
10.8. Ready To Transfer (R2T). . . . . . . . . . . . . . . . 142
10.8.1. TotalAHSLength and DataSegmentLength . . . . 143
10.8.2. R2TSN. . . . . . . . . . . . . . . . . . . . 143
10.8.3. StatSN . . . . . . . . . . . . . . . . . . . 144
10.8.4. Desired Data Transfer Length and Buffer
Offset . . . . . . . . . . . . . . . . . . . 144
10.8.5. Target Transfer Tag. . . . . . . . . . . . . 144
10.9. Asynchronous Message . . . . . . . . . . . . . . . . . 145
10.9.1. AsyncEvent . . . . . . . . . . . . . . . . . 146
10.9.2. AsyncVCode . . . . . . . . . . . . . . . . . 147
10.9.3. LUN. . . . . . . . . . . . . . . . . . . . . 147
10.9.4. Sense Data and iSCSI Event Data. . . . . . . 148
10.9.4.1. SenseLength . . . . . . . . . . . 148
10.10. Text Request . . . . . . . . . . . . . . . . . . . . . 149
10.10.1. F (Final) Bit. . . . . . . . . . . . . . . . 150
10.10.2. C (Continue) Bit . . . . . . . . . . . . . . 150
10.10.3. Initiator Task Tag . . . . . . . . . . . . . 150
10.10.4. Target Transfer Tag. . . . . . . . . . . . . 150
10.10.5. Text . . . . . . . . . . . . . . . . . . . . 151
10.11. Text Response. . . . . . . . . . . . . . . . . . . . . 152
10.11.1. F (Final) Bit. . . . . . . . . . . . . . . . 152
10.11.2. C (Continue) Bit . . . . . . . . . . . . . . 153
10.11.3. Initiator Task Tag . . . . . . . . . . . . . 153
10.11.4. Target Transfer Tag. . . . . . . . . . . . . 153
10.4.8. ExpDataSN. . . . . . . . . . . . . . . . . . 127
10.4.9. StatSN - Status Sequence Number. . . . . . . 127
10.4.10. ExpCmdSN - Next Expected CmdSN from this
Initiator. . . . . . . . . . . . . . . . . . 128
10.4.11. MaxCmdSN - Maximum CmdSN from this Initiator 128
10.5. Task Management Function Request . . . . . . . . . . . 129
10.5.1. Function . . . . . . . . . . . . . . . . . . 129
10.5.2. TotalAHSLength and DataSegmentLength . . . . 132
10.5.3. LUN. . . . . . . . . . . . . . . . . . . . . 132
10.5.4. Referenced Task Tag. . . . . . . . . . . . . 132
10.5.5. RefCmdSN . . . . . . . . . . . . . . . . . . 132
10.5.6. ExpDataSN. . . . . . . . . . . . . . . . . . 133
10.6. Task Management Function Response. . . . . . . . . . . 134
10.6.1. Response . . . . . . . . . . . . . . . . . . 134
10.6.2. Task Management Actions on Task Sets . . . . 136
10.6.3. TotalAHSLength and DataSegmentLength . . . . 137
10.7. SCSI Data-Out & SCSI Data-In . . . . . . . . . . . . . 137
10.7.1. F (Final) Bit. . . . . . . . . . . . . . . . 139
10.7.2. A (Acknowledge) Bit. . . . . . . . . . . . . 139
10.7.3. Flags (byte 1) . . . . . . . . . . . . . . . 140
10.7.4. Target Transfer Tag and LUN. . . . . . . . . 140
10.7.5. DataSN . . . . . . . . . . . . . . . . . . . 141
10.7.6. Buffer Offset. . . . . . . . . . . . . . . . 141
10.7.7. DataSegmentLength. . . . . . . . . . . . . . 141
10.8. Ready To Transfer (R2T). . . . . . . . . . . . . . . . 142
10.8.1. TotalAHSLength and DataSegmentLength . . . . 143
10.8.2. R2TSN. . . . . . . . . . . . . . . . . . . . 143
10.8.3. StatSN . . . . . . . . . . . . . . . . . . . 144
10.8.4. Desired Data Transfer Length and Buffer
Offset . . . . . . . . . . . . . . . . . . . 144
10.8.5. Target Transfer Tag. . . . . . . . . . . . . 144
10.9. Asynchronous Message . . . . . . . . . . . . . . . . . 145
10.9.1. AsyncEvent . . . . . . . . . . . . . . . . . 146
10.9.2. AsyncVCode . . . . . . . . . . . . . . . . . 147
10.9.3. LUN. . . . . . . . . . . . . . . . . . . . . 147
10.9.4. Sense Data and iSCSI Event Data. . . . . . . 148
10.9.4.1. SenseLength . . . . . . . . . . . 148
10.10. Text Request . . . . . . . . . . . . . . . . . . . . . 149
10.10.1. F (Final) Bit. . . . . . . . . . . . . . . . 150
10.10.2. C (Continue) Bit . . . . . . . . . . . . . . 150
10.10.3. Initiator Task Tag . . . . . . . . . . . . . 150
10.10.4. Target Transfer Tag. . . . . . . . . . . . . 150
10.10.5. Text . . . . . . . . . . . . . . . . . . . . 151
10.11. Text Response. . . . . . . . . . . . . . . . . . . . . 152
10.11.1. F (Final) Bit. . . . . . . . . . . . . . . . 152
10.11.2. C (Continue) Bit . . . . . . . . . . . . . . 153
10.11.3. Initiator Task Tag . . . . . . . . . . . . . 153
10.11.4. Target Transfer Tag. . . . . . . . . . . . . 153
10.11.5. StatSN . . . . . . . . . . . . . . . . . . . 154
10.11.6. Text Response Data . . . . . . . . . . . . . 154
10.12. Login Request. . . . . . . . . . . . . . . . . . . . . 154
10.12.1. T (Transit) Bit. . . . . . . . . . . . . . . 155
10.12.2. C (Continue) Bit . . . . . . . . . . . . . . 155
10.12.3. CSG and NSG. . . . . . . . . . . . . . . . . 156
10.12.4. Version. . . . . . . . . . . . . . . . . . . 156
10.12.4.1. Version-max. . . . . . . . . . . 156
10.12.4.2. Version-min. . . . . . . . . . . 156
10.12.5. ISID . . . . . . . . . . . . . . . . . . . . 157
10.12.6. TSIH . . . . . . . . . . . . . . . . . . . . 158
10.12.7. Connection ID - CID. . . . . . . . . . . . . 158
10.12.8. CmdSN. . . . . . . . . . . . . . . . . . . . 159
10.12.9. ExpStatSN. . . . . . . . . . . . . . . . . . 159
10.12.10. Login Parameters . . . . . . . . . . . . . . 159
10.13. Login Response . . . . . . . . . . . . . . . . . . . . 160
10.13.1. Version-max. . . . . . . . . . . . . . . . . 160
10.13.2. Version-active . . . . . . . . . . . . . . . 161
10.13.3. TSIH . . . . . . . . . . . . . . . . . . . . 161
10.13.4. StatSN . . . . . . . . . . . . . . . . . . . 161
10.13.5. Status-Class and Status-Detail . . . . . . . 161
10.13.6. T (Transit) Bit. . . . . . . . . . . . . . . 164
10.13.7. C (Continue) Bit . . . . . . . . . . . . . . 164
10.13.8. Login Parameters . . . . . . . . . . . . . . 164
10.14. Logout Request . . . . . . . . . . . . . . . . . . . . 165
10.14.1. Reason Code. . . . . . . . . . . . . . . . . 167
10.14.2. TotalAHSLength and DataSegmentLength . . . . 168
10.14.3. CID. . . . . . . . . . . . . . . . . . . . . 168
10.14.4. ExpStatSN. . . . . . . . . . . . . . . . . . 168
10.14.5. Implicit termination of tasks. . . . . . . . 168
10.15. Logout Response. . . . . . . . . . . . . . . . . . . . 169
10.15.1. Response . . . . . . . . . . . . . . . . . . 170
10.15.2. TotalAHSLength and DataSegmentLength . . . . 170
10.15.3. Time2Wait. . . . . . . . . . . . . . . . . . 170
10.15.4. Time2Retain. . . . . . . . . . . . . . . . . 170
10.16. SNACK Request. . . . . . . . . . . . . . . . . . . . . 171
10.16.1. Type . . . . . . . . . . . . . . . . . . . . 172
10.16.2. Data Acknowledgement . . . . . . . . . . . . 173
10.16.3. Resegmentation . . . . . . . . . . . . . . . 173
10.16.4. Initiator Task Tag . . . . . . . . . . . . . 174
10.16.5. Target Transfer Tag or SNACK Tag . . . . . . 174
10.16.6. BegRun . . . . . . . . . . . . . . . . . . . 174
10.16.7. RunLength. . . . . . . . . . . . . . . . . . 174
10.17. Reject . . . . . . . . . . . . . . . . . . . . . . . . 175
10.17.1. Reason . . . . . . . . . . . . . . . . . . . 176
10.17.2. DataSN/R2TSN . . . . . . . . . . . . . . . . 177
10.17.3. StatSN, ExpCmdSN and MaxCmdSN. . . . . . . . 177
10.17.4. Complete Header of Bad PDU . . . . . . . . . 177
10.11.5. StatSN . . . . . . . . . . . . . . . . . . . 154
10.11.6. Text Response Data . . . . . . . . . . . . . 154
10.12. Login Request. . . . . . . . . . . . . . . . . . . . . 154
10.12.1. T (Transit) Bit. . . . . . . . . . . . . . . 155
10.12.2. C (Continue) Bit . . . . . . . . . . . . . . 155
10.12.3. CSG and NSG. . . . . . . . . . . . . . . . . 156
10.12.4. Version. . . . . . . . . . . . . . . . . . . 156
10.12.4.1. Version-max. . . . . . . . . . . 156
10.12.4.2. Version-min. . . . . . . . . . . 156
10.12.5. ISID . . . . . . . . . . . . . . . . . . . . 157
10.12.6. TSIH . . . . . . . . . . . . . . . . . . . . 158
10.12.7. Connection ID - CID. . . . . . . . . . . . . 158
10.12.8. CmdSN. . . . . . . . . . . . . . . . . . . . 159
10.12.9. ExpStatSN. . . . . . . . . . . . . . . . . . 159
10.12.10. Login Parameters . . . . . . . . . . . . . . 159
10.13. Login Response . . . . . . . . . . . . . . . . . . . . 160
10.13.1. Version-max. . . . . . . . . . . . . . . . . 160
10.13.2. Version-active . . . . . . . . . . . . . . . 161
10.13.3. TSIH . . . . . . . . . . . . . . . . . . . . 161
10.13.4. StatSN . . . . . . . . . . . . . . . . . . . 161
10.13.5. Status-Class and Status-Detail . . . . . . . 161
10.13.6. T (Transit) Bit. . . . . . . . . . . . . . . 164
10.13.7. C (Continue) Bit . . . . . . . . . . . . . . 164
10.13.8. Login Parameters . . . . . . . . . . . . . . 164
10.14. Logout Request . . . . . . . . . . . . . . . . . . . . 165
10.14.1. Reason Code. . . . . . . . . . . . . . . . . 167
10.14.2. TotalAHSLength and DataSegmentLength . . . . 168
10.14.3. CID. . . . . . . . . . . . . . . . . . . . . 168
10.14.4. ExpStatSN. . . . . . . . . . . . . . . . . . 168
10.14.5. Implicit termination of tasks. . . . . . . . 168
10.15. Logout Response. . . . . . . . . . . . . . . . . . . . 169
10.15.1. Response . . . . . . . . . . . . . . . . . . 170
10.15.2. TotalAHSLength and DataSegmentLength . . . . 170
10.15.3. Time2Wait. . . . . . . . . . . . . . . . . . 170
10.15.4. Time2Retain. . . . . . . . . . . . . . . . . 170
10.16. SNACK Request. . . . . . . . . . . . . . . . . . . . . 171
10.16.1. Type . . . . . . . . . . . . . . . . . . . . 172
10.16.2. Data Acknowledgement . . . . . . . . . . . . 173
10.16.3. Resegmentation . . . . . . . . . . . . . . . 173
10.16.4. Initiator Task Tag . . . . . . . . . . . . . 174
10.16.5. Target Transfer Tag or SNACK Tag . . . . . . 174
10.16.6. BegRun . . . . . . . . . . . . . . . . . . . 174
10.16.7. RunLength. . . . . . . . . . . . . . . . . . 174
10.17. Reject . . . . . . . . . . . . . . . . . . . . . . . . 175
10.17.1. Reason . . . . . . . . . . . . . . . . . . . 176
10.17.2. DataSN/R2TSN . . . . . . . . . . . . . . . . 177
10.17.3. StatSN, ExpCmdSN and MaxCmdSN. . . . . . . . 177
10.17.4. Complete Header of Bad PDU . . . . . . . . . 177
10.18. NOP-Out. . . . . . . . . . . . . . . . . . . . . . . . 178
10.18.1. Initiator Task Tag . . . . . . . . . . . . . 179
10.18.2. Target Transfer Tag. . . . . . . . . . . . . 179
10.18.3. Ping Data. . . . . . . . . . . . . . . . . . 179
10.19. NOP-In . . . . . . . . . . . . . . . . . . . . . . . . 180
10.19.1. Target Transfer Tag. . . . . . . . . . . . . 181
10.19.2. StatSN . . . . . . . . . . . . . . . . . . . 181
10.19.3. LUN. . . . . . . . . . . . . . . . . . . . . 181
11. iSCSI Security Text Keys and Authentication Methods . . . . . 181
11.1. AuthMethod . . . . . . . . . . . . . . . . . . . . . . 182
11.1.1. Kerberos . . . . . . . . . . . . . . . . . . 184
11.1.2. Simple Public-Key Mechanism (SPKM) . . . . . 184
11.1.3. Secure Remote Password (SRP) . . . . . . . . 185
11.1.4. Challenge Handshake Authentication Protocol
(CHAP) . . . . . . . . . . . . . . . . . . . 186
12. Login/Text Operational Text Keys. . . . . . . . . . . . . . . 187
12.1. HeaderDigest and DataDigest. . . . . . . . . . . . . . 188
12.2. MaxConnections . . . . . . . . . . . . . . . . . . . . 190
12.3. SendTargets. . . . . . . . . . . . . . . . . . . . . . 191
12.4. TargetName . . . . . . . . . . . . . . . . . . . . . . 191
12.5. InitiatorName. . . . . . . . . . . . . . . . . . . . . 192
12.6. TargetAlias. . . . . . . . . . . . . . . . . . . . . . 192
12.7. InitiatorAlias . . . . . . . . . . . . . . . . . . . . 193
12.8. TargetAddress. . . . . . . . . . . . . . . . . . . . . 193
12.9. TargetPortalGroupTag . . . . . . . . . . . . . . . . . 194
12.10. InitialR2T . . . . . . . . . . . . . . . . . . . . . . 194
12.11. ImmediateData. . . . . . . . . . . . . . . . . . . . . 195
12.12. MaxRecvDataSegmentLength . . . . . . . . . . . . . . . 196
12.13. MaxBurstLength . . . . . . . . . . . . . . . . . . . . 196
12.14. FirstBurstLength . . . . . . . . . . . . . . . . . . . 197
12.15. DefaultTime2Wait . . . . . . . . . . . . . . . . . . . 197
12.16. DefaultTime2Retain . . . . . . . . . . . . . . . . . . 198
12.17. MaxOutstandingR2T. . . . . . . . . . . . . . . . . . . 198
12.18. DataPDUInOrder . . . . . . . . . . . . . . . . . . . . 198
12.19. DataSequenceInOrder. . . . . . . . . . . . . . . . . . 199
12.20. ErrorRecoveryLevel . . . . . . . . . . . . . . . . . . 199
12.21. SessionType. . . . . . . . . . . . . . . . . . . . . . 200
12.22. The Private or Public Extension Key Format . . . . . . 200
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 201
13.1. Naming Requirements. . . . . . . . . . . . . . . . . . 203
13.2. Mechanism Specification Requirements . . . . . . . . . 203
13.3. Publication Requirements . . . . . . . . . . . . . . . 203
13.4. Security Requirements. . . . . . . . . . . . . . . . . 203
13.5. Registration Procedure . . . . . . . . . . . . . . . . 204
13.5.1. Present the iSCSI extension item to the
Community. . . . . . . . . . . . . . . . . . 204
13.5.2. iSCSI extension item review and IESG
approval . . . . . . . . . . . . . . . . . . 204
10.18. NOP-Out. . . . . . . . . . . . . . . . . . . . . . . . 178
10.18.1. Initiator Task Tag . . . . . . . . . . . . . 179
10.18.2. Target Transfer Tag. . . . . . . . . . . . . 179
10.18.3. Ping Data. . . . . . . . . . . . . . . . . . 179
10.19. NOP-In . . . . . . . . . . . . . . . . . . . . . . . . 180
10.19.1. Target Transfer Tag. . . . . . . . . . . . . 181
10.19.2. StatSN . . . . . . . . . . . . . . . . . . . 181
10.19.3. LUN. . . . . . . . . . . . . . . . . . . . . 181
11. iSCSI Security Text Keys and Authentication Methods . . . . . 181
11.1. AuthMethod . . . . . . . . . . . . . . . . . . . . . . 182
11.1.1. Kerberos . . . . . . . . . . . . . . . . . . 184
11.1.2. Simple Public-Key Mechanism (SPKM) . . . . . 184
11.1.3. Secure Remote Password (SRP) . . . . . . . . 185
11.1.4. Challenge Handshake Authentication Protocol
(CHAP) . . . . . . . . . . . . . . . . . . . 186
12. Login/Text Operational Text Keys. . . . . . . . . . . . . . . 187
12.1. HeaderDigest and DataDigest. . . . . . . . . . . . . . 188
12.2. MaxConnections . . . . . . . . . . . . . . . . . . . . 190
12.3. SendTargets. . . . . . . . . . . . . . . . . . . . . . 191
12.4. TargetName . . . . . . . . . . . . . . . . . . . . . . 191
12.5. InitiatorName. . . . . . . . . . . . . . . . . . . . . 192
12.6. TargetAlias. . . . . . . . . . . . . . . . . . . . . . 192
12.7. InitiatorAlias . . . . . . . . . . . . . . . . . . . . 193
12.8. TargetAddress. . . . . . . . . . . . . . . . . . . . . 193
12.9. TargetPortalGroupTag . . . . . . . . . . . . . . . . . 194
12.10. InitialR2T . . . . . . . . . . . . . . . . . . . . . . 194
12.11. ImmediateData. . . . . . . . . . . . . . . . . . . . . 195
12.12. MaxRecvDataSegmentLength . . . . . . . . . . . . . . . 196
12.13. MaxBurstLength . . . . . . . . . . . . . . . . . . . . 196
12.14. FirstBurstLength . . . . . . . . . . . . . . . . . . . 197
12.15. DefaultTime2Wait . . . . . . . . . . . . . . . . . . . 197
12.16. DefaultTime2Retain . . . . . . . . . . . . . . . . . . 198
12.17. MaxOutstandingR2T. . . . . . . . . . . . . . . . . . . 198
12.18. DataPDUInOrder . . . . . . . . . . . . . . . . . . . . 198
12.19. DataSequenceInOrder. . . . . . . . . . . . . . . . . . 199
12.20. ErrorRecoveryLevel . . . . . . . . . . . . . . . . . . 199
12.21. SessionType. . . . . . . . . . . . . . . . . . . . . . 200
12.22. The Private or Public Extension Key Format . . . . . . 200
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 201
13.1. Naming Requirements. . . . . . . . . . . . . . . . . . 203
13.2. Mechanism Specification Requirements . . . . . . . . . 203
13.3. Publication Requirements . . . . . . . . . . . . . . . 203
13.4. Security Requirements. . . . . . . . . . . . . . . . . 203
13.5. Registration Procedure . . . . . . . . . . . . . . . . 204
13.5.1. Present the iSCSI extension item to the
Community. . . . . . . . . . . . . . . . . . 204
13.5.2. iSCSI extension item review and IESG
approval . . . . . . . . . . . . . . . . . . 204
13.5.3. IANA Registration. . . . . . . . . . . . . . 204
13.5.4. Standard iSCSI extension item-label format . 204
13.6. IANA Procedures for Registering iSCSI extension items. 205
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Appendix A. Sync and Steering with Fixed Interval Markers . . . . 209
A.1. Markers At Fixed Intervals . . . . . . . . . . . . . . 209
A.2. Initial Marker-less Interval . . . . . . . . . . . . . 210
A.3. Negotiation. . . . . . . . . . . . . . . . . . . . . . 210
A.3.1. OFMarker, IFMarker . . . . . . . . . . . . . 210
A.3.2. OFMarkInt, IFMarkInt . . . . . . . . . . . . 211
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 212
B.1. Read Operation Example . . . . . . . . . . . . . . . . 212
B.2. Write Operation Example. . . . . . . . . . . . . . . . 213
B.3. R2TSN/DataSN Use Examples. . . . . . . . . . . . . . . 214
B.4. CRC Examples . . . . . . . . . . . . . . . . . . . . . 217
Appendix C. Login Phase Examples . . . . . . . . . . . . . . . . 219
Appendix D. SendTargets Operation. . . . . . . . . . . . . . . . 229
Appendix E. Algorithmic Presentation of Error Recovery Classes . 233
E.1. General Data Structure and Procedure Description . . . 233
E.2. Within-command Error Recovery Algorithms . . . . . . . 234
E.2.1. Procedure Descriptions . . . . . . . . . . . 234
E.2.2. Initiator Algorithms . . . . . . . . . . . . 235
E.2.3. Target Algorithms. . . . . . . . . . . . . . 237
E.3. Within-connection Recovery Algorithms. . . . . . . . . 240
E.3.1. Procedure Descriptions . . . . . . . . . . . 240
E.3.2. Initiator Algorithms . . . . . . . . . . . . 241
E.3.3. Target Algorithms. . . . . . . . . . . . . . 243
E.4. Connection Recovery Algorithms . . . . . . . . . . . . 243
E.4.1. Procedure Descriptions . . . . . . . . . . . 243
E.4.2. Initiator Algorithms . . . . . . . . . . . . 244
E.4.3. Target Algorithms. . . . . . . . . . . . . . 246
Appendix F. Clearing Effects of Various Events on Targets. . . . 249
F.1. Clearing Effects on iSCSI Objects. . . . . . . . . . . 249
F.2. Clearing Effects on SCSI Objects . . . . . . . . . . . 253
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 254
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 256
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 257
13.5.3. IANA Registration. . . . . . . . . . . . . . 204
13.5.4. Standard iSCSI extension item-label format . 204
13.6. IANA Procedures for Registering iSCSI extension items. 205
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Appendix A. Sync and Steering with Fixed Interval Markers . . . . 209
A.1. Markers At Fixed Intervals . . . . . . . . . . . . . . 209
A.2. Initial Marker-less Interval . . . . . . . . . . . . . 210
A.3. Negotiation. . . . . . . . . . . . . . . . . . . . . . 210
A.3.1. OFMarker, IFMarker . . . . . . . . . . . . . 210
A.3.2. OFMarkInt, IFMarkInt . . . . . . . . . . . . 211
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 212
B.1. Read Operation Example . . . . . . . . . . . . . . . . 212
B.2. Write Operation Example. . . . . . . . . . . . . . . . 213
B.3. R2TSN/DataSN Use Examples. . . . . . . . . . . . . . . 214
B.4. CRC Examples . . . . . . . . . . . . . . . . . . . . . 217
Appendix C. Login Phase Examples . . . . . . . . . . . . . . . . 219
Appendix D. SendTargets Operation. . . . . . . . . . . . . . . . 229
Appendix E. Algorithmic Presentation of Error Recovery Classes . 233
E.1. General Data Structure and Procedure Description . . . 233
E.2. Within-command Error Recovery Algorithms . . . . . . . 234
E.2.1. Procedure Descriptions . . . . . . . . . . . 234
E.2.2. Initiator Algorithms . . . . . . . . . . . . 235
E.2.3. Target Algorithms. . . . . . . . . . . . . . 237
E.3. Within-connection Recovery Algorithms. . . . . . . . . 240
E.3.1. Procedure Descriptions . . . . . . . . . . . 240
E.3.2. Initiator Algorithms . . . . . . . . . . . . 241
E.3.3. Target Algorithms. . . . . . . . . . . . . . 243
E.4. Connection Recovery Algorithms . . . . . . . . . . . . 243
E.4.1. Procedure Descriptions . . . . . . . . . . . 243
E.4.2. Initiator Algorithms . . . . . . . . . . . . 244
E.4.3. Target Algorithms. . . . . . . . . . . . . . 246
Appendix F. Clearing Effects of Various Events on Targets. . . . 249
F.1. Clearing Effects on iSCSI Objects. . . . . . . . . . . 249
F.2. Clearing Effects on SCSI Objects . . . . . . . . . . . 253
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 254
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 256
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 257
The Small Computer Systems 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, 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 (see [RFC791], [RFC793], [RFC1035], [RFC1122]), providing for an interoperable solution which can take advantage of existing Internet infrastructure, Internet management facilities, and address distance limitations.
本文档中定义的iSCSI协议描述了通过TCP/IP传输SCSI数据包的方法（请参阅[RFC791]、[RFC793]、[RFC1035]、[RFC1122]），提供了一个可互操作的解决方案，该解决方案可以利用现有的Internet基础设施、Internet管理设施和地址距离限制。
- 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命令、参数和数据。
- iSCSI Device: A SCSI Device using an iSCSI service delivery subsystem. Service Delivery Subsystem is defined by [SAM2] as a transport mechanism for SCSI commands and responses.
- 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: The "initiator". 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 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: 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. 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 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节点可通过一个或多个网络入口访问。iSCSI节点由其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 "target".
- iSCSI目标节点：“目标”。
- 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 initiator part of the Session Identifier. It is explicitly specified by the initiator during Login.
- 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,'+ 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，“+门户组标记）。
- 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 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: 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：目标通过以下方式之一检测到PDU中的一个或多个数据丢失时生成的R2T：摘要错误、序列错误或序列接收超时。恢复R2T携带下一个未使用的R2TSN，但请求先前R2T（具有较低R2TSN）已经请求的全部或部分数据突发。
- Responder: In a negotiation or exchange, the party that responds to the originator of the negotiation or exchange.
- 响应者：在谈判或交换中，响应谈判或交换发起人的一方。
- SCSI Device: This is the SAM2 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 logical units. 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设备：这是SAM2术语，表示包含一个或多个连接到服务交付子系统并支持SCSI应用程序协议的SCSI端口的实体。例如，SCSI启动器设备包含一个或多个SCSI启动器端口和零个或多个应用程序客户端。目标设备包含一个或多个SCSI目标端口、一个或多个设备服务器和相关逻辑单元。对于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 command execute [SAM2] parameters to/from the iSCSI Layer.
- SCSI层：该层构建/接收SCSI CDB（命令描述符块），并使用剩余的命令执行[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 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: This is the SAM2 term for an entity in a SCSI Device that provides the SCSI functionality to interface with a service delivery subsystem. For iSCSI, the definition of the SCSI Initiator Port and the SCSI Target Port are different.
- SCSI端口：这是SAM2术语，表示SCSI设备中提供SCSI功能以与服务交付子系统接口的实体。对于iSCSI，SCSI启动器端口和SCSI目标端口的定义不同。
- SCSI Port Name: A name made up as UTF-8 [RFC2279] characters and includes the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag.
- SCSI端口名称：由UTF-8[RFC2279]字符组成的名称，包括iSCSI名称+“i”或“t”+ISID或门户组标记。
- 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 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 when TargetName is given.
- SSID（会话ID）：iSCSI启动器和iSCSI目标之间的会话由会话ID定义，会话ID是由启动器部分（ISID）和目标部分（目标门户组标记）组成的元组。ISID由发起方在会话建立时明确指定。发起方通过在连接建立时选择TCP端点来暗示目标门户组标记。当给定TargetName时，目标还必须在连接建立期间返回TargetPortalGroupTag密钥作为确认。
- Target Portal Group Tag: A numerical identifier (16-bit) for an iSCSI Target Portal Group.
- 目标门户组标记：iSCSI目标门户组的数字标识符（16位）。
- TSIH (Target Session Identifying Handle): A target assigned tag for a session with a specific named initiator. The target generates it during session establishment. Its internal format and content are not defined by this protocol, except for the value 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（目标会话标识句柄）：为具有特定命名启动器的会话分配的目标标记。目标在会话建立期间生成它。该协议未定义其内部格式和内容，但启动器保留并用于指示新会话的值0除外。在同一会话的附加连接建立过程中，会将其提供给目标。
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
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
ESP Encapsulating Security Payload
EUI Extended Unique Identifier
FFP Full Feature Phase
FFPO Full Feature Phase Only
FIM Fixed Interval Marker
Gbps Gigabits per Second
HBA Host Bus Adapter
HMAC Hashed Message Authentication Code
I_T Initiator_Target
I_T_L Initiator_Target_LUN
IANA Internet Assigned Numbers Authority
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
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
ESP Encapsulating Security Payload
EUI Extended Unique Identifier
FFP Full Feature Phase
FFPO Full Feature Phase Only
FIM Fixed Interval Marker
Gbps Gigabits per Second
HBA Host Bus Adapter
HMAC Hashed Message Authentication Code
I_T Initiator_Target
I_T_L Initiator_Target_LUN
IANA Internet Assigned Numbers Authority
ID Identifier IDN Internationalized Domain Name IEEE Institute of Electrical & 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 ISID Initiator Session ID 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 Codes NA Not Applicable NIC Network Interface Card NOP No Operation NSG Next Stage OS Operating System 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 SAM SCSI Architecture Model SAM2 SCSI Architecture Model - 2 SAN Storage Area Network SCSI Small Computer Systems Interface SN Sequence Number SNACK Selective Negative Acknowledgment - also Sequence Number Acknowledgement for data SPKM Simple Public-Key Mechanism SRP Secure Remote Password SSID Session ID SW Session Wide TCB Task Control Block TCP Transmission Control Protocol TPGT Target Portal Group Tag TSIH Target Session Identifying Handle
ID标识符IDN国际化域名IEEE电气与电子工程师协会IETF互联网工程任务组IKE互联网密钥交换I/O输入-输出IO仅初始化IP互联网协议IPsec互联网协议安全IPv4互联网协议版本4 IPv6互联网协议版本6 IQN iSCSI限定名称ISID启动器会话ID ITN iSCSI目标名称ITT启动器任务标记KRB5 Kerberos V5 LFL较低功能层LTDS逻辑文本数据段LO仅前导LU逻辑单元LUN逻辑单元编号MAC消息身份验证代码NA不适用NIC网络接口卡NOP无操作NSG下一阶段操作系统PDU协议数据单元PKI公钥基础设施R2T准备传输R2TSN准备传输序列号RDMA远程直接内存访问RFC请求评论SAM SCSI体系结构模型SAM2 SCSI体系结构模型-2 SAN存储区域网络SCSI小型计算机系统接口SN序列号零食选择性否定确认-也数据序列号确认SPKM简单公钥机制SRP安全远程密码SSID会话ID SW会话范围TCB任务控制块TCP传输控制协议TPGT目标入口组标记TSIH目标会话标识句柄
TTT Target Transfer Tag UFL Upper Functional Layer ULP Upper Level Protocol URN Uniform Resource Names [RFC2396] UTF Universal Transformation Format WG Working Group
TTT目标传输标签UFL上层功能层ULP上层协议URN统一资源名称[RFC2396]UTF通用转换格式工作组
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 BCP 14 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
iSCSI messages - PDUs - are represented by diagrams as in the following example:
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) |
+---------------+---------------+---------------+---------------+
----------
+| |
+---------------+---------------+---------------+---------------+
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) |
+---------------+---------------+---------------+---------------+
----------
+| |
+---------------+---------------+---------------+---------------+
The diagrams include byte and bit numbering.
图表包括字节和位编号。
The following representation and ordering rules are observed in this document:
本文件遵循以下表述和订购规则：
- Word Rule - Half-word Rule - Byte Rule
- 字规则-半字规则-字节规则
A word holds four consecutive bytes. Whenever a word has numeric content, it is considered an unsigned number in base 2 positional representation with the lowest numbered byte (e.g., byte 0) bit 0 representing 2**31 and bit 1 representing 2**30 through lowest numbered byte + 3 (e.g., byte 3) bit 7 representing 2**0.
一个字包含四个连续的字节。当一个字有数字内容时，它被视为以2为基数的位置表示法中的无符号数，最低编号的字节（如字节0）位0表示2**31，位1表示2**30，最低编号的字节+3（如字节3）位7表示2**0。
Decimal and hexadecimal representation of word values map this representation to decimal or hexadecimal positional notation.
单词值的十进制和十六进制表示法将此表示法映射为十进制或十六进制位置表示法。
A half-word holds two consecutive bytes. Whenever a half-word has numeric content it is considered an unsigned number in base 2 positional representation with the lowest numbered byte (e.g., byte 0), bit 0 representing 2**15 and bit 1 representing 2**14 through lowest numbered byte + 1 (e.g., byte 1), bit 7 representing 2**0.
半个字包含两个连续字节。当半个字包含数字内容时，它被视为以2为基数的位置表示法中的无符号数，其编号最低的字节（如字节0），位0表示2**15，位1表示2**14到编号最低的字节+1（如字节1），位7表示2**0。
Decimal and hexadecimal representation of half-word values map this representation to decimal or hexadecimal positional notation.
半个字值的十进制和十六进制表示法将此表示法映射为十进制或十六进制位置表示法。
For every PDU, bytes are sent and received in increasing numbered order (network order).
对于每个PDU，字节以递增的编号顺序（网络顺序）发送和接收。
Whenever a byte has numerical content, it is considered an unsigned number in base 2 positional representation with bit 0 representing 2**7 and bit 1 representing 2**6 through bit 7 representing 2**0.
每当一个字节有数字内容时，它在基2位置表示中被视为无符号数，位0表示2**7，位1表示2**6，位7表示2**0。
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, logical units, of a server known as a "target". The "device server" on the logical unit accepts SCSI commands and processes them.
SCSI是一种客户机-服务器体系结构。SCSI接口的客户端称为“启动器”。启动器发出SCSI“命令”以从称为“目标”的服务器的组件、逻辑单元请求服务。逻辑单元上的“设备服务器”接受SCSI命令并对其进行处理。
A "SCSI transport" maps the client-server SCSI protocol to a specific interconnect. Initiators are one endpoint of a SCSI transport. The "target" is the other endpoint. A target can contain multiple Logical Units (LUs). Each Logical Unit 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
SCSI任务是一个SCSI命令，也可能是一组链接的SCSI命令。某些LU支持多个挂起（排队）任务，但
queue of tasks is managed by the logical unit. 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.
任务队列由逻辑单元管理。目标使用启动器提供的“任务标记”来区分任务。在任何给定时间，任务中只能有一条命令处于未完成状态。
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 target (e.g., WRITE), target to 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 (CDB) are the data structures used to contain the command parameters that an initiator sends to a target. The CDB content and structure is defined by [SAM2] and device-type specific SCSI standards.
命令描述符块（CDB）是用于包含启动器发送到目标的命令参数的数据结构。CDB内容和结构由[SAM2]和特定于设备类型的SCSI标准定义。
The iSCSI protocol is a mapping of the SCSI remote procedure invocation 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 Section 3.4.1 iSCSI Architecture Model) unless otherwise qualified.
对于本文档的其余部分，术语“启动器”和“目标”分别指“iSCSI启动器节点”和“iSCSI目标节点”（参见第3.4.1节iSCSI体系结构模型），除非另有限定。
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:
以下概念分层模型用于指定启动器和目标操作，以及它们与传输和接收的协议数据单元的关联方式：
a) the SCSI layer builds/receives SCSI CDBs (Command Descriptor Blocks) and passes/receives them with the remaining command execute parameters ([SAM2]) to/from
a) SCSI层构建/接收SCSI CDB（命令描述符块），并将它们与剩余的命令执行参数（[SAM2]）一起传递/接收到/从中传递
b) 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".
b) 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 (loosely equivalent to a SCSI I_T nexus, see Section 3.4.2 SCSI Architecture Model). 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，请参见第3.4.2节SCSI体系结构模型）。会话由会话ID定义，会话ID由启动器部分和目标部分组成。可以在会话中添加和删除TCP连接。会话中的每个连接都由连接ID（CID）标识。
Across all connections within a session, an initiator sees one "target image". All target identifying elements, such as 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/In PDUs may be utilized to synchronize the command and status ordering counters of the target and initiator.
通常，iSCSI PDU中的字段在启动器和目标之间传递序列号。在连接上的通信量是单向的期间，iSCSI NOP Out/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 [CORD].
iSCSI会话抽象相当于SCSI I_T nexus，iSCSI会话提供从SCSI启动器到SCSI目标的有序命令传递。有关导致此处定义的iSCSI会话模型的详细设计考虑事项，以及如何将SCSI规范中定义的SCSI命令排序功能与iSCSI概念联系起来，请参见[CORD]。
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 10.5 Task Management Function Request) may be performed on any iSCSI task.
iSCSI考虑在目标上实例化一个任务，以响应启动器发出的每个请求。可以对任何iSCSI任务执行一组任务管理操作，包括中止和重新分配（请参阅第10.5节任务管理功能请求）。
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 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 CmdSN 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. CmdSN does 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 command numbers are incremented by 1 for every non-immediate command issued afterwards.
命令编号从会话的第一个连接上的第一个登录请求（主要连接上的主要登录）开始，之后发出的每个非立即命令的命令编号都增加1。
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 task management commands act as specified by [SAM2]. For example, both commands and responses appear as if delivered in order. Whenever CmdSN for an outgoing PDU is not specified by an explicit rule, CmdSN will carry the current value of the local CmdSN variable (see later in this section).
如果即时交付与任务管理命令一起使用，则这些命令可能会在其应执行的任务之前到达目标。但是，它们的CmdSN可以作为它们在命令流中位置的标记。发起者和目标必须确保任务管理命令按照[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 for execution is not acknowledged through the numbering scheme. Immediate commands MAY be rejected by the iSCSI target layer due to a lack of resources. 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 CmdSN. Commands marked for immediate delivery may be delivered by 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., CLEAR TASK SET Task Management request received before all the commands on which it was supposed to act).
在本文档中，交付执行是指交付到SCSI执行引擎或特定于iSCSI协议的执行引擎（例如，对于具有涉及执行组件的公共或私有扩展密钥的文本请求）。除标记为立即传递的命令外，iSCSI目标层必须按照CmdSN指定的顺序传递要执行的命令。标记为立即传递的命令可由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. CmdSN always contains the number to be assigned to the next Command 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 CmdSN less than ExpCmdSN as acknowledged. The target iSCSI layer sets the ExpCmdSN to the largest non-immediate CmdSN that it can deliver for execution plus 1 (no holes in the CmdSN sequence). - MaxCmdSN - the maximum number to be shipped. The queuing capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1.
- CmdSN—当前命令序列号，除标记为立即传递的命令外，在每个已发出的命令上前进1。CmdSN始终包含要分配给下一个命令PDU的编号。-ExpCmdSN—目标所需的下一个命令。目标确认所有达到但不包括此数字的命令。启动器将CmdSN小于ExpCmdSN的所有命令视为已确认。目标iSCSI层将ExpCmdSN设置为其可交付执行的最大非即时CmdSN加1（CmdSN序列中无孔）。-MaxCmdSN-要装运的最大数量。接收iSCSI层的队列容量为MaxCmdSN-ExpCmdSN+1。
The initiator's ExpCmdSN and MaxCmdSN are derived from target-to-initiator PDU fields. Comparisons and arithmetic on 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 ExpCmdSN to 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 MaxCmdSN, the target window is closed. For group task management commands issued as immediate commands, CmdSN indicates the scope of the group action (e.g., on ABORT TASK SET indicates which commands are aborted).
目标不能传输小于ExpCmdSN-1的MaxCmdSN。对于非立即命令，CmdSN字段可以采用ExpCmdSN到MaxCmdSN（包括ExpCmdSN）之间的任何值。目标必须以静默方式忽略此范围之外的任何非即时命令或该范围内的非即时重复命令。即时命令携带的CmdSN可能位于ExpCmdSN到MaxCmdSN范围之外。例如，如果启动器先前发送了一个非即时命令，该命令中的CmdSN等于MaxCmdSN，则目标窗口将关闭。对于作为即时命令发出的组任务管理命令，CmdSN表示组操作的范围（例如，on ABORT task SET表示中止了哪些命令）。
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 Serial Arithmetic Sense), they are both ignored. - If the PDU MaxCmdSN is greater than the local MaxCmdSN (in Serial Arithmetic Sense), it updates the local MaxCmdSN; otherwise, it is ignored. - If the PDU ExpCmdSN is greater than the local ExpCmdSN (in Serial Arithmetic Sense), it updates the local ExpCmdSN; otherwise, it is ignored.
- 如果PDU MaxCmdSN小于PDU ExpCmdSN-1（在串行算术意义上），则它们都将被忽略。-如果PDU MaxCmdSN大于本地MaxCmdSN（串行算术意义），则更新本地MaxCmdSN；否则，它将被忽略如果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 6.2.1 Usage of Retry). At the target, CmdSN is only relevant when the command has not created any state related to its execution (execution state); afterwards, 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.
已编号的iSCSI请求不会更改其分配的CmdSN，无论其重新发出的次数和情况如何（请参阅第6.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 the connection is no longer operational (i.e., it has returned to the FREE state, see Section 7.1.3 Standard Connection State Diagram for an Initiator), the connection has been reinstated (see Section 5.3.4 Connection Reinstatement), or a non-immediate command with CmdSN equal 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 9.4 Command Retry and Cleaning Old Command Instances).
如果当会话CmdSN值为Q时，发起程序在连接上发出命令重试命令，则除非连接不再可操作（即，它已返回自由状态，请参阅第7.1.3节发起程序的标准连接状态图），否则不得将CmdSN提前超过R+2**31-1，连接已恢复（请参阅第5.3.4节连接恢复），或者在同一连接上执行命令重试后，发出了CmdSN等于或大于Q的非即时命令，并且目标确认收到该命令（请参阅第9.4节命令重试和清除旧命令实例）。
A target MUST NOT issue a command response or Data-In PDU with status before acknowledging the command. However, the acknowledgement can be included in the response or 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. StatSN is a counter maintained per connection. 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 ExpStatSN.
要启用命令恢复，目标可能会保留足够的状态信息，以便在连接失败后恢复数据和状态。在通过ExpStatSN确认命令（编号为StatSN）的状态传递后，这样做的目标可以安全地放弃为恢复命令而维护的所有状态信息。
A large absolute difference between StatSN and ExpStatSN may indicate a failed connection. Initiators MUST undertake recovery actions if
StatSN和ExpStatSN之间的绝对差值较大可能表示连接失败。发起人必须在以下情况下采取恢复行动：
the difference is greater than an implementation defined constant that MUST NOT exceed 2**31-1.
差值大于实现定义的常量，该常量不得超过2**31-1。
Initiators and Targets MUST support the response-numbering scheme.
启动器和目标必须支持响应编号方案。
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, 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, 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，DataSN前进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。
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 3.4.2 SCSI Architecture Model).
会话用于向目标标识与给定启动器之间属于同一I_T nexus的所有连接。（有关会话如何与I_T nexus关联的更多详细信息，请参阅第3.4.2节SCSI体系结构模型）。
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.
作为登录过程的一部分，启动器和目标应相互验证，并可为会话设置安全关联协议。这可能以许多不同的方式发生，并有待协商。
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 Chapter 8 and [RFC3723].
为了保护TCP连接，可以在登录请求之前建立IPsec安全关联。有关将IPsec安全性用于iSCSI的信息，请参阅第8章和[RFC3723]。
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 Chapter 5.
iSCSI登录阶段通过登录请求和响应进行。一旦进行了适当的身份验证并设置了操作参数，会话将过渡到完整功能阶段，启动器可能会开始发送SCSI命令。目标是否以及通过何种方式选择授权启动器的安全策略超出了本文档的范围。有关登录阶段的更详细说明，请参阅第5章。
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 portal group tag (see Section 3.4.1 iSCSI Architecture Model). ISID is subject to reuse restrictions because it is used to identify a persistent state (see Section 3.4.3 Consequences of the Model).
在会话建立期间，目标通过值对（InitiatorName，ISID）标识SCSI启动器端口（“I_T nexus”中的“I”）。我们将在本节后面介绍InitiatorName。目标上与SCSI启动器端口关联的任何持久状态（例如，持久保留）都基于此值对进行标识。与SCSI目标端口（“I_T nexus”中的“T”）关联的任何状态都由TargetName和portal group标记在外部标识（请参见第3.4.1节iSCSI体系结构模型）。ISID受重用限制，因为它用于标识持久状态（见第3.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 a 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 initiator is authorized to do so, the iSCSI session is in the iSCSI Full Feature Phase. A session is in Full Feature Phase after successfully finishing the Login Phase on the first (leading)
一旦授权启动器执行此操作，iSCSI会话将处于iSCSI完整功能阶段。在成功完成第一个登录阶段后，会话处于全功能阶段（领先）
connection of a session. A connection is in Full Feature Phase if the session is in Full Feature Phase and the connection login has completed successfully. An iSCSI connection is not in Full Feature Phase
会话的连接。如果会话处于全功能阶段并且连接登录已成功完成，则连接处于全功能阶段。iSCSI连接未处于全功能阶段
a) when it does not have an established transport connection,
a) 当它没有已建立的传输连接时，
OR
或
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 6.2 Retry and Reassign in Recovery.
对于通过TCP连接发出的任何iSCSI请求，必须通过同一连接发送相应的响应和/或其他相关PDU。我们称之为“连接忠诚”。如果原始连接在命令完成之前失败，则可以按照第6.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 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序列中或同时以两种方式立即发送长度不超过FirstBurstLength（不超过协商的最大PDU长度）的未经请求的数据。必须征求所有后续数据。单个数据PDU的最大长度或第一个未经请求的突发的直接部分可以在登录时协商。
The maximum amount of unsolicited data that can be sent with a command is negotiated at login through the FirstBurstLength 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键协商。目标可以单独启用即时数据（通过ImmediateData键），而不启用更通用（单独数据PDU）形式的非请求数据（通过InitialR2T键）。
Unsolicited data on 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 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 part, outside of the bounds of the command.
发起者必须对有效的未完成命令（即，携带有效的发起者任务标记）执行R2T数据请求，并交付所有请求的数据，前提是该命令应交付传出数据，并且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. These mechanisms are designed to accomplish efficient data delivery along with a large degree of control over the data flow.
挂起命令的启动器标记在会话的启动器范围内是唯一的。协议没有严格指定目标标记。假设目标使用目标标记（单独或与LUN组合）标记请求的数据。目标标记由目标生成，并由启动器“回显”。这些机制旨在实现高效的数据交付以及对数据流的高度控制。
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 solely based 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
SCSI任务管理假定单个任务和任务组可以仅基于任务标记（针对单个任务）或任务管理命令的计时（针对任务组）中止，并且任务管理操作是同步执行的，即。，SCSI启动器在收到任务管理响应后，不会看到任何涉及中止任务的消息。在iSCSI启动器中
and targets interact asynchronously over several connections. iSCSI specifies the protocol mechanism and implementation requirements needed to present a synchronous view while using an asynchronous infrastructure.
和目标通过多个连接异步交互。iSCSI指定在使用异步基础架构时显示同步视图所需的协议机制和实现要求。
An iSCSI connection may be terminated by use of a transport connection shutdown or a transport reset. 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 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 Full Feature Phase, connection cleanup (see section 7) is required prior to recovery. By doing connection cleanup before starting recovery, the initiator and target will avoid receiving stale PDUs after recovery.
如果在全功能阶段终止连接，则需要在恢复之前进行连接清理（参见第7节）。通过在开始恢复之前进行连接清理，启动器和目标将避免在恢复后接收过时的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 of an iSCSI device. 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 operational domain of the end user. However, because the operational 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 two 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 3.4.2 SCSI Architecture Model for the definition of the SCSI port name/identifier for iSCSI ports.
某些SCSI命令要求在SCSI CDB内通信特定于协议的标识符。有关iSCSI端口的SCSI端口名称/标识符的定义，请参阅第3.4.2节SCSI体系结构模型。
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目标名称及其地址。
Each iSCSI node, whether an initiator or target, MUST have an iSCSI name.
每个iSCSI节点（无论是启动器还是目标）都必须具有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 2.3 iSCSI Session Types) is to be established. In this case, the iSCSI Initiator Name is still required, but the iSCSI Target Name MAY be omitted.
启动器必须在新会话或连接的第一个登录请求中同时显示其iSCSI启动器名称和要连接的iSCSI目标名称。唯一的例外情况是，如果要建立发现会话（请参阅第2.3节iSCSI会话类型）。在这种情况下，仍然需要iSCSI启动器名称，但可以省略iSCSI目标名称。
iSCSI names have the following properties:
iSCSI名称具有以下属性：
a) iSCSI names are globally unique. No two initiators or targets can have the same name. b) iSCSI names are permanent. An iSCSI initiator node or target node has the same name for its lifetime. c) 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. d) iSCSI names do not rely on a central name broker; the naming authority is distributed. e) iSCSI names support integration with existing unique naming schemes. f) iSCSI names rely on existing naming authorities. iSCSI does not create any new naming authority.
a) iSCSI名称是全局唯一的。两个启动器或目标不能具有相同的名称。b） iSCSI名称是永久的。iSCSI启动器节点或目标节点在其生存期内具有相同的名称。c） iSCSI名称并不表示位置或地址。iSCSI启动器或目标可以移动，也可以有多个地址。地址的改变并不意味着姓名的改变。d） iSCSI名称不依赖于中央名称代理；命名权限是分布式的。e） iSCSI名称支持与现有唯一命名方案的集成。f） iSCSI名称依赖于现有的命名机构。iSCSI不会创建任何新的命名机构。
The encoding of an iSCSI name has the following properties:
iSCSI名称的编码具有以下属性：
a) iSCSI names have the same encoding method regardless of the underlying protocols. b) iSCSI names are relatively simple to compare. The algorithm for comparing two iSCSI names for equivalence does not rely on an external server.
a) 无论底层协议如何，iSCSI名称都具有相同的编码方法。b） iSCSI名称比较起来相对简单。比较两个iSCSI名称是否等效的算法不依赖于外部服务器。
c) iSCSI names are composed only of displayable characters. iSCSI names allow the use of international character sets but are not case sensitive. No whitespace characters are used in iSCSI names. d) iSCSI names may be transported using both binary and ASCII-based protocols.
c) iSCSI名称仅由可显示字符组成。iSCSI名称允许使用国际字符集，但不区分大小写。iSCSI名称中不使用空格字符。d） 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 (URN) [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 encoding of a string of Unicode characters with the following properties:
iSCSI名称必须是具有以下属性的Unicode字符字符串的UTF-8编码：
- It is in Normalization Form C (see "Unicode Normalization Forms" [UNICODE]). - It only contains characters allowed by the output of the iSCSI stringprep template (described in [RFC3722]). - The following characters are used for formatting iSCSI names:
- 它是标准化形式C（参见“Unicode标准化形式”[Unicode]）-它仅包含iSCSI stringprep模板输出所允许的字符（如[RFC3722]中所述）以下字符用于格式化iSCSI名称：
- dash ('-'=U+002d) - dot ('.'=U+002e) - colon (':'=U+003a)
- 破折号（'-'=U+002d）-点（'.'=U+002e）-冒号（':'=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]. Stringprep 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. Strings MUST NOT include punctuation, spacing, diacritical marks, or other characters that could get in the way of readability. The stringprep process also converts strings into equivalent strings of lower-case characters.
[RFC3454]中描述了stringprep过程；[RFC3722]中描述了iSCSI对stringprep过程的使用。Stringprep是由国际化域名（IDN）工作组设计的一种方法，用于将人工输入的字符串转换为可作为不透明字符串进行比较的格式。字符串不得包含标点、空格、变音符号或其他可能影响可读性的字符。stringprep进程还将字符串转换为小写字符的等效字符串。
The stringprep process does not need to be implemented if the names are only generated using numeric and lower-case (any character set) alphabetic characters.
如果名称仅使用数字和小写（任何字符集）字母字符生成，则不需要实现stringprep过程。
Once iSCSI names encoded in UTF-8 are "normalized" they may be safely compared byte-for-byte.
一旦UTF-8中编码的iSCSI名称“规范化”，就可以安全地逐字节比较它们。
An iSCSI name consists of two parts--a type designator followed by a unique name string.
iSCSI名称由两部分组成——一个类型指示符，后跟一个唯一的名称字符串。
The iSCSI name does not define any new naming authorities. Instead, it supports two existing ways of designating naming authorities: an iSCSI-Qualified Name, using domain names to identify a naming authority, and the EUI format, where the IEEE Registration Authority assists in the formation of worldwide unique names (EUI-64 format).
iSCSI名称未定义任何新的命名权限。相反，它支持两种指定命名机构的现有方式：iSCSI限定名称（使用域名来标识命名机构）和EUI格式（其中IEEE注册机构协助形成全球唯一名称）（EUI-64格式）。
The type designator strings currently defined are:
当前定义的类型指示符字符串为：
iqn. - iSCSI Qualified name eui. - Remainder of the string is an IEEE EUI-64 identifier, in ASCII-encoded hexadecimal.
iqn-iSCSI限定名称eui。-字符串的其余部分是IEEE EUI-64标识符，采用ASCII编码的十六进制。
These two 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中详细说明。
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 be active, and 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. For this reason, a date code is provided as part of the "iqn." format.
由于域名可能会过期、被另一个实体获取，或者可能被两个所有者用于生成iSCSI名称，因此必须在命名机构拥有该域名的日期之前对该域名进行附加限定。因此，日期代码作为“iqn.”格式的一部分提供。
The iSCSI qualified name string consists of:
iSCSI限定名称字符串包括：
- The string "iqn.", used to distinguish these names from "eui." formatted names. - 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. - A dot "." - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. - 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 reversed 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".
- 字符串“iqn.”，用于区分这些名称与“eui.”格式的名称。-日期代码，yyyy-mm格式。此日期必须是命名机构拥有此格式中使用的域名的日期，并且应该是该命名机构在该月第一天00:01 GMT拥有域名的第一个月。此日期代码使用公历。年份中的所有四位数字都必须存在。月份的两个数字都必须存在，一月==“01”和十二月==“12”。破折号必须包括在内点“.”-创建此iSCSI名称的命名机构（个人或组织）的反向域名。-域名所有者认为合适的字符集和长度边界内的可选冒号（：）前缀字符串。这可能包含产品类型、序列号、主机标识符或软件密钥（例如，它可能包括分隔组织边界的冒号）。除冒号前缀外，域名所有者可以根据需要分配反转域名后的所有内容。作为命名机构的实体有责任确保其分配的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]中讨论了名称构造的更多示例。
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 Section 3.4.2 SCSI Architecture Model and Section 3.4.3 Consequences of the Model).
iSCSI不需要跨会话进行任何持久状态维护。但是，在某些情况下，SCSI需要持久标识SCSI启动器端口名（请参阅第3.4.2节SCSI体系结构模型和第3.4.3节模型的后果）。
iSCSI sessions do not persist through power cycles and boot operations.
iSCSI会话不会在电源循环和引导操作期间保持不变。
All iSCSI session and connection parameters are re-initialized upon 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 10.5 Task Management Function Request.)
如果会话持续存在并且支持会话内的命令恢复，则命令将在连接终止后继续存在。但是，当连接断开时，iSCSI感知到的命令执行（即涉及受影响任务的iSCSI协议交换）将暂停，直到“任务重新分配”任务管理功能建立新的忠诚。（参见第10.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, upon which 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 pre-allocated 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. To make these schemes work, iSCSI implementations have to make sure that the appropriate protocol layers are provided with enough information to implement a synchronization and/or data steering mechanism. One of these schemes is detailed in Appendix A. - Sync and Steering with Fixed Interval Markers -.
可以使用不同的方案来恢复同步。要使这些方案发挥作用，iSCSI实施必须确保为适当的协议层提供足够的信息，以实现同步和/或数据控制机制。附录A中详细介绍了其中一种方案-使用固定间隔标记进行同步和转向-。
The Fixed Interval Markers (FIM) scheme works by inserting markers in the payload stream at fixed intervals that contain the offset for the start of the next iSCSI PDU.
固定间隔标记（FIM）方案通过以固定间隔在有效负载流中插入标记来工作，该标记包含下一个iSCSI PDU开始的偏移量。
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
在正常情况下（没有PDU丢失或数据接收出现故障），除了使用TCP报头中的TCP序列号外，还可以使用iSCSI报头中的标识标签和数据偏移字段来完成iSCSI数据引导。这个
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与SCSI缓冲区地址关联，同时使用数据偏移量和TCP序列号确定缓冲区内的偏移量。
When the part of the TCP data stream containing an iSCSI PDU header is delayed or lost, markers may be used to minimize the damage as follows:
当包含iSCSI PDU标头的TCP数据流部分延迟或丢失时，可使用标记将损坏降至最低，如下所示：
- Markers indicate where the next iSCSI PDU starts and enable continued processing when iSCSI headers have to be dropped due to data errors discovered at the iSCSI level (e.g., iSCSI header CRC errors).
- 标记指示下一个iSCSI PDU的启动位置，并在由于在iSCSI级别发现的数据错误（例如，iSCSI标头CRC错误）而必须删除iSCSI标头时启用继续处理。
- Markers help minimize the amount of data that has to be kept by the TCP/iSCSI layer while waiting for a late TCP packet arrival or recovery, because later they might help find iSCSI PDU headers and use the information contained in those to steer data to SCSI buffers.
- 标记有助于最大限度地减少TCP/iSCSI层在等待TCP数据包延迟到达或恢复时必须保留的数据量，因为稍后它们可能有助于查找iSCSI PDU头并使用其中包含的信息将数据引导到SCSI缓冲区。
When a large iSCSI message is sent, the TCP segment(s) that contain 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段可能会丢失。剩余的TCP段（直到下一条iSCSI消息）必须进行缓冲（在临时缓冲区中），因为指示数据将被引导到哪个SCSI缓冲区的iSCSI标头已丢失。为了最大限度地减少缓冲量，建议将iSCSI PDU长度限制为一个较小的值（长度可能为几个TCP段）。在登录期间，iSCSI会话的每一端都指定它将接受的最大iSCSI PDU长度。
iSCSI defines two types of sessions:
iSCSI定义了两种类型的会话：
a) Normal operational session - an unrestricted session. 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 the reason "close the session". All other requests MUST be rejected.
a) 正常操作会话-非限制会话。b） 发现会话-仅为目标发现而打开的会话。目标必须只接受带有SendTargets键的文本请求和带有“关闭会话”原因的注销请求。必须拒绝所有其他请求。
The session type is defined during login with the key=value parameter in the login command.
会话类型是在登录期间使用login命令中的key=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 3.4.1 iSCSI Architecture Model.
下图显示了多个iSCSI节点（本例中的目标）如何在同一网络实体内共存并共享网络入口（IP地址和TCP端口）的示例。其他更复杂的配置也是可能的。有关这些关系图组件的详细说明，请参阅第3.4.1节iSCSI体系结构模型。
+-----------------------------------+
| Network Entity (iSCSI Client) |
| |
| +-------------+ |
| | iSCSI Node | |
| | (Initiator) | |
| +-------------+ |
| | | |
| +--------------+ +--------------+ |
| |Network Portal| |Network Portal| |
| | 10.1.30.4 | | 10.1.40.6 | |
+-+--------------+-+--------------+-+
| |
| IP Networks |
| |
+-+--------------+-+--------------+-+
| |Network Portal| |Network Portal| |
| | 10.1.30.21 | | 10.1.40.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| |
| | 10.1.30.4 | | 10.1.40.6 | |
+-+--------------+-+--------------+-+
| |
| IP Networks |
| |
+-+--------------+-+--------------+-+
| |Network Portal| |Network Portal| |
| | 10.1.30.21 | | 10.1.40.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体系结构模型之间的关系最为相关的部分。
a) 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 item d), each of which can be used by some iSCSI Nodes (see item (b)) contained in that Network Entity to gain access to the IP network.
a) 网络实体-表示可从IP网络访问的设备或网关。网络实体必须具有一个或多个网络入口（请参见项目d），该网络实体中包含的某些iSCSI节点（请参见项目（b））可以使用每个入口访问IP网络。
b) iSCSI Node - represents a single iSCSI initiator or iSCSI target. There are one or more iSCSI Nodes within a Network Entity. The iSCSI Node is accessible via one or more Network Portals (see item d). An iSCSI Node is identified by its iSCSI Name (see Section 3.2.6 iSCSI Names and Chapter 12). 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 the same iSCSI node to use multiple addresses.
b) iSCSI节点—表示单个iSCSI启动器或iSCSI目标。网络实体中有一个或多个iSCSI节点。iSCSI节点可通过一个或多个网络入口访问（请参见项目d）。iSCSI节点由其iSCSI名称标识（请参阅第3.2.6节iSCSI名称和第12章）。将iSCSI名称与iSCSI节点使用的地址分离，允许多个iSCSI节点使用相同的地址，而同一iSCSI节点可以使用多个地址。
c) 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.
c) 别名字符串也可能与iSCSI节点关联。别名允许组织将用户友好的字符串与iSCSI名称关联。但是，别名字符串不能替代iSCSI名称。
d) 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.
d) 网络入口—具有TCP/IP网络地址的网络实体的一个组件，该网络实体内的iSCSI节点可将该组件用于其一个iSCSI会话内的连接。在启动器中，它由其IP地址标识。在目标中，它由其IP地址和侦听TCP端口标识。
e) 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 Section 12.3 SendTargets). All Network Portals with the same portal group tag in the context of a given iSCSI Node are in the same Portal Group.
e) 门户组—iSCSI支持同一会话中的多个连接；一些实现将能够在跨多个网络门户的会话中组合连接。门户组定义了iSCSI节点内的一组网络门户，这些门户共同支持通过跨这些门户的连接协调会话的功能。并非门户组中的所有网络门户都需要参与通过该门户组连接的每个会话。一个或多个门户组可以提供对iSCSI节点的访问。给定iSCSI节点使用的每个网络入口都只属于该节点内的一个入口组。iSCSI节点内的入口组由入口组标记标识，入口组标记是一个介于0和65535之间的简单无符号整数（请参阅第12.3节SendTargets）。给定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 9.1.1 Conservative Reuse of ISIDs.
iSCSI启动器和iSCSI目标都有入口组，但只有iSCSI目标入口组直接用于iSCSI协议（例如，在SendTargets中）。有关启动器门户组的参考，请参阅第9.1.1节ISID的保守重用。
f) Portals within a Portal Group should support similar session parameters, because they may participate in a common session.
f) 门户组中的门户应支持类似的会话参数，因为它们可能参与公共会话。
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 the constructs of the SCSI device, SCSI port and I_T nexus, and the iSCSI constructs described in Section 3.4.1 iSCSI Architecture Model.
本节介绍SCSI体系结构模型[SAM2]与SCSI设备、SCSI端口和I_T nexus的结构之间的关系，以及第3.4.1节iSCSI体系结构模型中描述的iSCSI结构。
This relationship implies implementation requirements in order to conform to the SAM2 model and other SCSI operational functions. These requirements are detailed in Section 3.4.3 Consequences of the Model.
这种关系意味着实现要求，以符合SAM2模型和其他SCSI操作功能。这些要求详见第3.4.3节“模型的后果”。
The following list outlines mappings of SCSI architectural elements to iSCSI.
以下列表概述了SCSI体系结构元素到iSCSI的映射。
a) SCSI Device - the SAM2 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 logical units. For iSCSI, the SCSI Device is the component within an iSCSI Node that provides the SCSI functionality. As such, there can be one SCSI Device, at most, within an iSCSI Node. Access to the SCSI Device can only be achieved in an iSCSI normal operational session (see Section 3.3 iSCSI Session Types). The SCSI Device Name is defined to be the iSCSI Name of the node and MUST be used in the iSCSI protocol.
a) SCSI设备—SAM2术语，表示包含一个或多个连接到服务交付子系统并支持SCSI应用程序协议的SCSI端口的实体。例如，SCSI启动器设备包含一个或多个SCSI启动器端口和零个或多个应用程序客户端。SCSI目标设备包含一个或多个SCSI目标端口和一个或多个逻辑单元。对于iSCSI，SCSI设备是iSCSI节点中提供SCSI功能的组件。因此，iSCSI节点内最多只能有一个SCSI设备。只能在iSCSI正常操作会话中访问SCSI设备（请参阅第3.3节iSCSI会话类型）。SCSI设备名称定义为节点的iSCSI名称，必须在iSCSI协议中使用。
b) SCSI Port - the SAM2 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 definition of SCSI Initiator Port and SCSI Target Port are different.
b) SCSI端口—SCSI设备中的实体的SAM2术语，该设备提供SCSI功能以与服务交付子系统或传输接口。对于iSCSI，SCSI启动器端口和SCSI目标端口的定义不同。
SCSI Initiator Port: This maps to one endpoint of an iSCSI normal operational session (see Section 3.3 iSCSI Session Types). 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正常操作会话的一个端点（请参阅第3.3节iSCSI会话类型）。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 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: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' (for SCSI Initiator Port) or the ASCII character 't' (for SCSI Target Port) (1 byte), followed by
iSCSI中必须使用SCSI端口名。在SCSI参数数据中使用时，SCSI端口名称必须编码为：-UTF-8格式的iSCSI名称，后跟-逗号分隔符（1字节），后跟-ASCII字符“i”（用于SCSI启动器端口）或ASCII字符“t”（用于SCSI目标端口）（1字节），后跟
- a comma separator (1 byte), followed by - a text encoding as a hex-constant (see Section 5.1 Text Format) of the ISID (for SCSI initiator port) or the portal group tag (for SCSI target port) including the initial 0X or 0x and the terminating null (15 bytes).
- 逗号分隔符（1字节），后跟-一个文本编码，作为ISID（用于SCSI启动器端口）或入口组标记（用于SCSI目标端口）的十六进制常量（参见第5.1节文本格式），包括初始0X或0X以及终止null（15字节）。
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 - 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' + ISID, iSCSI Target Name + 't' + Portal Group Tag).
c) I_T nexus-根据[SAM2]，SCSI启动器端口和SCSI目标端口之间的关系。对于iSCSI，此关系是一个会话，定义为iSCSI启动器的会话结束（SCSI启动器端口）与iSCSI目标的入口组之间的关系。I_T nexus可以通过SCSI端口名的连接或iSCSI会话标识符SSID来识别。iSCSI将I_T nexus标识符定义为元组（iSCSI启动器名称+I'+ISID，iSCSI目标名称+T'+门户组标记）。
NOTE: The I_T nexus identifier is not equal to the session identifier (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 can exist between a given iSCSI initiator node and an iSCSI target node, with the same session identifier (SSID).
本节描述了将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 ISID that identifies the SCSI initiator port. See Section 10.12.5 ISID.
ISID规则：在给定的iSCSI启动器和iSCSI目标门户组（SCSI目标端口）之间，只有一个会话具有标识SCSI启动器端口的给定ISID值。见第10.12.5节ISID。
The structure of the ISID that contains a naming authority component (see Section 10.12.5 ISID and [RFC3721]) provides a mechanism to facilitate compliance with the ISID rule. (See Section 9.1.1 Conservative Reuse of ISIDs.)
包含命名机构组件的ISID结构（见第10.12.5节ISID和[RFC3721]）提供了一种机制，以促进遵守ISID规则。（参见第9.1.1节ISID的保守再利用。）
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 9.1.1 Conservative Reuse of ISIDs). 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以及不同的目标门户组（请参阅第9.1.1节ISID的保守重用）。允许这样做类似于单个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 nexus with the same identifier should never exist at the same time.
注：ISID规则和I_T nexus标识符规范的一个结果是，具有相同标识符的两个Nexu不应同时存在。
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 logical unit 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 perform session recovery as described in Chapter 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 logical unit device server uses to identify the I_T nexus.
某些nexus关系包含一个显式状态（例如，特定于启动器的模式页面），该状态可能需要通过iSCSI层中的更改或故障（例如，会话故障）由逻辑单元中的设备服务器[SAM2]保留。为了恢复该状态，iSCSI启动器应使用以前的ISID重新建立其到同一目标门户组的会话（重新登录）。也就是说，它应该按照第6章所述执行会话恢复。这是因为SCSI启动器端口标识符和SCSI目标端口标识符（或相对目标端口）构成SCSI逻辑单元设备服务器用于标识I_T连接的数据。
This section lists and briefly describes all the iSCSI PDU types (request 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 procedure call (see [SAM2]) IN arguments such as task attributes, Expected Data Transfer Length for one or both transfer directions (the latter for bidirectional commands), and 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.
此请求在诸如任务属性、一个或两个传输方向的预期数据传输长度（后者用于双向命令）和任务标记（作为I_T_L_x nexus的一部分）等参数中携带SCSI CDB和所有其他SCSI execute命令过程调用（请参见[SAM2]）。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) for the session and the expected status number (ExpStatSN) for the connection.
此外，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协议所需的信息：
- The number of Data-In PDUs that a target has sent (to enable the initiator to check that all have arrived). - StatSN - the Status Sequence Number on this connection.
- 目标已发送的PDU中的数据数（以使启动器能够检查所有数据是否已到达）。-StatSN—此连接上的状态序列号。
- ExpCmdSN - the next Expected Command Sequence Number at the target. - MaxCmdSN - the maximum CmdSN acceptable at the target from this initiator.
- ExpCmdSN-目标处的下一个预期命令序列号。-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 (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 was completed (response and qualifier) and additional information for failure responses.
任务管理功能响应包含任务管理功能请求的功能完成指示，包括如何完成（响应和限定符）以及故障响应的附加信息。
After the Task Management 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 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
SCSI数据输出和SCSI数据输入是SCSI数据有效负载在启动器和目标之间传输的主要载体。数据有效负载通过启动器任务标记与特定SCSI命令相关联。为方便目标，传出请求的数据还带有
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.
目标传输标记（从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 are built to enable the direction switching for bidirectional commands.
构建输入序列以启用双向命令的方向切换。
For input, the target may request positive acknowledgement 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, 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) - StatSN - ExpCmdSN - MaxCmdSN
- R2TSN（使启动器能够检测缺失的R2T）-StatSN-ExpCmdSN-MaxCmdSN
Asynchronous Messages are used to carry SCSI asynchronous events (AEN) and iSCSI asynchronous messages.
异步消息用于承载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 Request/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 (Final) flag bit in the text response header to indicate its consent to sequence termination.
文本请求/响应可以使用相同的启动器任务标记形成扩展序列。发起者使用文本请求头中的F（Final）标志位指示其准备终止序列。目标使用文本响应头中的F（最终）标志位表示其同意序列终止。
Text Request 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) 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），后者的外观由“传输”标志（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初始值也由主要登录名设置。
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 initiators 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 text key Time2Retain and how long the initiator must wait before proceeding with recovery in the text key Time2Wait.
在文本键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 acknowledgement 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 acknowledgement.
通过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 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.
该请求/响应对可由发起方和目标方用作“ping”机制，以验证连接/会话是否仍然处于活动状态以及其所有组件是否可操作。这种ping可由发起方或目标方触发。触发方通过在相应的启动器/目标传输标记中设置不同于默认0xffffffff的值来指示它想要应答。
NOP-In/NOP-Out may also be used "unidirectional" 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 3.2.3 iSCSI Login) and during the Full Feature Phase (Section 3.2.4 iSCSI Full Feature Phase) by using Text Requests and Responses. In
iSCSI参数在会话或连接建立时通过使用登录请求和响应（请参阅第3.2.3节iSCSI登录）进行协商，在完整功能阶段（第3.2.4节iSCSI完整功能阶段）通过使用文本请求和响应进行协商。在里面
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文本键=值对的交换。为简洁起见，在本文档的其余部分中，iSCSI文本键仅称为键。
Keys are either declarative or require negotiation and the key description indicates if the key is declarative or requires negotiation.
密钥是声明性的或需要协商的，并且密钥描述指示该密钥是声明性的还是需要协商的。
For the declarative keys, the declaring party sets a value for the key. The key specification indicates if the key can be declared by the initiator, 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 PDUs. 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 one of the following Login or Text Response or Request PDUs. For most of the keys both the initiator and target can be proposing parties.
对于需要协商的密钥，其中一方（提议方）通过在登录或文本请求或响应PDU的数据部分中包含key=值来提议一个或一组值。另一方（接受方）根据提议的值或值列表进行选择，并将所选值包含在以下登录或文本响应或请求PDU之一的数据部分的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 the setting of 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 (Transition) 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 (continuation) bit is used (both in Login and Text) to indicate that "more follows".
由于某些键=值对可能不完全适合单个PDU，因此使用C（延续）位（在登录和文本中）表示“更多”。
The text negotiation uses an additional mechanism by which a target may deliver larger amounts of data to an enquiring 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 chapter details 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 to be presented and interpreted in the case in which they appear in this document. They are case sensitive.
启动器和目标发送一组以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) - letters
(0-9) - 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
(a-z, A-Z) - letters
(0-9) - 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
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 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 have the C bit set to 0, or 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内发送partial 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 consist 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 consist 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 consist of minus, dot, colon, or any character allowed by the output of the iSCSI string-prep template as specified in [RFC3722] (see also Section 3.2.6.2 iSCSI Name Encoding).
iSCSI名称值：由一个或多个字符组成的字符串，由减号、点、冒号或[RFC3722]中指定的iSCSI字符串准备模板输出所允许的任何字符组成（另请参见第3.2.6.2节iSCSI名称编码）。
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 start 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-constant MUST NOT be used for parameter values if the values can be equal 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 or letters or plus or slash or equal. The encoding is done according to [RFC2045] and each character, except equal, represents a base64 digit or a 6-bit binary string. Base64-constants are used to encode numerical-values or binary strings. When used to encode numerical values, the excessive use of leading 0 digits (encoded as A) is discouraged. The string following 0B (or 0b) represents a base64 number that starts with the most significant base64 digit, followed by all other digits in decreasing order of significance and ending with the least-significant base64 digit; the least significant base64 digit may be optionally followed by pad digits (encoded as equal) that are not considered as part of the number. When used to encode binary strings, base64-constants have an implicit byte-length that includes six bits for every character of the constant, excluding trailing equals (i.e., a base64-constant of n base64 characters excluding the trailing equals has a byte-length of ((the integer part of) (n*3/4)). Correctly encoded base64 strings cannot have n values of 1, 5 ... k*4+1.
base64常量：base64常量编码为一个字符串，以“0b”或“0b”开头，后跟一个或多个数字、字母、加号、斜杠或等号。根据[RFC2045]进行编码，每个字符（相等字符除外）表示一个base64位数字或一个6位二进制字符串。Base64常量用于编码数值或二进制字符串。当用于编码数值时，不鼓励过度使用前导0位（编码为A）。0B（或0B）后面的字符串表示一个base64数字，该数字以最有效的base64位开始，然后按重要性降序排列所有其他数字，以最低有效的base64位结束；最低有效的base64数字后面可以可选地跟有不被视为数字一部分的焊盘数字（编码为相等）。当用于编码二进制字符串时，base64常量具有隐式字节长度，该长度包括常量每个字符的六位，不包括尾随等于（即，不包括尾随等于的n个base64字符的base64常量的字节长度为（（的整数部分）（n*3/4））。正确编码的base64字符串不能有n个值1、5…k*4+1。
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-numeric-values.
大数值：一个无符号整数，可以大于或等于2**64，编码为十六进制常量或base64常量。无符号整数算术适用于大数值。
numeric-range: Two numerical-values separated by a tilde where the value to the right of 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, numeric-value, a numeric-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 of at least 64 kilobytes of key=value data (see Appendix 11.1.2 - Simple Public-Key Mechanism (SPKM) - that require support for public key certificates).
任何iSCSI目标或启动器都必须支持在协商序列中接收至少8192字节的key=value数据。当建议或接受明确要求支持超长身份验证项的身份验证方法时，发起方和目标方必须支持接收至少64 KB的key=value数据（参见附录11.1.2-简单公钥机制（SPKM）-需要支持公钥证书）。
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 to 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 Text or Login Response PDU that has the C bit set to 1 MUST NOT have the F/T bit set to 1.
发起人通过文本或登录请求启动协商和/或声明，并指示何时准备完成（通过在文本请求中将F位设置为1并在登录请求中将其保持为1或T位）。由于协商文本可能跨越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 Text or Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule.
目标或发起方不应使用无数据段（DataSegmentLength 0）的文本或登录响应或文本或登录请求，除非通用或密钥特定协商规则明确要求。
The format of a declaration is:
声明的格式为：
Declarer-> <key>=<valuex>
Declarer-> <key>=<valuex>
The general format of text negotiation is:
文本协商的一般形式是：
Proposer-> <key>=<valuex>
Acceptor-> <key>={<valuey>|NotUnderstood|Irrelevant|Reject}
Proposer-> <key>=<valuex>
Acceptor-> <key>={<valuey>|NotUnderstood|Irrelevant|Reject}
Thus a declaration is a one-way textual exchange while a negotiation is a two-way exchange.
因此，声明是单向文本交换，而协商是双向交换。
The proposer or declarer can either be the initiator or the target, and the acceptor can either be 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 use of some other value has serious consequences.
所有谈判都是明确的（即，结果必须仅基于新交换或声明的值）。没有隐含的建议。如果没有提出建议，那么就不可能得到答复。保守设计还要求，当使用其他值会产生严重后果时，不应依赖默认值。
The value proposed or declared can be a numerical-value, a numerical-range defined by lower and upper values 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 it is 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 negotiation. However the negotiation is not considered as 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 OFMarker=Yes,OFMarkInt=2048~8192
T->I OFMarker=No,OFMarkInt=Irrelevant
I->T OFMarker=Yes,OFMarkInt=2048~8192
T->I OFMarker=No,OFMarkInt=Irrelevant
I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb)
T->I X#vkey1=None,X#vkey2=Irrelevant
I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb)
T->I X#vkey1=None,X#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 not understood MUST be key=NotUnderstood.
在不影响基本功能的情况下，接受方可以忽略任何未被接受方理解的密钥。但是，未理解的密钥的答案必须是key=notunderspected。
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 re-negotiation 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 it is sent, the proposer MAY choose to terminate the connection or session.
如果接受方发送“拒绝”作为应答，协商密钥将保留其当前值（如果未设置值，则为默认值）。如果当前值在连接或发送的会话中不被投标人接受，投标人可以选择终止连接或会话。
All keys in this document, except for the X extension formats, 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.
本文档中的所有密钥（X扩展格式除外）在按此处指定使用时，必须由iSCSI启动器和目标支持。如果按规定使用，这些钥匙不得以NotUnderstanding（未理解）回答。
Implementers may introduce new keys by prefixing them with "X-", followed by their (reversed) domain name, or with new keys registered with IANA prefixing them with X#. For example, the entity owning the domain example.com can issue:
实现者可以引入新密钥，方法是在它们前面加上“X-”，然后加上它们的（反向）域名，或者在IANA注册的新密钥前面加上X#。例如，拥有域example.com的实体可以发布：
X-com.example.bar.foo.do_something=3
X-com.example.bar.foo.do\u something=3
or a new registered key may be used as in:
或者可以使用新的注册密钥，如下所示：
X#SuperCalyPhraGilistic=Yes
X#超级珊瑚礁=是
Implementers MAY also introduce new values, but ONLY for new keys or authentication methods (see Section 11 iSCSI Security Text Keys and Authentication Methods), or digests (see Section 12.1 HeaderDigest and DataDigest).
实施者还可以引入新值，但仅针对新密钥或身份验证方法（请参阅第11节iSCSI安全文本密钥和身份验证方法）或摘要（请参阅第12.1节HeaderDigest和DataDigest）。
Whenever parameter action or acceptance is dependent on other parameters, the dependency rules and parameter sequence must be specified with the parameters.
当参数操作或接受依赖于其他参数时，必须使用参数指定依赖规则和参数序列。
In the Login Phase (see Section 5.3 Login Phase), every stage is a separate negotiation. In the FullFeaturePhase, 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.
在登录阶段（参见第5.3节登录阶段），每个阶段都是单独的协商。在FullFeature阶段，文本请求-响应序列是协商。谈判必须作为原子行动来处理。例如，所有协商值在协商达成一致后生效，或在协商失败时被忽略。
Some parameters may be subject to integrity rules (e.g., parameter-x must not exceed parameter-y or parameter-u not 1 implies parameter-v be Yes). Whenever required, integrity rules are specified with the keys. Checking for compliance with the integrity 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.
某些参数可能受完整性规则的约束（例如，参数-x不得超过参数-y或参数-u非1表示参数-v为是）。只要需要，完整性规则都会与密钥一起指定。只有在所有参数都可用（现有参数和新协商的参数）后，才能检查是否符合完整性规则。在新参数生效之前，iSCSI目标必须执行完整性检查。启动器可以执行完整性检查。
An iSCSI initiator or target MAY terminate a negotiation that does not end within a reasonable time or number of exchanges.
iSCSI启动器或目标可能会终止未在合理时间或交换次数内结束的协商。
In list negotiation, the originator sends a list of values (which may include "None") in its 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.
常量“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 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" or the acceptor MAY 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).
对于数值范围，选择的值必须是建议范围内的整数或“拒绝”（如果范围不可接受）。
In Boolean negotiations (i.e., those that result in 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 to answer with are expressed as Boolean functions of the value received, and the value that the accepting party would have selected if given a choice.
在布尔协商中（即，导致键取值Yes或No的协商），当接收到的值不能自行确定协商结果时，接受方必须使用相同的键和协商结果进行回答。传输的最后一个值成为协商结果。选择要回答的值的规则表示为所接收值的布尔函数，以及接受方在给出选择时将选择的值。
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". - The Boolean function is "OR" and the value "Yes" is received. The outcome of the negotiation is "Yes".
- 布尔函数为“AND”，并接收到值“No”。谈判结果为“否”——布尔函数为“或”，并收到值“是”。谈判的结果是“是”。
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, security parameters, and authenticates the initiator and target to each other.
登录阶段在启动器和目标之间建立iSCSI连接；它还会创建新会话或将连接与现有会话相关联。登录阶段设置iSCSI协议参数、安全参数，并相互验证启动器和目标。
The Login Phase is only implemented via Login Request 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命令）。
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 or both, but MUST include at least one of them. 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.
一些操作参数可以通过文本请求和响应在登录外部协商。
Security MUST be completely negotiated within the Login Phase. The use of underlying IPsec security is specified in Chapter 8 and in [RFC3723]. iSCSI support for security within the protocol only consists of authentication in the Login Phase.
安全性必须在登录阶段内完全协商。第8章和[RFC3723]中规定了基础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 SecurityNegotiation keys appear in Chapter 11 and the LoginOperationalNegotiation keys appear in Chapter 12. Only a limited set of keys (marked as Any-Stage in Chapter 12) may be used in any of the two stages.
大多数协商密钥只允许在特定阶段使用。安全协商密钥见第11章，LoginOperationalNegotiation密钥见第12章。两个阶段中的任何一个阶段只能使用有限的一组钥匙（在第12章中标记为任何阶段）。
Any given Login Request or Response belongs to a specific stage; this determines the negotiation keys allowed with the request or response. It is considered to be a protocol error to send a key that is not allowed in the current stage.
任何给定的登录请求或响应都属于特定阶段；这决定了请求或响应允许的协商密钥。发送当前阶段不允许的密钥被视为协议错误。
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 through 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 pair of Login Request-Responses have no bearing on the T bit settings of the next pair. An initiator that has a 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
发起方和目标方都不应在登录期间多次尝试声明或协商参数，除非响应明确允许重复密钥声明的特定密钥（例如TargetAddress）。发起者和目标必须检测到重新协商/重新声明不允许的参数的尝试。如果检测到这种尝试
by the target, the target MUST respond with Login reject (initiator error); if detected by the initiator, the initiator MUST drop the connection.
对于目标，目标必须响应登录拒绝（启动器错误）；如果启动器检测到，则启动器必须断开连接。
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 - ISID, TSIH, and connection Ids - Negotiation stage that the initiator is ready to enter.
- 发起程序支持的协议版本。-iSCSI启动器名称和iSCSI目标名称—ISID、TSIH和连接ID—启动器准备进入的协商阶段。
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 5.3.5) |
+------------------------------------------------------------------+
|existing | non-zero | new | add a new connection to |
| | existing | | the session |
+------------------------------------------------------------------+
|existing | non-zero |existing| do connection reinstatement|
| | existing | | (see section 5.3.4) |
+------------------------------------------------------------------+
|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 5.3.5) |
+------------------------------------------------------------------+
|existing | non-zero | new | add a new connection to |
| | existing | | the session |
+------------------------------------------------------------------+
|existing | non-zero |existing| do connection reinstatement|
| | existing | | (see section 5.3.4) |
+------------------------------------------------------------------+
|existing | non-zero | any | fail the login |
| | new | | ("session does not exist") |
+------------------------------------------------------------------+
Determination of "existing" or "new" are made by the target.
由目标公司确定“现有”或“新”。
Optionally, the Login Request may include:
可选地，登录请求可以包括：
- Security parameters OR - iSCSI operational parameters AND/OR - The next negotiation stage that the initiator is ready to enter.
- 安全参数或-iSCSI操作参数和/或-启动器准备进入的下一个协商阶段。
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 and the CSG and NSG fields are reserved. - Login Response with Login Accept as a final response (T bit set to 1 and the NSG in both request and response are 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). - 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.
- 带有登录拒绝的登录响应。这是来自目标的立即拒绝，如果这是新会话的第一个（或唯一）连接，则会导致连接终止和会话终止。保留T位、CSG和NSG字段。-登录响应，登录接受作为最终响应（T位设置为1，请求和响应中的NSG都设置为FullFeaturePhase）。响应包括目标支持的协议版本和会话ID，还可能包括iSCSI操作或安全参数（取决于当前阶段）。-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 10.13 Login Response) without SecurityNegotiation and will terminate the connection with a response of Authentication failure (see Section 10.13.5 Status-Class and Status-Detail).
如果发起者决定放弃SecurityNegotiation阶段，则会发出CSG设置为LoginOperationalNegotiation的登录，目标可能会回复一个登录响应，表明其不愿意接受连接（参见第10.13节登录响应）没有SecurityNegotiation，将终止连接，并响应身份验证失败（参见第10.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 12.9 TargetPortalGroupTag), 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密钥（请参阅第12.9节TargetPortalGroupTag）、设置为1的T位、设置为SecurityNegotiation的CSG以及设置为LoginOperationalNegotiation的NSG。
An initiator that chooses to operate without iSCSI security, 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 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 when TargetName is given and the response is not a redirection. 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.
在登录阶段，当给定TargetName且响应不是重定向时，iSCSI目标必须为所有会话类型返回TargetPortalGroupTag密钥以及允许其使用的第一个登录响应PDU（即，在第一个登录请求之后发出的第一个登录响应，C位设置为0）。TargetPortalGroupTag键值表示为登录请求PDU提供服务的iSCSI门户组。如果在给定环境中需要重新配置iSCSI门户组，则iSCSI启动器应使用此密钥来确定它确实已使用目标门户组启动了登录阶段。
The security exchange sets the security mechanism and authenticates the initiator user and the target to each other. The exchange proceeds according to the authentication method chosen in the negotiation phase and is conducted using the Login Requests' and responses' key=value parameters.
安全交换设置安全机制，并相互认证发起方用户和目标。交换根据在协商阶段选择的身份验证方法进行，并使用登录请求和响应的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 5.2 Text Mode Negotiation). The parameters are encoded in UTF8 as key=value. For security parameters, see Chapter 11.
- 目标必须使用其支持的列表中的第一个选项进行回复，并且允许用于特定的启动器，除非它不支持任何选项，在这种情况下，它必须使用“拒绝”进行回复（参见第5.2节文本模式协商）。参数在UTF8中编码为key=value。有关安全参数，请参见第11章。
- When the initiator considers that it is 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
- 当发起者认为它已经准备好结束SecurityNegotiation阶段时，它将T位设置为1，并将NSG设置为它希望下一阶段的状态。然后，目标将T位设置为1，并在发送完安全密钥后将NSG设置为登录响应的下一阶段。下一个
stage selected will be the one the target selected. If the next stage is FullFeaturePhase, the target MUST respond with a Login Response with the TSIH value.
所选阶段将是目标选择的阶段。如果下一阶段是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).
应该注意的是，如果发起方确实支持安全性，但尚未准备好指导协商，则协商也可能由目标方指导（建议选项）。
Operational parameter negotiation during the login 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-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。
If the target responds to a Login Request that has the T bit set to 1 with a Login Response that has the T bit set to 0, the initiator should keep sending the Login Request (even empty) with the T bit set to 1, while it still wants to switch stage, until it receives the Login Response that has the T bit set to 1 or it receives a key that requires it 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 FullFeaturePhase. New or replacement connections can only be added to a session after the session is operational.
会话在FullFeaturePhase中至少有一个连接后即可运行。新连接或替换连接只能在会话运行后添加到会话中。
For operational parameters, see Chapter 12.
有关操作参数，请参见第12章。
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 reinstating a new Full Feature Phase iSCSI connection in its place (with the same CID). Thus, the TSIH in the Login 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 Full Feature Phase if ErrorRecoveryLevel is 2 and SHOULD support opening a second connection if ErrorRecoveryLevel is less than 2.
连接恢复是指启动器使用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 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.
如果operational ErrorRecoveryLevel为2，则连接恢复将启用将来的任务重新分配。如果operational ErrorRecoveryLevel小于2，则连接恢复是在不启用任务重新分配的情况下替换旧CID。在这种情况下，必须立即终止旧CID上处于活动状态的所有任务，而无需进一步通知启动器。
The initiator connection state MUST be CLEANUP_WAIT (section 7.1.3) when the initiator attempts a connection reinstatement.
当启动器尝试恢复连接时，启动器连接状态必须为CLEANUP_WAIT（第7.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 the initiator logging in with an ISID that is possibly active from the target's perspective. 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 7.3 Session State Diagrams) when the initiator attempts a session reinstatement.
当启动器尝试恢复会话时，启动器会话状态必须失败（第7.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 7.2 Connection Cleanup State Diagram for Initiators and Targets) and no tasks in the session are waiting for reassignment.
- 成功的“会话关闭”注销。-当会话中没有其他连接等待清理（第7.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 (N6 transition in the session state diagram).
会话超时是定义为在上次连接状态超时过期且没有任务等待重新分配时发生的事件。这将使会话进入空闲状态（会话状态图中的N6转换）。
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丢失”通知：
a) Successful completion of session reinstatement. b) Session closure event. c) Session timeout event.
a) 成功完成会话恢复。b） 会话结束事件。c） 会话超时事件。
Certain SCSI object clearing actions may result due to the notification in the SCSI end nodes, as documented in Appendix F. - Clearing Effects of Various Events on Targets -.
由于SCSI终端节点中的通知，可能会导致某些SCSI对象清除操作，如附录F-清除各种事件对目标的影响-中所述。
Session continuation is the process by which the state of a preexisting session continues to be used by connection reinstatement (Section 5.3.4 Connection Reinstatement), or by adding a connection with a new CID. Either of these actions associates the new transport connection with the session state.
会话继续是指通过连接恢复（第5.3.4节连接恢复）或通过添加具有新CID的连接，继续使用先前存在会话的状态的过程。这些操作都会将新传输连接与会话状态相关联。
Session failure is an event where the last Full Feature Phase connection reaches the CLEANUP_WAIT state (Section 7.2 Connection Cleanup State Diagram for Initiators and Targets), or completes a successful recovery logout, thus causing all active tasks (that are formerly allegiant to the connection) to start waiting for task reassignment.
会话失败是指最后一个完整功能阶段连接达到清理等待状态（第7.2节启动器和目标的连接清理状态图）或成功完成恢复注销，从而导致所有活动任务（以前是连接allegiant）开始等待任务重新分配的事件。
Some operational parameters MAY be negotiated outside (after) the Login Phase.
某些操作参数可能在登录阶段之外（之后）协商。
Parameter negotiation in Full Feature Phase is done through Text requests and responses. Operational parameter negotiation MAY involve several Text request-response exchanges, which the initiator always starts and terminates using the same Initiator Task Tag. The initiator MUST indicate its intent to terminate 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 and with a Text response with the F bit set to 0, the initiator should keep sending the Text request (even empty) 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的文本请求。
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 pair of Text request-responses 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 without an intervening operational parameter negotiation reset, except for responses to specific keys that explicitly allow repeated key declarations (e.g., TargetAddress). If detected by the target, this MUST result in 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中的大部分错误恢复功能：
i) 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. ii) A TCP connection may fail at any time during the data transfer. All the active tasks must optionally be allowed to continue on a different TCP connection within the same session.
i) iSCSI PDU可能无法通过摘要检查并被丢弃，尽管TCP层已接收到它。必须选择性地允许iSCSI层恢复此类丢失的PDU。ii）在数据传输过程中，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 chapter describes a general model for recovery in support of interoperability. See Appendix E. - Algorithmic Presentation of Error Recovery Classes - for further detail 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.
本章介绍了支持互操作性的一般恢复模型。有关如何实现所述模型的更多详细信息，请参见附录E——错误恢复类的算法演示。兼容的实现不必与所呈现的模型的实现细节相匹配，但此类实现的外部行为必须与所呈现模型的外部可观察特征相对应。
The major design goals of the iSCSI error recovery scheme are as follows:
iSCSI错误恢复方案的主要设计目标如下：
a) Allow iSCSI implementations to meet different requirements by defining a collection of error recovery mechanisms that implementations may choose from. b) Ensure interoperability between any two implementations supporting different sets of error recovery capabilities. c) Define the error recovery mechanisms to ensure command ordering even in the face of errors, for initiators that demand ordering.
a) 通过定义一组可供实施选择的错误恢复机制，允许iSCSI实施满足不同的要求。b） 确保支持不同错误恢复功能集的任意两个实现之间的互操作性。c） 定义错误恢复机制，以确保即使在出现错误的情况下，也能为需要排序的启动器进行命令排序。
d) Do not make additions in the fast path, but allow moderate complexity in the error recovery path. e) 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.
d) 不要在快速路径中添加，但在错误恢复路径中允许中等复杂度。e） 防止启动器和目标同时尝试恢复同一组PDU。例如，启动器和目标之间必须有明确的“错误恢复功能分布”。
The initiator mechanisms defined in connection with error recovery are:
与错误恢复相关的启动器机制包括：
a) NOP-OUT to probe sequence numbers of the target (section 10.18) b) Command retry (section 6.2.1) c) Recovery R2T support (section 6.7) d) Requesting retransmission of status/data/R2T using the SNACK facility (section 10.16) e) Acknowledging the receipt of the data (section 10.16) f) Reassigning the connection allegiance of a task to a different TCP connection (section 6.2.2) g) Terminating the entire iSCSI session to start afresh (section 6.1.4.4)
a) NOP-OUT探测目标的序列号（第10.18节）b）命令重试（第6.2.1节）c）恢复R2T支持（第6.7节）d）使用快餐设施请求重新传输状态/数据/R2T（第10.16节）e）确认收到数据（第10.16节）f）将任务的连接忠诚度重新分配给不同的TCP连接（第6.2.2节）g）终止整个iSCSI会话以重新启动（第6.1.4.4节）
The target mechanisms defined in connection with error recovery are:
与错误恢复相关的目标机制包括：
a) NOP-IN to probe sequence numbers of the initiator (section 10.19) b) Requesting retransmission of data using the recovery R2T feature (section 6.7) c) SNACK support (section 10.16) d) Requesting that parts of read data be acknowledged (section 10.7.2) e) Allegiance reassignment support (section 6.2.2) f) Terminating the entire iSCSI session to force the initiator to start over (section 6.1.4.4)
a) NOP-IN探测启动器的序列号（第10.19节）b）使用恢复R2T功能请求数据重传（第6.7节）c）零食支持（第10.16节）d）请求确认部分读取数据（第10.7.2节）e）效忠重新分配支持（第6.2.2节）f）终止整个iSCSI会话以强制启动器重新启动（第6.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 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.
对于任何未完成的SCSI命令，假定iSCSI与启动器处的SCSI一起能够保留足够的信息，以便能够重建命令PDU，并且在命令未完成时，传出数据（在主机内存中）可用于重新传输。还假定在目标位置，传入数据（读取数据）可以保留以进行恢复，也可以从设备服务器重新读取。
It is further assumed that a target will keep the "status & 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 class recovery 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。
Use of within-connection and within-command recovery classes MUST NOT be attempted before the connection is in 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 and used.
在恢复类的详细描述中，强制条款（必须、应该、可能等）指出了在支持和使用恢复类的情况下要执行的规范性措施。
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 6.7 Digest Errors, using the option of a recovery R2T.
a) 数据摘要错误-按照第6.7节摘要错误中的规定处理，使用恢复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 6.8 Sequence Errors, using the option of a recovery R2T. c) Header digest error, which manifests as a sequence reception timeout or a sequence error - dealt with as specified in Section 6.8 Sequence Errors, using the option of a recovery R2T.
b) 序列接收超时（无数据或部分数据和无F位）-视为隐式序列错误，并按照第6.8节序列错误中的规定，使用恢复R2T选项进行处理。c） 报头摘要错误，表现为序列接收超时或序列错误-按照第6.8节“序列错误”中的规定处理，使用恢复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 6.7 Digest Errors, using the option of a SNACK. b) Sequence reception timeout (no status) or response reception timeout - dealt with as specified in Section 6.8 Sequence Errors, using the option of a SNACK. c) Header digest error, which manifests as a sequence reception timeout or a sequence error - dealt with as specified in Section 6.8 Sequence Errors, using the option of a SNACK.
a) 数据摘要错误-按照第6.7节摘要错误中的规定，使用零食选项进行处理。b） 序列接收超时（无状态）或响应接收超时-按照第6.8节“序列错误”中的规定，使用零食选项进行处理。c） 标题摘要错误，表现为序列接收超时或序列错误-按照第6.8节“序列错误”中的规定，使用快捷键选项进行处理。
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. 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:
在启动器处，以下情况有助于连接内恢复：
- Requests not acknowledged for a long time. Requests are acknowledged explicitly through ExpCmdSN or implicitly by receiving data and/or status. The initiator MAY retry non-acknowledged commands as specified in Section 6.2 Retry and Reassign in Recovery.
- 长时间未确认的请求。请求通过ExpCmdSN显式确认，或通过接收数据和/或状态隐式确认。启动器可以按照第6.2节“重试”和“恢复中重新分配”中的规定重试未确认的命令。
- 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 by receiving a Response PDU with a higher StatSN than expected. In the first case, digest error handling is done as specified in Section 6.7 Digest Errors using the option of a SNACK. In the second case, sequence error handling is done as specified in Section 6.8 Sequence Errors, using the option of a SNACK.
- 丢失iSCSI编号的响应。通过识别响应PDU上的数据摘要错误或PDU中携带状态的数据，或通过接收StatSN高于预期的响应PDU来识别。在第一种情况下，按照第6.7节“摘要错误”的规定，使用零食选项进行摘要错误处理。在第二种情况下，序列错误处理按照第6.8节“序列错误”中的规定进行，使用零食选项。
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启动器上，以下情况有助于连接恢复：
- TCP connection failure: The initiator MUST close the connection. It then MUST either implicitly or explicitly logout 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 10.5.1 Function). For an initiator, a command is in progress as long as it has not received a response or a Data-In PDU including status.
- TCP连接失败：启动器必须关闭连接。然后，它必须使用原因码“remove the connection for recovery”隐式或显式地注销失败的连接，并使用“任务重新分配”任务管理功能（参见第10.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.
注意：注销功能是必需的。但是，只有当失败的连接是会话中的最后一个或唯一连接时，才必须建立新的连接。
- Receiving an Asynchronous Message that indicates one or all connections in a session has been dropped. The initiator MUST handle it as a TCP connection failure for the connection(s) referred to in the Message.
- 接收异步消息，该消息指示会话中的一个或所有连接已断开。对于消息中提到的连接，启动器必须将其作为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 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 F. - Clearing Effects of Various Events on Targets -.
有关会话恢复对SCSI和iSCSI对象可能产生的清除影响，请参阅附录F-清除目标上各种事件的影响。
The error recovery classes described so far are organized into a hierarchy for ease in understanding and to limit the implementation complexity. With few and 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. b) As a corollary, supporting a higher error recovery level means increased sophistication and possibly an increase in resource requirements. 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.
a) 每个级别都是上一级别功能的超集。例如，级别1支持意味着支持级别0及以上的所有功能。b） 因此，支持更高的错误恢复级别意味着更高的复杂性，并且可能增加资源需求。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 capabilities expected from the implementations that support each error recovery level.
下表列出了支持每个错误恢复级别的实现所需的错误恢复功能。
+-------------------+--------------------------------------------+
|ErrorRecoveryLevel | Associated Error recovery capabilities |
+-------------------+--------------------------------------------+
| 0 | Session recovery class |
| | (Section 6.1.4.4 Session Recovery) |
+-------------------+--------------------------------------------+
| 1 | Digest failure recovery (See Note below.) |
| | plus the capabilities of ER Level 0 |
+-------------------+--------------------------------------------+
| 2 | Connection recovery class |
| | (Section 6.1.4.3 Connection Recovery) |
| | plus the capabilities of ER Level 1 |
+-------------------+--------------------------------------------+
+-------------------+--------------------------------------------+
|ErrorRecoveryLevel | Associated Error recovery capabilities |
+-------------------+--------------------------------------------+
| 0 | Session recovery class |
| | (Section 6.1.4.4 Session Recovery) |
+-------------------+--------------------------------------------+
| 1 | Digest failure recovery (See Note below.) |
| | plus the capabilities of ER Level 0 |
+-------------------+--------------------------------------------+
| 2 | Connection recovery class |
| | (Section 6.1.4.3 Connection Recovery) |
| | plus the capabilities of ER Level 1 |
+-------------------+--------------------------------------------+
Note: Digest failure recovery is comprised of two recovery classes: Within-Connection recovery class (Section 6.1.4.2 Recovery Within-connection) and Within-Command recovery class (Section 6.1.4.1 Recovery Within-command).
注意：摘要故障恢复由两个恢复类组成：连接内恢复类（第6.1.4.2节连接内恢复）和命令内恢复类（第6.1.4.1节命令内恢复）。
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, the functionality corresponding to any defined value numerically less than the proposed. When a defined value of ErrorRecoveryLevel is returned by a responder in a text negotiation, the responder MUST support the functionality corresponding to the ErrorRecoveryLevel it is accepting.
当发起人在文本协商中提出ErrorRecoveryLevel的定义值时，发起人必须支持为该建议值定义的功能，此外，还必须支持与数值小于建议值的任何定义值对应的功能。当响应者在文本协商中返回定义的ErrorRecoveryLevel值时，响应者必须支持与其接受的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 acknowledgement (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 10.16, although the usage of SNACK is OPTIONAL.
除堵塞命令序列间隙外，不得使用“重试”，尤其不能用于从目标请求PDU重新传输。对于当前正在进行的allegiant命令，任何此类PDU重传请求都可以使用第10.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 3.2.2.1.
如果作为上述填补命令序列间隙的一部分，启动器无意中对已在执行的allegiant命令发出重试（即，目标没有看到CmdSN排序中的不连续性），则目标会按照第3.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 10.5.1 Function), 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 10.14) MUST be successfully completed for the previous connection to which the task was allegiant.
通过发出“任务重新分配”任务管理请求（第10.5.1节功能），发起者表示其打算继续执行已激活的命令（但没有当前的连接忠诚），作为连接恢复的一部分。这意味着将为命令请求新的连接效忠，该命令试图将其与发出任务管理请求的连接相关联。在尝试为任务重新分配忠诚之前，必须为任务所属的上一个连接成功完成隐式或显式注销，原因代码为“删除恢复连接”（参见第10.14节）。
In reassigning connection allegiance for a command, the targets 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 zero if there was no data transfer) and bring the read command to completion by sending the remaining data and sending (or resending) the status. ExpDataSN acknowledges all data sent up to, but not including, the Data-In PDU and or R2T with DataSN (or R2TSN) equal to 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 an accurate state. Initiators MUST not subsequently request data retransmission through Data SNACK for PDUs numbered less than 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字段（如果没有数据传输，则必须设置为零），并通过发送剩余数据和发送（或重新发送）状态来完成读取命令。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 "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 either by transmitting a command PDU with the same CmdSN, or by aborting the task (see section 6.9 on how an abort may plug a CmdSN gap).
即使可以可靠地确定被拒绝命令PDU的CmdSN，目标也不得认为已接收到被拒绝命令PDU的CmdSN（如果是非即时命令）（即，必须为CmdSN假定命令序列间隔）。收到拒绝后，发起方必须插入CmdSN间隙才能继续使用会话。可以通过使用相同的CmdSN发送命令PDU或中止任务来堵塞间隙（参见第6.9节“中止如何堵塞CmdSN间隙”）。
When a data PDU is rejected and its DataSN can be ascertained, a target MUST advance 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被拒绝并且可以确定其DataSN时，如果正在生成恢复R2T，则目标必须为当前数据突发提前EXPDASN。如果目标不尝试恢复丢失的数据PDU，它可能会提前EXPDASCN。
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
iSCSI定义了两个会话全局超时值（以秒为单位）—Time2Wait和Time2Retain—在iSCSI全功能阶段连接有意或因异常而停止服务时适用。Time2Wait是尝试显式/隐式注销相关CID或重新分配受影响任务（如果有）之前的初始“暂停时间”。Time2Retain是初始暂停间隔后保证在服务器上保持任务和/或连接状态的最长时间
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.
目标是满足可能的恢复尝试。连接和/或任务的恢复尝试不应在Time2Wait秒之前进行，但必须在初始Time2Wait等待期之后的Time2Retain秒内完成。
A transport connection shutdown or a transport reset without any preceding iSCSI protocol interactions informing the end-points 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 12.15 DefaultTime2Wait) and DefaultTime2Retain (Section 12.16 DefaultTime2Retain) text keys for the session.
在没有任何先前的iSCSI协议交互通知端点的情况下关闭传输连接或重置传输会导致全功能阶段iSCSI连接突然终止。本例中使用的超时值是会话的defaultTime2Wait（第12.15节defaultTime2Wait）和DefaultTime2Retain（第12.16节DefaultTime2Retain）文本键的协商值。
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 10.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"; section 10.9.1) specify the timeout values to be used in each of these cases.
任何计划的全功能阶段iSCSI连接停用之前都会有一个注销响应PDU或一个异步消息PDU。注销响应PDU中的Time2Wait和Time2Retain字段值（第10.15节）以及异步消息的Parameter2和Parameter3字段（AsyncEvent类型“删除连接”或“删除所有连接”；第10.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 of "Close the connection" and there are active tasks allegiant to that connection.
a) 当连接以“Close the connection”（关闭连接）的原因代码隐式或显式注销，并且该连接存在活动任务allegiant时。
b) When a connection fails and the connection state eventually times out (state transition M1 in Section 7.2.2 State Transition Descriptions for Initiators and Targets) and there are active tasks allegiant to that connection.
b) 当连接失败且连接状态最终超时时（第7.2.2节启动器和目标的状态转换说明中的状态转换M1），并且该连接存在活动任务allegiant。
c) When a successful Logout with the reason code of "remove the connection for recovery" is performed while there are active tasks allegiant to that connection, and those tasks eventually
c) 当成功注销且原因代码为“删除连接以进行恢复”时，同时存在活动任务allegiant连接到该连接，并且这些任务最终
time out after the Time2Wait and Time2Retain periods without allegiance reassignment.
Time2Wait和Time2Retain时段后超时，无效忠重新分配。
d) When a connection is implicitly or explicitly logged out with the reason code of "Close the session" and there are active tasks in that session.
d) 当连接以“关闭会话”的原因代码隐式或显式注销，并且该会话中存在活动任务时。
If the tasks terminated in the above cases a), b, c) and d)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 SCSI level depending on the SCSI context as defined by the SCSI standards (e.g., queued commands and ACA, in cases a), b), and c), 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, and the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT" , etc. - see [SAM2] and [SPC3]).
如果在上述情况下终止的任务a）、b、c）和d）都是SCSI任务，则它们必须在内部终止，就像使用检查条件状态一样。此状态仅对适当处理内部SCSI状态和与订购有关的SCSI副作用有意义，因为此状态永远不会作为终止状态传回启动器。但是，根据SCSI标准定义的SCSI上下文（例如，队列命令和ACA，在情况a）、b）和c中），在任务终止后，可能必须在SCSI级别采取其他操作，目标必须在每个受影响的I_T_L nexus的任何连接上处理的下一个命令上报告一个单位注意状态，状态为检查状态，ASC/ASCQ值为47h/7Fh-“某些命令被ISCSI协议事件清除”，等等-请参阅[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 10 iSCSI PDU Formats). b) Inconsistent field contents (consistent field contents are specified in Section 10 iSCSI PDU Formats).
a) 任何PDU头字段（操作码除外）的非法内容（第10节iSCSI PDU格式中指定了合法值）。b） 字段内容不一致（第10节iSCSI PDU格式中指定了一致的字段内容）。
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 either with a connection close or with a connection reset and escalate the format error to session recovery (see Section 6.1.4.4 Session Recovery).
当目标或启动器收到带有格式错误的iSCSI PDU时，它必须立即终止会话中的所有传输连接（连接关闭或连接重置），并将格式错误升级到会话恢复（请参阅第6.1.4.4节会话恢复）。
The discussion of the legal choices in handling digest errors below 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, non-data PDU rule below applies), the target MUST do one of the following: a) Request retransmission with a recovery R2T. b) Terminate the task with a response PDU with a CHECK CONDITION Status and an iSCSI Condition of "protocol service CRC error" (Section 10.4.7.2 Sense Data). 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 response PDU. A task management command (such as an abort task) from the initiator during this wait may also conclude the task. - No further action is necessary for targets if the discarded PDU is a non-data PDU. In case of immediate data being present on a discarded command, the immediate data is implicitly recovered when the task is retried (see section 6.2.1), followed by the entire data transfer for the task.
- 如果丢弃的PDU是请求的或未经请求的iSCSI数据PDU（对于命令PDU中的即时数据，以下非数据PDU规则适用），则目标必须执行以下操作之一：a）使用恢复R2T请求重新传输。b） 使用带有检查条件状态和iSCSI条件“协议服务CRC错误”的响应PDU终止任务（第10.4.7.2节检测数据）。如果目标选择实现此选项，则在发送响应PDU之前，必须等待接收所有数据（由数据PDU发出信号，并为所有未完成的R2T设置最终位）。在此等待期间，发起者发出的任务管理命令（如中止任务）也可能结束任务。-如果丢弃的PDU是非数据PDU，则无需对目标执行进一步操作。如果丢弃的命令上存在即时数据，则在重试任务时（参见第6.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: i) 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 10.4.7.2 Sense Data). ii) 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
a) 通过Snapshot请求所需的数据PDU。作为对SNACK的响应，目标必须重新发送数据PDU或使用拒绝PDU拒绝SNACK，原因代码为“SNACK reject”，在这种情况下：i）如果尚未发送命令的状态，目标必须使用检查条件状态和iSCSI条件“SNACK rejected”终止命令（第10.4.7.2节感知数据）。ii）如果状态已发送，则无需对目标采取进一步措施。在这种情况下，发起者必须等待收到状态，然后放弃状态，以便在内部用检查条件发出完成信号
Status and an iSCSI Condition of "protocol service CRC error" (Section 10.4.7.2 Sense Data). b) Abort the task and terminate the command with an error.
“协议服务CRC错误”的状态和iSCSI条件（第10.4.7.2节检测数据）。b） 中止任务并在出现错误时终止命令。
- If the discarded PDU is a response PDU, the initiator MUST do one of the following:
- 如果丢弃的PDU是响应PDU，则启动器必须执行以下操作之一：
a) Request PDU retransmission with a status SNACK. b) Logout the connection for recovery and continue the tasks on a different connection instance as described in Section 6.2 Retry and Reassign in Recovery. c) Logout to close the connection (abort all the commands associated with the connection).
a) 请求PDU重新传输，并显示状态信息。b） 注销连接以进行恢复，并在不同的连接实例上继续执行任务，如第6.2节“在恢复中重试并重新分配”所述。c） 注销以关闭连接（中止与连接关联的所有命令）。
- No further action is necessary for initiators if the discarded PDU is an unsolicited PDU (e.g., Async, Reject). Task timeouts as in the initiator waiting for a command completion, or process timeouts, as in the target waiting for a Logout, will ensure that the correct operational behavior will result in these cases despite the discarded PDU.
- 如果丢弃的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. The initiator MUST address these implied digest errors as described in Section 6.7 Digest Errors. 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 6.7 Digest Errors.
当启动器接收到带有无序R2TSN/DataSN的iSCSI R2T/data PDU或带有EXPDASN的SCSI响应PDU（表示缺少数据PDU）时，这意味着启动器必须在一个或多个早期R2T/data PDU上检测到标头或负载摘要错误。发起者必须解决这些隐含的摘要错误，如第6.7节摘要错误所述。当一个目标接收到一个数据PDU，其中包含一个无序的DataSN时，这意味着该目标必须在至少一个较早的数据PDU上遇到报头或有效负载摘要错误。目标公司必须解决这些隐含的摘要错误，如第6.7节摘要错误所述。
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 6.7 Digest Errors. 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出现故障，这意味着缺少响应时，它必须按照第6.7节“摘要错误”中的说明处理一个或多个缺少的状态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。
An iSCSI initiator MAY attempt to plug a command sequence gap on the target end (in the absence of an acknowledgement of the command by way of ExpCmdSN) before the ULP timeout by retrying the unacknowledged command, as described in Section 6.2 Retry and Reassign in Recovery.
iSCSI启动器可尝试在ULP超时之前，通过重试未确认的命令（如第6.2节“重试并在恢复中重新分配”中所述），在目标端（在没有通过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 either using an appropriate Task Management function request for the specific command, or a "close the connection" Logout. 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:
在命令（带有n的CmdSN）的ULP超时时，如果iSCSI启动器打算继续会话，则必须通过对特定命令使用适当的任务管理功能请求或“关闭连接”注销来中止该命令。使用中止任务时，如果ExpCmdSN仍然小于（n+1），则由于以下原因之一，目标可能会看到中止请求，同时丢失原始命令本身：
- Original command was dropped due to digest error. - Connection on which the original command was sent was successfully logged out. Upon 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 to be 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 of "Task Does Not Exist".
如果接收到中止请求且原始命令丢失，则目标必须考虑原始命令，并接收ReqCMDSN，并用响应代码发出任务管理响应：“函数完成”。此响应结束了两端的任务。如果接收到中止请求，并且目标可以确定（基于引用的任务标记）已接收并执行命令，并且在中止之前已发送响应，则目标必须使用响应代码“任务不存在”进行响应。
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:
文本请求和响应序列用于设置/协商操作参数时，构成协商/参数设置。谈判失败被视为以下一项或多项：
- None of the choices, or the stated value, is acceptable to one of the sides 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:
应使用以下两条规则来解决协商失败问题：
- During Login, any failure in negotiation MUST be considered a login process failure and the Login Phase must be terminated, and with it, the connection. If the target detects the failure, it must terminate the login with the appropriate Login Response code.
- 在登录过程中，协商中的任何失败都必须视为登录过程失败，并且必须终止登录阶段以及连接。如果目标检测到故障，则必须使用相应的登录响应代码终止登录。
- A failure in negotiation, while in the Full Feature Phase, will terminate the entire negotiation sequence that 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).
- 在全功能阶段，协商失败将终止整个协商序列，该序列可能由使用相同启动器任务标记的一系列文本请求组成。会话或连接的操作参数必须继续为先前成功协商期间商定的值（即，此不成功协商的任何部分结果不得生效，必须丢弃）。
Mapping framed messages over a "stream" 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 above mechanisms for connection drop and reestablishment help handle this type of mapping errors.
通过“流”连接（如TCP）映射帧消息，使得所提出的机制容易受到简单软件帧错误的影响。另一方面，引入帧机制来限制这些错误的影响可能会对简单实现的性能造成很大的影响。命令序列号和上述连接断开和重建机制有助于处理此类映射错误。
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 by a failing iSCSI NOP (acting as a ping). The latter MAY be used periodically to increase the speed and likelihood of detecting connection failures. Initiators and targets MAY also use the keep-alive option on the TCP connection to enable early link failure detection on otherwise idle links.
如果iSCSI能够在启动器和目标之间及时保持/建立至少一个TCP连接，则可以使会话保持运行。目标和/或启动器可以通过传输级别方式（TCP）、命令序列号中的间隙、长时间未填充的响应流或故障iSCSI NOP（充当ping）来识别故障连接。后者可定期用于提高检测连接故障的速度和可能性。启动器和目标还可以在TCP连接上使用保持活动选项，以便在其他空闲链路上启用早期链路故障检测。
On connection failure, the initiator and target MUST do one of the following:
连接失败时，启动器和目标必须执行以下操作之一：
- Attempt connection recovery within the session (Section 6.1.4.3 Connection Recovery).
- 尝试在会话内恢复连接（第6.1.4.3节连接恢复）。
- Logout the connection with the reason code "closes the connection" (Section 10.14.5 Implicit termination of tasks), re-issue missing commands, and implicitly terminate all active commands. This option requires support for the within-connection recovery class (Section 6.1.4.2 Recovery Within-connection).
- 注销连接，原因码为“关闭连接”（第10.14.5节“隐式终止任务”），重新发出缺失的命令，并隐式终止所有活动命令。此选项要求支持连接内恢复类（第6.1.4.2节连接内恢复）。
- Perform session recovery (Section 6.1.4.4 Session Recovery).
- 执行会话恢复（第6.1.4.4节会话恢复）。
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 5.3.5).
- 重置或关闭所有传输连接。-在启动新会话之前，使用适当的响应终止所有未完成的请求。如果打算重新建立相同的I_T nexus，则发起方必须采用会话恢复（见第5.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). - Terminates all active tasks that were allegiant to the connection(s) that constituted the session.
- 重置或关闭TCP连接（关闭会话）。-终止与构成会话的连接相关的所有活动任务。
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 state diagrams for ease in understanding. The first diagram, "standard connection state diagram", 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 diagram, "connection cleanup state diagram", describes the connection state transitions while performing the iSCSI connection cleanup.
为了便于理解，连接状态转换在两个独立但相关的状态图中进行了描述。第一个图“标准连接状态图”描述了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 state transitions are described in the 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 -initiator: State on instantiation, or after successful connection closure. -target: State on instantiation, or after successful connection closure. -S2: XPT_WAIT -initiator: Waiting for a response to its transport connection establishment request. -target: Illegal -S3: XPT_UP -initiator: Illegal -target: Waiting for the Login process to commence. -S4: IN_LOGIN -initiator: Waiting for the Login process to conclude, possibly involving several PDU exchanges. -target: Waiting for the Login process to conclude, possibly involving several PDU exchanges.
-S1：空闲-启动器：实例化时或成功关闭连接后的状态-目标：实例化时或成功关闭连接后的状态-S2:XPT_WAIT-启动器：等待对其传输连接建立请求的响应-目标：非法-S3:XPT\u UP-启动器：非法-目标：等待登录过程开始-S4：IN_登录-启动器：等待登录过程结束，可能涉及多个PDU交换-目标：等待登录过程结束，可能涉及多个PDU交换。
-S5: LOGGED_IN -initiator: In Full Feature Phase, waiting for all internal, iSCSI, and transport events. -target: In Full Feature Phase, waiting for all internal, iSCSI, and transport events. -S6: IN_LOGOUT -initiator: Waiting for a Logout response. -target: Waiting for an internal event signaling completion of logout processing. -S7: LOGOUT_REQUESTED -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 -initiator: Waiting for the context and/or resources to initiate the cleanup processing for this CSM. -target: Waiting for the cleanup process to start for this CSM.
-S5：已登录-启动器：处于全功能阶段，等待所有内部、iSCSI和传输事件-目标：处于全功能阶段，等待所有内部、iSCSI和传输事件-S6：IN_注销-发起人：等待注销响应-目标：等待内部事件信号完成注销处理-S7：请求注销-发起人：等待内部事件信号准备就绪以继续注销-目标：通过异步消息请求注销后，等待注销进程启动-S8:CLEANUP_WAIT-启动器：等待上下文和/或资源启动此CSM的清理处理-目标：等待此CSM的清理进程启动。
-T1: -initiator: Transport connect request was made (e.g., TCP SYN sent). -target: Illegal -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: -initiator: Illegal -target: Received a valid transport connection request that establishes the transport connection. -T4: -initiator: Transport connection established, thus prompting the initiator to start the iSCSI Login. -target: Initial iSCSI Login Request was received. -T5: -initiator: The final iSCSI Login Response with a Status-Class of zero was received. -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.
-T1:-发起方：已发出传输连接请求（例如，已发送TCP SYN）-目标：非法-T2:-启动器：传输连接请求超时，接收到传输重置，或者接收到在另一个连接上接收“关闭会话”注销请求的注销响应（成功）的内部事件-目标：非法-T3:-启动器：非法-目标：接收到建立传输连接的有效传输连接请求-T4:-启动器：已建立传输连接，从而提示启动器启动iSCSI登录-目标：收到初始iSCSI登录请求-T5:-启动器：收到状态类为零的最终iSCSI登录响应-目标：接收到结束登录阶段的最终iSCSI登录请求，从而提示目标发送状态类为零的最终iSCSI登录响应。
-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. -T7: -initiator - one of the following events caused the transition: - The final iSCSI Login Response was received with a non-zero Status-Class. - Login timed out. - A transport disconnect indication was received. - A transport reset was received. - An internal event was received indicating a transport timeout. - An internal event of receiving a Logout response (success) on another connection for a "close the session" Logout request was received.
-T6:-启动器：非法-目标：等待iSCSI登录超时、接收到传输断开连接指示、接收到传输重置或接收到表示传输超时的内部事件。在所有这些情况下，都要关闭连接-T7:-启动器-以下事件之一导致转换：-接收到具有非零状态类的最终iSCSI登录响应。-登录超时。-接收到传输断开连接指示。-已收到传输重置。-接收到指示传输超时的内部事件。-收到“关闭会话”注销请求的另一个连接上收到注销响应（成功）的内部事件。
In all these cases, the transport connection is closed.
在所有这些情况下，传输连接都是关闭的。
-target - one of the following events caused the transition: - 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. - Login timed out. - Transport disconnect indication was received. - Transport reset was received. - An internal event indicating a transport timeout was received. - On another connection a "close the session" Logout request was received. In all these cases, the connection is to be closed. -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 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 is received, thus prompting the target to close this connection cleanly.
-目标-以下事件之一导致转换：-接收到结束登录阶段的最终iSCSI登录请求，提示目标发送具有非零状态类的最终iSCSI登录响应。-登录超时。-已收到传输断开指示。-已收到传输重置。-接收到指示传输超时的内部事件。-在另一个连接上收到“关闭会话”注销请求。在所有这些情况下，都要关闭连接-T8:-启动器：收到另一个连接上的“关闭会话”注销请求的注销响应（成功）的内部事件，因此关闭此连接不需要进一步清理-目标：收到针对“关闭会话”注销请求在另一个连接上发送注销响应（成功）的内部事件，或收到成功连接/会话恢复的内部事件，从而提示目标干净地关闭此连接。
-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. -target: An iSCSI Logout request was received. -T11, T12: -initiator: Async PDU with AsyncEvent "Request Logout" was received. -target: An internal event that requires the decommissioning of the connection is received, thus causing an Async PDU with an AsyncEvent "Request Logout" to be sent. -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. -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 an internal event of a successful connection/session reinstatement is received. In all these cases, the transport connection is closed.
-T9，T10:-启动器：接收到一个内部事件，指示已准备好启动注销过程，从而提示启动器发送iSCSI注销-目标：收到iSCSI注销请求-T11、T12:-启动器：接收到带有AsyncEvent“请求注销”的异步PDU-目标：接收到要求断开连接的内部事件，从而导致发送带有AsyncEvent“Request Logout”的异步PDU-T13:-启动器：接收到iSCSI注销响应（成功），或者接收到在另一个连接上接收“关闭会话”注销请求的注销响应（成功）的内部事件-目标：收到一个内部事件，指示成功处理注销，提示发送iSCSI注销响应（成功）；收到在另一个连接上发送“关闭会话”注销请求的注销响应（成功）的内部事件；或者接收到成功恢复连接/会话的内部事件。在所有这些情况下，传输连接都是关闭的。
-T14: -initiator: Async PDU with AsyncEvent "Request Logout" was received again. -target: Illegal -T15, T16: -initiator: One or more of the following events caused this transition: -Internal event that indicates a transport connection timeout was received thus prompting transport RESET or transport connection closure. -A transport RESET. -A transport disconnect indication. -Async PDU with AsyncEvent "Drop connection" (for this CID). -Async PDU with AsyncEvent "Drop all connections". -target: One or more of the following events caused this transition: -Internal event that indicates a transport connection timeout was received, thus prompting transport RESET or transport connection closure. -An internal event of a failed connection/session reinstatement is received. -A transport RESET. -A transport disconnect indication.
-T14:-启动器：再次收到带有AsyncEvent“请求注销”的异步PDU-目标：非法-T15、T16:-启动器：以下一个或多个事件导致了此转换：-表示接收到传输连接超时的内部事件，从而提示传输重置或传输连接关闭-传输重置-传输断开指示-带有AsyncEvent“Drop connection”（用于此CID）的异步PDU-带有AsyncEvent“删除所有连接”的异步PDU-目标：以下一个或多个事件导致了此转换：-表示接收到传输连接超时的内部事件，从而提示传输重置或传输连接关闭-接收到连接/会话恢复失败的内部事件-传输重置-传输断开指示。
-Internal emergency cleanup event was received which prompts an Async PDU with AsyncEvent "Drop connection" (for this CID), or event "Drop all connections". -T17: -initiator: One or more of the following events caused this transition: -Logout response, (failure i.e., a non-zero status) was received, or Logout timed out. -Any of the events specified for T15 and T16. -target: One or more of the following events caused this transition: -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. -Any of the events specified for T15 and T16. -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 is received. In both these cases, the connection is closed.
-接收到内部紧急清理事件，该事件提示异步PDU使用AsyncEvent“断开连接”（对于此CID）或事件“断开所有连接”-T17:-启动器：以下一个或多个事件导致了此转换：-收到注销响应（失败，即非零状态），或注销超时-为T15和T16指定的任何事件-目标：导致此转换的以下一个或多个事件：-表示接收到注销处理失败的内部事件，提示发送注销响应（失败，即非零状态）-为T15和T16指定的任何事件-T18:-发起方：收到“关闭会话”注销请求的另一个连接上收到注销响应（成功）的内部事件-目标：收到针对“关闭会话”注销请求在另一个连接上发送注销响应（成功）的内部事件，或者收到成功连接/会话恢复的内部事件。在这两种情况下，连接都是关闭的。
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 S2: XPT_WAIT S4: IN_LOGIN S5: LOGGED_IN S6: IN_LOGOUT S7: LOGOUT_REQUESTED S8: CLEANUP_WAIT
S1：空闲S2:XPT\u等待S4:IN\u登录S5:LOGGED\u登录S6:IN\u注销S7:LOGOUT\u请求S8:CLEANUP\u等待
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 S3: XPT_UP S4: IN_LOGIN S5: LOGGED_IN S6: IN_LOGOUT S7: LOGOUT_REQUESTED S8: CLEANUP_WAIT
S1：空闲S3:XPT\U向上S4:IN\U登录S5:LOGGED\U登录S6:IN\U注销S7:LOGOUT\U请求S8:CLEANUP\U等待
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) R2: IN_CLEANUP R3: FREE (same as S1)
R1:清理等待（与S8相同）R2:清理中R3:空闲（与S1相同）
Whenever a connection state machine (e.g., CSM-C) enters the CLEANUP_WAIT state (S8), it must go through the state transitions described in the connection cleanup state diagram either a) using a separate full-feature phase connection (let's call it CSM-E) in the LOGGED_IN state in the same session, or b) using a new transport connection (let's call it CSM-I) 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 (either as 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 5.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 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-C）进入清除等待状态（S8），它必须通过连接清除状态图中描述的状态转换，a）使用同一会话中处于登录状态的单独全功能阶段连接（我们称之为CSM-e），或b）使用新的传输连接（我们称之为CSM-I）处于要添加到同一会话的空闲状态。在CSM-E情况下，对应于CSM-C的CID的显式注销（作为连接或会话注销）需要执行以完成清理。在CSM-I情况下，需要通过连接恢复的方式执行对应于CSM-C的CID的隐式注销（第5.3.4节）对于该CID。在这两种情况下，CSM-E或CSM-I上的协议交换确定CSM-C的状态转换。因此，此清理状态图仅适用于清理中的连接实例（即CSM-C）。例如，在隐式注销的情况下，CSM-C达到自由（R3）在CSM-I到达LOGGED_IN时。在显式注销的情况下，当CSM-E在继续处于LOGGED_IN状态时收到成功的注销响应时，CSM-C到达FREE（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.
以下状态图适用于启动器和目标。
-------
/ 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) -initiator: Waiting for the internal event to initiate the cleanup processing for CSM-C. -target: Waiting for the cleanup process to start for CSM-C. -R2: IN_CLEANUP -initiator: Waiting for the connection cleanup process to conclude for CSM-C. -target: Waiting for the connection cleanup process to conclude for CSM-C. -R3: FREE (Same as S1) -initiator: End state for CSM-C. -target: End state for CSM-C.
-R1：清理_等待（与S8相同）-启动器：等待内部事件启动CSM-C的清理处理。-目标：等待CSM-C的清理过程启动。-R2:IN_cleanup-启动器：等待CSM-C的连接清理过程结束。-目标：等待CSM-C的连接清理过程结束。-R3:空闲（与S1相同）-启动器：CSM-C的结束状态。-目标：CSM-C的结束状态。
-M1: One or more of the following events was received: -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.
-M1:接收到以下一个或多个事件：-启动器：-指示连接状态超时的内部事件-在“关闭会话”注销的不同连接上接收成功注销响应的内部事件-目标：-指示连接状态超时的内部事件-针对“关闭会话”注销请求在不同连接上发送注销响应（成功）的内部事件。
-M2: An implicit/explicit logout process was initiated by the initiator. -In CSM-I usage: -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. -target: A connection/session reinstatement Login was received while in state XPT_UP. -In CSM-E usage: -initiator: An internal event that indicates that an explicit logout was sent for this CID in state LOGGED_IN. -target: An explicit logout was received for this CID in state LOGGED_IN.
-M2:启动器启动了隐式/显式注销过程-在CSM-I用法中：-启动器：收到请求恢复连接（或会话）的内部事件，从而提示发送连接（或会话）恢复登录，将CSM-I转换为\u登录中的状态-目标：在处于XPT_UP状态时收到连接/会话恢复登录-在CSM-E用法中：-启动器：一个内部事件，指示此处于已登录状态的CID已发送显式注销-目标：收到此处于已登录状态的CID的显式注销。
-M3: Logout failure detected -In CSM-I usage: -initiator: CSM-I failed to reach LOGGED_IN and arrived into FREE instead. -target: CSM-I failed to reach LOGGED_IN and arrived into FREE instead. -In CSM-E usage: -initiator: CSM-E either moved out of LOGGED_IN, or Logout timed out and/or aborted, or Logout response (failure) was received. -target: CSM-E either moved out of LOGGED_IN, Logout timed out and/or aborted, or an internal event that indicates a failed Logout processing was received. A Logout response (failure) was sent in the last case.
-M3：检测到注销失败-在CSM-I使用中：-启动器：CSM-I未能到达已登录的\u，而是到达空闲状态-目标：CSM-I未能到达登录的_，而是到达免费-在CSM-E使用中：-启动器：CSM-E已从登录中移出，或注销超时和/或中止，或收到注销响应（失败）-目标：CSM-E移出已登录、注销超时和/或中止，或者接收到表明注销处理失败的内部事件。在最后一个案例中发送了注销响应（失败）。
-M4: Successful implicit/explicit logout was performed.
-M4:执行了成功的隐式/显式注销。
- In CSM-I usage: -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. -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. - In CSM-E usage: -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. -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-I用法中：-启动器：CSM-I达到已登录状态，或收到另一个连接上收到“关闭会话”注销请求的注销响应（成功）的内部事件-目标：CSM-I已达到已登录状态，或收到“关闭会话”注销请求在不同连接上发送注销响应（成功）的内部事件。-在CSM-E用法中：-启动器：CSM-E保持登录状态并收到注销响应（成功），或者收到另一个连接上收到“关闭会话”注销请求的注销响应（成功）的内部事件-目标：CSM-E保持登录状态，并收到指示成功注销处理的内部事件，或收到针对“关闭会话”注销请求在不同连接上发送注销响应（成功）的内部事件。
Symbolic Names for States:
国家的符号名称：
Q1: FREE Q3: LOGGED_IN Q4: FAILED
第一季度：免费第三季度：第四季度中登录的\u：失败
State Q3 represents the Full Feature Phase operation of the session.
状态Q3表示会话的完整功能阶段操作。
The state diagram is as follows:
状态图如下所示：
-------
/ 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 Q2: ACTIVE Q3: LOGGED_IN Q4: FAILED Q5: IN_CONTINUE
Q1:可用Q2:活动Q3:登录Q4:失败Q5:继续
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 -initiator: State on instantiation or after cleanup. -target: State on instantiation or after cleanup.
-Q1：自由-启动器：实例化时或清理后的状态-目标：实例化时或清理后的状态。
-Q2: ACTIVE -initiator: Illegal. -target: The first iSCSI connection in the session transitioned to IN_LOGIN, waiting for it to complete the login process.
-问题2：活动-启动器：非法-目标：会话中的第一个iSCSI连接已转换为in_登录，等待它完成登录过程。
-Q3: LOGGED_IN -initiator: Waiting for all session events. -target: Waiting for all session events.
-问题3：已登录-启动器：等待所有会话事件-目标：等待所有会话事件。
-Q4: FAILED -initiator: Waiting for session recovery or session continuation. -target: Waiting for session recovery or session continuation.
-问题4：失败-启动器：正在等待会话恢复或会话继续-目标：等待会话恢复或会话继续。
-Q5: IN_CONTINUE -initiator: Illegal. -target: Waiting for session continuation attempt to reach a conclusion.
-问题5：IN_CONTINUE-启动器：非法-目标：等待会话继续尝试得出结论。
-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.
-N1:-启动器：至少有一个传输连接达到登录状态-目标：会话中的第一个iSCSI连接已达到in_登录状态。
-N2: -initiator: Illegal. -target: At least one iSCSI connection reached the LOGGED_IN state.
-N2:-发起人：非法-目标：至少有一个iSCSI连接达到登录状态。
-N3: -initiator: Graceful closing of the session via session closure (Section 5.3.6 Session Continuation and Failure). -target: Graceful closing of the session via session closure (Section 5.3.6 Session Continuation and Failure) or a successful session reinstatement cleanly closed the session.
-N3:-发起方：通过会话关闭（第5.3.6节会话继续和失败）优雅地关闭会话-目标：通过会话关闭（第5.3.6节会话继续和失败）优雅地关闭会话，或成功地恢复会话干净地关闭会话。
-N4: -initiator: A session continuation attempt succeeded. -target: Illegal.
-N4:-发起方：会话继续尝试成功-目标：非法。
-N5: -initiator: Session failure (Section 5.3.6 Session Continuation and Failure) occurred. -target: Session failure (Section 5.3.6 Session Continuation and Failure) occurred.
-N5:-发起人：发生会话失败（第5.3.6节会话继续和失败）-目标：发生会话失败（第5.3.6节会话继续和失败）。
-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.
-N6:-启动器：发生会话状态超时，或会话恢复已清除此会话实例。这将导致释放所有相关资源，并丢弃会话状态-目标：发生会话状态超时，或会话恢复已清除此会话实例。这将导致释放所有相关资源，并丢弃会话状态。
-N7: -initiator: Illegal. -target: A session continuation attempt is initiated.
-N7:-发起人：非法-目标：启动会话继续尝试。
-N8: -initiator: Illegal. -target: The last session continuation attempt failed.
-N8:-发起人：非法-目标：上次会话继续尝试失败。
-N9: -initiator: Illegal. -target: Login attempt on the leading connection failed.
-N9:-发起人：非法-目标：尝试登录前导连接失败。
-N10: -initiator: Illegal. -target: A session continuation attempt succeeded.
-N10:-发起人：非法-目标：会话继续尝试成功。
-N11: -initiator: Illegal. -target: A successful session reinstatement cleanly closed the session.
-N11:-发起人：非法-目标：成功的会话恢复干净地关闭了会话。
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. iSCSI configured without security should be confined, in extreme cases, to closed environments without any security risk. [RFC3723] specifies the mechanisms that must be used in order to mitigate risks fully described in that document.
尽管在技术上可行，但在配置iSCSI时不应缺少安全性。在极端情况下，在没有安全性的情况下配置的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 end points. iSCSI scenarios in which multiple initiators or targets share a single communication end point are expected. To accommodate such scenarios, iSCSI uses 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 end points.
iSCSI安全性涉及的实体包括启动器、目标和IP通信端点。iSCSI场景中，多个启动器或目标共享一个通信端点。为了适应这种情况，iSCSI使用了两种独立的安全机制：iSCSI连接级别的启动器和目标之间的带内身份验证（由iSCSI登录PDU的交换执行），以及IP级别的IPsec数据包保护（完整性、身份验证和机密性）。这两种安全机制相辅相成。带内身份验证在iSCSI启动器和目标之间提供端到端信任（登录时），而IPsec在IP通信端点之间提供安全通道。
Further details on typical iSCSI scenarios and the relation between the initiators, targets, and the communication end points 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 clear text (or equivalent) passwords is not acceptable; 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 clear. The authentication
身份验证机制通过使用虚假身份（欺骗）防止未经授权登录到存储资源。身份验证阶段完成后，如果未使用基础IPsec，则所有PDU都将以明文形式发送和接收。认证
mechanism alone (without underlying IPsec) should only be used when there is no risk of eavesdropping, message insertion, deletion, modification, and replaying.
仅当不存在窃听、消息插入、删除、修改和重播的风险时，才应使用单独的机制（没有底层IPsec）。
Section 11 iSCSI Security Text Keys and Authentication Methods 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. Whenever an iSCSI target gets a 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 "Authentication Failure" status MUST be specified. The importance of this rule can be illustrated in CHAP with target authentication (see Section 11.1.4 Challenge Handshake Authentication Protocol (CHAP)) where the initiator would have been able to conduct a reflection attack by omitting his 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.
第11节iSCSI安全文本密钥和身份验证方法定义了几种身份验证方法以及在每种方法中必须遵循的确切步骤，包括iSCSI文本密钥及其在每个步骤中允许的值。每当iSCSI启动器收到密钥或其值不符合步骤定义的响应时，它必须中止连接。每当iSCSI目标收到其密钥或其值不符合步骤定义的响应时，它必须以“启动器错误”或“缺少参数”状态的登录拒绝进行响应。这些状态不适用于加密错误的值，例如CHAP响应，必须为其指定“身份验证失败”状态。此规则的重要性可以在CHAP中通过目标身份验证（参见第11.1.4节质询握手身份验证协议（CHAP））进行说明，其中启动器可以通过省略其响应密钥（CHAP）来进行反射攻击使用与目标相同的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 11.1.4 Challenge Handshake Authentication Protocol (CHAP) and SRP_U, see Section 11.1.3 Secure Remote Password (SRP)).
对于某些身份验证方法，密钥指定用于身份验证的iSCSI启动器或目标的标识。与该密钥关联的值可能与iSCSI名称不同，并且应该是可配置的。（第N章，见第11.1.4节质询握手认证协议（CHAP）和SRP，见第11.1.3节安全远程密码（SRP））。
Compliant iSCSI initiators and targets MUST implement the CHAP authentication method [RFC1994] (according to Section 11.1.4 Challenge Handshake Authentication Protocol (CHAP) including the target authentication option).
符合要求的iSCSI启动器和目标必须实施CHAP身份验证方法[RFC1994]（根据第11.1.4节挑战握手身份验证协议（CHAP），包括目标身份验证选项）。
When CHAP is performed over a non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support 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
CHAP与少于96个随机位的秘密一起使用的环境的管理实体必须实施IPsec加密（根据第节中的实现要求）
8.3.2 Confidentiality) 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.
8.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, Section 11.1.4 Challenge Handshake Authentication Protocol (CHAP)) 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，第11.1.4节质询握手身份验证协议（CHAP）），除非它可以验证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机密和身份。以下是通过上述要求防止的攻击示例：
Rogue wants to impersonate Storage to Alice, and knows that a single secret is used for both directions of Storage-Alice authentication.
Rogue想向Alice模拟存储，并且知道存储Alice身份验证的两个方向都使用一个秘密。
Rogue convinces Alice to open two connections to Rogue, and Rogue identifies itself as Storage on both connections.
Rogue说服Alice打开到Rogue的两个连接，Rogue将自己标识为两个连接上的存储器。
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.
Rogue在连接1上发出CHAP质询，等待Alice响应，然后将Alice的质询反映为连接2上对Alice的初始质询。
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.
如果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 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. - 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) to verify the target's CHAP responses and do not know the target's CHAP secret.
在单个管理域内：-单个CHAP密钥可用于启动器到多个目标的身份验证。-当发起方使用外部服务器（例如RADIUS）验证目标的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 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 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.
如果未使用外部响应验证服务器（例如RADIUS），则使用单个CHAP机密对多个启动器进行目标身份验证需要所有此类启动器都知道该目标机密。这些启动器中的任何一个都可以向任何其他此类启动器模拟目标，而此类启动器的泄露使攻击者能够向所有此类启动器模拟目标。当存在此类风险时，目标公司应使用单独的CHAP机密对每个启动器进行身份验证；在这种情况下，可能需要为每个启动器或启动器组配置一个单独的逻辑iSCSI目标，其中每个启动器或启动器组都有自己的iSCSI节点名。
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-German 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-German素数（形式为N=2q+1，其中q也是素数），且生成器g是GF（N）的本原根。在iSCSI身份验证中，基本模数N必须至少为768位。
The list of allowed SRP groups is provided in [RFC3723].
[RFC3723]中提供了允许的SRP组列表。
iSCSI uses the IPsec mechanism for packet protection (cryptographic integrity, authentication, and confidentiality) at the IP level between the iSCSI communicating end points. The following sections describe the IPsec protocols that must be implemented for data integrity and authentication, 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].
[RFC3723]中提供了将IPsec用于iSCSI的详细注意事项和建议。
Data authentication and integrity is 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 integrity and authentication by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide data integrity and authentication by implementing IPsec with ESP in transport mode. The IPsec implementation MUST fulfill the following iSCSI specific requirements:
符合iSCSI的启动器或目标必须通过在隧道模式下使用ESP[RFC2406]实现IPsec[RFC2401]来提供数据完整性和身份验证，并且可以通过在传输模式下使用ESP实现IPsec来提供数据完整性和身份验证。IPsec实施必须满足以下特定于iSCSI的要求：
- HMAC-SHA1 MUST be implemented [RFC2404]. - AES CBC MAC with XCBC extensions SHOULD be implemented [RFC3566].
- 必须实施HMAC-SHA1[RFC2404]。-应实施带有XCBC扩展的AES CBC MAC[RFC3566]。
The ESP anti-replay service MUST also be implemented.
还必须实施ESP防重播服务。
At the high speeds iSCSI is expected to operate, a single IPsec SA could rapidly cycle through the 32-bit IPsec sequence number space. In view of this, it may be desirable in the future for an iSCSI implementation that operates at speeds of 1 Gbps or greater to implement the IPsec sequence number extension [SEQ-EXT].
在iSCSI预期运行的高速率下，单个IPsec SA可以在32位IPsec序列号空间中快速循环。有鉴于此，未来可能需要以1 Gbps或更高速度运行的iSCSI实现来实现IPsec序列号扩展[SEQ-EXT]。
Confidentiality is provided by encrypting the data in every packet. When confidentiality is used it MUST be accompanied by data integrity and authentication to provide comprehensive protection against eavesdropping, message insertion, deletion, modification, and replaying.
通过加密每个数据包中的数据来提供机密性。当使用保密性时，它必须伴随着数据完整性和身份验证，以提供全面的保护，防止窃听、消息插入、删除、修改和重播。
An iSCSI compliant initiator or target MUST provide confidentiality by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide confidentiality by implementing IPsec with ESP in transport mode, with the following iSCSI specific requirements:
符合iSCSI的启动器或目标必须通过在隧道模式下使用ESP[RFC2406]实现IPsec[RFC2401]来提供机密性，并且可以通过在传输模式下使用ESP实现IPsec来提供机密性，具体要求如下：
- 3DES in CBC mode MUST be implemented [RFC2451]. - AES in Counter mode SHOULD be implemented [RFC3686].
- 必须在CBC模式下实施3DE[RFC2451]。-应实现计数器模式下的AES[RFC3686]。
DES in CBC mode SHOULD NOT be used due to its inherent weakness. The NULL encryption algorithm MUST also be implemented.
CBC模式下的DES由于其固有的弱点不应使用。还必须实现空加密算法。
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] with the following iSCSI specific requirements:
符合要求的iSCSI实施必须满足IPsec协议套件的加密密钥管理要求。身份验证、安全关联协商和加密密钥管理必须通过使用IPsec DOI[RFC2407]实现IKE[RFC2409]，并满足以下特定于iSCSI的要求来提供：
- Peer authentication using a pre-shared cryptographic key MUST be supported. Certificate-based peer authentication using digital signatures MAY be supported. Peer authentication using the public key encryption methods outlined in IKE sections 5.2 and 5.3[7] SHOULD NOT be used.
- 必须支持使用预共享加密密钥的对等身份验证。可能支持使用数字签名的基于证书的对等身份验证。不应使用IKE第5.2节和第5.3节[7]中概述的使用公钥加密方法的对等身份验证。
- 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 the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE authentication procedures.
- 当使用数字签名实现身份验证时，IKE谈判者应使用IKE证书请求有效载荷来指定证书颁发机构。IKE谈判者在接受用于IKE身份验证过程的PKI证书之前，应检查相关的证书撤销列表（CRL）。
- Conformant iSCSI implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE main mode with pre-shared key authentication method SHOULD NOT be used when either the initiator or the target uses dynamically assigned IP 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.
- 一致的iSCSI实施必须支持IKE主模式，并应支持主动模式。当启动器或目标使用动态分配的IP地址时，不应使用带有预共享密钥身份验证方法的IKE主模式。虽然在许多情况下，预共享密钥提供了良好的安全性，但在使用动态分配的地址的情况下，强制使用组预共享密钥，这会造成中间人攻击的漏洞。
- In the IKE Phase 2 Quick Mode, exchanges for creating the Phase 2 SA, the Identity Payload, fields MUST be present. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) and ID_FQDN Identity payloads MUST be supported; ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN formats SHOULD NOT be used. The ID_KEY_ID Identity Payload MUST NOT be used.
- 在IKE第2阶段快速模式中，必须存在用于创建第2阶段SA（身份有效负载）的交换字段。必须支持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标识有效负载。
Manual cryptographic keying MUST NOT be used because it does not provide the necessary re-keying support.
不得使用手动加密键控，因为它不提供必要的重新键控支持。
When IPsec is used, the receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down the iSCSI TCP connection. If additional traffic is sent on it, a new IKE Phase 2 SA will be created to protect it.
使用IPsec时，接收IKE第2阶段删除消息不应被解释为断开iSCSI TCP连接的原因。如果在其上发送额外的通信量，将创建一个新的IKE阶段2 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标准中没有定义。
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。
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 3.4.3 Consequences of the Model.
还建议实施者考虑ISCSI对SCSI映射模型的实施后果，如在3.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
iSCSI协议允许多个连接，而不是所有连接都需要通过同一网络适配器。如果要在硬件支持下使用多个网络连接，则iSCSI协议
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.
命令数据状态与一个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 clauses (particularly, Section 3.4.2 SCSI Architecture Model) 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.
过去，SCSI模型（以及基于该模型的实现和应用程序）假定SCSI端口是静态的物理实体。SCSI模型的最新扩展利用了这些端口的持久全球唯一名称。但是，在iSCSI中，SCSI启动器端口是动态创建会话的端点，因此“静态和物理”的假设不适用。在任何情况下，模型条款（特别是第3.4.2节SCSI体系结构模型）为iSCSI类型SCSI启动器端口提供了持久的、可重用的名称，即使不需要任何物理实体绑定到这些名称。
To both minimize the disruption of legacy applications and to 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 to 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 3.4.3 Consequences of the Model) 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规则（第3.4.3节模型的后果）仅禁止对同一目标门户组进行重用。它并不“排除”对其他目标门户组的重用。保守重用原则“鼓励”对其他目标门户组进行重用。当SCSI目标设备在不同的会话中看到同一对（InitiatorName，ISID）到不同的目标门户组时，它可以将每个会话上的底层SCSI启动器端口标识为相同的SCSI端口。实际上，它可以识别来自同一源的多条路径。
The designers of the iSCSI protocol envisioned there being one iSCSI Initiator Node Name per operating system image on a machine. This enables SAN resource configuration and authentication schemes based on a system's identity. It supports the notion that it should be possible to assign access to storage resources based on "initiator device" identity.
iSCSI协议的设计者设想机器上的每个操作系统映像都有一个iSCSI启动器节点名称。这将启用基于系统标识的SAN资源配置和身份验证方案。它支持这样一种概念，即应该可以根据“启动器设备”标识分配对存储资源的访问。
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 (ISID for initiators) to enforce both the ISID and TSIH RULES (see Section 3.4.3 Consequences of the Model).
当有多个硬件或软件组件协调为单个iSCSI节点时，必须有某个（逻辑）实体表示iSCSI节点，使iSCSI节点名称可用于会话创建和登录中涉及的所有组件。类似地，此表示iSCSI节点的实体必须能够协调会话标识符资源（启动器的ISID），以强制实施ISID和TSIH规则（请参见第3.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 anytime 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 either by pointing the component to a vendor-specific location for this datum or to a system-wide location. The structure of the ISID namespace (see Section 10.12.5 ISID 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 3.4.3 Consequences of the Model) at the initiator.
认识到目前还没有此类启动器API，可以实现该实体角色的其他实现。例如，在会话创建和登录所涉及的每个iSCSI组件的安装过程中，人员可以实例化（公共）节点名称。这可以通过将部件指向该基准的供应商特定位置或系统范围内的位置来实现。ISID名称空间的结构（见第10.12.5节ISID和[RFC3721]）通过允许每个组件供应商以特定于供应商的方式（独立于其他供应商的组件）协调分配、使用和重用其自己的ISID名称空间分区，促进了ISID协调的实施。在该供应商管理的发起方门户组内对ISID命名空间进行分区，允许每个此类发起方门户组在选择ISID进行登录时独立于所有其他门户组进行操作；这有助于在发起方实施ISID规则（见第3.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 unique worldwide. It is therefore important that when one chooses to reuse the iSCSI Node Name of a disabled unit, not to re-assign 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 pre-assigned 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 be via public APIs (perhaps driven by an independent vendor's software, such as the OS vendor) or via private APIs driven by the vendor's own software.
此外，iSCSI硬件供应商必须实施一种机制，为给定iSCSI节点内由该硬件的多个实例管理的所有会话配置和/或协调ISID。此类配置可以在工厂永久预分配（以必要的全局唯一方式）、静态分配（例如，在初始化时以本地唯一方式跨所有NIC分区）或动态分配（例如，在线分配器，也以本地唯一方式）。在后两种情况下，配置可以通过公共API（可能由独立供应商的软件驱动，例如OS供应商）或通过由供应商自己的软件驱动的私有API。
Autosense refers to the automatic return of sense data to the initiator in case a command did not complete successfully. iSCSI initiators and targets MUST support and use autosense.
Autosense是指在命令未成功完成的情况下，自动将感知数据返回到启动器。iSCSI启动器和目标必须支持并使用autosense。
ACA helps preserve ordered command execution in the presence of errors. As iSCSI can have many commands in-flight between initiator and target, iSCSI initiators and targets SHOULD support ACA.
ACA有助于在出现错误时保持命令的有序执行。由于iSCSI可以在启动器和目标之间执行许多命令，因此iSCSI启动器和目标应支持ACA。
iSCSI recovery actions are often dependent on iSCSI time-outs being recognized and acted upon before SCSI time-outs. Determining the right time-outs to use for various iSCSI actions (command acknowledgements expected, status acknowledgements, etc.) is very much dependent on infrastructure (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 the network load variability. For connection teardown the implementer may want to consider also the 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 SHOULD be generous enough to avoid affecting interoperability (e.g., allowing each key to be negotiated on a separate exchange).
文本谈判也可能受到时间限制或交流次数限制的限制。这些应该足够慷慨，以避免影响互操作性（例如，允许在单独的交换上协商每个密钥）。
The relation 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 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超时应长于iSCSI超时加上iSCSI恢复所需的时间。或者，实施者可以选择将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 wrap around, the protocol requires (see Section 3.2.2.1 Command Numbering and Acknowledging) that on every connection on which a retry has been issued, a non-immediate command be issued and acknowledged within a 2**31-1 commands interval from the CmdSN of the retried command. This requirement can be fulfilled by an implementation in several ways.
为避免在命令序列号换行后，旧的重试命令实例出现在有效的命令窗口中，协议要求（参见第3.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. As 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 synch and steering layer is optional, an initiator/target that does not have it working against a target/initiator that demands synch and steering may experience performance degradation caused by packet reordering and loss. Providing a synch and steering mechanism is recommended for all high-speed implementations.
虽然同步和引导层是可选的，但没有同步和引导层的启动器/目标与要求同步和引导的目标/启动器协同工作时，可能会因数据包重新排序和丢失而导致性能下降。对于所有高速实施，建议提供同步和转向机构。
9.6. Considerations for State-dependent Devices and Long-lasting SCSI Operations
9.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 is 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 re-issued due to no status received for the command. If the first SPACE command was actually processed, the re-issued 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空间命令用于退一个文件框，然后由于没有接收到命令的状态而重新发布。如果实际处理了第一个空格命令，则重新发出的空格命令（如果已处理）将导致位置更改。因此，随后的写入操作会将数据写入错误的位置，并且该位置的任何先前数据都将被覆盖。
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 re-issued due to no status received for the command. If the first EXCHANGE MEDIUM command was actually processed, the re-issued EXCHANGE MEDIUM command, if processed, will perform the swap again. The net effect is that a swap was not performed thus leaving a data integrity exposure.
对于介质交换设备，考虑交换媒体命令（源地址和目的地址是相同的，因此执行交换）的情况，然后由于没有接收到命令的状态而重新发布。如果实际处理了第一个EXCHANGE介质命令，则重新发出的EXCHANGE介质命令（如果已处理）将再次执行交换。净影响是没有执行交换，因此留下了数据完整性暴露。
All commands that change the state of the device (as in SPACE commands for sequential access devices, and EXCHANGE MEDIUM for medium changer device), MUST be issued as non-immediate commands for deterministic and in order 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 SCSI level is difficult and error recovery at 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. b) Required level of availability in the face of transport connection failures. c) Probability of transport layer "checksum escape". 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.
a) 应用程序对I/O故障的恢复能力。b） 面临传输连接故障时所需的可用性级别。c） 传输层“校验和转义”的概率。这进而决定了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 the connection failure is also of high likelihood 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。
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 zero 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.
除非另有规定，否则任何符合要求的发送方必须将所有未定义的位和所有保留字段设置为零。除非另有规定，否则任何兼容接收器必须忽略任何未定义的位和所有保留字段。接收到定义字段中的保留代码值时，必须报告为协议错误。
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 four byte words. The padding bytes SHOULD be sent as 0.
iSCSI PDU填充到最接近的四字节字整数。填充字节应作为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 four byte words. For example, all PDU segments and digests start at a four byte word boundary and the padding ranges from 0 to 3 bytes. The padding bytes SHOULD be sent as 0.
所有PDU段和摘要填充到最接近的四字节字整数。例如，所有PDU段和摘要都从四字节字边界开始，填充范围为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 0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block) 0x02 SCSI Task Management function request 0x03 Login Request 0x04 Text Request 0x05 SCSI Data-Out (for WRITE operations) 0x06 Logout Request 0x10 SNACK Request 0x1c-0x1e Vendor specific codes
0x00 NOP Out 0x01 SCSI命令（封装SCSI命令描述符块）0x02 SCSI任务管理功能请求0x03登录请求0x04文本请求0x05 SCSI数据输出（用于写入操作）0x06注销请求0x10零食请求0x1c-0x1e供应商特定代码
Target opcodes are:
目标操作码是：
0x20 NOP-In 0x21 SCSI Response - contains SCSI status and possibly sense information or other response information. 0x22 SCSI Task Management function response 0x23 Login Response 0x24 Text Response 0x25 SCSI Data-In - for READ operations. 0x26 Logout Response 0x31 Ready To Transfer (R2T) - sent by target when it is ready to receive data. 0x32 Asynchronous Message - sent by target to indicate certain special conditions. 0x3c-0x3e Vendor specific codes 0x3f Reject
0x21 SCSI响应中的0x20 NOP-包含SCSI状态以及可能的检测信息或其他响应信息。0x22 SCSI任务管理功能响应0x23登录响应0x24文本响应0x25 SCSI数据输入-用于读取操作。0x26注销响应0x31准备传输（R2T）-由目标在准备接收数据时发送。0x32异步消息-由目标发送以指示某些特殊情况。0x3c-0x3e供应商特定代码0x3f拒绝
All other opcodes are reserved.
保留所有其他操作码。
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.
对于不同的操作码类型，这些字段具有不同的含义。
Total length of all AHS header segments in units of four byte words including padding, if any.
所有AHS头段的总长度，以四字节字为单位，包括填充（如有）。
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 Logical Unit. The Logical Unit Number (LUN) field identifies which Logical Unit. If the opcode does not relate to a Logical Unit, this field is either ignored or may be used in an opcode specific way. The LUN field is 64-bits and should
某些操作码在特定的逻辑单元上运行。逻辑单元号（LUN）字段标识了哪个逻辑单元。如果操作码与逻辑单元无关，则该字段将被忽略或以特定于操作码的方式使用。LUN字段为64位，应为
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.
按照[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命令也是唯一的。
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 1 - Extended CDB 2 - Expected Bidirectional Read Data Length 3 - 63 Reserved
0-保留1-扩展CDB 2-预期双向读取数据长度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. The length includes the reserved byte 3.
如果CDBLength小于17，则不得使用此类AHS。长度包括保留字节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| Expected Read-Data 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| Expected Read-Data 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 are:
SCSI命令的标志为：
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 1 - Simple 2 - Ordered 3 - Head of Queue 4 - ACA 5-7 - Reserved
0-未标记1-简单2-有序3-队列头4-ACA 5-7-保留
Setting both the W and the F bit to 0 is an error. Either or both of R and W MAY be 1 when either the Expected Data Transfer Length and/or 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).
将W和F位都设置为0是一个错误。当预期数据传输长度和/或双向读取预期数据传输长度为0时，R和W中的一个或两个可以为1，但当预期数据传输长度和/或双向读取预期数据传输长度不为0时，它们不能同时为0（即，当预期进行某些数据传输时，传输方向由R和/或W位指示）。
Enables ordered delivery across multiple connections in a single session.
在单个会话中跨多个连接启用有序传递。
Command responses up to ExpStatSN-1 (mod 2**32) have been received (acknowledges status) on the connection.
已在连接上接收到ExpStatSN-1（mod 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 SAM2 byte count.
对于单向操作，预期数据传输长度字段包含此SCSI操作中涉及的数据字节数。对于单向写入操作（W标志设置为1，R标志设置为0），启动器使用此字段指定它希望为此操作传输的数据字节数。对于单向读取操作（W标志设置为0，R标志设置为1），启动器使用此字段指定它希望目标传输到启动器的数据字节数。它对应于SAM2字节计数。
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 SAM2 byte count
对于双向操作（R和W标志均设置为1），此字段包含写入传输中涉及的数据字节数。对于双向操作，报头序列中必须存在一个额外的报头段，用于指示双向读取预期的数据传输长度。预期数据传输长度字段和双向读取预期数据传输长度字段对应SAM2字节计数
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
某些SCSI命令需要额外的参数数据来伴随SCSI命令。此数据可能放置在数据段中iSCSI标头的边界之外。或者，用户数据（例如，来自写入操作）可以放置在数据段中（两种情况都是相同的）
referred to as immediate data). These data are governed by the rules for solicited vs. unsolicited data outlined in Section 3.2.4.2 Data Transfer Overview.
称为即时数据）。这些数据受第3.2.4.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 Expected Bidirectional Read 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). For a response other than "Command Completed at Target", bits 3-6 MUST be 0.
位O和U以及位O和U是互斥的（即，将O和U或O和U都设置为1是协议错误）。对于“在目标完成命令”以外的响应，位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 0x02 CHECK CONDITION 0x08 BUSY 0x18 RESERVATION CONFLICT 0x28 TASK SET FULL 0x30 ACA ACTIVE 0x40 TASK ABORTED
0x00良好0x02检查条件0x08忙0x18保留冲突0x28任务集已满0x30 ACA活动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 0x01 - Target Failure 0x80-0xff - Vendor specific
0x00-命令在目标0x01处完成-目标故障0x80-0xff-特定于供应商
All other response codes are reserved.
保留所有其他响应代码。
The Response 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 [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.
响应用于报告服务响应。如果需要，将响应代码映射为SCSI服务响应代码值超出了本文档的范围。但是，在符号术语中，响应值0x00映射到任务完成或链接命令完成的SCSI服务响应（请参见[SAM2]和[SPC3]）。所有其他响应值映射到服务交付或目标故障的SCSI服务响应。
If a PDU that includes SCSI status (Response PDU or Data-In PDU including status) does not arrive before the session is terminated, the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE.
如果包含SCSI状态（响应PDU或PDU中包含状态的数据）的PDU在会话终止前未到达，则SCSI服务响应为服务交付或目标故障。
A non-zero Response field indicates a failure to execute the command in which case the Status and Flag fields are undefined.
非零响应字段表示执行命令失败，在这种情况下，状态和标志字段未定义。
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 an 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 10.16 SNACK Request.
有关R-Data快餐的详细讨论，请参见第10.16节快餐请求。
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 is reserved. Targets may set the residual count and initiators may use it when the response code is "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位的情况下有效。如果未设置任何一位，则保留剩余计数字段。目标可以设置剩余计数，当响应代码“在目标完成”（即使返回的状态不好）时，启动器也可以使用它。如果设置了O位，则剩余计数表示由于启动器的预期数据传输长度不足而未传输的字节数。如果设置了U位，则剩余计数表示预期传输的字节数中未传输的字节数。
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 "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 Expected Bidirectional Read 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 /
/ /
+---------------+---------------+---------------+---------------+
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/ Response Data /
/ /
+---------------+---------------+---------------+---------------+
z|
Length of Sense Data.
感测数据的长度。
The Sense Data contains detailed information about a check condition and [SPC3] specifies the format and content of the Sense Data.
检测数据包含有关检查条件的详细信息，[SPC3]指定检测数据的格式和内容。
Certain iSCSI conditions result in the command being terminated at the target (response Command Completed at Target) with a SCSI Check Condition Status as outlined in the next table:
某些iSCSI条件导致命令在目标端终止（响应命令在目标端完成），SCSI检查条件状态如下表所示：
+--------------------------+----------+---------------------------+
| iSCSI Condition |Sense | Additional Sense Code & |
| |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 & |
| |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的数据量与请求的数据量不匹配时，目标会报告相同的错误。
The number of R2T and Data-In (read) PDUs the target has sent for the command.
目标为命令发送的（读取）PDU中的R2T和数据数。
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。
StatSN is a Sequence Number that the target iSCSI layer generates per connection and that in turn, enables the initiator to acknowledge status reception. StatSN is incremented by 1 for every response/status sent on a connection except for responses sent as a 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是目标iSCSI层为每个连接生成的序列号，反过来，它使启动器能够确认接收状态。对于连接上发送的每个响应/状态，StatSN都会增加1，但由于重试或中断而发送的响应除外。在由于重传请求而发送响应的情况下，StatSN必须与第一次发送PDU时相同，除非此后重新启动了连接。
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表示目标无法接受新命令。
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 MaxCmdSN is equal to ExpCmdSN-1, this indicates to the initiator that the target cannot receive any additional commands. When 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 logical unit.
2-中止任务集-中止通过此会话在逻辑单元上发布的所有任务。
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 Referenced Task Tag field to this connection, thus resuming the iSCSI exchanges for the task.
8-任务重新分配-将引用的任务标记字段标识的任务的连接忠诚重新分配到此连接，从而恢复该任务的iSCSI交换。
For all these functions, the Task Management function response MUST be returned as detailed in Section 10.6 Task Management Function Response. 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 with CmdSN equal or exceeding CmdSN.
对于所有这些功能，必须按照第10.6节任务管理功能响应中的详细说明返回任务管理功能响应。所有这些函数都适用于引用的任务，无论它们是正确的SCSI任务还是标记的iSCSI操作。任务管理请求必须作用于同一会话中CmdSN低于任务管理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 CmdSN lower than the task management command CmdSN) but except 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, 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. The issuing initiator SHOULD however terminate (i.e., by setting the F-bit to 1) these response sequences as quickly as possible. The target on its part MUST wait for responses on all affected target
对于中止任务集和清除任务集，发出的启动器必须继续响应与受影响任务集相关的所有有效目标传输标记（通过R2T、文本响应、NOP In或PDU中的SCSI数据接收），即使在发出任务管理请求之后也是如此。但是，发出的启动器应尽快终止（即，通过将F位设置为1）这些响应序列。目标必须等待所有受影响目标的响应
transfer tags before acting on either of these two task management requests. In case 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 within-command error recovery class (see Section 6.1.4.1 Recovery Within-command) if it is supporting ErrorRecoveryLevel >= 1, or alternatively may drop the connection to complete the requested task set function.
在对这两个任务管理请求中的任何一个执行操作之前转移标记。如果未收到有效TTT的全部或部分响应序列（由于摘要错误），目标可将其视为命令内错误恢复类（参见第6.1.4.1节命令内恢复），前提是其支持ErrorRecoveryLevel>=1，或者，也可以断开连接以完成请求的任务集功能。
If an ABORT TASK is issued for a task created by an immediate command then RefCmdSN MUST be that of the Task Management request itself (i.e., CmdSN and RefCmdSN are equal); otherwise RefCmdSN MUST be set to the CmdSN of the task to be aborted (lower than CmdSN).
如果为立即命令创建的任务发出中止任务，则RefCmdSN必须是任务管理请求本身的任务（即，CmdSN和RefCmdSN相等）；否则，必须将RefCmdSN设置为要中止的任务的CmdSN（低于CmdSN）。
If the connection is still active (it is not undergoing an implicit or explicit logout), 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 issued but not acknowledged, will be reissued 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 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 10.6 Task Management Function Response 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访问控制的约束。当目标授权失败时，目标必须返回第10.6节任务管理功能响应中所述的相应响应。目标冷重设功能不受SCSI访问控制，但其执行权限可由iSCSI机制（如登录验证）管理。
When executing the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations on all Logical Units 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.
在执行目标温复位和目标冷复位功能时，目标会取消发出启动器已知的所有逻辑单元上的所有挂起操作。这两个功能相当于[SAM2]指定的目标重置功能。它们可能会影响使用SCSI目标端口登录的许多其他启动器。
The target MUST treat the TARGET COLD RESET function additionally 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. For additional usage semantics see Section 6.2 Retry and Reassign in Recovery.
对于任务重新分配功能，目标应将连接忠诚度重新分配给此新连接（从而恢复任务的iSCSI交换）。只有在先前执行命令的连接成功注销后，目标才能接收任务重新分配。任务管理响应必须在重新分配生效之前发出。有关其他用法语义，请参阅“恢复”中的第6.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 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，总长度和数据段长度必须为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、逻辑单元重置）的功能需要此字段，并且在所有其他功能中保留此字段。
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 RefCmdSN MUST be that of the Task Management request itself (i.e., CmdSN and RefCmdSN are equal).
如果为立即命令创建的任务发出中止任务，则RefCmdSN必须是任务管理请求本身的任务（即，CmdSN和RefCmdSN相等）。
For an ABORT TASK of a task created by non-immediate command 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 10.6.1 when the task identified by the Referenced Task Tag field is not with the target.
对于由非即时命令创建的任务的中止任务，RefCmdSN必须设置为由引用的任务标记字段标识的任务的CmdSN。当引用的任务标记字段标识的任务与目标不在一起时，目标必须使用第10.6.1节中所述的该字段。
Otherwise, this field is reserved.
否则，此字段将保留。
For recovery purposes, the iSCSI target and initiator maintain a data acknowledgement 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, ExpDataSN will contain an updated data acknowledgement reference number or the value 0; the latter indicating that the data acknowledgement 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 acknowledgement 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。如果功能为任务重新分配，为先前发出的读取或双向命令建立新的连接效忠，EXPDASN将包含更新的数据确认参考号或值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:
目标提供的响应可能具有以下值：
a) 0 - Function complete. b) 1 - Task does not exist. c) 2 - LUN does not exist. d) 3 - Task still allegiant. e) 4 - Task allegiance reassignment not supported.
a) 0-功能完成。b） 1-任务不存在。c） 2-LUN不存在。d） 任务仍然是allegiant。e） 4-不支持任务忠诚重新分配。
f) 5 - Task management function not supported. g) 6 - Function authorization failed. h) 255 - Function rejected.
f) 5-不支持任务管理功能。g） 6-功能授权失败。h） 255-函数被拒绝。
All other values are reserved.
所有其他值均保留。
For a discussion on usage of response codes 3 and 4, see Section 6.2.2 Allegiance Reassignment.
有关使用响应代码3和4的讨论，请参见第6.2.2节忠诚重新分配。
For the TARGET COLD RESET and TARGET WARM RESET functions, the target cancels all pending operations across all Logical Units 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).
对于目标冷复位和目标热复位功能，目标取消发出启动器已知的所有逻辑单元中的所有挂起操作。对于目标冷重置功能，目标必须关闭其与所有启动器的所有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. 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服务响应。所有其他响应值映射到函数拒绝的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 have been confirmed (acknowledged through ExpStatSN) by the initiator on all connections of this session. For the exact timeline of events, refer to Section 10.6.2 Task Management Actions on Task Sets.
只有在目标接收到所有受影响的命令，SCSI目标执行了相应的任务管理功能，并且在确认任务管理功能完成之前，目标才能发出对中止任务集和清除任务集的响应（通过ExpStatSN确认）此会话的所有连接上的启动器。有关事件的确切时间线，请参阅第10.6.2节任务集上的任务管理操作。
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. b) If the Referenced Task Tag does not identify an existing task, but if 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 received and return the "Function complete" response.
a) 如果引用的任务标记标识导致成功终止的有效任务，则目标必须返回“功能完成”响应。b）如果引用的任务标记不标识现有任务，但如果任务管理功能请求中的ReCMCMN字段指示的CMDSN位于有效的CMDSN窗口中，并且小于任务管理功能请求本身的CmdSN，则目标必须考虑接收到的CMDSN并返回“函数完成”。回答
c) If the Referenced Task Tag does not identify an existing task and if 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窗口之外，则目标必须返回“任务不存在”响应。
The execution of ABORT TASK SET and CLEAR TASK SET Task Management function requests consists of the following sequence of events in the specified order on each of the entities.
中止任务集和清除任务集任务管理功能请求的执行由每个实体上按指定顺序的以下事件序列组成。
The initiator:
发起人：
a) Issues ABORT TASK SET/CLEAR TASK SET request. b) Continues to respond to each target transfer tag received for the affected task set. c) Receives any responses for the tasks in the affected task set (may process them as usual because they are guaranteed to be valid). d) Receives the task set management response, thus concluding all the tasks in the affected task set.
a) 发出中止任务集/清除任务集请求。b） 继续响应为受影响的任务集接收的每个目标传输标记。c） 接收受影响任务集中任务的任何响应（可以像往常一样处理它们，因为它们保证有效）。d） 接收任务集管理响应，从而结束受影响任务集中的所有任务。
The target:
目标：
a) Receives the ABORT TASK SET/CLEAR TASK SET request. b) Waits for all target transfer tags to be responded to and for all affected tasks in the task set to be received. c) Propagates the command to and receives the response from the target SCSI layer. d) Takes note of last-sent StatSN on each of the connections in the iSCSI sessions (one or more) sharing the affected task set, and waits for acknowledgement of each StatSN (may solicit for acknowledgement by way of a NOP-In). If some tasks originate from non-iSCSI I_T_L nexi then the means by which the target insures that all affected tasks have returned their status to the initiator are defined by the specific protocol.
a) 接收中止任务集/清除任务集请求。b） 等待响应所有目标传输标记，并等待接收任务集中所有受影响的任务。c） 将命令传播到目标SCSI层并从目标SCSI层接收响应。d） 注意共享受影响任务集的iSCSI会话（一个或多个）中每个连接上最后发送的StatSN，并等待每个StatSN的确认（可能通过NOP in请求确认）。如果某些任务源自非iSCSI I_T_L nexi，则目标公司确保所有受影响的任务已将其状态返回到启动器的方式由特定协议定义。
e) Sends the task set management response to the issuing initiator.
e) 将任务集管理响应发送给发出的启动器。
For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
对于此PDU，总长度和数据段长度必须为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 though 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 MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength ratio (as PDUs may be limited in length by the sender capabilities). Using 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 acknowledgement 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 ExpStatSN on other outbound PDUs if the status for the task is also received. In the latter case (acknowledgement through 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 acknowledgement through ExpStatSN. If the initiator has detected holes in the read data prior to that Data-In PDU, it MUST
在ErrorRecoveryLevel大于0的会话中，当在PDU中接收到位设置为1的数据时，若在PDU中读取数据之前，读取数据中并没有孔，发起方必须发出DataACK类型的SNACK，除非它能够通过其他出站PDU上的ExpStatSN立即确认任务的状态（如果还接收到任务的状态）。在后一种情况下（通过ExpStatSN确认），发送DataACK类型的SNACK以响应a位是可选的，但如果完成了，则不得在通过ExpStatSN确认状态之后发送。如果启动器在PDU中的数据之前检测到读取数据中存在漏洞，则必须
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 acknowledgement for a task that generated the Data-In PDUs is considered by the target as an implicit acknowledgement of the Data-In PDUs if such an acknowledgement was requested by the target.
推迟发放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. As 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). If Status is sent with the data, then a SCSI Response PDU MUST NOT be sent as this would violate SCSI rules (a single status). For Bidirectional commands, the status MUST be sent in a SCSI Response PDU.
对于成功完成的SCSI命令（状态为良好、满足条件、中间或满足中间条件），从目标发送到启动器的最后一个SCSI数据包也可以选择包含数据传输的状态。由于检测数据不能与命令状态一起发送，如果命令完成时出现错误，则响应和检测数据必须在SCSI响应PDU中发送（即，不得在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 10.4.1 Flags (byte 1).
位5-6-与SCSI响应中使用的相同。这些位仅在S设置为1时有效。有关详细信息，请参见第10.4.1节标志（字节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 and their values are defined in Section 10.4 SCSI Response.
只有当S位设置为1且其值在第10.4节SCSI响应中定义时，字段StatSN、Status和剩余计数才具有有意义的内容。
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 3.2.2.3 Data Sequencing).
在双向命令的上下文中，R2T和PDU中的数据共享编号顺序（参见第3.2.2.3节数据顺序）。
For output (write) data PDUs, the DataSN is the Data-Out PDU number within the current output sequence. The current output sequence is either identified by the Initiator Task Tag (for unsolicited data) or 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 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
R2T指定的数据传输长度，并且数据PDU的数据长度必须与R2T中指定的所需数据传输长度相同。如果R2T由一系列数据PDU应答，则缓冲区偏移量和长度必须在R2T指定的范围内，并且最后一个PDU的F位必须设置为1。如果在传输所需数据传输长度之前接收到最后一个PDU（用F位标记），则目标可以选择拒绝该PDU
PDU with "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.
带有“协议错误”原因代码的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 are limited by the value of the negotiated key MaxOutstandingR2T. Within a connection, 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，总长度和数据段长度必须为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 3.2.2.3 Data Sequencing).
对于双向命令R2T和PDU中的数据，共享输入PDU编号顺序（参见第3.2.2.3节数据顺序）。
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 correspondence 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]相关。
StatSN counts this PDU as an acknowledgeable event (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 - 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异步事件报告的目标支持（参见[SAM2]），如标准查询数据（参见[SPC3]）中所示。它的使用可以通过SCSI控制模式页面中的参数启用（请参见[SPC3]）。
1 - 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. 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 Logout 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 - target indicates it will drop the connection. The Parameter1 field indicates the CID of the connection that is going to be dropped.
2-目标表示它将断开连接。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 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.
如果启动器在Parameter3指定的时间内未尝试重新连接和/或重新分配未完成的命令，或者如果Parameter3为0，则目标将终止此连接上所有未完成的命令。在这种情况下，对于此连接上的未完成命令，不应期望目标做出其他响应。
A value of 0 for Parameter2 indicates that reconnect can be attempted immediately.
参数2的值为0表示可以立即尝试重新连接。
3 - target indicates it will drop all the connections of this session.
3-目标表示它将删除此会话的所有连接。
Parameter1 field is reserved.
参数1字段是保留的。
The Parameter2 field (Time2Wait) indicates, in seconds, the minimum time to wait before attempting to reconnect. The Parameter3 field (Time2Retain) indicates the maximum time allowed to reassign commands after the initial wait (in Parameter2).
Parameter2字段（Time2Wait）以秒为单位指示尝试重新连接前的最短等待时间。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.
如果启动器未在参数3指定的时间内尝试重新连接和/或重新分配未完成的命令，或者如果参数3为0，则会话终止。
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.
在这种情况下，目标将终止此会话中所有未完成的命令；对于此会话中未完成的命令，不应期望目标做出其他响应。参数2的值为0表示可以立即尝试重新连接。
4 - 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秒，以满足此请求，除非文本请求已在连接上挂起，或者发出注销请求。如果发起方未发出文本请求，则目标方可重新发出请求参数协商的异步消息。
255 - vendor specific iSCSI Event. The AsyncVCode details the vendor code, and data MAY accompany the report.
255-特定于供应商的iSCSI事件。AsyncVCode详细说明了供应商代码，报告中可能附带数据。
All other event codes are reserved.
保留所有其他事件代码。
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 to 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 have at most 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 must cause such a task to be implicitly terminated by the target.
在连接失败时，启动器必须显式中止任何活动的allegiant文本协商任务，或者必须导致目标隐式终止此类任务。
When set to 1, 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, 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。
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 in the following example:
长文本响应的处理方式如下例所示：
I->T Text SendTargets=All (F=1,TTT=0xffffffff)
T->I Text <part 1> (F=0,TTT=0x12345678)
I->T Text <empty> (F=1, TTT=0x12345678)
T->I Text <part 2> (F=0, TTT=0x12345678)
I->T Text <empty> (F=1, TTT=0x12345678)
...
T->I Text <part n> (F=1, TTT=0xffffffff)
I->T Text SendTargets=All (F=1,TTT=0xffffffff)
T->I Text <part 1> (F=0,TTT=0x12345678)
I->T Text <empty> (F=1, TTT=0x12345678)
T->I Text <part 2> (F=0, TTT=0x12345678)
I->T Text <empty> (F=1, TTT=0x12345678)
...
T->I Text <part n> (F=1, TTT=0xffffffff)
The data lengths of a text request MUST NOT exceed the iSCSI target MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter). The text format is specified in Section 5.2 Text Mode Negotiation.
文本请求的数据长度不得超过iSCSI目标MaxRecvDataSegmentLength（每个连接和每个方向协商的参数）。第5.2节文本模式协商中规定了文本格式。
Chapter 11 and Chapter 12 list some basic Text key=value pairs, some of which can be used in Login Request/Response and some in Text Request/Response.
第11章和第12章列出了一些基本的文本键=值对，其中一些可用于登录请求/响应，另一些可用于文本请求/响应。
A key=value pair can span Text request or 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的结束不一定表示键=值对的结束。
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.
目标通过将其响应发送回启动器进行响应。响应文本格式类似于请求文本格式。文本响应可能指早期文本请求中呈现的键=值对，请求中的文本可能指早期响应。
Chapter 5 details the rules for the Text Requests and Responses.
第五章详细介绍了文本请求和响应的规则。
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 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.
当设置为1时，为了响应文本请求（最后一位设置为1），F位表示目标已完成整个操作。否则，如果为响应文本请求而将最后一位设置为1而将其设置为0，则表示目标有更多工作要做（邀请后续文本请求）。响应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 of 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 0xffffffff.
F位设置为0的文本响应必须将目标传输标记字段设置为保留0xFFFFFF以外的值。
When set to 1, 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 of 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 of 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), state 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 per connection and per direction negotiated parameter).
文本响应的数据长度不得超过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 10.10.5 Text).
文本响应数据中的文本受与文本请求数据中的文本相同的规则管辖（见第10.10.5节文本）。
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 Chapter 5) consists of a sequence of Login Requests and Responses that carry the same Initiator Task Tag.
登录阶段（参见第5章）由一系列带有相同启动器任务标记的登录请求和响应组成。
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 /
+/ /
+---------------+---------------+---------------+---------------+
If set to 1, indicates that the initiator is ready to transit to the next stage.
如果设置为1，则表示启动器已准备好转移到下一阶段。
If the T bit is set to 1 and NSG is FullFeaturePhase, then this also indicates that the initiator is ready for the Final Login Response (see Chapter 5).
如果T位设置为1且NSG为FullFeaturePhase，则这也表示启动器已准备好进行最终登录响应（参见第5章）。
When set to 1, 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 Chapter 5). The next stage value is only valid when the T bit is 1; otherwise, it is reserved.
通过这些字段，当前阶段（CSG）和下一阶段（NSG），登录协商请求和响应与会话中的特定阶段（SecurityNegotiation、LoginOperationalNegotiation、FullFeaturePhase）相关联，并可能指示他们要移动到的下一阶段（见第5章）。下一级值仅在T位为1时有效；否则，它是保留的。
The stage codes are:
阶段代码为：
- 0 - SecurityNegotiation - 1 - LoginOperationalNegotiation - 3 - FullFeaturePhase
- 0-安全协商-1-登录操作协商-3-完整功能阶段
All other codes are reserved.
所有其他代码均保留。
The version number of the current draft is 0x00. As such, all devices MUST carry version 0x00 for both Version-min and Version-max.
当前草稿的版本号为0x00。因此，对于版本最小和版本最大，所有设备都必须携带版本0x00。
Maximum Version number supported.
支持的最大版本号。
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 [RFC3721] and Section 9.1.1 Conservative Reuse of ISIDs for details):
这是一个由启动器定义的会话标识符组件，其结构如下（有关详细信息，请参见[RFC3721]和第9.1.1节ISID的保守重用）：
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 A&B are a 22 bit OUI (the I/G & U/L bits are omitted) C&D 24 bit qualifier 01b EN - Format (IANA Enterprise Number) A - Reserved B&C EN (IANA Enterprise Number) D - Qualifier 10b "Random" A - Reserved B&C Random D - Qualifier 11b A,B,C&D Reserved
00b OUI格式A和B是22位OUI（省略I/G和U/L位）C和D 24位限定符01b EN-格式（IANA企业编号）A-保留B和C EN（IANA企业编号）D-限定符10b“随机”A-保留B和C随机D-限定符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 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).
对于T字段值00b和01b，a和B（对于00b）或B和C（对于01b）的组合标识其组件（软件或硬件）生成此ISID的供应商或组织。具有一个或多个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 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 Section 3.4.3 Consequences of the Model and Section 9.1.1 Conservative Reuse of ISIDs).
限定符字段是一个16位或24位无符号整数值，它为选定命名空间内的ISID提供一系列可能的值。可以将其设置为iSCSI协议中规定的约束范围内的任何值（请参阅第3.4.3节模型的后果和第9.1.1节ISID的保守重用）。
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 Section 9.1.1 Conservative Reuse of ISIDs and Section 9.1.2 iSCSI Name, ISID, and TPGT Use). The resultant ISID MUST also be persistent over power cycles, reboot, card swap, etc.
如果ISID源于供应商分配给硬件适配器或接口的某个内容，作为预设默认值，则它必须可配置为根据安装它的系统所需的SCSI端口行为分配的值（请参阅第9.1.1节ISID的保守重用和第9.1.2节iSCSI名称、ISID和TPGT使用）。生成的ISID还必须在电源循环、重新启动、卡交换等过程中保持不变。
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 5.3.1 Login Phase Start.
目标必须检查第一次登录请求中显示的值，并按照第5.3.1节“登录阶段开始”中的规定行事。
A unique ID for this connection within the session.
会话中此连接的唯一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 5.3.4 Connection Reinstatement). For the details of the implicit Logout Request, see Section 10.14 Logout Request.
具有非零TSIH和等于现有连接的CID的登录请求意味着先注销连接，然后再登录（参见第5.3.4节连接恢复）。有关隐式注销请求的详细信息，请参阅第10.14节注销请求。
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 FullFeaturePhase also carries the CmdSN 123.
- 领先连接上的登录-如果领先登录携带CmdSN 123，则同一登录阶段中的所有其他登录请求都携带CmdSN 123，而FullFeaturePhase中的第一个非即时命令也携带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 CmdSN.
- 在前导连接以外的其他连接上登录-如果在连接上发出第一次登录时的当前CmdSN为500，则该PDU携带CmdSN=500。如果在同一会话中的其他连接上发出非即时请求，则完成此登录阶段所需的后续登录请求可能包含高于500的CmdSN。
If the Login Request is a leading Login Request, the target MUST use the value presented in CmdSN as the target value for ExpCmdSN.
如果登录请求是前导登录请求，则目标必须使用CmdSN中显示的值作为ExpCmdSN的目标值。
For the first Login Request on a connection this is ExpStatSN for the old connection and this field is only valid if the Login Request restarts a connection (see Section 5.3.4 Connection Reinstatement).
对于连接上的第一个登录请求，这是旧连接的ExpStatSN，并且此字段仅在登录请求重新启动连接时有效（请参阅第5.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 10.10.5 Text for text requests also hold for Login Requests. Keys and their explanations are listed in Chapter 11 (security negotiation keys) and Chapter 12 (operational parameter negotiation keys). All keys in Chapter 12, except for the X extension formats, MUST be supported by iSCSI initiators and targets. Keys in Chapter 11 only need to be supported when the function to which they refer is mandatory to implement.
第10.10.5节文本请求中规定的所有规则也适用于登录请求。第11章（安全协商密钥）和第12章（操作参数协商密钥）中列出了密钥及其说明。第12章中的所有密钥（X扩展格式除外）必须由iSCSI启动器和目标支持。仅当第11章中的键所指的功能必须实现时，才需要支持这些键。
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.
启动器必须使用作为对第一个登录请求的响应而显示的值。
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.
指示目标和启动器支持的最高版本。如果目标不支持启动器指定范围内的版本，则目标拒绝登录，此字段表示目标支持的最低版本。
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 that 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 5.3 Login Phase).
TSIH是目标分配的会话标识句柄。除保留的值0外，其内部格式和内容不由该协议定义。除新会话中的登录最终响应外，此字段应设置为发起人在登录请求中提供的TSIH。对于新会话，目标必须生成非零TSIH，并且仅在登录最终响应中返回它（请参见第5.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
状态类状态详细信息
0 Status-Class 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. The Status-Detail allows finer-grained exception handling for more sophisticated initiators and for better information for logging.
非零状态类表示异常。在这种情况下，Status类足以让简单的启动器在处理异常时使用，而无需查看状态详细信息。状态详细信息允许对更复杂的启动器进行更细粒度的异常处理，并为日志记录提供更好的信息。
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 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 re-try 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.
-----------------------------------------------------------------
-----------------------------------------------------------------
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 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 | | of 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.
-----------------------------------------------------------------
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 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 | | of 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.
-----------------------------------------------------------------
(*1) If the response T bit is 1 in both the request and the matching response, and the NSG is 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 NSG is FullFeaturePhase, then this is also the Final Login Response (see Chapter 5). A T bit of 0 indicates a "partial" response, which means "more negotiation needed".
T位设置为1，作为阶段结束的指示器。如果T位设置为1且NSG为FullFeaturePhase，则这也是最终登录响应（参见第5章）。T位为0表示“部分”响应，表示“需要更多协商”。
A Login Response with a 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, 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 10.11.6 Text Response Data for text responses also hold for Login Responses. Keys and their explanations are listed in Chapter 11 (security negotiation keys) and Chapter 12 (operational parameter negotiation keys). All keys in Chapter 12, except for the X extension formats, MUST be supported by iSCSI initiators and targets. Keys in Chapter 11, only need to be supported when the function to which they refer is mandatory to implement.
第10.11.6节针对文本响应的文本响应数据中规定的所有规则也适用于登录响应。第11章（安全协商密钥）和第12章（操作参数协商密钥）中列出了密钥及其说明。第12章中的所有密钥（X扩展格式除外）必须由iSCSI启动器和目标支持。第11章中的键，仅当它们所指的功能必须实现时才需要支持。
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 of "close the connection" or "close the session", the target MUST terminate all pending commands, whether acknowledged via ExpCmdSN or not, on that connection or session respectively.
当接收到原因码为“关闭连接”或“关闭会话”的注销请求时，目标必须终止该连接或会话上的所有挂起命令，无论是否通过ExpCmdSN确认。
When receiving a Logout Request with the reason code "remove connection for recovery", the target MUST discard all requests not yet acknowledged via 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 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 the Login Request with a non-zero TSIH and the same CID on a new connection for the same effect (see Section 10.14.3 CID). 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 5.3.4 Connection Reinstatement).
如果启动器打算为故障连接启动恢复，则必须使用注销请求“清理”故障连接的目标端并启用恢复启动，或者在新连接上使用非零TSIH和相同CID的登录请求以获得相同的效果（参见第10.14.3节CID）。在具有单个连接的会话中，可以关闭连接，然后重新打开新连接。连接恢复登录可用于恢复（见第5.3.4节连接恢复）。
A successful completion of a Logout Request with the reason code of "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 have not been delivered to SCSI because one or more commands with a smaller CmdSN has not been received by iSCSI. See Section 3.2.2.1 Command Numbering and Acknowledging. The resulting holes the in command sequence numbers will have to be handled by appropriate recovery (see Chapter 6) unless the session is also closed.
成功完成注销请求（原因代码为“关闭连接”或“删除连接以进行恢复”）会导致目标放弃注销连接时收到的未确认命令。这些是在注销连接时到达的命令，但由于iSCSI未接收到一个或多个具有较小CmdSN的命令，因此尚未传递到SCSI。参见第3.2.2.1节命令编号和确认。除非会话也关闭，否则必须通过适当的恢复（参见第6章）处理命令序列号中产生的漏洞。
The entire logout discussion in this section is also applicable for an implicit Logout realized via 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
-------------------------------------------
0 session reinstatement
1 connection reinstatement when
the operational ErrorRecoveryLevel < 2
2 connection reinstatement when
the operational ErrorRecoveryLevel = 2
Reason code Type of implicit Logout
-------------------------------------------
0 session reinstatement
1 connection reinstatement when
the operational ErrorRecoveryLevel < 2
2 connection reinstatement when
the operational ErrorRecoveryLevel = 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) |
+---------------+---------------+---------------+---------------+
Reason Code indicates the reason for Logout as follows:
原因代码表示注销的原因，如下所示：
0 - close the session. All commands associated with the session (if any) are terminated.
0 - close the session. All commands associated with the session (if any) are terminated.translate error, please retry
1 - close the connection. All commands associated with connection (if any) are terminated.
1-关闭连接。与连接（如果有）关联的所有命令都将终止。
2 - remove the connection for recovery. 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，总长度和数据段长度必须为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 of "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 7.2.2 State Transition Descriptions for Initiators and Targets) and there are active tasks allegiant to that connection.
b) 当连接失败并最终连接状态超时时（第7.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 of "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 SCSI level depending on the SCSI context as defined by the SCSI standards (e.g., queued commands and ACA, in cases a), b), and c), 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, and
如果在上述任何情况下终止的任务是SCSI任务，则它们必须在内部终止，就像使用检查条件状态一样。此状态仅对适当处理内部SCSI状态和与订购有关的SCSI副作用有意义，因为此状态永远不会作为终止状态传回启动器。但是，根据SCSI标准定义的SCSI上下文（例如，队列命令和ACA，在情况a）、b）和c中），在任务终止后，可能必须在SCSI级别采取其他操作，对于每个受影响的I_T_L nexus，目标必须在任何连接上处理的下一个命令上报告一个单位注意条件，状态为检查条件，以及
the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT" - etc. - see [SAM2] and [SPC3]).
47h/7Fh的ASC/ASCQ值-“某些命令被ISCSI协议事件清除”-等-请参阅[SAM2]和[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) |
+---------------+---------------+---------------+---------------+
Logout Response:
注销响应：
0 - connection or session closed successfully.
0-连接或会话已成功关闭。
1 - CID not found.
1-找不到CID。
2 - connection recovery is not supported. If Logout reason code was recovery and target does not support it as indicated by the ErrorRecoveryLevel.
2-不支持连接恢复。如果注销原因代码为recovery，并且目标不支持ErrorRecoveryLevel所指示的注销原因代码。
3 - cleanup failed for various reasons.
3-由于各种原因，清理失败。
For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
对于此PDU，总长度和数据段长度必须为0。
If the Logout Response code is 0 and if 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 if 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 if the operational ErrorRecoveryLevel is 2, this is the maximum amount of time, in seconds, after the initial wait (Time2Wait), 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 if the operational ErrorRecoveryLevel is less than 2, this field is to be ignored.
如果注销响应代码为0，并且操作错误RecoveryLevel为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), 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 by the target, 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. - When used in both BegRun and RunLength, it means all unacknowledged PDUs.
- 在RunLength中使用时，它意味着所有PDU都以首字母开头。-在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 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 10.16.3 Resegmentation).
数据快餐请求的PDU中的编号数据必须作为目标最初传输的数据的精确副本交付，ExpCmdSN和MaxCmdSN字段除外，这两个字段必须携带当前值并进行重新分段（参见第10.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-Data/R2T Snapshot-请求在或R2T PDU中重新传输一个或多个数据。
1-Status SNACK - requesting retransmission of one or more numbered responses.
1-状态-请求重新传输一个或多个编号响应。
2-DataACK - positively acknowledges Data-In PDUs.
2-DataACK-积极确认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 acknowledgement 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 10.16.1 Type). 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快照（参见第10.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 responses must carry the same StatSN (see Section 10.4.4 SNACK Tag). If an initiator attempts to recover a lost SCSI Response (with a Status SNACK, see Section 10.16.1 Type) 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响应必须携带相同的StatSN（请参阅第10.4.4节）。当发送了多个响应时，如果启动器尝试恢复丢失的SCSI响应（带有状态快捷键，请参阅第10.16.1节类型），则目标将发送SCSI响应，其中包含目标已知的最新内容，包括命令的最后一个快捷键标记。
For considerations in allegiance reassignment of a task to a connection with a different MaxRecvDataSegmentLength, refer to Section 6.2.2 Allegiance Reassignment.
有关将任务忠诚重新分配到具有不同MaxRecvDataSegmentLength的连接的注意事项，请参阅第6.2.2节忠诚重新分配。
For 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.
对于Status Snapshot和DataACK，启动器任务标记必须设置为保留值0xFFFFFF。在所有其他情况下，启动器任务标记字段必须设置为引用命令的启动器任务标记。
For an 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 of 0xffffffff.
在所有其他情况下，目标传输标记字段必须设置为保留值0xFFFFFF。
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的数据N、R2TSN或StatSN（数据/R2T和状态零食）或下一个预期数据N（数据确认零食）。
BegRun 0 when used in conjunction with RunLength 0 means resend all unacknowledged Data-In, R2T or Response PDUs.
当与RunLength 0一起使用时，BegRun 0表示在、R2T或响应PDU中重新发送所有未确认的数据。
BegRun MUST be 0 for a R-Data SNACK.
对于R-Data Snapshot，BegRun必须为0。
The number of PDUs whose retransmission is requested.
请求重新传输的PDU数。
RunLength 0 signals that all Data-In, R2T, or Response PDUs carrying the numbers equal to or greater than BegRun have to be resent.
RunLength 0表示必须重新发送、R2T或响应PDU中的所有数据，这些数据中的数字等于或大于BegRun。
The RunLength MUST also be 0 for a DataACK SNACK in addition to 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 re-sent? |
+------+----------------------------------------+------------------+
| 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 Operation Reject - Can't generate | yes |
| | Target Transfer Tag - out of resources | |
| | | |
| 0x0b | Negotiation Reset | no |
| | | |
| 0x0c | Waiting for Logout | no |
+------+----------------------------------------+------------------+
+------+----------------------------------------+------------------+
| Code | Explanation | Can the original |
| (hex)| | PDU be re-sent? |
+------+----------------------------------------+------------------+
| 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 Operation Reject - Can't generate | yes |
| | Target Transfer Tag - out of resources | |
| | | |
| 0x0b | Negotiation Reset | no |
| | | |
| 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，以及快照中的无效序列号。
All other values for Reason are reserved.
保留所有其他合理值。
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 10.4.3 Response. 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命令响应，并带有第10.4.3节“响应”中所述的检查条件。在这些情况下，如果SCSI任务的状态在拒绝之前已发送，则不需要其他状态。如果在仍然预期来自启动器的数据时检测到错误（即，命令PDU未包含所有数据，且目标尚未接收到数据输出PDU，未经请求的数据（如有）的最终位设置为1，以及所有未完成的R2T（如有）），在发送响应PDU之前，目标必须等待直到收到最后一个预期的数据输出PDU（F位设置为1）。
For additional usage semantics of Reject PDU, see Section 6.3 Usage Of Reject PDU in Recovery.
有关Reject PDU的其他用法语义，请参阅第6.3节Recovery中Reject PDU的用法。
This field is only valid if the rejected PDU is a Data/R2T SNACK and the Reject reason code is "Protocol error" (see Section 10.16 SNACK Request). The DataSN/R2TSN is the next Data/R2T sequence number that the target would send for the task, if any.
仅当被拒绝的PDU为数据/R2T零食且拒绝原因代码为“协议错误”（参见第10.16节零食请求）时，此字段才有效。DataSN/R2TSN是目标将为任务发送的下一个Data/R2T序列号（如果有）。
These fields carry their usual values and are not related to the rejected command. StatSN is advanced after a Reject.
这些字段带有它们的常规值，与被拒绝的命令无关。StatSN在拒绝后提前。
The target returns the header (not including 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) |
+---------------+---------------+---------------+---------------+
A 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 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.
收到NOP In且目标传输标记设置为有效值（不是保留的0xFFFFFF）时，启动器必须以NOP Out响应。在这种情况下，NOP Out目标传输标记必须包含NOP In目标传输标记的副本。
The NOP-Out MUST have the Initiator Task Tag set to a valid value only if a response in the form of 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 10.19 NOP-In).
当目标接收到带有有效启动器任务标记的NOP Out时，它必须以NOP响应（请参阅中的第10.19节NOP）。
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不会处于高级状态。
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 are reflected in the NOP-In Response. The length of the reflected data are limited to MaxRecvDataSegmentLength. The length of ping data are 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 either sent by a target as a response to a NOP-Out, as a "ping" to an initiator, or as 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.
当目标接收到带有有效启动器任务标记（不是保留值0xFFFFFF）的NOP Out时，它必须使用NOP In和NOP Out请求中提供的相同启动器任务标记进行响应。它还必须复制到启动器提供的Ping数据的第一个MaxRecvDataSegmentLength字节。对于这样的响应，目标传输标记必须是0xFFFFFF。
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 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 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 of 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, 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 AuthMethod and the keys used by the authentication methods specified under Section 11.1 AuthMethod along with all of their associated keys as well as Vendor Specific Authentication Methods.
SessionType InitiatorName TargetName TargetAddress InitiatorAlias TargetPortalGroupTag AuthMethod和第11.1节AuthMethod中指定的身份验证方法使用的密钥及其所有关联密钥以及特定于供应商的身份验证方法。
Other keys MUST NOT be used.
不得使用其他钥匙。
SessionType, InitiatorName, TargetName, InitiatorAlias, TargetAlias, and TargetPortalGroupTag are described in Chapter 12 as they can be used also in the OperationalNegotiation stage.
SessionType、InitiatorName、TargetName、InitiatorAlias、TargetAlias和TargetPortalGroupTag在第12章中进行了描述，因为它们也可用于操作协商阶段。
All security keys have connection-wide applicability.
所有安全密钥都具有广泛的适用性。
Use: During Login - Security Negotiation Senders: Initiator and
Target Scope: connection
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 those listed in the following table or are vendor-unique methods:
可使用的身份验证方法（显示在值列表中）可以是下表中列出的方法，也可以是供应商独有的方法：
+------------------------------------------------------------+
| Name | Description |
+------------------------------------------------------------+
| KRB5 | Kerberos V5 - defined in [RFC1510] |
+------------------------------------------------------------+
| SPKM1 | Simple Public-Key GSS-API Mechanism |
| | defined in [RFC2025] |
+------------------------------------------------------------+
| SPKM2 | Simple Public-Key GSS-API Mechanism |
| | defined in [RFC2025] |
+------------------------------------------------------------+
| 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 [RFC1510] |
+------------------------------------------------------------+
| SPKM1 | Simple Public-Key GSS-API Mechanism |
| | defined in [RFC2025] |
+------------------------------------------------------------+
| SPKM2 | Simple Public-Key GSS-API Mechanism |
| | defined in [RFC2025] |
+------------------------------------------------------------+
| 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 keys(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 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:
扩展身份验证方法必须使用以下两种格式之一命名：
a) Z-reversed.vendor.dns_name.do_something=
b) Z<#><IANA-registered-string>=
a) Z-reversed.vendor.dns_name.do_something=
b) Z<#><IANA-registered-string>=
Authentication methods named using the Z- format are used as private extensions. Authentication methods named using the Z# format are used as public extensions that must be registered with IANA and MUST be described by an informational RFC.
使用Z格式命名的身份验证方法用作私有扩展。使用Z#格式命名的身份验证方法用作公共扩展，必须向IANA注册，并且必须由信息RFC描述。
For all of the public or private extension authentication methods, the method specific keys MUST conform to the format specified in Section 5.1 Text Format for standard-label.
对于所有公共或私有扩展验证方法，方法特定密钥必须符合第5.1节标准标签文本格式中规定的格式。
To identify the vendor for private extension authentication methods, we suggest you use the reversed DNS-name as a prefix to the proper digest names.
为了确定专用扩展身份验证方法的供应商，我们建议您使用反向DNS名称作为正确摘要名称的前缀。
The part of digest-name following Z- and Z# MUST conform to the format for standard-label specified in Section 5.1 Text Format.
摘要名称的Z-和Z#后面的部分必须符合第5.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) [RFC1510] and [RFC1964], the initiator MUST use:
对于KRB5（Kerberos V5）[RFC1510]和[RFC1964]，启动器必须使用：
KRB_AP_REQ=<KRB_AP_REQ>
KRB_AP_REQ=<KRB_AP_REQ>
where KRB_AP_REQ is the client message as defined in [RFC1510].
其中KRB_AP_REQ是[RFC1510]中定义的客户机消息。
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 [RFC1510].
其中KRB_AP_REP是[RFC1510]中定义的服务器响应消息。
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.
KRB_AP_REQ和KRB_AP_REP是二进制值，它们的二进制长度（不是以编码形式表示它们的字符串长度）不得超过65536字节。
For SPKM1 and SPKM2 [RFC2025], the initiator MUST use:
对于SPKM1和SPKM2[RFC2025]，启动器必须使用：
SPKM_REQ=<SPKM-REQ>
SPKM_REQ=<SPKM-REQ>
where SPKM-REQ is the first initiator token as defined in [RFC2025].
其中，SPKM-REQ是[RFC2025]中定义的第一个启动器令牌。
[RFC2025] defines situations where each side may send an error token that may cause the peer to re-generate and resend its last token. This scheme is followed in iSCSI, and the error token syntax is:
[RFC2025]定义每一方可能发送错误令牌的情况，该错误令牌可能导致对等方重新生成并重新发送其最后一个令牌。iSCSI中遵循此方案，错误令牌语法为：
SPKM_ERROR=<SPKM-ERROR>
SPKM_ERROR=<SPKM-ERROR>
However, SPKM-DEL tokens that are defined by [RFC2025] for fatal errors will not be used by iSCSI. If the target needs to send a SPKM-DEL token, it will, instead, send a Login "login reject" message with the "Authentication Failure" status and terminate the connection. If the initiator needs to send a SPKM-DEL token, it will close the connection.
但是，[RFC2025]为致命错误定义的SPKM-DEL令牌将不会被iSCSI使用。如果目标需要发送SPKM-DEL令牌，它将发送一条“登录拒绝”消息，状态为“身份验证失败”，并终止连接。如果启动器需要发送SPKM-DEL令牌，它将关闭连接。
In the following sections, we assume that no SPKM-ERROR tokens are required.
在以下部分中，我们假设不需要SPKM-ERROR令牌。
If the initiator authentication fails, the target MUST return an error. Otherwise, if the AuthMethod is SPKM1 or if the initiator has selected the mutual authentication option (by setting mutual-state bit in the options field of the REQ-TOKEN in the SPKM-REQ), the target MUST reply with:
如果启动器身份验证失败，目标必须返回错误。否则，如果AuthMethod为SPKM1，或者如果发起方选择了相互身份验证选项（通过在SPKM-REQ中的REQ-TOKEN的选项字段中设置相互状态位），则目标方必须回复：
SPKM_REP_TI=<SPKM-REP-TI>
SPKM_REP_TI=<SPKM-REP-TI>
where SPKM-REP-TI is the target token as defined in [RFC2025].
其中，SPKM-REP-TI是[RFC2025]中定义的目标令牌。
If mutual authentication was selected and target authentication fails, the initiator MUST close the connection. Otherwise, if the AuthMethod is SPKM1, the initiator MUST continue with:
如果选择了相互身份验证且目标身份验证失败，则启动器必须关闭连接。否则，如果AuthMethod为SPKM1，则启动器必须继续执行以下操作：
SPKM_REP_IT=<SPKM-REP-IT>
SPKM_REP_IT=<SPKM-REP-IT>
where SPKM-REP-IT is the second initiator token as defined in [RFC2025]. If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status.
其中，SPKM-REP-IT是[RFC2025]中定义的第二个启动器令牌。如果启动器身份验证失败，目标必须以“身份验证失败”状态的登录拒绝应答。
SPKM requires support for very long authentication items.
SPKM需要支持非常长的身份验证项。
All the SPKM-* tokens 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.
所有SPKM-*标记都是二进制值，其二进制长度（而不是编码形式中表示它们的字符串长度）不得超过65536字节。
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) and G,Gn (Gn stands for G1,G2...) are identifiers of SRP groups specified in [RFC3723]. 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.
其中U、s、A、B、M和H（A | M | K）在[RFC2945]中定义（使用SHA1散列函数，如SRP-SHA1），G、Gn（Gn代表G1、G2…）是[RFC3723]中指定的SRP组的标识符。G、 Gn和U是文本字符串，s、A、B、M和H（A | M | K）是二进制值。二进制形式的s、A、B、M和H（A | M | K）的长度（而不是以编码形式表示它们的字符串长度）不得超过1024字节。
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], in the first step, the initiator MUST send:
对于CHAP[RFC1994]，在第一步中，启动器必须发送：
CHAP_A=<A1,A2...>
CHAP_A=<A1,A2...>
Where A1,A2... are proposed algorithms, in order of preference.
其中A1，A2。。。这些算法是按优先顺序提出的。
In the second step, 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。。。这是发起者提出的。
In the third step, 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 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 is a text string, A,A1,A2, and I are numbers, and C and R are large-binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes.
其中，N，（A，A1，A2），I，C和R（相应地）是[RFC1994]中定义的名称、算法、标识符、质询和响应，N是文本字符串，A，A1，A2和I是数字，C和R是大二进制值，它们的二进制长度（而不是编码形式中表示它们的字符串长度）不得超过1024字节。
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
某些特定于会话的参数只能在前导连接上进行，并且在前导连接登录后不能更改（例如，MaxConnections，最大连接数）。这
holds for a single connection session with regard to connection restart. The keys that fall into this category have the use: LO (Leading Only).
就连接重新启动而言，保留单个连接会话。属于此类别的键具有以下用途：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 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 chapter 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
用法：IO发送者：启动器和目标作用域：CO
HeaderDigest = <list-of-values>
DataDigest = <list-of-values>
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 that 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 for this digest is given in hex-notation (e.g., 0x3b stands for 0011 1011 and the polynomial is x**5+X**4+x**3+x+1).
本摘要的生成器多项式以十六进制表示（例如，0x3b代表0011 1011，多项式为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 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 considered 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 in bit 7 of the lowest numbered byte of the digest continuing through to the byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, continuing with the x^23 coefficient in bit 7 of next byte through x^0 in bit 0 of the highest numbered byte.
- CRC位被映射到摘要字中。摘要最低编号字节第7位中的x^31系数一直延续到最低编号字节第0位中的x^24系数，下一个字节第7位中的x^23系数一直延续到最高编号字节第0位中的x^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 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:
扩展摘要算法必须使用以下两种格式之一命名：
a) Y-reversed.vendor.dns_name.do_something=
b) Y<#><IANA-registered-string>=
a) Y-reversed.vendor.dns_name.do_something=
b) Y<#><IANA-registered-string>=
Digests named using the Y- format are used for private purposes (unregistered). Digests named using the Y# format (public extension) must be registered with IANA and MUST be described by an informational RFC.
使用Y格式命名的摘要用于私人目的（未注册）。使用Y#格式（公共扩展名）命名的摘要必须向IANA注册，并且必须由信息RFC描述。
For private extension digests, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to the proper digest names.
对于私有扩展摘要，为了识别供应商，我们建议您使用反向DNS名称作为正确摘要名称的前缀。
The part of digest-name following Y- and Y# MUST conform to the format for standard-label specified in Section 5.1 Text Format.
摘要名称的Y-和Y#后面的部分必须符合第5.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。结果函数是最小的。
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 D. - SendTargets Operation -.
有关完整说明，请参见附录D-发送目标操作-。
Use: IO by initiator, FFPO by target - only as response to a SendTargets, Declarative, Any-Stage
使用：IO按启动器，FFPO按目标-仅作为对SendTargets的响应，声明性，任何阶段
Senders: Initiator and Target Scope: SW
发送方：发起方和目标作用域：SW
TargetName=<iSCSI-name-value>
TargetName=<iSCSI-name-value>
Examples:
示例：
TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678 TargetName=eui.020000023B040506
TargetName=iqn.1993-11.com.磁盘供应商：diskarrays.sn.45678 TargetName=eui.020000023B040506
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”文本请求返回（这是目标发出的唯一用途）。
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.2001-02.com.ssp.users:customer235.host90
InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345
InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90
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键使启动器能够向远程端点标识自己。
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=Database Server 1 Log Disk TargetAlias=Web Server 3 Disk 20
TargetAlias=Bob-s Disk TargetAlias=数据库服务器1日志磁盘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 12.21 SessionType). 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（参见第12.21节SessionType），则应将此名称告知启动器。此字符串不用作标识符，也不用于身份验证或授权决策。它可以由启动器的用户界面在其连接的目标列表中显示。
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=spyalley.nsa.gov InitiatorAlias=Exchange Server
InitiatorAlias=Web服务器4 InitiatorAlias=spyalley.nsa.gov 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 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 [RFC2732].
域名可以指定为DNS主机名、虚线十进制IPv4地址或括号内的IPv6地址，如[RFC2732]中所述。
If the TCP port is not specified, it is assumed to be the IANA-assigned default port for iSCSI (see Section 13 IANA Considerations).
如果未指定TCP端口，则假定它是IANA为iSCSI分配的默认端口（请参阅第13节IANA注意事项）。
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=[1080:0:0:0:8:800:200C:417A],65
TargetAddress=[1080::8:800:200C:417A]:5003,1
TargetAddress=computingcenter.example.com,23
TargetAddress=10.0.0.1:5003,1
TargetAddress=[1080:0:0:0:8:800:200C:417A],65
TargetAddress=[1080::8:800:200C:417A]:5003,1
TargetAddress=computingcenter.example.com,23
Use of the portal-group-tag is described in Appendix D. - SendTargets Operation -. The formats for the port and portal-group-tag are the same as the one specified in Section 12.9 TargetPortalGroupTag.
门户组标记的使用在附录D-发送目标操作-中进行了说明。端口和入口组标记的格式与第12.9节TargetPortalGroupTag中规定的格式相同。
Use: IO by target, Declarative, Any-Stage Senders: Target Scope: SW
使用：目标IO、声明性、任何阶段发送者：目标范围：SW
TargetPortalGroupTag=<16-bit-binary-value>
TargetPortalGroupTag=<16-bit-binary-value>
Examples: TargetPortalGroupTag=1
示例：TargetPortalGroupTag=1
The target portal group tag 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.
目标门户组标记是一个16位二进制值，用于唯一标识iSCSI目标节点内的门户组。此键包含为登录请求提供服务的门户组的标记的值。iSCSI目标在第一个登录请求PDU的登录响应PDU中将此密钥返回给启动器，当启动器提供TargetName时，该PDU的C位设置为0。
For the complete usage expectations of this key see Section 5.3 Login Phase.
有关此密钥的完整使用预期，请参阅第5.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
T->InitialR2T=No
I->InitialR2T=No
T->InitialR2T=No
Default is Yes. Result function is OR.
默认值是Yes。结果函数是OR。
The InitialR2T key is used to turn off the default use of R2T for unidirectional 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 |Immediate Data|
| | | Data Out PDUs | |
+----------+-------------+------------------+--------------+
| No | No | Yes | No |
+----------+-------------+------------------+--------------+
| No | Yes | Yes | Yes |
+----------+-------------+------------------+--------------+
| Yes | No | No | No |
+----------+-------------+------------------+--------------+
| Yes | Yes | No | Yes |
+----------+-------------+------------------+--------------+
+----------+-------------+------------------+--------------+
|InitialR2T|ImmediateData| Unsolicited |Immediate Data|
| | | 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 Kbytes). Result function is Minimum.
默认值为262144（256 KB）。结果函数是最小的。
The initiator and target negotiate 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 one.
启动器和目标在数据输入或请求的数据输出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 Kbytes). 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
Use: LO Senders: Initiator and Target Scope: 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>
Irrelevant when: SessionType=Discovery
MaxOutstandingR2T=<numerical-value-from-1-to-65535>
Irrelevant when: SessionType=Discovery
Default is 1. Result function is Minimum.
默认值为1。结果函数是最小的。
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 6.1.4.1 Recovery Within-command) is encountered for that data sequence.
发起方和目标方协商每个任务未完成R2T的最大数量，不包括可能是该任务一部分的任何隐含初始R2T。在传输最后一个数据PDU（F位设置为1）或该数据序列遇到序列接收超时（第6.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 one. 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 MaxOustandingR2T 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 6.1.5 Error Recovery Hierarchy describes the mapping between the classes and the levels.
在恢复机制的描述中，指定了某些恢复类。第6.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.
发现会话意味着MaxConnections=1，并覆盖默认设置和显式设置。
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=
or
或
X<#><IANA-registered-string>=
X<#><IANA-registered-string>=
Keys with this format are used for public or private extension purposes. These keys always start with X- if unregistered with IANA (private) or X# if registered with IANA (public).
此格式的密钥用于公共或私有扩展目的。如果未向IANA注册（专用），这些密钥总是以X开头；如果向IANA注册（公用），这些密钥总是以X开头。
For unregistered keys, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to the key-proper.
对于未注册的密钥，为了识别供应商，我们建议您使用反向DNS名称作为密钥的前缀。
The part of key-name following X- and X# MUST conform to the format for key-name specified in Section 5.1 Text Format.
X-和X#后面的键名部分必须符合第5.1节文本格式中规定的键名格式。
For IANA registered keys the string following X# must be registered with IANA and the use of the key MUST be described by an informational RFC.
对于IANA注册的密钥，必须向IANA注册X#后的字符串，并且必须通过信息RFC描述密钥的使用。
Vendor specific keys MUST ONLY be used in normal sessions.
供应商特定密钥只能在正常会话中使用。
Support for public or private extension keys is OPTIONAL.
对公共或私有扩展密钥的支持是可选的。
This section conforms to [RFC2434].
本节符合[RFC2434]。
The well-known user 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 use of port 860, as 3260 is the only allowed default.
IANA为iSCSI连接分配的众所周知的用户TCP端口号为3260，这是默认的iSCSI端口。需要系统TCP端口号的实现可以使用端口860，IANA分配的端口作为iSCSI系统端口；但是，为了使用端口860，必须明确指定它-实现不能默认使用端口860，因为3260是唯一允许的默认值。
Extension keys, authentication methods, or digest types for which a vendor or group of vendors intend to provide publicly available descriptions MUST be described by an RFC and MUST be registered with IANA.
供应商或供应商组打算提供公开可用描述的扩展密钥、认证方法或摘要类型必须由RFC描述，并且必须向IANA注册。
The IANA has set up the following three registries:
IANA设立了以下三个登记处：
a) iSCSI extended key registry b) iSCSI authentication methods registry c) iSCSI digests registry
a) iSCSI扩展密钥注册表b）iSCSI身份验证方法注册表c）iSCSI摘要注册表
[RFC3723] also instructs IANA to maintain a registry for the values of the SRP_GROUP key. The format of these values must conform to the one specified for iSCSI extension item-label in Section 13.5.4 Standard iSCSI extension item-label format.
[RFC3723]还指示IANA维护SRP_组键值的注册表。这些值的格式必须符合第13.5.4节标准iSCSI扩展项标签格式中为iSCSI扩展项标签指定的格式。
For the iSCSI authentication methods registry and the iSCSI digests registry, IANA MUST also assign a 16-bit unsigned integer number (the method number for the authentication method and the digest number for the digest).
对于iSCSI身份验证方法注册表和iSCSI摘要注册表，IANA还必须分配一个16位无符号整数（身份验证方法的方法号和摘要的摘要号）。
The following initial values for the registry for authentication methods are specified by the standards action of this document:
本文件的标准行动规定了认证方法注册表的以下初始值：
Authentication Method | Number |
+----------------------------------------+--------+
| CHAP | 1 |
+----------------------------------------+--------+
| SRP | 2 |
+----------------------------------------+--------+
| KRB5 | 3 |
+----------------------------------------+--------+
| SPKM1 | 4 |
+----------------------------------------+--------+
| SPKM2 | 5 |
+----------------------------------------+--------+
Authentication Method | Number |
+----------------------------------------+--------+
| CHAP | 1 |
+----------------------------------------+--------+
| SRP | 2 |
+----------------------------------------+--------+
| KRB5 | 3 |
+----------------------------------------+--------+
| SPKM1 | 4 |
+----------------------------------------+--------+
| SPKM2 | 5 |
+----------------------------------------+--------+
All other record numbers from 0 to 255 are reserved. IANA will register numbers above 255.
保留0到255之间的所有其他记录编号。IANA将注册255以上的号码。
Authentication methods with numbers above 255 MUST be unique within the registry and MUST be used with the prefix Z#.
数字大于255的身份验证方法在注册表中必须是唯一的，并且必须与前缀Z#一起使用。
The following initial values for the registry for digests are specified by the standards action of this document:
本文件的标准行动规定了以下摘要注册初始值：
Digest | Number |
+----------------------------------------+--------+
| CRC32C | 1 |
+----------------------------------------+--------+
Digest | Number |
+----------------------------------------+--------+
| CRC32C | 1 |
+----------------------------------------+--------+
All other record numbers from 0 to 255 are reserved. IANA will register numbers above 255.
保留0到255之间的所有其他记录编号。IANA将注册255以上的号码。
Digests with numbers above 255 MUST be unique within the registry and MUST be used with the prefix Y#.
数字大于255的摘要在注册表中必须是唯一的，并且必须与前缀Y#一起使用。
The RFC that describes the item to be registered MUST indicate in the IANA Considerations section the string and iSCSI registry to which it should be recorded.
描述要注册的项的RFC必须在IANA注意事项部分中指明该项应记录到的字符串和iSCSI注册表。
Extension Keys, Authentication Methods, and digests (iSCSI extension items) must conform to a number of requirements as described below.
扩展密钥、身份验证方法和摘要（iSCSI扩展项）必须符合如下所述的许多要求。
Each iSCSI extension item must have a unique name in its category. This name will be used as a standard-label for the key, access method, or digest and must conform to the syntax specified in Section 13.5.4 Standard iSCSI extension item-label format for iSCSI extension item-labels.
每个iSCSI扩展项在其类别中必须具有唯一的名称。此名称将用作密钥、访问方法或摘要的标准标签，并且必须符合第13.5.4节iSCSI扩展项标签的标准iSCSI扩展项标签格式中指定的语法。
For iSCSI extension items all of the protocols and procedures used by a given iSCSI extension item must be described, either in the specification of the iSCSI extension item itself or in some other publicly available specification, in sufficient detail for the iSCSI extension item to be implemented by any competent implementor. Use of secret and/or proprietary methods in iSCSI extension items are expressly prohibited. In addition, the restrictions imposed by [RFC1602] on the standardization of patented algorithms must be respected.
对于iSCSI扩展项，给定iSCSI扩展项使用的所有协议和过程必须在iSCSI扩展项本身的规范或其他一些公开可用的规范中进行详细描述，以便由任何合格的实施者实施iSCSI扩展项。明确禁止在iSCSI扩展项中使用秘密和/或专有方法。此外，必须遵守[RFC1602]对专利算法标准化的限制。
All iSCSI extension items must be described by an RFC. The RFC may be informational rather than Standards-Track, although Standards Track review and approval are encouraged for all iSCSI extension items.
所有iSCSI扩展项都必须由RFC描述。RFC可能是信息性的，而不是标准跟踪，尽管鼓励对所有iSCSI扩展项进行标准跟踪审查和批准。
Any known security issues that arise from the use of the iSCSI extension item must be completely and fully described. It is not required that the iSCSI extension item be secure or that it be free from risks, but that the known risks be identified. Publication of a new iSCSI extension item does not require an exhaustive security review, and the security considerations section is subject to continuing evaluation.
必须完整完整地描述因使用iSCSI扩展项而产生的任何已知安全问题。iSCSI扩展项不需要是安全的或没有风险的，但需要识别已知的风险。发布新的iSCSI扩展项不需要进行详尽的安全审查，安全注意事项部分需要持续评估。
Additional security considerations should be addressed by publishing revised versions of the iSCSI extension item specification.
应通过发布修订版的iSCSI扩展项规范来解决其他安全注意事项。
For each of these registries, IANA must record the registered string, which MUST conform to the format rules described in Section 13.5.4 Standard iSCSI extension item-label format for iSCSI extension item-labels, and the RFC number that describes it. The key prefix (X#, Y# or Z#) is not part of the recorded string.
对于每个注册中心，IANA必须记录注册的字符串，该字符串必须符合第13.5.4节iSCSI扩展项标签的标准iSCSI扩展项标签格式中描述的格式规则，以及描述该字符串的RFC编号。键前缀（X#、Y#或Z#）不是录制字符串的一部分。
Registration of a new iSCSI extension item starts with the construction of an Internet Draft to become an RFC.
注册新的iSCSI扩展项首先要构建一个Internet草稿，使其成为RFC。
Send a proposed access type specification to the IPS WG mailing list, or if the IPS WG is disbanded at the registration time, to a mailing list designated by the IETF Transport Area Director for a review period of a month. The intent of the public posting is to solicit comments and feedback on the iSCSI extension item specification and a review of any security considerations.
将建议的访问类型规范发送至IPS工作组邮件列表，或者如果IPS工作组在注册时解散，则发送至IETF传输区总监指定的邮件列表，审查期为一个月。公开发布的目的是征求对iSCSI扩展项规范的意见和反馈，并审查任何安全注意事项。
When the one month period has passed, the IPS WG chair or a person nominated by the IETF Transport Area Director (the iSCSI extension item reviewer) forwards the Internet Draft to the IESG for publication as an informational RFC or rejects it. If the specification is a standards track document, the usual IETF procedures for such documents are followed.
一个月后，IPS工作组主席或IETF传输区域主任（iSCSI扩展项目审查员）指定的人员将互联网草案转发给IESG，以作为信息RFC发布，或予以拒绝。如果规范是标准跟踪文件，则遵循此类文件的通常IETF程序。
Decisions made by the iSCSI extension item reviewer must be published within two weeks after the month-long review period. Decisions made by the iSCSI extension item reviewer can be appealed through the IESG appeal process.
iSCSI扩展项审阅者所做的决定必须在长达一个月的审阅期后的两周内发布。可以通过IESG上诉流程对iSCSI扩展项目审查员做出的决定提出上诉。
Provided that the iSCSI extension item has either passed review or has been successfully appealed to the IESG, and the specification is published as an RFC, then IANA will register the iSCSI extension item and make the registration available to the community.
如果iSCSI扩展项已通过审查或已成功向IESG上诉，且规范已作为RFC发布，则IANA将注册iSCSI扩展项并向社区提供注册。
The following character symbols are used iSCSI extension item-labels (the hexadecimal values represent Unicode code points):
以下字符符号用于iSCSI扩展项标签（十六进制值表示Unicode代码点）：
(a-z, A-Z) - letters
(0-9) - digits
"." (0x2e) - dot
"-" (0x2d) - minus
"+" (0x2b) - plus
"@" (0x40) - commercial at
"_" (0x5f) - underscore
(a-z, A-Z) - letters
(0-9) - digits
"." (0x2e) - dot
"-" (0x2d) - minus
"+" (0x2b) - plus
"@" (0x40) - commercial at
"_" (0x5f) - underscore
An iSCSI extension item-label is a string of one or more characters that consist of letters, digits, dot, minus, plus, commercial at, or underscore. An iSCSI extension item-label MUST begin with a capital letter and must not exceed 63 characters.
iSCSI扩展项标签是由一个或多个字符组成的字符串，这些字符由字母、数字、点、减、加、商用at或下划线组成。iSCSI扩展项标签必须以大写字母开头，且不得超过63个字符。
The identity of the iSCSI extension item reviewer is communicated to the IANA by the IESG. Then, the IANA only acts in response to iSCSI extension item definitions that are approved by the iSCSI extension item reviewer and forwarded by the reviewer to the IANA for registration, or in response to a communication from the IESG that an iSCSI extension item definition appeal has overturned the iSCSI extension item reviewer's ruling.
iSCSI扩展项审阅者的身份由IESG传达给IANA。然后，IANA仅响应iSCSI扩展项审核人批准并由审核人转发给IANA注册的iSCSI扩展项定义，或响应IESG关于iSCSI扩展项定义上诉推翻了iSCSI扩展项审核人裁决的通信。
References
工具书类
Normative References
规范性引用文件
[CAM] ANSI X3.232-199X, Common Access Method-3.
[CAM]ANSI X3.232-199X，通用访问方法-3。
[EUI] "Guidelines for 64-bit Global Identifier (EUI-64)",
http:
//standards.ieee.org/regauth/oui/tutorials/EUI64.html
[EUI] "Guidelines for 64-bit Global Identifier (EUI-64)",
http:
//standards.ieee.org/regauth/oui/tutorials/EUI64.html
[OUI] "IEEE OUI and Company_Id Assignments",
http://standards.ieee.org/regauth/oui
[OUI] "IEEE OUI and Company_Id Assignments",
http://standards.ieee.org/regauth/oui
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts-Communication Layer", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机通信层的要求”，STD 3，RFC 1122，1989年10月。
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[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月。
[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月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025]Adams，C.，“简单公钥GSS-API机制（SPKM）”，RFC 20252996年10月。
[RFC2045] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Borenstein，N.和N.Freed，“MIME（多用途Internet邮件扩展）第一部分：指定和描述Internet邮件正文格式的机制”，RFC 20451996年11月。
[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月。
[RFC2279] Yergeau, F., "UTF-8, a Transformation Format of ISO 10646", RFC 2279 October 1996.
[RFC2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1996年10月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter "Uniform Resource Identifiers", RFC 2396, August 1998.
[RFC2396]Berners Lee，T.，Fielding，R.和L.Masinter“统一资源标识符”，RFC 2396，1998年8月。
[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月。
[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月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation of 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)", RFC2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC2409，1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs.", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[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月。
[RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2451, December 1999.
[RFC2732]Hinden，R.，Carpenter，B.和L.Masinter，“URL中文字IPv6地址的格式”，RFC 24511999年12月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945]Wu，T.，“SRP认证和密钥交换系统”，RFC 29452000年9月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", STD 47, RFC 3066, January 2001.
[RFC3066]Alvestrand，H.，“语言识别标签”，STD 47，RFC 3066，2001年1月。
[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月。
[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, March 2004.
[RFC3722]Bakke，M.，“互联网小型计算机系统接口（iSCSI）名称的字符串配置文件”，RFC 3722，2004年3月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, March 2004.
[RFC3723]Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.和F.Travostino，“通过IP保护块存储协议”，RFC 37232004年3月。
[SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2).
[SAM2]T10/1157D，SCSI体系结构模型-2（SAM-2）。
[SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC).
[SBC]NCITS.306-1998，SCSI-3块命令（SBC）。
[SPC3] T10/1416-D, SCSI Primary Commands-3.
[SPC3]T10/1416-D，SCSI主命令-3。
[UNICODE] Unicode Standard Annex #15, "Unicode Normalization
Forms", http://www.unicode.org/unicode/reports/tr15
[UNICODE] Unicode Standard Annex #15, "Unicode Normalization
Forms", http://www.unicode.org/unicode/reports/tr15
Informative References
资料性引用
[BOOT] P. Sarkar, et al., "Bootstrapping Clients using the iSCSI Protocol", Work in Progress, July 2003.
[BOOT]P.Sarkar等人，“使用iSCSI协议引导客户端”，正在进行的工作，2003年7月。
[Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE Transact. on Communications, Vol. 41, No. 6, June 1993.
[Castagnoli93]G.Castagnoli，S.Braeuer和M.Herrman，“具有24和32奇偶校验位的循环冗余校验码的优化”，IEEE Transact。《来文》，第41卷，第6期，1993年6月。
[CORD] Chadalapaka, M. and R. Elliott, "SCSI Command Ordering Considerations with iSCSI", Work in Progress.
[CORD]Chadalapaka，M.和R.Elliott，“使用iSCSI的SCSI命令排序注意事项”，正在进行中。
[RFC3347] Krueger, M., Haagens, R., Sapuntzakis, C. and M. Bakke, "Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations", RFC 3347, July 2002.
[RFC3347]Krueger，M.，Haagens，R.，Sapuntzakis，C.和M.Bakke，“互联网上的小型计算机系统接口协议（iSCSI）要求和设计注意事项”，RFC 3347，2002年7月。
[RFC3385] Sheinwald, D., Staran, 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.，Staran，J.，Thaler，P.和V.Cavanna，“互联网协议小型计算机系统接口（iSCSI）循环冗余校验（CRC）/校验和注意事项”，RFC 33852002年9月。
[RFC3721] Bakke M., Hafner, J., Hufferd, J., Voruganti, K. and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery, RFC 3721, March 2004.
[RFC3721]Bakke M.，Hafner，J.，Hufferd，J.，Voruganti，K.和M.Krueger，“互联网小型计算机系统接口（iSCSI）命名和发现”，RFC 37212004年3月。
[SEQ-EXT] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in Progress, July 2002.
[SEQ-EXT]Kent，S.，“IP封装安全有效负载（ESP）”，正在进行的工作，2002年7月。
This appendix presents a simple scheme for synchronization (PDU boundary retrieval). It uses markers that include synchronization information placed at fixed intervals in the TCP stream.
本附录介绍了一种简单的同步方案（PDU边界检索）。它使用的标记包括TCP流中以固定间隔放置的同步信息。
A Marker consists of:
标记包括：
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| Next-iSCSI-PDU-start pointer - copy #1 |
+---------------+---------------+---------------+---------------+
4| Next-iSCSI-PDU-start pointer - copy #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| Next-iSCSI-PDU-start pointer - copy #1 |
+---------------+---------------+---------------+---------------+
4| Next-iSCSI-PDU-start pointer - copy #2 |
+---------------+---------------+---------------+---------------+
The Marker scheme uses payload byte stream counting that includes every byte placed by iSCSI in the TCP stream except for the markers themselves. It also excludes any bytes that TCP counts but are not originated by iSCSI.
标记方案使用有效负载字节流计数，包括iSCSI在TCP流中放置的每个字节，标记本身除外。它还排除TCP计数但不是由iSCSI发起的任何字节。
Markers MUST NOT be included in digest calculation.
摘要计算中不得包含标记。
The Marker indicates the offset to the next iSCSI PDU header. The Marker is eight bytes in length and contains two 32-bit offset fields that indicate how many bytes to skip in the TCP stream in order to find the next iSCSI PDU header. The marker uses two copies of the pointer so that a marker that spans a TCP packet boundary should leave at least one valid copy in one of the packets.
该标记指示到下一个iSCSI PDU标头的偏移量。该标记长度为8个字节，包含两个32位偏移量字段，用于指示要查找下一个iSCSI PDU标头，需要在TCP流中跳过多少字节。标记使用指针的两个副本，因此跨越TCP数据包边界的标记应在其中一个数据包中至少保留一个有效副本。
The structure and semantics of an inserted marker are independent of the marker interval.
插入标记的结构和语义与标记间隔无关。
The use of markers is negotiable. The initiator and target MAY indicate their readiness to receive and/or send markers during login separately for each connection. The default is No.
标记的使用是可以协商的。发起方和目标方可在登录期间分别为每个连接指示其准备好接收和/或发送标记。默认值为否。
A marker is inserted at fixed intervals in the TCP byte stream. During login, each end of the iSCSI session specifies the interval at which it is willing to receive the marker, or it disables the marker altogether. If a receiver indicates that it desires a marker, the sender MAY agree (during negotiation) and provide the marker at the desired interval. However, in certain environments, a sender that does not provide markers to a receiver that wants markers may suffer an appreciable performance degradation.
在TCP字节流中以固定的间隔插入标记。在登录过程中，iSCSI会话的每一端都指定它愿意接收标记的时间间隔，或者完全禁用标记。如果接收者表示它需要一个标记，发送者可以同意（在协商过程中）并以所需的间隔提供标记。但是，在某些环境中，如果发送方不向需要标记的接收方提供标记，则可能会出现明显的性能下降。
The marker interval and the initial marker-less interval are counted in terms of the bytes placed in the TCP stream data by iSCSI.
标记间隔和初始无标记间隔根据iSCSI放置在TCP流数据中的字节计数。
When reduced to iSCSI terms, markers MUST indicate the offset to a 4-byte word boundary in the stream. The least significant two bits of each marker word are reserved and are considered 0 for offset computation.
当简化为iSCSI术语时，标记必须指示流中4字节字边界的偏移量。每个标记字的最低有效两位被保留，在偏移量计算中被视为0。
Padding iSCSI PDU payloads to 4-byte word boundaries simplifies marker manipulation.
将iSCSI PDU有效负载填充到4字节字边界简化了标记操作。
To enable the connection setup including the Login Phase negotiation, marking (if any) is only started at the first marker interval after the end of the Login Phase. However, in order to enable the marker inclusion and exclusion mechanism to work without knowledge of the length of the Login Phase, the first marker will be placed in the TCP stream as if the Marker-less interval had included markers.
要启用包括登录阶段协商的连接设置，标记（如果有）仅在登录阶段结束后的第一个标记间隔开始。然而，为了使标记包含和排除机制能够在不知道登录阶段长度的情况下工作，第一个标记将被放置在TCP流中，就像无标记间隔包含了标记一样。
Thus, all markers appear in the stream at locations conforming to the formula: [(MI + 8) * n - 8] where MI = Marker Interval, n = integer number.
因此，所有标记出现在符合以下公式的流中：[（MI+8）*n-8]，其中MI=标记间隔，n=整数。
For example, if the marker interval is 512 bytes and the login ended at byte 1003 (first iSCSI placed byte is 0), the first marker will be inserted after byte 1031 in the stream.
例如，如果标记间隔为512字节，登录结束于字节1003（第一个iSCSI放置的字节为0），则第一个标记将插入流中字节1031之后。
The following operational key=value pairs are used to negotiate the fixed interval markers. The direction (output or input) is relative to the initiator.
以下操作键=值对用于协商固定间隔标记。方向（输出或输入）与启动器有关。
Use: IO Senders: Initiator and Target Scope: CO
用法：IO发送者：启动器和目标作用域：CO
OFMarker=<boolean-value>
IFMarker=<boolean-value>
OFMarker=<boolean-value>
IFMarker=<boolean-value>
Default is No.
默认为否。
Result function is AND.
结果函数为和。
OFMarker is used to turn on or off the initiator to target markers on the connection. IFMarker is used to turn on or off the target to initiator markers on the connection.
OFMarker用于打开或关闭启动器到连接上的目标标记。IFMarker用于打开或关闭连接上的目标到启动器标记。
Examples:
示例：
I->OFMarker=Yes,IFMarker=Yes
T->OFMarker=Yes,IFMarker=Yes
I->OFMarker=Yes,IFMarker=Yes
T->OFMarker=Yes,IFMarker=Yes
Results in the Marker being used in both directions while:
导致标记在两个方向上使用，同时：
I->OFMarker=Yes,IFMarker=Yes
T->OFMarker=Yes,IFMarker=No
I->OFMarker=Yes,IFMarker=Yes
T->OFMarker=Yes,IFMarker=No
Results in Marker being used from the initiator to the target, but not from the target to initiator.
导致从启动器到目标使用标记，而不是从目标到启动器使用标记。
Use: IO
Senders: Initiator and Target
Scope: CO
OFMarkInt is Irrelevant when: OFMarker=No
IFMarkInt is Irrelevant when: IFMarker=No
Use: IO
Senders: Initiator and Target
Scope: CO
OFMarkInt is Irrelevant when: OFMarker=No
IFMarkInt is Irrelevant when: IFMarker=No
Offering:
提供：
OFMarkInt=<numeric-range-from-1-to-65535>
IFMarkInt=<numeric-range-from-1-to-65535>
OFMarkInt=<numeric-range-from-1-to-65535>
IFMarkInt=<numeric-range-from-1-to-65535>
Responding:
答复：
OFMarkInt=<numeric-value-from-1-to-65535>|Reject
IFMarkInt=<numeric-value-from-1-to-65535>|Reject
OFMarkInt=<numeric-value-from-1-to-65535>|Reject
IFMarkInt=<numeric-value-from-1-to-65535>|Reject
OFMarkInt is used to set the interval for the initiator to target markers on the connection. IFMarkInt is used to set the interval for the target to initiator markers on the connection.
OFMarkInt用于设置启动器到连接上目标标记的间隔。IFMarkInt用于设置连接上目标到启动器标记的间隔。
For the offering, the initiator or target indicates the minimum to maximum interval (in 4-byte words) it wants the markers for one or both directions. In case it only wants a specific value, only a single value has to be specified. The responder selects a value within the minimum and maximum offered or the only value offered or indicates through the xFMarker key=value its inability to set and/or receive markers. When the interval is unacceptable the responder answers with "Reject". Reject is resetting the marker function in the specified direction (Output or Input) to No.
对于产品，发起者或目标表示它希望标记用于一个或两个方向的最小到最大间隔（4字节字）。如果它只需要一个特定的值，则只需指定一个值。响应者选择提供的最小值和最大值内的值或提供的唯一值，或通过xFMarker key=value指示其无法设置和/或接收标记。当间隔不可接受时，响应者回答“拒绝”。拒绝是将指定方向（输出或输入）上的标记功能重置为否。
The interval is measured from the end of a marker to the beginning of the next marker. For example, a value of 1024 means 1024 words (4096 bytes of iSCSI payload between markers).
间隔是从一个标记的末尾到下一个标记的开头测量的。例如，1024表示1024个字（标记之间的iSCSI负载为4096字节）。
The default is 2048.
默认值为2048。
+------------------+-----------------------+----------------------+
|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 | | |
+------------------+-----------------------+---------------------+
Output (write) data DataSN/R2TSN Example
输出（写入）数据DataSN/R2TSN示例
+------------------+-----------------------+----------------------+
|Initiator Function| PDU Type & 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 & 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 | | |
+------------------+-----------------------+----------------------+
Input (read) data DataSN Example
输入（读取）数据数据示例
+------------------+-----------------------+----------------------+
|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 | | |
+------------------+-----------------------+----------------------+
Bidirectional DataSN Example
双向DataSN示例
+------------------+-----------------------+----------------------+
|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 = 1, F=0 | |
+------------------+-----------------------+----------------------+
| * Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 2, F=1 | |
+------------------+-----------------------+----------------------+
| * Send Data | SCSI Data-Out >>> | Receive Data |
| for R2TSN 0 | DataSN = 0, 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 = 1, F=0 | |
+------------------+-----------------------+----------------------+
| * Receive Data | <<< SCSI Data-In | Send Data |
| | DataSN = 2, F=1 | |
+------------------+-----------------------+----------------------+
| * Send Data | SCSI Data-Out >>> | Receive Data |
| for R2TSN 0 | DataSN = 0, F=1 | |
+------------------+-----------------------+----------------------+
| | <<< SCSI Response |Send Status and Sense |
| | ExpDataSN = 3 | |
+------------------+-----------------------+----------------------+
| 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可以跟随所接收的数据）。
Unsolicited and immediate output (write) data with DataSN Example
非请求和即时输出（写入）数据，带有DataSN示例
+------------------+-----------------------+----------------------+
|Initiator Function| PDU Type & 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 & 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 | | |
+------------------+-----------------------+----------------------+
N.B. 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
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) FirstBurstLength=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
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 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 SPKM1:
在下一个示例中，启动器和目标通过SPKM1相互验证：
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=SPKM1,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=SPKM1,KRB5,None
T-> Login (CSG,NSG=0,0 T=0)
AuthMethod=SPKM1
T-> Login (CSG,NSG=0,0 T=0)
AuthMethod=SPKM1
I-> Login (CSG,NSG=0,0 T=0)
SPKM_REQ=<spkm-req>
I-> Login (CSG,NSG=0,0 T=0)
SPKM_REQ=<spkm-req>
(spkm-req is the SPKM-REQ token with the mutual-state bit in the options field of the REQ-TOKEN set)
（spkm req是spkm-req令牌，其相互状态位位于req-token集合的选项字段中）
T-> Login (CSG,NSG=0,0 T=0)
SPKM_REP_TI=<spkm-rep-ti>
T-> Login (CSG,NSG=0,0 T=0)
SPKM_REP_TI=<spkm-rep-ti>
If the authentication is successful, the initiator proceeds:
如果身份验证成功，启动器将继续：
I-> Login (CSG,NSG=0,1 T=1)
SPKM_REP_IT=<spkm-rep-it>
I-> Login (CSG,NSG=0,1 T=1)
SPKM_REP_IT=<spkm-rep-it>
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)
The initiator may proceed:
发起人可继续：
I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
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 target's authentication by the initiator is not successful, the initiator terminates the connection (without responding to the Login SPKM_REP_TI message).
如果启动器对目标的身份验证不成功，则启动器会终止连接（不响应登录SPKM_REP_TI消息）。
If the initiator's authentication by the target is not successful, the target responds with:
如果目标对启动器的身份验证不成功，则目标会响应：
T-> Login "login reject"
T->登录“拒绝登录”
instead of the Login "proceed and change stage" message, and terminates the connection.
而不是登录“继续并更改阶段”消息，并终止连接。
In the next example, the initiator and target authenticate each other via SPKM2:
在下一个示例中，启动器和目标通过SPKM2相互验证：
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=SPKM1,SPKM2
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=SPKM1,SPKM2
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=SPKM2
T-> Login-PR (CSG,NSG=0,0 T=0)
AuthMethod=SPKM2
I-> Login (CSG,NSG=0,1 T=1)
SPKM_REQ=<spkm-req>
I-> Login (CSG,NSG=0,1 T=1)
SPKM_REQ=<spkm-req>
(spkm-req is the SPKM-REQ token with the mutual-state bit in the options field of the REQ-TOKEN not set)
（spkm req是spkm-req令牌，req-token选项字段中的相互状态位未设置）
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)
The initiator may proceed:
发起人可继续：
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 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_GROUP=SRP-1536,SRP-1024
SRP_s=<s>
T-> Login (CSG,NSG=0,0 T=0)
SRP_GROUP=SRP-1536,SRP-1024
SRP_s=<s>
I-> Login (CSG,NSG=0,0 T=0)
SRP_GROUP=SRP-1536
SRP_A=<A>
I-> Login (CSG,NSG=0,0 T=0)
SRP_GROUP=SRP-1536
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:
如果启动器身份验证成功，目标将继续：
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 terminates the connection.
而不是T->Login SRP_HM=<H（A | M | K）>消息并终止连接。
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=No
I-> Login (CSG,NSG=0,0 T=0)
SRP_U=<user>
TargetAuth=No
T-> Login (CSG,NSG=0,0 T=0)
SRP_GROUP=SRP-1536
SRP_s=<s>
T-> Login (CSG,NSG=0,0 T=0)
SRP_GROUP=SRP-1536
SRP_s=<s>
I-> Login (CSG,NSG=0,0 T=0)
SRP_GROUP=SRP-1536
SRP_A=<A>
I-> Login (CSG,NSG=0,0 T=0)
SRP_GROUP=SRP-1536
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:
如果启动器身份验证成功，目标将继续：
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:
如果启动器身份验证成功，目标将继续：
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
T-> Login (CSG,NSG=1,0 T=0)
... iSCSI parameters
I-> Login (CSG,NSG=1,0 T=0)
... iSCSI parameters
T-> Login (CSG,NSG=1,0 T=0)
... iSCSI parameters
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 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:
如果启动器身份验证成功，目标将继续：
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"
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 (target name and IP address-port pairs and portal group tags) for the targets on the target network entity which 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 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 or 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 had 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 12.4 TargetName.
有关TargetName的格式，请参见第12.4节TargetName。
In a discovery session, a target 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, as specified for the TargetAddress key.
主机名或IP地址包含为TargetAddress密钥指定的域名、IPv4地址或IPv6地址。
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 portal group tag (as in Section 12.9 TargetPortalGroupTag). 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都属于一个门户组，由其数字门户组标记标识（如第12.9节TargetPortalGroupTag所示）。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 target 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响应。
Initiator sends text request that contains:
启动器发送包含以下内容的文本请求：
SendTargets=All
SendTargets=All
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 the 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 used on the current connection to the default iSCSI target.
在这个简单的例子中，所有目标必须返回的是目标名称。启动器假定此目标的IP地址和TCP端口与默认iSCSI目标的当前连接上使用的相同。
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
TargetAddress=10.1.0.45:3000,1 TargetAddress=10.1.1.45:3000,2
TargetName=iqn.1993-11.com.example:diskarray.sn.1234567
TargetAddress=10.1.0.45:3000,1 TargetAddress=10.1.1.45:3000,2
TargetName=iqn.1993-11.com.example:diskarray.sn.8675309
TargetAddress=10.1.0.45:3000,1 TargetAddress=10.1.1.45:3000,2
TargetName=iqn.1993-11.com.example:diskarray.sn.1234567
TargetAddress=10.1.0.45:3000,1 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 portal group tag; they do not support spanning multiple-connection sessions with each other. Keep in mind that the 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 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.1.46:3000,1
TargetAddress=10.1.0.47:3000,2 TargetAddress=10.1.1.48:3000,2
TargetAddress=10.1.1.49:3000,3
TargetAddress=10.1.0.45:3000,1 TargetAddress=10.1.1.46:3000,1
TargetAddress=10.1.0.47:3000,2 TargetAddress=10.1.1.48:3000,2
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:
本附录说明了使用伪编程语言的错误恢复类。过程名称的选择对大多数实现者来说是显而易见的。所描述的每个恢复类都有启动器过程和目标过程。这些算法侧重于概述错误恢复类的机制，而不是详尽地描述所有其他方面/情况。这种方法的例子有：
- 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;
};
Data structure definitions -
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 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;
struct TransferContext
TransferContextList[MaxOutStandingR2T];
int InitiatorTaskTag;
int CmdSN;
int SNACK_Tag;
int零食标签；
};
};
struct Connection {
struct Session SessionReference;
Boolean SoFarInOrder;
int CID;
int State;
struct Connection {
struct Session SessionReference;
Boolean SoFarInOrder;
int CID;
int State;
int CurrentTimeout;
int ExpectedStatSN;
int MissingStatSNList[MaxMissingSPDU];
Boolean PerformConnectionCleanup;
};
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-a-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);
Procedure descriptions -
Receive-a-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);
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);
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: Handle-Status-SNACK-request is defined in Within-connection recovery algorithms.
- 本节中使用的一个过程：处理状态零食请求在连接恢复算法中定义。
- The Response processing pseudo-code, shown in the target algorithms, applies to all solicited PDUs that carry 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);
}
} 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);
}
}
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);
}
}
Receive-a-In-PDU(Connection, CurrentPDU)
{
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Retrieve TCB for CurrentPDU.InitiatorTaskTag.
Receive-a-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 {
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.
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.
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);
}
}
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-a-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[].
}
Receive-a-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) {
}
}
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,
if（数据请求）{从BegRun和RunLength.Build-and-Send-a-Data-burst（连接）为数据突发创建一个数据描述符，
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 upto CurrentPDU.BegRun as
acknowledged.
Free up the retransmission resources for that data.
} else if (CurrentPDU.type == R-Data SNACK) {
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 upto 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;
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 (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);
} else {
TCB.Reason = "Protocol service CRC error";
if (TCB.ActiveR2Ts = 0) {
Build-And-Send-Status(Connection, 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);
}
}
}
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);
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);
Implementation-specific tunables: InitiatorProactiveSNACKEnabled
特定于实现的可调参数：Initiator RoactivesNackenabled
Notes:
笔记：
- The initiator algorithms only deal with unsolicited Nop-In PDUs for generating status SNACKs. A solicited Nop-In PDU has an assigned StatSN, which, 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处理，如果可能，再次导致恢复状态。
- The pseudo-code 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) {
如果可能，重新传输命令（连接，CmdSN）{
if (operational ErrorRecoveryLevel > 0) {
Retrieve the InitiatorTaskTag, and thus TCB for the CmdSN.
Build-And-Send-Command(Connection, TCB);
}
}
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;
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;
}
} 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-a-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 */
}
}
Receive-a-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 */
}
}
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);
}
}
}
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);
}
}
}
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);
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);
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);
Notes: - 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-a-In-PDU(Connection, CurrentPDU) {
check-basic-validity(CurrentPDU);
if (Header-Digest-Bad) discard, return;
Receive-a-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;
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;
}
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 {
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,
} 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);
}
} }
* 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 =
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); }
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;
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);
Connection.CurrentTimeout = DefaultTime2Retain;
Start-Timer(Connection-Cleanup-Handler, Connection,
DefaultTime2Wait);
} else {
Connection.State = FREE;
} }
} else {
Connection.State = FREE;
} }
Receive-a-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,
Receive-a-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);
}
}
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, "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 == TaskManagement) {
if (CurrentPDU.function == "TaskReassign") {
if (Session.ErrorRecoveryLevel < 2) {
Build-And-Send-TaskMgmt-Response(Connection,
CurrentPDU, "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,
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;
}
}
(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. N = No (not affected on the event specified in the row, i.e., stays at previous value). NA = Not Applicable or Not Defined.
Y=是（在行中指定的事件上清除/丢弃/重置）。除非另有说明，否则清除操作仅适用于发出启动器端口。N=否（不受行中指定事件的影响，即保持在以前的值）。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 |Y |Y |Y |Y |
+---------------------+-----+-----+-----+-----+-----+
|target warm reset(16)|Y |Y |Y |Y |Y |
+---------------------+-----+-----+-----+-----+-----+
|LU reset(19) |Y |Y |Y |Y |Y |
+---------------------+-----+-----+-----+-----+-----+
|powercycle(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 |Y |Y |Y |Y |
+---------------------+-----+-----+-----+-----+-----+
|target warm reset(16)|Y |Y |Y |Y |Y |
+---------------------+-----+-----+-----+-----+-----+
|LU reset(19) |Y |Y |Y |Y |Y |
+---------------------+-----+-----+-----+-----+-----+
|powercycle(16) |Y |Y |Y |Y |Y |
+---------------------+-----+-----+-----+-----+-----+
1. Incomplete TTTs - Target Transfer Tags on which the target is still expecting PDUs to be received. Examples include TTTs received via R2T, NOP-IN, etc.
1. TTTs不完整-目标仍希望接收PDU的目标传输标记。示例包括通过R2T、NOP-IN等接收的TTT。
2. Immediate Commands - immediate commands, but waiting for execution on a target. For example, Abort Task Set.
2. 即时命令-即时命令，但等待在目标上执行。例如，中止任务集。
5. Connection Tasks - tasks that are active on the iSCSI connection in question.
5. 连接任务—在相关iSCSI连接上处于活动状态的任务。
6. Session Tasks - tasks that are active on the entire iSCSI session. A union of "connection tasks" on all participating connections.
6. 会话任务—在整个iSCSI会话中处于活动状态的任务。所有参与连接上的“连接任务”的联合。
7. Partial PDUs (if any) - PDUs that are partially sent and waiting for transport window credit to complete the transmission.
7. 部分PDU（如果有）-部分发送并等待传输窗口积分完成传输的PDU。
8. Connection failure is a connection exception condition - one of the transport connections shutdown, 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 that 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).
9. 如果连接在清除等待状态下花费了登录协商期间商定的更多时间，则会发生连接状态超时，这会使连接进入空闲状态（连接清除状态图中的M1转换）。
10. These are defined in Section 5.3.5 Session Reinstatement, Closure, and Timeout.
10. 这些在第5.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 5.3.6 Session Continuation and Failure.
12. 会话继续在第5.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 5.3.6 Session Continuation and Failure.
18. 会话失败在第5.3.6节会话继续和失败中定义。
19. This operation affects all logged-in initiators and the clearing effects are only applicable to the LU being reset.
19. 此操作影响所有已登录的启动器，清除效果仅适用于正在重置的LU。
+-----+-----+-----+-----+-----+
|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 |
+---------------------+-----+-----+-----+-----+-----+
|powercycle |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 |
+---------------------+-----+-----+-----+-----+-----+
|powercycle |Y |Y |Y |Y(10)|NA |
+---------------------+-----+-----+-----+-----+-----+
1. Discontiguous Commands - 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. 不连续命令-命令allegiant连接到相关连接，并等待在iSCSI层中重新排序。此列中的所有“Y”都假定导致事件的任务（如果事件确实是任务的结果）是作为立即命令发出的，因为不连续性可能在任务之前。
2. Discontiguous Data - data PDUs received for the task in question and waiting to be reordered due to prior discontiguities in DataSN.
2. 不连续数据-收到的有关任务的数据PDU，由于数据N中先前的不连续而等待重新排序。
3. StatSN
3. 斯塔森
4. CmdSN
4. CmdSN
5. DataSN
5. 数据集
7. It 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 4.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 [SBC]) 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丢失”通知（第4.3.5.1节nexus丢失通知）。[SPC3]描述了此通知对各种SCSI属性的清除效果。此外，SCSI标准文档（如[SAM2]和[SBC]）定义了在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对象（如永久保留）将自动关联到此新会话。
Acknowledgements
致谢
This protocol was developed by a design team that, in addition to the authors, included Daniel Smith, Ofer Biran, Jim Hafner and John Hufferd (IBM), Mark Bakke (Cisco), Randy Haagens (HP), Matt Wakeley (Agilent, now Sierra Logic), Luciano Dalle Ore (Quantum), and Paul Von Stamwitz (Adaptec, now TrueSAN Networks).
该协议由一个设计团队开发，除作者外，该设计团队还包括丹尼尔·史密斯、奥费尔·比兰、吉姆·哈夫纳和约翰·赫福德（IBM）、马克·巴克（Cisco）、兰迪·哈根斯（HP）、马特·韦克利（安捷伦，现为塞拉逻辑）、卢西亚诺·达勒·奥雷（Quantum）和保罗·冯·斯坦维茨（Adaptec，现为TrueSAN Networks）。
Furthermore, a large group of people contributed to this work through their review, comments, and valuable insights. We are grateful to all of them. We especially thank those people who found the time and patience to take part in our weekly phone conferences and intermediate meetings in Almaden and Haifa, which helped shape this document: Prasenjit Sarkar, Meir Toledano, John Dowdy, Steve Legg, Alain Azagury (IBM), Dave Nagle (CMU), David Black (EMC), John Matze (Veritas - now Okapi Software), Steve DeGroote, Mark Schrandt (Cisco), Gabi Hecht (Gadzoox), Robert Snively and Brian Forbes (Brocade), Nelson Nachum (StorAge), and Uri Elzur (Broadcom). Many others helped edit and improve this document within the IPS working group. We are especially grateful to David Robinson and Raghavendra Rao (Sun), Charles Monia, Joshua Tseng (Nishan), Somesh Gupta (Silverback), Michael Krause, Pierre Labat, Santosh Rao, Matthew Burbridge, Bob Barry, Robert Elliott, Nick Martin (HP), Stephen Bailey (Sandburst), Steve Senum, Ayman Ghanem, Dave Peterson (Cisco), Barry Reinhold (Trebia Networks), Bob Russell (UNH), Eddy Quicksall (iVivity, Inc.), Bill Lynn and Michael Fischer (Adaptec), Vince Cavanna, Pat Thaler (Agilent), Jonathan Stone (Stanford), Luben Tuikov (Splentec), Paul Koning (EqualLogic), Michael Krueger (Windriver), Martins Krikis (Intel), Doug Otis (Sanlight), John Marberg (IBM), Robert Griswold and Bill Moody (Crossroads), Bill Studenmund (Wasabi Systems), Elizabeth Rodriguez (Brocade) and Yaron Klein (Sanrad). The recovery chapter was enhanced with the help of Stephen Bailey (Sandburst), Somesh Gupta (Silverback), and Venkat Rangan (Rhapsody Networks). Eddy Quicksall contributed some examples and began the Definitions section. Michael Fischer and Bob Barry started the Acronyms section. Last, but not least, we thank Ralph Weber for keeping us in line with T10 (SCSI) standardization.
此外，一大群人通过他们的审查、评论和宝贵的见解为这项工作做出了贡献。我们感谢他们所有人。我们特别感谢那些有时间和耐心参加我们在阿尔马登和海法举行的每周电话会议和中间会议的人：Prasenjit Sarkar、Meir Toledano、John Dowdy、Steve Legg、Alain Azagury（IBM）、Dave Nagle（CMU）、David Black（EMC）、John Matze（Veritas-现在的Okapi软件），史蒂夫·德格罗特（Steve DeGroote）、马克·施兰特（Cisco）、加比·赫特（Gabi Hecht）、罗伯特·斯尼弗利（Robert Snifly）和布莱恩·福布斯（Brian Forbes）（Brocade）、纳尔逊·纳丘（Nelson Nachum）（StorAge）和乌里·埃尔祖尔（Broadcom）。许多其他人在IPS工作组内帮助编辑和改进了该文件。我们特别感谢大卫·罗宾逊和拉格文德拉·饶（太阳）、查尔斯·莫尼亚、曾约书亚（尼山）、萨默什·古普塔（银背）、迈克尔·克劳斯、皮埃尔·拉巴特、桑托什·饶、马修·伯布里奇、鲍勃·巴里、罗伯特·埃利奥特、尼克·马丁（惠普）、斯蒂芬·贝利（桑德伯斯特）、史蒂夫·塞纳姆、艾曼·加内姆、戴夫·彼得森（思科）、巴里·莱因霍尔德（Trebia Networks）、Bob Russell（UNH）、Eddy Quicksall（iVivity，Inc.）、Bill Lynn和Michael Fischer（Adaptec）、Vince Cavanna、Pat Thaler（安捷伦）、Jonathan Stone（斯坦福）、Luben Tuikov（斯普莱特克）、Paul Koning（EqualLogic）、Michael Krueger（Windriver）、Martins Krikis（英特尔）、Doug Otis（Sanlight）、John Marberg（IBM）罗伯特·格里斯沃尔德和比尔·穆迪（Crossroads）、比尔·斯图登蒙德（Wasabi Systems）、伊丽莎白·罗德里格斯（Brocade）和亚伦·克莱因（Sanrad）。在斯蒂芬·贝利（Sandburst）、萨默什·古普塔（Silverback）和文卡特·兰根（Rhapsody Networks）的帮助下，恢复章节得到了加强.Eddy Quicksall提供了一些示例，并开始了定义部分。Michael Fischer和Bob Barry开始了首字母缩写部分。最后，但并非最不重要的是，我们感谢Ralph Weber使我们与T10（SCSI）标准保持一致。
We would like to thank Steve Hetzler for his unwavering support and for coming up with such a good name for the protocol, and Micky Rodeh, Jai Menon, Clod Barrera, and Andy Bechtolsheim for helping make this work happen.
我们要感谢史蒂夫·赫茨勒（Steve Hetzler）的坚定支持，感谢他为协议创造了这么好的名声，感谢米奇·罗德（Micky Rodeh）、杰伊·梅农（Jai Menon）、克洛德·巴雷拉（Clod Barrera）和安迪·贝奇托尔斯海姆（Andy Bechtolsheim）帮助实现了这项工作。
In addition to this document, we recommend you acquaint yourself with the following in order to get a full understanding of the iSCSI specification: "iSCSI Naming & Discovery"[RFC3721], "Bootstrapping Clients using the iSCSI Protocol" [BOOT], "Securing Block Storage Protocols over IP" [RFC3723] documents, "iSCSI Requirements and
除本文档外，我们建议您熟悉以下内容，以便全面了解iSCSI规范：“iSCSI命名与发现”[RFC3721]、“使用iSCSI协议引导客户端”[BOOT]、“通过IP保护块存储协议”[RFC3723]文档、“iSCSI要求和
Design Considerations" [RFC3347] and "SCSI Command Ordering Considerations with iSCSI" [CORD].
设计注意事项“[RFC3347]和“iSCSI的SCSI命令排序注意事项”[CORD]。
The "iSCSI Naming & Discovery" document is authored by:
“iSCSI命名和发现”文档的作者是：
Mark Bakke (Cisco), Jim Hafner, John Hufferd, Kaladhar Voruganti (IBM), and Marjorie Krueger (HP).
马克·巴克（思科）、吉姆·哈夫纳（Jim Hafner）、约翰·赫弗德（John Hufferd）、卡拉达尔·沃鲁甘蒂（IBM）和马乔里·克鲁格（HP）。
The "Bootstrapping Clients using the iSCSI Protocol" document is authored by:
“使用iSCSI协议引导客户端”文档由以下作者编写：
Prasenjit Sarkar (IBM), Duncan Missimer (HP), and Costa Sapuntzakis (Cisco).
Prasenjit Sarkar（IBM）、Duncan Missimer（惠普）和Costa Sapuntzakis（思科）。
The "Securing Block Storage Protocols over IP" document is authored by:
“通过IP保护块存储协议”文档由以下作者编写：
Bernard Aboba (Microsoft), Joshua Tseng (Nishan), Jesse Walker (Intel), Venkat Rangan (Rhapsody Networks), and Franco Travostino (Nortel Networks).
Bernard Aboba（微软）、Joshua Tseng（尼山）、Jesse Walker（英特尔）、Venkat Rangan（狂想曲网络）和Franco Travostino（北电网络）。
The "iSCSI Requirements and Design Considerations" document is authored by:
“iSCSI要求和设计注意事项”文档的作者是：
Marjorie Krueger, Randy Haagens (HP), Costa Sapuntzakis, and Mark Bakke (Cisco).
Marjorie Krueger、Randy Haagens（惠普）、Costa Sapuntzakis和Mark Bakke（思科）。
The "SCSI Command Ordering Considerations with iSCSI" document is authored by:
“iSCSI的SCSI命令排序注意事项”文档由以下作者编写：
Mallikarjun Chadalapaka, Rob Elliot (HP)
Mallikarjun Chadalapaka，Rob Elliot（惠普）
We are grateful to all of them for their good work and for helping us correlate this document with the ones they produced.
我们感谢他们的出色工作，并帮助我们将本文件与他们制作的文件联系起来。
Authors' Addresses
作者地址
Julian Satran IBM Research Laboratory in Haifa Haifa University Campus - Mount Carmel Haifa 31905, Israel
朱利安·萨特兰（Julian Satran）位于以色列海法31905卡梅尔山海法大学校园的IBM研究实验室
Phone +972.4.829.6264 EMail: Julian_Satran@il.ibm.com
电话+972.4.829.6264电子邮件：Julian_Satran@il.ibm.com
Kalman Meth IBM Research Laboratory in Haifa 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
Costa Sapuntzakis Stanford University 353 Serra Mall Dr #407 Stanford, CA 94305
Costa Sapuntzakis斯坦福大学353 Serra Mall Dr#407斯坦福，加利福尼亚州94305
Phone: +1.650.723.2458
EMail: csapuntz@alum.mit.edu
Phone: +1.650.723.2458
EMail: csapuntz@alum.mit.edu
Efri Zeidner XIV Ltd. 1 Azrieli Center, Tel-Aviv 67021, Israel
以色列特拉维夫Azrieli中心1号Efra Zeidner XIV有限公司67021
Phone: +972.3.607.4722
EMail: efri@xiv.co.il
Phone: +972.3.607.4722
EMail: efri@xiv.co.il
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd. Roseville, CA 95747-5668, USA
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd。美国加利福尼亚州罗斯维尔95747-5668
Phone: +1.916.785.5621
EMail: cbm@rose.hp.com
Phone: +1.916.785.5621
EMail: cbm@rose.hp.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。