summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3720.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc3720.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc3720.txt')
-rw-r--r--doc/rfc/rfc3720.txt14395
1 files changed, 14395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3720.txt b/doc/rfc/rfc3720.txt
new file mode 100644
index 0000000..2041f93
--- /dev/null
+++ b/doc/rfc/rfc3720.txt
@@ -0,0 +1,14395 @@
+
+
+
+
+
+
+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)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+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.
+
+ 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.).
+
+ 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.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 1]
+
+RFC 3720 iSCSI April 2004
+
+
+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
+
+
+
+Satran, et al. Standards Track [Page 2]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 3]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 4]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 5]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 6]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 7]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 8]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+1. Introduction
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 9]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+2. Definitions and Acronyms
+
+2.1. Definitions
+
+ - 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.
+
+ - 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.
+
+ - 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).
+
+ - 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 Initiator Name: The iSCSI Initiator Name specifies the
+ worldwide unique name of the initiator.
+
+ - 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 Layer: This layer builds/receives iSCSI PDUs and
+ relays/receives them to/from one or more TCP connections that form
+ an initiator-target "session".
+
+
+
+
+Satran, et al. Standards Track [Page 10]
+
+RFC 3720 iSCSI April 2004
+
+
+ - iSCSI Name: The name of an iSCSI initiator or iSCSI target.
+
+ - 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 Target Name: The iSCSI Target Name specifies the worldwide
+ unique name of the target.
+
+ - iSCSI Target Node: The "target".
+
+ - iSCSI Task: An iSCSI task is an iSCSI request for which a response
+ is expected.
+
+ - 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.
+
+ - ISID: The initiator part of the Session Identifier. It is
+ explicitly specified by the initiator during Login.
+
+ - 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).
+
+ - 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.
+
+ - 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.
+
+
+
+
+Satran, et al. Standards Track [Page 11]
+
+RFC 3720 iSCSI April 2004
+
+
+ - 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.
+
+ - 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.
+
+ - 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.
+
+ - 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.
+
+ - 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 12]
+
+RFC 3720 iSCSI April 2004
+
+
+ - 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.
+
+ - 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.
+
+ - 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 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 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 Target Port: This maps to an iSCSI Target Portal Group.
+
+ - 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.
+
+ - 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.
+
+ - Target Portal Group Tag: A numerical identifier (16-bit) for an
+ iSCSI Target Portal Group.
+
+
+
+Satran, et al. Standards Track [Page 13]
+
+RFC 3720 iSCSI April 2004
+
+
+ - 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.
+
+2.2. Acronyms
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 14]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 15]
+
+RFC 3720 iSCSI April 2004
+
+
+ TTT Target Transfer Tag
+ UFL Upper Functional Layer
+ ULP Upper Level Protocol
+ URN Uniform Resource Names [RFC2396]
+ UTF Universal Transformation Format
+ WG Working Group
+
+2.3. Conventions
+
+ In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator
+ and target respectively.
+
+ 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].
+
+ iSCSI messages - PDUs - are represented by diagrams as in the
+ following example:
+
+ 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
+
+2.3.1. Word 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.
+
+ Decimal and hexadecimal representation of word values map this
+ representation to decimal or hexadecimal positional notation.
+
+
+
+Satran, et al. Standards Track [Page 16]
+
+RFC 3720 iSCSI April 2004
+
+
+2.3.2. Half-Word Rule
+
+ 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.
+
+ Decimal and hexadecimal representation of half-word values map this
+ representation to decimal or hexadecimal positional notation.
+
+2.3.3. Byte Rule
+
+ For every PDU, bytes are sent and received in increasing numbered
+ order (network order).
+
+ 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.
+
+3. Overview
+
+3.1. SCSI Concepts
+
+ 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.
+
+ 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 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.
+
+ 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).
+
+ A SCSI task is a SCSI command or possibly a linked set of SCSI
+ commands. Some LUs support multiple pending (queued) tasks, but the
+
+
+
+Satran, et al. Standards Track [Page 17]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+3.2. iSCSI Concepts and Functional Overview
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ An iSCSI task is an iSCSI request for which a response is expected.
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 18]
+
+RFC 3720 iSCSI April 2004
+
+
+3.2.1. Layers and Sessions
+
+ 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
+
+ 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".
+
+ 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).
+
+ 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.
+
+ 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.
+
+3.2.2. Ordering and iSCSI Numbering
+
+ iSCSI uses Command and Status numbering schemes and a Data sequencing
+ scheme.
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 19]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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].
+
+3.2.2.1. Command Numbering and Acknowledging
+
+ 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 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 20]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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).
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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.
+
+ For the numbering mechanism, the initiator and target maintain the
+ following three variables for each session:
+
+
+
+
+
+Satran, et al. Standards Track [Page 21]
+
+RFC 3720 iSCSI April 2004
+
+
+ - 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.
+
+ 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.
+
+ 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).
+
+ MaxCmdSN and ExpCmdSN fields are processed by the initiator as
+ follows:
+
+ - 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.
+
+ This sequence is required because updates may arrive out of order
+ (e.g., the updates are sent on different TCP connections).
+
+ iSCSI initiators and targets MUST support the command numbering
+ scheme.
+
+
+
+Satran, et al. Standards Track [Page 22]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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).
+
+ 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.
+
+3.2.2.2. Response/Status Numbering and Acknowledging
+
+ 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.
+
+ 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.
+
+ A large absolute difference between StatSN and ExpStatSN may indicate
+ a failed connection. Initiators MUST undertake recovery actions if
+
+
+
+Satran, et al. Standards Track [Page 23]
+
+RFC 3720 iSCSI April 2004
+
+
+ the difference is greater than an implementation defined constant
+ that MUST NOT exceed 2**31-1.
+
+ Initiators and Targets MUST support the response-numbering scheme.
+
+3.2.2.3. Data Sequencing
+
+ 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.
+
+ 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.
+
+3.2.3. iSCSI Login
+
+ 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.
+
+ 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).
+
+ 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.
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 24]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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].
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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.
+
+ 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.
+
+3.2.4. iSCSI Full Feature Phase
+
+ 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)
+
+
+
+Satran, et al. Standards Track [Page 25]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+ a) when it does not have an established transport connection,
+
+ OR
+
+ b) when it has a valid transport connection, but a successful
+ login was not performed or the connection is currently logged
+ out.
+
+ 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.
+
+3.2.4.1. Command Connection Allegiance
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 26]
+
+RFC 3720 iSCSI April 2004
+
+
+3.2.4.2. Data Transfer Overview
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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).
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 27]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+3.2.4.3. Tags and Integrity Checks
+
+ 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.
+
+ 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.
+
+3.2.4.4. Task Management
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 28]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+3.2.5. iSCSI Connection Termination
+
+ 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.
+
+ 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.
+
+ 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.
+
+3.2.6. iSCSI Names
+
+ 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 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 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 29]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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].
+
+3.2.6.1. iSCSI Name Properties
+
+ Each iSCSI node, whether an initiator or target, MUST have an iSCSI
+ name.
+
+ Initiators and targets MUST support the receipt of iSCSI names of up
+ to the maximum length of 223 bytes.
+
+ 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 names have the following properties:
+
+ 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.
+
+ The encoding of an iSCSI name has the following properties:
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 30]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+3.2.6.2. iSCSI Name Encoding
+
+ An iSCSI name MUST be a UTF-8 encoding of a string of Unicode
+ characters with the following properties:
+
+ - 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:
+
+ - dash ('-'=U+002d)
+ - dot ('.'=U+002e)
+ - colon (':'=U+003a)
+
+ - The UTF-8 encoding of the name is not larger than 223 bytes.
+
+
+
+
+
+Satran, et al. Standards Track [Page 31]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ Once iSCSI names encoded in UTF-8 are "normalized" they may be safely
+ compared byte-for-byte.
+
+3.2.6.3. iSCSI Name Structure
+
+ An iSCSI name consists of two parts--a type designator followed by a
+ unique name string.
+
+ 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).
+
+ 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.
+
+ 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.
+
+3.2.6.3.1. Type "iqn." (iSCSI Qualified Name)
+
+ 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.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 32]
+
+RFC 3720 iSCSI April 2004
+
+
+ just needs to be reserved to prevent others from generating iSCSI
+ names using the same domain name.
+
+ 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.
+
+ The iSCSI qualified name string consists of:
+
+ - 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".
+
+ The following are examples of iSCSI qualified names that might be
+ generated by "EXAMPLE Storage Arrays, Inc."
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 33]
+
+RFC 3720 iSCSI April 2004
+
+
+
+3.2.6.3.2. Type "eui." (IEEE EUI-64 format)
+
+ 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].
+
+ The format is "eui." followed by an EUI-64 identifier (16
+ ASCII-encoded hexadecimal digits).
+
+ Example iSCSI name:
+
+ 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.
+
+ More examples of name construction are discussed in [RFC3721].
+
+3.2.7. Persistent State
+
+ 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 sessions do not persist through power cycles and boot
+ operations.
+
+ All iSCSI session and connection parameters are re-initialized upon
+ session and connection creation.
+
+ 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.)
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 34]
+
+RFC 3720 iSCSI April 2004
+
+
+3.2.8. Message Synchronization and Steering
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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 -.
+
+ 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.
+
+ 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
+
+
+
+
+Satran, et al. Standards Track [Page 35]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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:
+
+ - 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).
+
+ - 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.
+
+3.2.8.1. Sync/Steering and iSCSI PDU Length
+
+ 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.
+
+3.3. iSCSI Session Types
+
+ iSCSI defines two types of sessions:
+
+ 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.
+
+ The session type is defined during login with the key=value parameter
+ in the login command.
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 36]
+
+RFC 3720 iSCSI April 2004
+
+
+3.4. SCSI to iSCSI Concepts Mapping Model
+
+ 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.
+
+ +-----------------------------------+
+ | 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) |
+ +-----------------------------------+
+
+3.4.1. iSCSI Architecture Model
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 37]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 38]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ f) Portals within a Portal Group should support similar session
+ parameters, because they may participate in a common session.
+
+ The following diagram shows an example of one such configuration on a
+ target and how a session that shares Network Portals within a Portal
+ Group may be established.
+
+ ----------------------------IP Network---------------------
+ | | |
+ +----|---------------|-----+ +----|---------+
+ | +---------+ +---------+ | | +---------+ |
+ | | Network | | Network | | | | Network | |
+ | | Portal | | Portal | | | | Portal | |
+ | +--|------+ +---------+ | | +---------+ |
+ | | | | | | |
+ | | Portal | | | | Portal |
+ | | Group 1 | | | | Group 2 |
+ +--------------------------+ +--------------+
+ | | |
+ +--------|---------------|--------------------|--------------------+
+ | | | | |
+ | +----------------------------+ +-----------------------------+ |
+ | | iSCSI Session (Target side)| | iSCSI Session (Target side) | |
+ | | | | | |
+ | | (TSIH = 56) | | (TSIH = 48) | |
+ | +----------------------------+ +-----------------------------+ |
+ | |
+ | iSCSI Target Node |
+ | (within Network Entity, not shown) |
+ +------------------------------------------------------------------+
+
+3.4.2. SCSI Architecture Model
+
+ 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.
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 39]
+
+RFC 3720 iSCSI April 2004
+
+
+ The following list outlines mappings of SCSI architectural elements
+ to 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.
+
+ 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.
+
+ 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 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.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 40]
+
+RFC 3720 iSCSI April 2004
+
+
+ - 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).
+
+ The ASCII character 'i' or 't' is the label that identifies
+ this port as either a SCSI Initiator Port or a SCSI Target
+ Port.
+
+ 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).
+
+ NOTE: The I_T nexus identifier is not equal to the session
+ identifier (SSID).
+
+3.4.3. Consequences of the Model
+
+ 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).
+
+ 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.
+
+ 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.)
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 41]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+3.4.3.1. I_T Nexus State
+
+ Certain nexus relationships contain an explicit state (e.g.,
+ initiator-specific mode pages) that may need to be preserved by the
+ device server [SAM2] in a 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.
+
+3.5. Request/Response Summary
+
+ This section lists and briefly describes all the iSCSI PDU types
+ (request and responses).
+
+ 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).
+
+ The basic header segment has a fixed length of 48 bytes.
+
+
+
+
+Satran, et al. Standards Track [Page 42]
+
+RFC 3720 iSCSI April 2004
+
+
+3.5.1. Request/Response Types Carrying SCSI Payload
+
+3.5.1.1. SCSI-Command
+
+ 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.
+
+ 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.
+
+ 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.
+
+3.5.1.2. SCSI-Response
+
+ The SCSI-Response carries all the SCSI execute-command procedure call
+ (see [SAM2]) OUT arguments and the SCSI execute-command procedure
+ call return value.
+
+ 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.
+
+ 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.
+
+ 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:
+
+ - 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.
+
+
+
+
+Satran, et al. Standards Track [Page 43]
+
+RFC 3720 iSCSI April 2004
+
+
+ - ExpCmdSN - the next Expected Command Sequence Number at the
+ target.
+ - MaxCmdSN - the maximum CmdSN acceptable at the target from
+ this initiator.
+
+3.5.1.3 Task Management Function Request
+
+ 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.
+
+ 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).
+
+ 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.
+
+ For a Task Management function, the coordination between responses to
+ the tasks affected and the Task Management function response is done
+ by the target.
+
+3.5.1.4. Task Management Function Response
+
+ 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.
+
+3.5.1.5. SCSI Data-Out and SCSI Data-In
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 44]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ In each direction, the data transfer is split into "sequences". An
+ end-of-sequence is indicated by the F bit.
+
+ 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.
+
+ 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.
+
+ 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).
+
+ In addition, StatSN is carried by the Data-In PDUs.
+
+ 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).
+
+3.5.1.6. Ready To Transfer (R2T)
+
+ R2T is the mechanism by which the SCSI target "requests" the
+ initiator for output data. R2T specifies to the initiator the offset
+ of the requested data relative to the buffer address from the execute
+ command procedure call and the length of the solicited data.
+
+ 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.
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 45]
+
+RFC 3720 iSCSI April 2004
+
+
+ R2T also carries information required for proper operation of the
+ iSCSI protocol, such as:
+
+ - R2TSN (to enable an initiator to detect a missing R2T)
+ - StatSN
+ - ExpCmdSN
+ - MaxCmdSN
+
+3.5.2. Requests/Responses carrying SCSI and iSCSI Payload
+
+3.5.2.1. Asynchronous Message
+
+ Asynchronous Messages are used to carry SCSI asynchronous events
+ (AEN) and iSCSI asynchronous messages.
+
+ When carrying an AEN, the event details are reported as sense data in
+ the data segment.
+
+3.5.3. Requests/Responses Carrying iSCSI Only Payload
+
+3.5.3.1. Text Request and Text Response
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Although a complete exchange is always started by the initiator,
+ specific parameter negotiations may be initiated by the initiator or
+ target.
+
+
+
+
+
+Satran, et al. Standards Track [Page 46]
+
+RFC 3720 iSCSI April 2004
+
+
+3.5.3.2. Login Request and Login Response
+
+ 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.
+
+ Similar to the Text Requests and Responses, Login Requests/Responses
+ carry key=value text information with a simple syntax in the data
+ segment.
+
+ 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).
+
+ 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.
+
+ StatSN for each connection is initiated by the connection login.
+
+ 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.
+
+3.5.3.3. Logout Request and Response
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 47]
+
+RFC 3720 iSCSI April 2004
+
+
+ new connection) in the text key Time2Retain and how long the
+ initiator must wait before proceeding with recovery in the text key
+ Time2Wait.
+
+3.5.3.4. SNACK Request
+
+ 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.
+
+3.5.3.5. Reject
+
+ 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.
+
+3.5.3.6. NOP-Out Request and NOP-In Response
+
+ 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.
+
+ 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.
+
+4. SCSI Mode Parameters for iSCSI
+
+ There are no iSCSI specific mode pages.
+
+5. Login and Full Feature Phase Negotiation
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 48]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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.
+
+ 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".
+
+
+
+
+
+Satran, et al. Standards Track [Page 49]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+5.1. Text Format
+
+ 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.
+
+ The following character symbols are used in this document for text
+ items (the hexadecimal values represent Unicode code points):
+
+ (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).
+
+ Every key=value pair, including the last or only pair in a LTDS, MUST
+ be followed by one null (0x00) delimiter.
+
+
+
+
+Satran, et al. Standards Track [Page 50]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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-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.
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 51]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 52]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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).
+
+5.2. Text Mode Negotiation
+
+ 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.
+
+ 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).
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 53]
+
+RFC 3720 iSCSI April 2004
+
+
+ The format of a declaration is:
+
+ Declarer-> <key>=<valuex>
+
+ The general format of text negotiation is:
+
+ 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.
+
+ 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 X#vkey1=(bla,alb,None),X#vkey2=(bla,alb)
+ T->I X#vkey1=None,X#vkey2=Irrelevant
+
+
+
+Satran, et al. Standards Track [Page 54]
+
+RFC 3720 iSCSI April 2004
+
+
+
+ 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.
+
+ 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.
+
+ 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-com.example.bar.foo.do_something=3
+
+ or a new registered key may be used as in:
+
+ X#SuperCalyPhraGilistic=Yes
+
+ 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).
+
+ Whenever parameter action or acceptance is dependent on other
+ parameters, the dependency rules and parameter sequence must be
+ specified with the parameters.
+
+
+
+
+
+Satran, et al. Standards Track [Page 55]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ An iSCSI initiator or target MAY terminate a negotiation that does
+ not end within a reasonable time or number of exchanges.
+
+5.2.1. List negotiations
+
+ 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.
+
+ 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.
+
+5.2.2. Simple-value Negotiations
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 56]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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".
+
+ Responses are REQUIRED in all other cases, and the value chosen and
+ sent by the acceptor becomes the outcome of the negotiation.
+
+5.3. Login Phase
+
+ 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.
+
+ 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).
+
+ The default MaxRecvDataSegmentLength is used during Login.
+
+ 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)
+
+
+
+
+Satran, et al. Standards Track [Page 57]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 58]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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 |
+ +-----------------------------------------------------------+
+
+ 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.
+
+ 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
+
+
+
+
+Satran, et al. Standards Track [Page 59]
+
+RFC 3720 iSCSI April 2004
+
+
+ by the target, the target MUST respond with Login reject (initiator
+ error); if detected by the initiator, the initiator MUST drop the
+ connection.
+
+5.3.1. Login Phase Start
+
+ 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.
+
+ 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:
+
+
+ +------------------------------------------------------------------+
+ |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.
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 60]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 61]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+5.3.2. iSCSI Security Negotiation
+
+ 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.
+
+ 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.
+
+ - 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
+
+
+
+
+Satran, et al. Standards Track [Page 62]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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).
+
+5.3.3. Operational Parameter Negotiation During the Login Phase
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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.
+
+ For operational parameters, see Chapter 12.
+
+
+
+
+
+Satran, et al. Standards Track [Page 63]
+
+RFC 3720 iSCSI April 2004
+
+
+5.3.4. Connection Reinstatement
+
+ 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.
+
+ 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.
+
+ The initiator connection state MUST be CLEANUP_WAIT (section 7.1.3)
+ when the initiator attempts a connection reinstatement.
+
+ In practical terms, in addition to the implicit logout of the old
+ connection, reinstatement is equivalent to a new connection login.
+
+5.3.5. Session Reinstatement, Closure, and Timeout
+
+ 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.
+
+ The initiator session state MUST be FAILED (Section 7.3 Session State
+ Diagrams) when the initiator attempts a session reinstatement.
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 64]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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).
+
+5.3.5.1. Loss of Nexus Notification
+
+ The iSCSI layer provides the SCSI layer with the "I_T nexus loss"
+ notification when any one of the following events happens:
+
+ a) Successful completion of session reinstatement.
+ b) Session closure event.
+ c) Session timeout event.
+
+ 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 -.
+
+5.3.6. Session Continuation and Failure
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 65]
+
+RFC 3720 iSCSI April 2004
+
+
+5.4. Operational Parameter Negotiation Outside the Login Phase
+
+ 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.
+
+ 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.
+
+ Targets MUST NOT submit parameters that require an additional
+ initiator Text request in a Text response with the F bit set to 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 66]
+
+RFC 3720 iSCSI April 2004
+
+
+ Parameters negotiated by a text exchange negotiation sequence only
+ become effective after the negotiation sequence is completed.
+
+6. iSCSI Error Handling and Recovery
+
+6.1. Overview
+
+6.1.1. Background
+
+ The following two considerations prompted the design of much of the
+ error recovery functionality in 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.
+
+ 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.
+
+6.1.2. Goals
+
+ The major design goals of the iSCSI error recovery scheme are as
+ follows:
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 67]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+6.1.3. Protocol Features and State Expectations
+
+ 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)
+
+ 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)
+
+ 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.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 68]
+
+RFC 3720 iSCSI April 2004
+
+
+ until either the status for the completed command is acknowledged, or
+ the data in question has been separately acknowledged.
+
+6.1.4. Recovery Classes
+
+ iSCSI enables the following classes of recovery (in the order of
+ increasing scope of affected iSCSI tasks):
+
+ - 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.
+
+ 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.
+
+ 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.
+
+6.1.4.1. Recovery Within-command
+
+ At the target, the following cases lend themselves to
+ within-command recovery:
+
+ - Lost data PDU - realized through one of the following:
+
+ a) Data digest error - dealt with as specified in Section 6.7
+ Digest Errors, using the option of a recovery R2T.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 69]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ At the initiator, the following cases lend themselves to
+ within-command recovery:
+
+ Lost data PDU or lost R2T - realized through one of the
+ following:
+
+ 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.
+
+ 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.
+
+ 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.
+
+6.1.4.2. Recovery Within-connection
+
+ 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.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 70]
+
+RFC 3720 iSCSI April 2004
+
+
+ - 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.
+
+ 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.
+
+ The timeout values used by the initiator and the target are outside
+ the scope of this document.
+
+6.1.4.3. Connection Recovery
+
+ At an iSCSI initiator, the following cases lend themselves to
+ connection recovery:
+
+ - 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.
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 71]
+
+RFC 3720 iSCSI April 2004
+
+
+ At an iSCSI target, the following cases lend themselves to connection
+ recovery:
+
+ - 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.
+
+6.1.4.4. Session Recovery
+
+ 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.
+
+ 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).
+
+ For possible clearing effects of session recovery on SCSI and iSCSI
+ objects, refer to Appendix F. - Clearing Effects of Various Events on
+ Targets -.
+
+6.1.5. Error Recovery Hierarchy
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 72]
+
+RFC 3720 iSCSI April 2004
+
+
+ The following diagram represents the error recovery hierarchy.
+
+ +
+ /
+ / 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 |
+ +-------------------+--------------------------------------------+
+
+ 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).
+
+ 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.
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 73]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ +-------------------+---------------------------------------------+
+ |Level transition | Incremental requirement |
+ +-------------------+---------------------------------------------+
+ | 0->1 | PDU retransmissions on the same connection |
+ +-------------------+---------------------------------------------+
+ | 1->2 | Retransmission across connections and |
+ | | allegiance reassignment |
+ +-------------------+---------------------------------------------+
+
+6.2. Retry and Reassign in Recovery
+
+ This section summarizes two important and somewhat related iSCSI
+ protocol features used in error recovery.
+
+6.2.1. Usage of Retry
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 74]
+
+RFC 3720 iSCSI April 2004
+
+
+6.2.2. Allegiance Reassignment
+
+ 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.
+
+ 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.
+
+ 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".
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 75]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+6.3. Usage Of Reject PDU in Recovery
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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.
+
+6.4. Connection Timeout Management
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 76]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+6.4.1. Timeouts on Transport Exception Events
+
+ 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.
+
+6.4.2. Timeouts on Planned Decommissioning
+
+ 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.
+
+ 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.
+
+6.5. Implicit Termination of Tasks
+
+ A target implicitly terminates the active tasks due to iSCSI protocol
+ dynamics in the following cases:
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+
+Satran, et al. Standards Track [Page 77]
+
+RFC 3720 iSCSI April 2004
+
+
+ time out after the Time2Wait and Time2Retain periods without
+ allegiance reassignment.
+
+ 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.
+
+ 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]).
+
+6.6. Format Errors
+
+ The following two explicit violations of PDU layout rules are format
+ errors:
+
+ 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).
+
+ 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).
+
+6.7. Digest Errors
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 78]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ - 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.
+
+ When an initiator receives any iSCSI PDU with a payload digest error,
+ it MUST discard the PDU.
+
+ - If the discarded PDU is an iSCSI data PDU, the initiator MUST do
+ one of the following:
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 79]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ - If the discarded PDU is a response PDU, the initiator MUST do one
+ of the following:
+
+ 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).
+
+ - 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.
+
+6.8. Sequence Errors
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 80]
+
+RFC 3720 iSCSI April 2004
+
+
+6.9. SCSI Timeouts
+
+ 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.
+
+ 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:
+
+ - 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".
+
+6.10. Negotiation Failures
+
+ 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.
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 81]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+6.11. Protocol Errors
+
+ 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.
+
+ 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.
+
+6.12. Connection Failures
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 82]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+ - 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).
+
+ - Perform session recovery (Section 6.1.4.4 Session Recovery).
+
+ 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).
+
+6.13. Session Errors
+
+ 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).
+
+ 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.
+
+ A target MUST also be prepared to handle a session reinstatement
+ request from the initiator, that may be addressing session errors.
+
+
+
+Satran, et al. Standards Track [Page 83]
+
+RFC 3720 iSCSI April 2004
+
+
+7. State Transitions
+
+ iSCSI connections and iSCSI sessions go through several well-defined
+ states from the time they are created to the time they are cleared.
+
+ 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.
+
+ 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.
+
+ 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.
+
+7.1. Standard Connection State Diagrams
+
+7.1.1. State Descriptions for Initiators and Targets
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 84]
+
+RFC 3720 iSCSI April 2004
+
+
+ -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.
+
+7.1.2. State Transition Descriptions for Initiators and Targets
+
+ -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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 85]
+
+RFC 3720 iSCSI April 2004
+
+
+ -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.
+
+ 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.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 86]
+
+RFC 3720 iSCSI April 2004
+
+
+ -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.
+
+ -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.
+
+
+
+Satran, et al. Standards Track [Page 87]
+
+RFC 3720 iSCSI April 2004
+
+
+ -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.
+
+ The CLEANUP_WAIT state (S8) implies that there are possible iSCSI
+ tasks that have not reached conclusion and are still considered busy.
+
+7.1.3. Standard Connection State Diagram for an Initiator
+
+ Symbolic names for States:
+
+ S1: FREE
+ S2: XPT_WAIT
+ S4: IN_LOGIN
+ S5: LOGGED_IN
+ S6: IN_LOGOUT
+ S7: LOGOUT_REQUESTED
+ S8: CLEANUP_WAIT
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 88]
+
+RFC 3720 iSCSI April 2004
+
+
+ States S5, S6, and S7 constitute the Full Feature Phase operation of
+ the connection.
+
+ 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
+ +---------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 89]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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 |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| - |- |- | - | - | - | - |
+ ---+----+---+---+---+---+----+---+
+
+7.1.4. Standard Connection State Diagram for a Target
+
+ Symbolic names for States:
+
+ S1: FREE
+ S3: XPT_UP
+ S4: IN_LOGIN
+ S5: LOGGED_IN
+ S6: IN_LOGOUT
+ S7: LOGOUT_REQUESTED
+ S8: CLEANUP_WAIT
+
+ States S5, S6, and S7 constitute the Full Feature Phase operation of
+ the connection.
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 90]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+ +---------------------------+
+
+ The following state transition table represents the above diagram,
+ and follows the conventions described for the initiator diagram.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 91]
+
+RFC 3720 iSCSI April 2004
+
+
+ +----+---+---+---+---+----+---+
+ |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| - |- |- | - | - | - | - |
+ ---+----+---+---+---+---+----+---+
+
+7.2. Connection Cleanup State Diagram for Initiators and Targets
+
+ Symbolic names for states:
+
+ R1: CLEANUP_WAIT (same as S8)
+ R2: IN_CLEANUP
+ R3: FREE (same as 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 92]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ The following state diagram applies to both initiators and targets.
+
+ -------
+ / 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 | - | - | - |
+ -----+----+----+----+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 93]
+
+RFC 3720 iSCSI April 2004
+
+
+7.2.1. State Descriptions for Initiators and Targets
+
+ -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.
+
+7.2.2. State Transition Descriptions for Initiators and Targets
+
+ -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.
+
+ -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.
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 94]
+
+RFC 3720 iSCSI April 2004
+
+
+ -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.
+
+ -M4: Successful implicit/explicit logout was performed.
+
+ - 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.
+
+7.3. Session State Diagrams
+
+7.3.1. Session State Diagram for an Initiator
+
+ Symbolic Names for States:
+
+ Q1: FREE
+ Q3: LOGGED_IN
+ Q4: FAILED
+
+ State Q3 represents the Full Feature Phase operation of the session.
+
+
+
+Satran, et al. Standards Track [Page 95]
+
+RFC 3720 iSCSI April 2004
+
+
+ The state diagram is as follows:
+
+ -------
+ / 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 | - |
+ -----+----+----+----+
+
+7.3.2. Session State Diagram for a Target
+
+ Symbolic Names for States:
+
+ Q1: FREE
+ Q2: ACTIVE
+ Q3: LOGGED_IN
+ Q4: FAILED
+ Q5: IN_CONTINUE
+
+ State Q3 represents the Full Feature Phase operation of the session.
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 96]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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 \
+ \ /<-------------\ /
+ ------- -------
+
+ 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 | - |
+ -----+----+----+----+----+----+
+
+7.3.3. State Descriptions for Initiators and Targets
+
+ -Q1: FREE
+ -initiator: State on instantiation or after cleanup.
+ -target: State on instantiation or after cleanup.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 97]
+
+RFC 3720 iSCSI April 2004
+
+
+ -Q2: ACTIVE
+ -initiator: Illegal.
+ -target: The first iSCSI connection in the session transitioned
+ to IN_LOGIN, waiting for it to complete the login process.
+
+ -Q3: LOGGED_IN
+ -initiator: Waiting for all session events.
+ -target: Waiting for all session events.
+
+ -Q4: FAILED
+ -initiator: Waiting for session recovery or session
+ continuation.
+ -target: Waiting for session recovery or session continuation.
+
+ -Q5: IN_CONTINUE
+ -initiator: Illegal.
+ -target: Waiting for session continuation attempt to reach a
+ conclusion.
+
+7.3.4. State Transition Descriptions for Initiators and Targets
+
+ -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.
+
+ -N2:
+ -initiator: Illegal.
+ -target: At least one iSCSI connection reached the LOGGED_IN
+ state.
+
+ -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.
+
+ -N4:
+ -initiator: A session continuation attempt succeeded.
+ -target: Illegal.
+
+ -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.
+
+
+
+Satran, et al. Standards Track [Page 98]
+
+RFC 3720 iSCSI April 2004
+
+
+ -N6:
+ -initiator: Session state timeout occurred, or a session
+ reinstatement cleared this session instance. This results
+ in the freeing of all associated resources and the session
+ state is discarded.
+ -target: Session state timeout occurred, or a session
+ reinstatement cleared this session instance. This results
+ in the freeing of all associated resources and the session
+ state is discarded.
+
+ -N7:
+ -initiator: Illegal.
+ -target: A session continuation attempt is initiated.
+
+ -N8:
+ -initiator: Illegal.
+ -target: The last session continuation attempt failed.
+
+ -N9:
+ -initiator: Illegal.
+ -target: Login attempt on the leading connection failed.
+
+ -N10:
+ -initiator: Illegal.
+ -target: A session continuation attempt succeeded.
+
+ -N11:
+ -initiator: Illegal.
+ -target: A successful session reinstatement cleanly closed the
+ session.
+
+8. Security Considerations
+
+ 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).
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 99]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ The following section describes the security mechanisms provided by
+ an iSCSI implementation.
+
+8.1. iSCSI Security Mechanisms
+
+ 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.
+
+ Further details on typical iSCSI scenarios and the relation between
+ the initiators, targets, and the communication end points can be
+ found in [RFC3723].
+
+8.2. In-band Initiator-Target Authentication
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+
+
+Satran, et al. Standards Track [Page 100]
+
+RFC 3720 iSCSI April 2004
+
+
+ mechanism alone (without underlying IPsec) should only be used when
+ there is no risk of eavesdropping, message insertion, deletion,
+ modification, and replaying.
+
+ 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.
+
+ 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)).
+
+8.2.1. CHAP Considerations
+
+ 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).
+
+ 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.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 101]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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:
+
+ Rogue wants to impersonate Storage to Alice, and knows that a
+ single secret is used for both directions of Storage-Alice
+ authentication.
+
+ Rogue convinces Alice to open two connections to Rogue, and Rogue
+ identifies itself as Storage on both connections.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 102]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+8.2.2. SRP Considerations
+
+ 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.
+
+ The list of allowed SRP groups is provided in [RFC3723].
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 103]
+
+RFC 3720 iSCSI April 2004
+
+
+8.3. IPsec
+
+ 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.
+
+ 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.
+
+ Detailed considerations and recommendations for using IPsec for iSCSI
+ are provided in [RFC3723].
+
+8.3.1. Data Integrity and Authentication
+
+ 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:
+
+ - HMAC-SHA1 MUST be implemented [RFC2404].
+ - AES CBC MAC with XCBC extensions SHOULD be implemented
+ [RFC3566].
+
+ The ESP anti-replay service MUST also be implemented.
+
+ 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].
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 104]
+
+RFC 3720 iSCSI April 2004
+
+
+8.3.2. Confidentiality
+
+ 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:
+
+ - 3DES in CBC mode MUST be implemented [RFC2451].
+ - AES in Counter mode SHOULD be implemented [RFC3686].
+
+ DES in CBC mode SHOULD NOT be used due to its inherent weakness. The
+ NULL encryption algorithm MUST also be implemented.
+
+8.3.3. Policy, Security Associations, and Cryptographic Key Management
+
+ 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:
+
+ - 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.
+
+ - 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.
+
+ - 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.
+
+
+
+
+Satran, et al. Standards Track [Page 105]
+
+RFC 3720 iSCSI April 2004
+
+
+ - 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+9. Notes to Implementers
+
+ 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.
+
+ 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.
+
+9.1. Multiple Network Adapters
+
+ 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
+
+
+
+
+Satran, et al. Standards Track [Page 106]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ However, some task management commands may require some loose form of
+ cooperation or replication at least on the target.
+
+9.1.1. Conservative Reuse of ISIDs
+
+ 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.
+
+ 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.
+
+9.1.2. iSCSI Name, ISID, and TPGT Use
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 107]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 108]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+9.2. Autosense and Auto Contingent Allegiance (ACA)
+
+ 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.
+
+ 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.
+
+9.3. iSCSI Timeouts
+
+ 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.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 109]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+9.4. Command Retry and Cleaning Old Command Instances
+
+ 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.
+
+ 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.
+
+9.5. Synch and Steering Layer and Performance
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 110]
+
+RFC 3720 iSCSI April 2004
+
+
+9.6. Considerations for State-dependent Devices and Long-lasting SCSI
+ Operations
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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).
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 111]
+
+RFC 3720 iSCSI April 2004
+
+
+9.6.1. Determining the Proper ErrorRecoveryLevel
+
+ The implementation and use of a specific ErrorRecoveryLevel should be
+ determined based on the deployment scenarios of a given iSCSI
+ implementation. Generally, the following factors must be considered
+ before deciding on the proper level of recovery:
+
+ 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 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.
+
+ For extended copy operations, implementations SHOULD use
+ ErrorRecoveryLevel=2 whenever there is a relatively high likelihood
+ of connection failure.
+
+10. iSCSI PDU Formats
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 112]
+
+RFC 3720 iSCSI April 2004
+
+
+10.1. iSCSI PDU Length and Padding
+
+ iSCSI PDUs are padded to the closest integer number of four byte
+ words. The padding bytes SHOULD be sent as 0.
+
+10.2. PDU Template, Header, and Opcodes
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 113]
+
+RFC 3720 iSCSI April 2004
+
+
+ The overall structure of an iSCSI PDU is as follows:
+
+ 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.
+
+ iSCSI response PDUs do not have AH Segments.
+
+10.2.1. Basic Header Segment (BHS)
+
+ The BHS is 48 bytes long. The Opcode and DataSegmentLength fields
+ appear in all iSCSI PDUs. In addition, when used, the Initiator Task
+ Tag and Logical Unit Number always appear in the same location in the
+ header.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 114]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+10.2.1.1 I
+
+ For request PDUs, the I bit set to 1 is an immediate delivery marker.
+
+10.2.1.2. Opcode
+
+ The Opcode indicates the type of iSCSI PDU the header encapsulates.
+
+ 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).
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 115]
+
+RFC 3720 iSCSI April 2004
+
+
+
+ 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
+
+ All other opcodes are reserved.
+
+10.2.1.3. Final (F) bit
+
+ When set to 1 it indicates the final (or only) PDU of a sequence.
+
+10.2.1.4. Opcode-specific Fields
+
+ These fields have different meanings for different opcode types.
+
+10.2.1.5. TotalAHSLength
+
+ Total length of all AHS header segments in units of four byte words
+ including padding, if any.
+
+ The TotalAHSLength is only used in PDUs that have an AHS and MUST be
+ 0 in all other PDUs.
+
+10.2.1.6. DataSegmentLength
+
+ This is the data segment payload length in bytes (excluding padding).
+ The DataSegmentLength MUST be 0 whenever the PDU has no data segment.
+
+10.2.1.7. LUN
+
+ 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
+
+
+
+
+Satran, et al. Standards Track [Page 116]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+10.2.1.8. Initiator Task Tag
+
+ 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.
+
+10.2.2. Additional Header Segment (AHS)
+
+ The general format of an AHS 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| AHSLength | AHSType | AHS-Specific |
+ +---------------+---------------+---------------+---------------+
+ 4/ AHS-Specific /
+ +/ /
+ +---------------+---------------+---------------+---------------+
+ x
+
+10.2.2.1. AHSType
+
+ The AHSType field is coded as follows:
+
+ bit 0-1 - Reserved
+
+ bit 2-7 - AHS code
+
+ 0 - Reserved
+ 1 - Extended CDB
+ 2 - Expected Bidirectional Read Data Length
+ 3 - 63 Reserved
+
+10.2.2.2. AHSLength
+
+ This field contains the effective length in bytes of the AHS
+ excluding AHSType and AHSLength and padding, if any. The AHS is
+ padded to the smallest integer number of 4 byte words (i.e., from 0
+ up to 3 padding bytes).
+
+
+
+Satran, et al. Standards Track [Page 117]
+
+RFC 3720 iSCSI April 2004
+
+
+10.2.2.3. Extended CDB AHS
+
+ The format of the Extended CDB AHS 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| 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.
+
+10.2.2.4. Bidirectional Expected Read-Data Length AHS
+
+ The format of the Bidirectional Read Expected Data Transfer Length
+ AHS 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| AHSLength (0x0005) | 0x02 | Reserved |
+ +---------------+---------------+---------------+---------------+
+ 4| Expected Read-Data Length |
+ +---------------+---------------+---------------+---------------+
+ 8
+
+10.2.3. Header Digest and Data Digest
+
+ 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.
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 118]
+
+RFC 3720 iSCSI April 2004
+
+
+ Digests are not included in data or header length fields.
+
+ A zero-length Data Segment also implies a zero-length data-digest.
+
+10.2.4. Data Segment
+
+ 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.
+
+10.3. SCSI Command
+
+ The format of the SCSI Command PDU 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| 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) /
+ +---------------+---------------+---------------+---------------+
+
+
+
+
+Satran, et al. Standards Track [Page 119]
+
+RFC 3720 iSCSI April 2004
+
+
+10.3.1. Flags and Task Attributes (byte 1)
+
+ The flags for a SCSI Command are:
+
+ 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.
+
+ bit 1 (R) is set to 1 when the command is expected to input data.
+
+ bit 2 (W) is set to 1 when the command is expected to output data.
+
+ bit 3-4 Reserved.
+
+ bit 5-7 contains Task Attributes.
+
+ Task Attributes (ATTR) have one of the following integer values (see
+ [SAM2] for details):
+
+ 0 - Untagged
+ 1 - Simple
+ 2 - Ordered
+ 3 - Head of Queue
+ 4 - ACA
+ 5-7 - Reserved
+
+ 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).
+
+10.3.2. CmdSN - Command Sequence Number
+
+ Enables ordered delivery across multiple connections in a single
+ session.
+
+10.3.3. ExpStatSN
+
+ Command responses up to ExpStatSN-1 (mod 2**32) have been received
+ (acknowledges status) on the connection.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 120]
+
+RFC 3720 iSCSI April 2004
+
+
+10.3.4. Expected Data Transfer Length
+
+ 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.
+
+ 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
+
+ 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.
+
+ 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.
+
+ 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.
+
+10.3.5. CDB - SCSI Command Descriptor Block
+
+ 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.
+
+10.3.6. Data Segment - Command Data
+
+ 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
+
+
+
+
+
+Satran, et al. Standards Track [Page 121]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+10.4. SCSI Response
+
+ The format of the SCSI Response PDU 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|.|.| 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) |
+ +---------------+---------------+---------------+---------------+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 122]
+
+RFC 3720 iSCSI April 2004
+
+
+10.4.1. Flags (byte 1)
+
+ bit 1-2 Reserved.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ bit 7 - (0) Reserved.
+
+ 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.
+
+10.4.2. Status
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 123]
+
+RFC 3720 iSCSI April 2004
+
+
+ Some of the status codes defined in [SAM2] are:
+
+ 0x00 GOOD
+ 0x02 CHECK CONDITION
+ 0x08 BUSY
+ 0x18 RESERVATION CONFLICT
+ 0x28 TASK SET FULL
+ 0x30 ACA ACTIVE
+ 0x40 TASK ABORTED
+
+ See [SAM2] for the complete list and definitions.
+
+ 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.
+
+10.4.3. Response
+
+ This field contains the iSCSI service response.
+
+ iSCSI service response codes defined in this specification are:
+
+ 0x00 - Command Completed at Target
+ 0x01 - Target Failure
+ 0x80-0xff - Vendor specific
+
+ 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.
+
+ 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.
+
+ A non-zero Response field indicates a failure to execute the command
+ in which case the Status and Flag fields are undefined.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 124]
+
+RFC 3720 iSCSI April 2004
+
+
+10.4.4. SNACK Tag
+
+ 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.
+
+ 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.
+
+ For a detailed discussion on R-Data SNACK see Section 10.16 SNACK
+ Request.
+
+10.4.5. Residual Count
+
+ 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.
+
+10.4.6. Bidirectional Read Residual Count
+
+ 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.
+
+10.4.7. Data Segment - Sense and Response Data Segment
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 125]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+ If the DataSegmentLength is not 0, the format of the Data Segment is
+ as follows:
+
+ 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|
+
+10.4.7.1. SenseLength
+
+ Length of Sense Data.
+
+10.4.7.2. Sense Data
+
+ The Sense Data contains detailed information about a check condition
+ and [SPC3] specifies the format and content of the Sense Data.
+
+ 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 126]
+
+RFC 3720 iSCSI April 2004
+
+
+ +--------------------------+----------+---------------------------+
+ | 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.
+
+10.4.8. ExpDataSN
+
+ The number of R2T and Data-In (read) PDUs the target has sent for the
+ command.
+
+ 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.
+
+10.4.9. StatSN - Status Sequence Number
+
+ 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.
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 127]
+
+RFC 3720 iSCSI April 2004
+
+
+10.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator
+
+ 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.
+
+10.4.11. MaxCmdSN - Maximum CmdSN from this Initiator
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 128]
+
+RFC 3720 iSCSI April 2004
+
+
+10.5. Task Management Function Request
+
+ 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) |
+ +---------------+---------------+---------------+---------------+
+
+10.5.1. Function
+
+ 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].
+
+ 1 - ABORT TASK - aborts the task identified by the Referenced Task
+ Tag field.
+
+ 2 - ABORT TASK SET - aborts all Tasks issued via this session on the
+ logical unit.
+
+ 3 - CLEAR ACA - clears the Auto Contingent Allegiance condition.
+
+
+
+
+
+Satran, et al. Standards Track [Page 129]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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]).
+
+ 5 - LOGICAL UNIT RESET
+
+ 6 - TARGET WARM RESET
+
+ 7 - TARGET COLD RESET
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 130]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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).
+
+ 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).
+
+ 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].
+
+ 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.
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 131]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+10.5.2. TotalAHSLength and DataSegmentLength
+
+ For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+
+10.5.3. LUN
+
+ 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.
+
+10.5.4. Referenced Task Tag
+
+ 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.
+
+10.5.5. RefCmdSN
+
+ 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).
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 132]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ Otherwise, this field is reserved.
+
+10.5.6. ExpDataSN
+
+ 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.
+
+ 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.
+
+ For other functions this field is reserved.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 133]
+
+RFC 3720 iSCSI April 2004
+
+
+10.6. Task Management Function Response
+
+ 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.
+
+10.6.1. Response
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 134]
+
+RFC 3720 iSCSI April 2004
+
+
+ f) 5 - Task management function not supported.
+ g) 6 - Function authorization failed.
+ h) 255 - Function rejected.
+
+ All other values are reserved.
+
+ For a discussion on usage of response codes 3 and 4, see Section
+ 6.2.2 Allegiance Reassignment.
+
+ 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).
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 135]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+10.6.2. Task Management Actions on Task Sets
+
+ 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.
+
+ 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.
+
+ e) Sends the task set management response to the issuing
+ initiator.
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 136]
+
+RFC 3720 iSCSI April 2004
+
+
+10.6.3. TotalAHSLength and DataSegmentLength
+
+ For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+
+10.7. SCSI Data-Out & SCSI Data-In
+
+ The SCSI Data-Out PDU for WRITE operations has the following 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|.|.| 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) |
+ +---------------+---------------+---------------+---------------+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 137]
+
+RFC 3720 iSCSI April 2004
+
+
+ The SCSI Data-In PDU for READ operations has the following 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|.|.| 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 138]
+
+RFC 3720 iSCSI April 2004
+
+
+10.7.1. F (Final) Bit
+
+ 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.
+
+ 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.
+
+ 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.
+
+ For Bidirectional operations, the F bit is 1 for both the end of the
+ input sequences and the end of the output sequences.
+
+10.7.2. A (Acknowledge) Bit
+
+ 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.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 139]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+10.7.3. Flags (byte 1)
+
+ 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.
+
+ bit 2-4 - Reserved.
+
+ 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).
+
+ 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.
+
+ 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.
+
+10.7.4. Target Transfer Tag and LUN
+
+ 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.
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 140]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+10.7.5. DataSN
+
+ 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.
+
+ R2T and Data-In PDUs, in the context of bidirectional commands, share
+ the numbering sequence (see Section 3.2.2.3 Data Sequencing).
+
+ 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).
+
+10.7.6. Buffer Offset
+
+ 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.
+
+ 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.
+
+ 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.
+
+10.7.7. DataSegmentLength
+
+ 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.
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 141]
+
+RFC 3720 iSCSI April 2004
+
+
+10.8. Ready To Transfer (R2T)
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 142]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+ 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.
+
+ 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 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:
+
+ - 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.
+
+ 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.
+
+10.8.1. TotalAHSLength and DataSegmentLength
+
+ For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+
+10.8.2. R2TSN
+
+ R2TSN is the R2T PDU input PDU number within the command identified
+ by the Initiator Task Tag.
+
+ For bidirectional commands R2T and Data-In PDUs share the input PDU
+ numbering sequence (see Section 3.2.2.3 Data Sequencing).
+
+
+
+
+Satran, et al. Standards Track [Page 143]
+
+RFC 3720 iSCSI April 2004
+
+
+10.8.3. StatSN
+
+ The StatSN field will contain the next StatSN. The StatSN for this
+ connection is not advanced after this PDU is sent.
+
+10.8.4. Desired Data Transfer Length and Buffer Offset
+
+ 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.
+
+10.8.5. Target Transfer Tag
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 144]
+
+RFC 3720 iSCSI April 2004
+
+
+10.9. Asynchronous Message
+
+ 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) |
+ +---------------+---------------+---------------+---------------+
+
+ Some Asynchronous Messages are strictly related to iSCSI while others
+ are related to SCSI [SAM2].
+
+ StatSN counts this PDU as an acknowledgeable event (StatSN is
+ advanced), which allows for initiator and target state
+ synchronization.
+
+
+
+Satran, et al. Standards Track [Page 145]
+
+RFC 3720 iSCSI April 2004
+
+
+10.9.1. AsyncEvent
+
+ The codes used for iSCSI Asynchronous Messages (events) are:
+
+ 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]).
+
+ 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.
+
+ 2 - target indicates it will drop the connection. The Parameter1
+ field indicates the CID of the connection that is going to be
+ dropped.
+
+ The Parameter2 field (Time2Wait) indicates, in seconds, the
+ minimum time to wait before attempting to reconnect or
+ reassign.
+
+ The Parameter3 field (Time2Retain) indicates the maximum time
+ allowed to reassign commands after the initial wait (in
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 146]
+
+RFC 3720 iSCSI April 2004
+
+
+ A value of 0 for Parameter2 indicates that reconnect can be
+ attempted immediately.
+
+ 3 - target indicates it will drop all the connections of this
+ session.
+
+ Parameter1 field is reserved.
+
+ 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).
+
+ If the initiator does not attempt to reconnect and/or reassign
+ the outstanding commands within the time specified by
+ Parameter3, or if Parameter3 is 0, the session is terminated.
+
+ In this case, the target will terminate all outstanding
+ commands in this session; no other responses should be
+ expected from the target for the outstanding commands in this
+ session. A value of 0 for Parameter2 indicates that reconnect
+ can be attempted immediately.
+
+ 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.
+
+ 255 - vendor specific iSCSI Event. The AsyncVCode details the
+ vendor code, and data MAY accompany the report.
+
+ All other event codes are reserved.
+
+10.9.2. AsyncVCode
+
+ AsyncVCode is a vendor specific detail code that is only valid if the
+ AsyncEvent field indicates a vendor specific event. Otherwise, it is
+ reserved.
+
+10.9.3. LUN
+
+ The LUN field MUST be valid if AsyncEvent is 0. Otherwise, this
+ field is reserved.
+
+
+
+Satran, et al. Standards Track [Page 147]
+
+RFC 3720 iSCSI April 2004
+
+
+10.9.4. Sense Data and iSCSI Event Data
+
+ For a SCSI event, this data accompanies the report in the data
+ segment and identifies the condition.
+
+ 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.
+
+ If the DataSegmentLength is not 0, the format of the DataSegment is
+ as follows:
+
+ 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|
+
+10.9.4.1. SenseLength
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 148]
+
+RFC 3720 iSCSI April 2004
+
+
+10.10. Text Request
+
+ 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) |
+ +---------------+---------------+---------------+---------------+
+
+ 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.
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 149]
+
+RFC 3720 iSCSI April 2004
+
+
+10.10.1. F (Final) Bit
+
+ 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.
+
+10.10.2. C (Continue) Bit
+
+ 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.
+
+10.10.3. Initiator Task Tag
+
+ 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.
+
+10.10.4. Target Transfer Tag
+
+ 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).
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 150]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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)
+
+10.10.5. Text
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 151]
+
+RFC 3720 iSCSI April 2004
+
+
+10.11. Text Response
+
+ 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.
+
+ 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) |
+ +---------------+---------------+---------------+---------------+
+
+10.11.1. F (Final) Bit
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 152]
+
+RFC 3720 iSCSI April 2004
+
+
+ A Text Response with the F bit set to 1 MUST NOT contain key=value
+ pairs that may require additional answers from the initiator.
+
+ A Text Response with the F bit set to 1 MUST have a Target Transfer
+ Tag field set to the reserved value of 0xffffffff.
+
+ 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.
+
+10.11.2. C (Continue) Bit
+
+ 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.
+
+10.11.3. Initiator Task Tag
+
+ The Initiator Task Tag matches the tag used in the initial Text
+ Request.
+
+10.11.4. Target Transfer Tag
+
+ 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.
+
+ When the Target Transfer Tag is not 0xffffffff, the LUN field may be
+ significant.
+
+ The initiator MUST copy the Target Transfer Tag and LUN in its next
+ request to indicate that it wants the rest of the data.
+
+ 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).
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 153]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+10.11.5. StatSN
+
+ The target StatSN variable is advanced by each Text Response sent.
+
+10.11.6. Text Response Data
+
+ The data lengths of a text response MUST NOT exceed the iSCSI
+ initiator MaxRecvDataSegmentLength (a per connection and per
+ direction negotiated parameter).
+
+ 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).
+
+ 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.
+
+10.12. Login Request
+
+ 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.
+
+ The Login Phase (see Chapter 5) consists of a sequence of Login
+ Requests and Responses that carry the same Initiator Task Tag.
+
+ Login Requests are always considered as immediate.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 154]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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 /
+ +/ /
+ +---------------+---------------+---------------+---------------+
+
+10.12.1. T (Transit) Bit
+
+ If set to 1, indicates that the initiator is ready to transit to the
+ next stage.
+
+ 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).
+
+10.12.2. C (Continue) Bit
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 155]
+
+RFC 3720 iSCSI April 2004
+
+
+10.12.3. CSG and NSG
+
+ 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.
+
+ The stage codes are:
+
+ - 0 - SecurityNegotiation
+ - 1 - LoginOperationalNegotiation
+ - 3 - FullFeaturePhase
+
+ All other codes are reserved.
+
+10.12.4. Version
+
+ The version number of the current draft is 0x00. As such, all
+ devices MUST carry version 0x00 for both Version-min and Version-max.
+
+10.12.4.1. Version-max
+
+ Maximum Version number supported.
+
+ All Login Requests within the Login Phase MUST carry the same
+ Version-max.
+
+ The target MUST use the value presented with the first Login Request.
+
+10.12.4.2. Version-min
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 156]
+
+RFC 3720 iSCSI April 2004
+
+
+10.12.5. ISID
+
+ 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):
+
+ 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
+
+ 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
+
+ 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).
+
+ 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".
+
+
+
+
+
+Satran, et al. Standards Track [Page 157]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+ The T field value of 11b is reserved.
+
+ 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.
+
+10.12.6. TSIH
+
+ 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.
+
+ All Login Requests within a Login Phase MUST carry the same 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.
+
+10.12.7. Connection ID - CID
+
+ A unique ID for this connection within the session.
+
+ All Login Requests within the Login Phase MUST carry the same 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.
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 158]
+
+RFC 3720 iSCSI April 2004
+
+
+10.12.8. CmdSN
+
+ 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.
+
+ 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.
+
+ - 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.
+
+ If the Login Request is a leading Login Request, the target MUST use
+ the value presented in CmdSN as the target value for ExpCmdSN.
+
+10.12.9. ExpStatSN
+
+ 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).
+
+ For subsequent Login Requests it is used to acknowledge the Login
+ Responses with their increasing StatSN values.
+
+10.12.10. Login Parameters
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 159]
+
+RFC 3720 iSCSI April 2004
+
+
+10.13. Login Response
+
+ 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 /
+ +/ /
+ +---------------+---------------+---------------+---------------+
+
+10.13.1. Version-max
+
+ This is the highest version number supported by the target.
+
+ All Login Responses within the Login Phase MUST carry the same
+ Version-max.
+
+ The initiator MUST use the value presented as a response to the first
+ Login Request.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 160]
+
+RFC 3720 iSCSI April 2004
+
+
+10.13.2. Version-active
+
+ Indicates the highest version supported by the target and initiator.
+ If the target does not support a version within the range specified
+ by the initiator, the target rejects the login and this field
+ indicates the lowest version supported by the target.
+
+ 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.
+
+10.13.3. TSIH
+
+ 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).
+
+10.13.4. StatSN
+
+ 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.
+
+10.13.5. Status-Class and Status-Detail
+
+ 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.
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 161]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+ -----------------------------------------------------------------
+
+
+
+Satran, et al. Standards Track [Page 162]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+ -----------------------------------------------------------------
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 163]
+
+RFC 3720 iSCSI April 2004
+
+
+ (*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.
+
+ If the Status Class is not 0, the initiator and target MUST close the
+ TCP connection.
+
+ If the target wishes to reject the Login Request for more than one
+ reason, it should return the primary reason for the rejection.
+
+10.13.6. T (Transit) bit
+
+ 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".
+
+ 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.
+
+ 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.
+
+10.13.7. C (Continue) Bit
+
+ 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.
+
+10.13.8. Login Parameters
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 164]
+
+RFC 3720 iSCSI April 2004
+
+
+10.14. Logout Request
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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).
+
+
+
+Satran, et al. Standards Track [Page 165]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 166]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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) |
+ +---------------+---------------+---------------+---------------+
+
+10.14.1. Reason Code
+
+ Reason Code indicates the reason for Logout as follows:
+
+ 0 - close the session. All commands associated with the session
+ (if any) are terminated.
+
+ 1 - close the connection. All commands associated with connection
+ (if any) are terminated.
+
+ 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.
+
+ All other values are reserved.
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 167]
+
+RFC 3720 iSCSI April 2004
+
+
+10.14.2. TotalAHSLength and DataSegmentLength
+
+ For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+
+10.14.3. CID
+
+ 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".
+
+10.14.4. ExpStatSN
+
+ This is the last ExpStatSN value for the connection to be closed.
+
+10.14.5. Implicit termination of tasks
+
+ A target implicitly terminates the active tasks due to the iSCSI
+ protocol in the following cases:
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 168]
+
+RFC 3720 iSCSI April 2004
+
+
+ the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI
+ PROTOCOL EVENT" - etc. - see [SAM2] and [SPC3]).
+
+10.15. Logout Response
+
+ 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).
+
+ 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) |
+ +---------------+---------------+---------------+---------------+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 169]
+
+RFC 3720 iSCSI April 2004
+
+
+10.15.1. Response
+
+ Logout Response:
+
+ 0 - connection or session closed successfully.
+
+ 1 - CID not found.
+
+ 2 - connection recovery is not supported. If Logout reason code
+ was recovery and target does not support it as indicated by the
+ ErrorRecoveryLevel.
+
+ 3 - cleanup failed for various reasons.
+
+10.15.2. TotalAHSLength and DataSegmentLength
+
+ For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+
+10.15.3. Time2Wait
+
+ 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.
+
+ This field is invalid if the Logout Response code is 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.
+
+ If Time2Wait is 0, the reassignment or a new Logout may be attempted
+ immediately.
+
+10.15.4. Time2Retain
+
+ 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.
+
+ This field is invalid if the Logout response code is 1.
+
+
+
+
+
+Satran, et al. Standards Track [Page 170]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ If it is the last connection of a session, the whole session state is
+ discarded after 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.
+
+10.16. SNACK Request
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 171]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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:
+
+ - When used in RunLength, it means all PDUs starting with the
+ initial.
+ - When used in both BegRun and RunLength, it means all
+ unacknowledged PDUs.
+
+ 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.
+
+ 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).
+
+ 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".
+
+10.16.1. Type
+
+ This field encodes the SNACK function as follows:
+
+ 0-Data/R2T SNACK - requesting retransmission of one or more Data-
+ In or R2T PDUs.
+
+ 1-Status SNACK - requesting retransmission of one or more numbered
+ responses.
+
+ 2-DataACK - positively acknowledges Data-In PDUs.
+
+ 3-R-Data SNACK - requesting retransmission of Data-In PDUs with
+ possible resegmentation and status tagging.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 172]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+10.16.2. Data Acknowledgement
+
+ 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).
+
+ The DataACK is used to free resources at the target and not to
+ request or imply data retransmission.
+
+ An initiator MUST NOT request retransmission for any data it had
+ already acknowledged.
+
+10.16.3. Resegmentation
+
+ 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.
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 173]
+
+RFC 3720 iSCSI April 2004
+
+
+ For considerations in allegiance reassignment of a task to a
+ connection with a different MaxRecvDataSegmentLength, refer to
+ Section 6.2.2 Allegiance Reassignment.
+
+10.16.4. Initiator Task Tag
+
+ 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.
+
+10.16.5. Target Transfer Tag or SNACK Tag
+
+ 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.
+
+ 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.
+
+ In all other cases, the Target Transfer Tag field MUST be set to the
+ reserved value of 0xffffffff.
+
+10.16.6. BegRun
+
+ 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).
+
+ BegRun 0 when used in conjunction with RunLength 0 means resend all
+ unacknowledged Data-In, R2T or Response PDUs.
+
+ BegRun MUST be 0 for a R-Data SNACK.
+
+10.16.7. RunLength
+
+ The number of PDUs whose retransmission is requested.
+
+ RunLength 0 signals that all Data-In, R2T, or Response PDUs carrying
+ the numbers equal to or greater than BegRun have to be resent.
+
+ The RunLength MUST also be 0 for a DataACK SNACK in addition to
+ R-Data SNACK.
+
+
+
+
+
+Satran, et al. Standards Track [Page 174]
+
+RFC 3720 iSCSI April 2004
+
+
+10.17. Reject
+
+ 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.).
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 175]
+
+RFC 3720 iSCSI April 2004
+
+
+10.17.1. Reason
+
+ 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 |
+ +------+----------------------------------------+------------------+
+
+ 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.
+
+ 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.
+
+ All other values for Reason are reserved.
+
+
+
+
+Satran, et al. Standards Track [Page 176]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ For additional usage semantics of Reject PDU, see Section 6.3 Usage
+ Of Reject PDU in Recovery.
+
+10.17.2. DataSN/R2TSN
+
+ 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.
+
+10.17.3. StatSN, ExpCmdSN and MaxCmdSN
+
+ These fields carry their usual values and are not related to the
+ rejected command. StatSN is advanced after a Reject.
+
+10.17.4. Complete Header of Bad PDU
+
+ The target returns the header (not including digest) of the PDU in
+ error as the data of the response.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 177]
+
+RFC 3720 iSCSI April 2004
+
+
+10.18. NOP-Out
+
+ 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".
+
+ A NOP-Out is also sent by an initiator in response to a 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.
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 178]
+
+RFC 3720 iSCSI April 2004
+
+
+10.18.1. Initiator Task Tag
+
+ 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.
+
+ 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).
+
+ 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.
+
+10.18.2. Target Transfer Tag
+
+ 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.
+
+ When the Target Transfer Tag is set to a value other than 0xffffffff,
+ the LUN field MUST also be copied from the NOP-In.
+
+10.18.3. Ping Data
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 179]
+
+RFC 3720 iSCSI April 2004
+
+
+10.19. NOP-In
+
+ 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).
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 180]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+10.19.1. Target Transfer Tag
+
+ If the target is responding to a NOP-Out, this is set to the reserved
+ value 0xffffffff.
+
+ 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).
+
+ 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.
+
+10.19.2. StatSN
+
+ 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.
+
+10.19.3. LUN
+
+ A LUN MUST be set to a correct value when the Target Transfer Tag is
+ valid (not the reserved value 0xffffffff).
+
+11. iSCSI Security Text Keys and Authentication Methods
+
+ Only the following keys are used during the SecurityNegotiation stage
+ of the Login Phase:
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 181]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ All security keys have connection-wide applicability.
+
+11.1. AuthMethod
+
+ Use: During Login - Security Negotiation Senders: Initiator and
+ Target Scope: connection
+
+ AuthMethod = <list-of-values>
+
+ The main item of security negotiation is the authentication method
+ (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 |
+ +------------------------------------------------------------+
+
+ The AuthMethod selection is followed by an "authentication exchange"
+ specific to the authentication method selected.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 182]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ 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.
+
+ 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>=
+
+ 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.
+
+ 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.
+
+ 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.
+
+ The part of digest-name following Z- and Z# MUST conform to the
+ format for standard-label specified in Section 5.1 Text Format.
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 183]
+
+RFC 3720 iSCSI April 2004
+
+
+11.1.1. Kerberos
+
+ For KRB5 (Kerberos V5) [RFC1510] and [RFC1964], the initiator MUST
+ use:
+
+ KRB_AP_REQ=<KRB_AP_REQ>
+
+ where KRB_AP_REQ is the client message as defined in [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/".
+
+ 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_REP=<KRB_AP_REP>
+
+ where KRB_AP_REP is the server's response message as defined in
+ [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.
+
+11.1.2. Simple Public-Key Mechanism (SPKM)
+
+ For SPKM1 and SPKM2 [RFC2025], the initiator MUST use:
+
+ SPKM_REQ=<SPKM-REQ>
+
+ where SPKM-REQ is the first initiator token as defined in [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:
+
+ SPKM_ERROR=<SPKM-ERROR>
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 184]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ In the following sections, we assume that no SPKM-ERROR tokens are
+ required.
+
+ 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:
+
+ SPKM_REP_TI=<SPKM-REP-TI>
+
+ where SPKM-REP-TI is the target token as defined in [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:
+
+ 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 requires support for very long authentication items.
+
+ 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.
+
+11.1.3. Secure Remote Password (SRP)
+
+ For SRP [RFC2945], the initiator MUST use:
+
+ 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>
+
+ Where G1,G2... are proposed groups, in order of preference.
+
+
+
+Satran, et al. Standards Track [Page 185]
+
+RFC 3720 iSCSI April 2004
+
+
+ The initiator MUST either close the connection or continue with:
+
+ SRP_A=<A> SRP_GROUP=<G>
+
+ Where G is one of G1,G2... that were proposed by the target.
+
+ The target MUST answer with a Login reject with the "Authentication
+ Failure" status or reply with:
+
+ SRP_B=<B>
+
+ The initiator MUST close the connection or continue with:
+
+ 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:
+
+ 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.
+
+ 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.
+
+11.1.4. Challenge Handshake Authentication Protocol (CHAP)
+
+ For CHAP [RFC1994], in the first step, the initiator MUST send:
+
+ CHAP_A=<A1,A2...>
+
+ Where A1,A2... are proposed algorithms, in order of preference.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 186]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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>
+
+ Where A is one of A1,A2... that were proposed by the initiator.
+
+ In the third step, the initiator MUST continue with:
+
+ 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>
+
+ 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>
+
+ 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.
+
+ For the Algorithm, as stated in [RFC1994], one value is required to
+ be implemented:
+
+ 5 (CHAP with MD5)
+
+ To guarantee interoperability, initiators MUST always offer it as one
+ of the proposed algorithms.
+
+12. Login/Text Operational Text Keys
+
+ 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
+
+
+
+
+
+Satran, et al. Standards Track [Page 187]
+
+RFC 3720 iSCSI April 2004
+
+
+ holds for a single connection session with regard to connection
+ restart. The keys that fall into this category have the use: LO
+ (Leading Only).
+
+ 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.
+
+ Keys that can only be used during Full Feature Phase use FFPO (Full
+ Feature Phase only).
+
+ Keys marked as Any-Stage may also appear in the SecurityNegotiation
+ stage while all other keys described in this chapter are operational
+ keys.
+
+ Keys that do not require an answer are marked as Declarative.
+
+ Key scope is indicated as session-wide (SW) or connection-only (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).
+
+12.1. HeaderDigest and DataDigest
+
+ Use: IO
+ Senders: Initiator and Target
+ Scope: CO
+
+ HeaderDigest = <list-of-values>
+ DataDigest = <list-of-values>
+
+ Default is None for both HeaderDigest and 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 188]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ +---------------------------------------------+
+ | 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).
+
+ When the Initiator and Target agree on a digest, this digest MUST be
+ used for every PDU in Full Feature Phase.
+
+ Padding bytes, when present in a segment covered by a CRC, SHOULD be
+ set to 0 and are included in the CRC.
+
+ The CRC MUST be calculated by a method that produces the same
+ results as the following process:
+
+ - 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).
+
+ - The most significant 32 bits are complemented.
+
+ - The polynomial is multiplied by x^32 then divided by G(x). The
+ generator polynomial produces a remainder R(x) of degree <= 31.
+
+ - The coefficients of R(x) are considered a 32 bit sequence.
+
+ - The bit sequence is complemented and the result is the 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.
+
+
+
+
+Satran, et al. Standards Track [Page 189]
+
+RFC 3720 iSCSI April 2004
+
+
+ - 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).
+
+ For a discussion about selection criteria for the CRC, see
+ [RFC3385]. For a detailed analysis of the iSCSI polynomial, see
+ [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.
+
+ 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>=
+
+ 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.
+
+ For private extension digests, to identify the vendor, we suggest
+ you use the reversed DNS-name as a prefix to the proper digest
+ names.
+
+ The part of digest-name following Y- and Y# MUST conform to the
+ format for standard-label specified in Section 5.1 Text Format.
+
+ Support for public or private extension digests is OPTIONAL.
+
+12.2. MaxConnections
+
+ Use: LO
+ Senders: Initiator and Target
+ Scope: SW
+ Irrelevant when: SessionType=Discovery
+
+ MaxConnections=<numerical-value-from-1-to-65535>
+
+ Default is 1.
+ Result function is Minimum.
+
+
+
+Satran, et al. Standards Track [Page 190]
+
+RFC 3720 iSCSI April 2004
+
+
+
+ Initiator and target negotiate the maximum number of connections
+ requested/acceptable.
+
+12.3. SendTargets
+
+ Use: FFPO
+ Senders: Initiator
+ Scope: SW
+
+ For a complete description, see Appendix D. - SendTargets
+ Operation -.
+
+12.4. TargetName
+
+ Use: IO by initiator, FFPO by target - only as response to a
+ SendTargets, Declarative, Any-Stage
+
+ Senders: Initiator and Target
+ Scope: SW
+
+ TargetName=<iSCSI-name-value>
+
+ Examples:
+
+ TargetName=iqn.1993-11.com.disk-vendor: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.
+
+ The TargetName key may also be returned by the "SendTargets" text
+ request (which is its only use when issued by a target).
+
+ TargetName MUST not be redeclared within the login phase.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 191]
+
+RFC 3720 iSCSI April 2004
+
+
+12.5. InitiatorName
+
+ Use: IO, Declarative, Any-Stage
+ Senders: Initiator
+ Scope: SW
+
+ InitiatorName=<iSCSI-name-value>
+
+ Examples:
+
+ 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.
+
+ InitiatorName MUST not be redeclared within the login phase.
+
+12.6. TargetAlias
+
+ Use: ALL, Declarative, Any-Stage
+ Senders: Target
+ Scope: SW
+
+ TargetAlias=<iSCSI-local-name-value>
+
+ Examples:
+
+ TargetAlias=Bob-s Disk
+ TargetAlias=Database Server 1 Log Disk
+ TargetAlias=Web Server 3 Disk 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.
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 192]
+
+RFC 3720 iSCSI April 2004
+
+
+12.7. InitiatorAlias
+
+ Use: ALL, Declarative, Any-Stage
+ Senders: Initiator
+ Scope: SW
+
+ InitiatorAlias=<iSCSI-local-name-value>
+
+ Examples:
+
+ InitiatorAlias=Web Server 4
+ InitiatorAlias=spyalley.nsa.gov
+ InitiatorAlias=Exchange Server
+
+ 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.
+
+12.8. TargetAddress
+
+ Use: ALL, Declarative, Any-Stage
+ Senders: Target
+ Scope: SW
+
+ TargetAddress=domainname[:port][,portal-group-tag]
+
+ 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].
+
+ If the TCP port is not specified, it is assumed to be the
+ IANA-assigned default port for iSCSI (see Section 13 IANA
+ Considerations).
+
+ 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.
+
+ If the TargetAddress is returned within a SendTargets response, the
+ portal group tag MUST be included.
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 193]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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
+
+ 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.
+
+12.9. TargetPortalGroupTag
+
+ Use: IO by target, Declarative, Any-Stage
+ Senders: Target
+ Scope: SW
+
+ TargetPortalGroupTag=<16-bit-binary-value>
+
+ Examples:
+ 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.
+
+ For the complete usage expectations of this key see Section 5.3 Login
+ Phase.
+
+12.10. InitialR2T
+
+ Use: LO
+ Senders: Initiator and Target
+ Scope: SW
+ Irrelevant when: SessionType=Discovery
+
+ InitialR2T=<boolean-value>
+
+ Examples:
+
+ I->InitialR2T=No
+ T->InitialR2T=No
+
+
+
+
+Satran, et al. Standards Track [Page 194]
+
+RFC 3720 iSCSI April 2004
+
+
+ Default is Yes.
+ Result function is 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).
+
+ 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).
+
+12.11. ImmediateData
+
+ Use: LO
+ Senders: Initiator and Target
+ Scope: SW
+ Irrelevant when: SessionType=Discovery
+
+ ImmediateData=<boolean-value>
+
+ Default is Yes.
+ Result function is AND.
+
+ 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.
+
+ If ImmediateData is set to Yes and InitialR2T is set to Yes
+ (default), then only immediate data are accepted in the first burst.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 195]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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 |
+ +----------+-------------+------------------+--------------+
+
+12.12. MaxRecvDataSegmentLength
+
+ Use: ALL, Declarative
+ Senders: Initiator and Target
+ Scope: CO
+
+ MaxRecvDataSegmentLength=<numerical-value-512-to-(2**24-1)>
+
+ Default is 8192 bytes.
+
+ The initiator or target declares the maximum data segment length in
+ bytes it can receive in an iSCSI PDU.
+
+ The transmitter (initiator or target) is required to send PDUs with a
+ data segment that does not exceed MaxRecvDataSegmentLength of the
+ receiver.
+
+ 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).
+
+12.13. MaxBurstLength
+
+ Use: LO
+ Senders: Initiator and Target
+ Scope: SW
+ Irrelevant when: SessionType=Discovery
+
+ MaxBurstLength=<numerical-value-512-to-(2**24-1)>
+
+
+
+
+
+Satran, et al. Standards Track [Page 196]
+
+RFC 3720 iSCSI April 2004
+
+
+ Default is 262144 (256 Kbytes).
+ Result function is Minimum.
+
+ 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.
+
+12.14. FirstBurstLength
+
+ 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)>
+
+ Default is 65536 (64 Kbytes).
+ Result function is Minimum.
+
+ 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.
+
+ FirstBurstLength MUST NOT exceed MaxBurstLength.
+
+12.15. DefaultTime2Wait
+
+ Use: LO
+ Senders: Initiator and Target
+ Scope: SW
+
+ DefaultTime2Wait=<numerical-value-0-to-3600>
+
+ Default is 2.
+ Result function is Maximum.
+
+ 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.
+
+
+
+
+Satran, et al. Standards Track [Page 197]
+
+RFC 3720 iSCSI April 2004
+
+
+12.16. DefaultTime2Retain
+
+ Use: LO Senders: Initiator and Target Scope: SW
+
+ DefaultTime2Retain=<numerical-value-0-to-3600>
+
+ Default is 20. Result function is Minimum.
+
+ 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.
+
+ 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.
+
+12.17. MaxOutstandingR2T
+
+ Use: LO
+ Senders: Initiator and Target
+ Scope: SW
+
+ MaxOutstandingR2T=<numerical-value-from-1-to-65535>
+ Irrelevant when: SessionType=Discovery
+
+ Default is 1.
+ Result function is Minimum.
+
+ 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.
+
+12.18. DataPDUInOrder
+
+ Use: LO
+ Senders: Initiator and Target
+ Scope: SW
+ Irrelevant when: SessionType=Discovery
+
+ DataPDUInOrder=<boolean-value>
+
+
+
+
+
+Satran, et al. Standards Track [Page 198]
+
+RFC 3720 iSCSI April 2004
+
+
+ Default is Yes.
+ Result function is 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.
+
+12.19. DataSequenceInOrder
+
+ Use: LO
+ Senders: Initiator and Target
+ Scope: SW
+ Irrelevant when: SessionType=Discovery
+
+ DataSequenceInOrder=<boolean-value>
+
+ Default is Yes.
+ Result function is 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.
+
+ If DataSequenceInOrder is set to No, Data PDU sequences may be
+ transferred in any order.
+
+ 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).
+
+ 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.
+
+12.20. ErrorRecoveryLevel
+
+ Use: LO
+ Senders: Initiator and Target
+ Scope: SW
+
+ ErrorRecoveryLevel=<numerical-value-0-to-2>
+
+
+
+
+
+Satran, et al. Standards Track [Page 199]
+
+RFC 3720 iSCSI April 2004
+
+
+ Default is 0.
+ Result function is Minimum.
+
+ 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.
+
+12.21. SessionType
+
+ Use: LO, Declarative, Any-Stage
+ Senders: Initiator
+ Scope: SW
+
+ 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".
+
+ The discovery session implies MaxConnections = 1 and overrides both
+ the default and an explicit setting.
+
+12.22. The Private or Public Extension Key Format
+
+ Use: ALL
+ Senders: Initiator and Target
+ Scope: specific key dependent
+
+ X-reversed.vendor.dns_name.do_something=
+
+ or
+
+ X<#><IANA-registered-string>=
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 200]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+ For unregistered keys, to identify the vendor, we suggest you use the
+ reversed DNS-name as a prefix to the key-proper.
+
+ The part of key-name following X- and X# MUST conform to the format
+ for key-name specified in Section 5.1 Text Format.
+
+ 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.
+
+ Vendor specific keys MUST ONLY be used in normal sessions.
+
+ Support for public or private extension keys is OPTIONAL.
+
+13. IANA Considerations
+
+ This section conforms to [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.
+
+ 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.
+
+ The IANA has set up the following three registries:
+
+ a) iSCSI extended key registry
+ b) iSCSI authentication methods registry
+ c) iSCSI digests registry
+
+ [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.
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 201]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+ 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 |
+ +----------------------------------------+--------+
+
+ All other record numbers from 0 to 255 are reserved. IANA will
+ register numbers above 255.
+
+ Authentication methods with numbers above 255 MUST be unique within
+ the registry and MUST be used with the prefix Z#.
+
+
+ The following initial values for the registry for digests are
+ specified by the standards action of this document:
+
+ Digest | Number |
+ +----------------------------------------+--------+
+ | CRC32C | 1 |
+ +----------------------------------------+--------+
+
+ All other record numbers from 0 to 255 are reserved. IANA will
+ register numbers above 255.
+
+ Digests with numbers above 255 MUST be unique within the registry and
+ MUST be used with the prefix 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.
+
+ Extension Keys, Authentication Methods, and digests (iSCSI extension
+ items) must conform to a number of requirements as described below.
+
+
+
+Satran, et al. Standards Track [Page 202]
+
+RFC 3720 iSCSI April 2004
+
+
+13.1. Naming Requirements
+
+ 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.
+
+13.2. Mechanism Specification Requirements
+
+ 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.
+
+13.3. Publication Requirements
+
+ 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.
+
+13.4. Security Requirements
+
+ 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.
+
+ Additional security considerations should be addressed by publishing
+ revised versions of the iSCSI extension item specification.
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 203]
+
+RFC 3720 iSCSI April 2004
+
+
+13.5. Registration Procedure
+
+ Registration of a new iSCSI extension item starts with the
+ construction of an Internet Draft to become an RFC.
+
+13.5.1. Present the iSCSI extension item to the Community
+
+ 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.
+
+13.5.2. iSCSI extension item review and IESG approval
+
+ 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.
+
+ 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.
+
+13.5.3. IANA Registration
+
+ 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.
+
+13.5.4. Standard iSCSI extension item-label format
+
+ The following character symbols are used iSCSI extension item-labels
+ (the hexadecimal values represent Unicode code points):
+
+ (a-z, A-Z) - letters
+ (0-9) - digits
+ "." (0x2e) - dot
+ "-" (0x2d) - minus
+ "+" (0x2b) - plus
+ "@" (0x40) - commercial at
+ "_" (0x5f) - underscore
+
+
+
+
+Satran, et al. Standards Track [Page 204]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+13.6. IANA Procedures for Registering iSCSI extension items
+
+ 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.
+
+References
+
+Normative References
+
+ [CAM] ANSI X3.232-199X, Common Access Method-3.
+
+ [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
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts-
+ Communication Layer", STD 3, RFC 1122, October 1989.
+
+ [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
+ Authentication Service (V5)", RFC 1510, September
+ 1993.
+
+ [RFC1737] Sollins, K. and L. Masinter "Functional Requirements
+ for Uniform Resource Names"RFC 1737, December 1994.
+
+
+
+
+
+Satran, et al. Standards Track [Page 205]
+
+RFC 3720 iSCSI April 2004
+
+
+ [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+ RFC 1964, June 1996.
+
+ [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
+ 1982, August 1996.
+
+ [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
+ Protocol (CHAP)", RFC 1994, August 1996.
+
+ [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
+ (SPKM)", RFC 2025, October 1996.
+
+ [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.
+
+ [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a Transformation Format of ISO
+ 10646", RFC 2279 October 1996.
+
+ [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter "Uniform
+ Resource Identifiers", RFC 2396, August 1998.
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
+ the Internet Protocol", RFC 2401, November 1998.
+
+ [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
+ within ESP and AH", RFC 2404, November 1998.
+
+ [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+ Payload (ESP)", RFC 2406, November 1998.
+
+ [RFC2407] Piper, D., "The Internet IP Security Domain of
+ Interpretation of ISAKMP", RFC 2407, November 1998.
+
+ [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+ (IKE)", RFC2409, November 1998.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs.", BCP 26, RFC
+ 2434, October 1998.
+
+
+
+
+Satran, et al. Standards Track [Page 206]
+
+RFC 3720 iSCSI April 2004
+
+
+ [RFC2451] Pereira, R. and R. Adams " The ESP CBC-Mode Cipher
+ Algorithms", RFC 2451, November 1998.
+
+ [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
+ Literal IPv6 Addresses in URL's", RFC 2451, December
+ 1999.
+
+ [RFC2945] Wu, T., "The SRP Authentication and Key Exchange
+ System", RFC 2945, September 2000.
+
+ [RFC3066] Alvestrand, H., "Tags for the Identification of
+ Languages", STD 47, RFC 3066, January 2001.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+ [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
+ Algorithm and Its Use With IPsec", RFC 3566, September
+ 2003.
+
+ [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
+ Counter Mode with IPsec Encapsulating Security Payload
+ (ESP)", RFC 3686, January 2004.
+
+ [RFC3722] Bakke, M., "String Profile for Internet Small Computer
+ Systems Interface (iSCSI) Names", RFC 3722, March
+ 2004.
+
+ [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F.
+ Travostino, "Securing Block Storage Protocols over
+ IP", RFC 3723, March 2004.
+
+ [SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2).
+
+ [SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC).
+
+ [SPC3] T10/1416-D, SCSI Primary Commands-3.
+
+ [UNICODE] Unicode Standard Annex #15, "Unicode Normalization
+ Forms", http://www.unicode.org/unicode/reports/tr15
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 207]
+
+RFC 3720 iSCSI April 2004
+
+
+Informative References
+
+ [BOOT] P. Sarkar, et al., "Bootstrapping Clients using the
+ iSCSI Protocol", Work in Progress, July 2003.
+
+ [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.
+
+ [CORD] Chadalapaka, M. and R. Elliott, "SCSI Command
+ Ordering Considerations with iSCSI", Work in Progress.
+
+ [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.
+
+ [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.
+
+ [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.
+
+ [SEQ-EXT] Kent, S., "IP Encapsulating Security Payload (ESP)",
+ Work in Progress, July 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 208]
+
+RFC 3720 iSCSI April 2004
+
+
+Appendix A. Sync and Steering with Fixed Interval Markers
+
+ 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.
+
+ 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 |
+ +---------------+---------------+---------------+---------------+
+
+ 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.
+
+ 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.
+
+ 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.1. Markers At Fixed Intervals
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 209]
+
+RFC 3720 iSCSI April 2004
+
+
+ The marker interval and the initial marker-less interval are counted
+ in terms of the bytes placed in the TCP stream data by iSCSI.
+
+ 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.
+
+ Padding iSCSI PDU payloads to 4-byte word boundaries simplifies
+ marker manipulation.
+
+A.2. Initial Marker-less Interval
+
+ 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.
+
+ Thus, all markers appear in the stream at locations conforming to the
+ formula: [(MI + 8) * n - 8] where MI = Marker Interval, n = integer
+ number.
+
+ 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.
+
+A.3. Negotiation
+
+ The following operational key=value pairs are used to negotiate the
+ fixed interval markers. The direction (output or input) is relative
+ to the initiator.
+
+A.3.1. OFMarker, IFMarker
+
+ Use: IO
+ Senders: Initiator and Target
+ Scope: CO
+
+ OFMarker=<boolean-value>
+ IFMarker=<boolean-value>
+
+ Default is No.
+
+ Result function is AND.
+
+
+
+
+
+Satran, et al. Standards Track [Page 210]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+ Examples:
+
+ 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
+
+ Results in Marker being used from the initiator to the target, but
+ not from the target to initiator.
+
+A.3.2. OFMarkInt, IFMarkInt
+
+ 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>
+
+ Responding:
+
+ 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.
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 211]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+ The default is 2048.
+
+Appendix B. Examples
+
+B.1. Read Operation Example
+
+ +------------------+-----------------------+----------------------+
+ |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 | | |
+ +------------------+-----------------------+----------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 212]
+
+RFC 3720 iSCSI April 2004
+
+
+B.2. Write Operation Example
+
+ +------------------+-----------------------+---------------------+
+ |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 | | |
+ +------------------+-----------------------+---------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 213]
+
+RFC 3720 iSCSI April 2004
+
+
+B.3. R2TSN/DataSN Use Examples
+
+ Output (write) data DataSN/R2TSN Example
+
+ +------------------+-----------------------+----------------------+
+ |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 | | |
+ +------------------+-----------------------+----------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 214]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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 | | |
+ +------------------+-----------------------+----------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 215]
+
+RFC 3720 iSCSI April 2004
+
+
+ Bidirectional DataSN Example
+
+ +------------------+-----------------------+----------------------+
+ |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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 216]
+
+RFC 3720 iSCSI April 2004
+
+
+ Unsolicited and immediate output (write) data with DataSN Example
+
+ +------------------+-----------------------+----------------------+
+ |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 | | |
+ +------------------+-----------------------+----------------------+
+
+B.4. CRC Examples
+
+ N.B. all Values are Hexadecimal
+
+ 32 bytes of zeroes:
+
+ Byte: 0 1 2 3
+
+ 0: 00 00 00 00
+ ...
+ 28: 00 00 00 00
+
+ CRC: aa 36 91 8a
+
+ 32 bytes of ones:
+
+ Byte: 0 1 2 3
+
+ 0: ff ff ff ff
+ ...
+ 28: ff ff ff ff
+
+
+
+
+Satran, et al. Standards Track [Page 217]
+
+RFC 3720 iSCSI April 2004
+
+
+ CRC: 43 ab a8 62
+
+ 32 bytes of incrementing 00..1f:
+
+ Byte: 0 1 2 3
+
+ 0: 00 01 02 03
+ ...
+ 28: 1c 1d 1e 1f
+
+ CRC: 4e 79 dd 46
+
+ 32 bytes of decrementing 1f..00:
+
+ Byte: 0 1 2 3
+
+ 0: 1f 1e 1d 1c
+ ...
+ 28: 03 02 01 00
+
+ CRC: 5c db 3f 11
+
+ An iSCSI - SCSI Read (10) Command PDU
+
+ Byte: 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
+
+ CRC: 56 3a 96 d9
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 218]
+
+RFC 3720 iSCSI April 2004
+
+
+Appendix C. Login Phase Examples
+
+ In the first example, the initiator and target authenticate each
+ other via 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
+
+ T-> Login (CSG,NSG=0,0 T=0)
+ AuthMethod=KRB5
+
+ 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)
+
+ If the authentication is successful, the target proceeds with:
+
+ T-> Login (CSG,NSG=0,1 T=1)
+ KRB_AP_REP=<krb_ap_rep>
+
+ (krb_ap_rep is the Kerberos V5 mutual authentication reply)
+
+ 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
+
+ T-> Login (CSG,NSG=1,0 T=0)
+ ... more iSCSI Operational Parameters
+
+ And at the end:
+
+ I-> Login (CSG,NSG=1,3 T=1)
+ optional iSCSI parameters
+
+ T-> Login (CSG,NSG=1,3 T=1) "login accept"
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 219]
+
+RFC 3720 iSCSI April 2004
+
+
+ If the initiator's authentication by the target is not
+ successful, the target responds with:
+
+ T-> Login "login reject"
+
+ instead of the Login KRB_AP_REP message, and terminates the
+ connection.
+
+ 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).
+
+ In the next example only the initiator is authenticated by the
+ target via 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
+
+ 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
+
+ (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req)
+
+ If the authentication is successful, the target proceeds with:
+
+ T-> Login (CSG,NSG=0,1 T=1)
+
+ I-> Login (CSG,NSG=1,0 T=0)
+ ... iSCSI parameters
+
+ T-> Login (CSG,NSG=1,0 T=0)
+ ... iSCSI parameters
+
+ . . .
+
+ T-> Login (CSG,NSG=1,3 T=1)"login accept"
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 220]
+
+RFC 3720 iSCSI April 2004
+
+
+ In the next example, the initiator and target authenticate each
+ other via 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
+
+ T-> Login (CSG,NSG=0,0 T=0)
+ AuthMethod=SPKM1
+
+ 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)
+
+ 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>
+
+ If the authentication is successful, the target proceeds with:
+
+ 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
+
+ And at the end:
+
+ I-> Login (CSG,NSG=1,3 T=1)
+ optional iSCSI parameters
+
+ 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).
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 221]
+
+RFC 3720 iSCSI April 2004
+
+
+ If the initiator's authentication by the target is not
+ successful, the target responds with:
+
+ T-> Login "login reject"
+
+ 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:
+
+ 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
+
+ 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)
+
+ If the authentication is successful, the target proceeds with:
+
+ 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
+
+ And at the end:
+
+ I-> Login (CSG,NSG=1,3 T=1)
+ optional iSCSI parameters
+
+ T-> Login (CSG,NSG=1,3 T=1) "login accept"
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 222]
+
+RFC 3720 iSCSI April 2004
+
+
+ In the next example, the initiator and target authenticate each
+ other via 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
+
+ T-> Login-PR (CSG,NSG=0,0 T=0)
+ AuthMethod=SRP
+
+ 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>
+
+ 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>
+
+ 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)>
+
+ Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945].
+
+ 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
+
+ T-> Login (CSG,NSG=1,0 T=0)
+ ... iSCSI parameters
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 223]
+
+RFC 3720 iSCSI April 2004
+
+
+ And at the end:
+
+ I-> Login (CSG,NSG=1,3 T=1)
+ optional iSCSI parameters
+
+ 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"
+
+ Instead of the T-> Login SRP_HM=<H(A | M | K)> message and
+ terminates the connection.
+
+ In the next example, the initiator and target authenticate each
+ other via 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
+
+ T-> Login-PR (CSG,NSG=0,0 T=0)
+ AuthMethod=SRP
+
+ 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>
+
+ 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>
+
+ 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)
+
+
+
+Satran, et al. Standards Track [Page 224]
+
+RFC 3720 iSCSI April 2004
+
+
+
+ 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
+
+ T-> Login (CSG,NSG=1,3 T=1) "login accept"
+
+ In the next example the initiator and target authenticate each other
+ via 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
+
+ T-> Login-PR (CSG,NSG=0,0 T=0)
+ AuthMethod=CHAP
+
+ 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>
+
+ I-> Login (CSG,NSG=0,1 T=1)
+ CHAP_N=<N>
+ CHAP_R=<R>
+ CHAP_I=<I>
+ CHAP_C=<C>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 225]
+
+RFC 3720 iSCSI April 2004
+
+
+ If the initiator authentication is successful, the target
+ proceeds:
+
+ 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
+
+ And at the end:
+
+ I-> Login (CSG,NSG=1,3 T=1)
+ optional iSCSI parameters
+
+ 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"
+
+ Instead of the Login CHAP_R=<response> "proceed and change
+ stage" message and terminates the connection.
+
+ In the next example, only the initiator is authenticated by the
+ target via 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
+
+ T-> Login-PR (CSG,NSG=0,0 T=0)
+ AuthMethod=CHAP
+
+ I-> Login (CSG,NSG=0,0 T=0)
+ CHAP_A=<A1,A2>
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 226]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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>
+
+ If the initiator authentication is successful, the target
+ proceeds:
+
+ T-> Login (CSG,NSG=0,1 T=1)
+
+ 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
+
+ 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:
+
+ 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
+
+ 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):
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 227]
+
+RFC 3720 iSCSI April 2004
+
+
+
+ T-> Login-PR (CSG,NSG=0,1 T=1)
+ AuthMethod=None
+
+ 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
+
+ T-> Login (CSG,NSG=1,3 T=1) "login accept"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 228]
+
+RFC 3720 iSCSI April 2004
+
+
+Appendix D. SendTargets Operation
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ An initiator MAY make use of the SendTargets as it sees fit.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 229]
+
+RFC 3720 iSCSI April 2004
+
+
+ <iSCSI-target-name>
+
+ 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.
+
+ <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.
+
+ For the format of the TargetName, see Section 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.
+
+ A SendTargets response MUST NOT contain target names if there are no
+ targets for the requesting initiator to access.
+
+ Each target record returned includes zero or more TargetAddress
+ fields.
+
+ Each target record starts with one text key of the form:
+
+ TargetName=<target-name-goes-here>
+
+ Followed by zero or more address keys of the form:
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 230]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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).
+
+ 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.
+
+ Multiple-connection sessions can span iSCSI addresses that belong to
+ the same portal group.
+
+ Multiple-connection sessions cannot span iSCSI addresses that belong
+ to different portal groups.
+
+ 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.
+
+ A SendTargets text response can be longer than a single Text Response
+ PDU, and makes use of the long text responses as specified.
+
+ 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.
+
+ Examples:
+
+ This example is the SendTargets response from a single target that
+ has no other interface ports.
+
+ Initiator sends text request that contains:
+
+ SendTargets=All
+
+ Target sends a text response that contains:
+
+ TargetName=iqn.1993-11.com.example: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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 231]
+
+RFC 3720 iSCSI April 2004
+
+
+ The next example has two internal iSCSI targets, each accessible via
+ two different ports with different IP addresses. The following is
+ the text response:
+
+ 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.
+
+ In the above example, a DNS host name or an IPv6 address could have
+ been returned instead of an IPv4 address.
+
+ 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
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 232]
+
+RFC 3720 iSCSI April 2004
+
+
+Appendix E. Algorithmic Presentation of Error Recovery Classes
+
+ 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.
+
+E.1. General Data Structure and Procedure Description
+
+ This section defines the procedures and data structures that are
+ commonly used by all the error recovery algorithms. The structures
+ may not be the exhaustive representations of what is required for a
+ typical implementation.
+
+ Data structure definitions -
+ struct TransferContext {
+ int TargetTransferTag;
+ int ExpectedDataSN;
+ };
+
+ struct 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;
+
+
+
+Satran, et al. Standards Track [Page 233]
+
+RFC 3720 iSCSI April 2004
+
+
+ struct TransferContext
+ TransferContextList[MaxOutStandingR2T];
+ int InitiatorTaskTag;
+ int CmdSN;
+
+ int SNACK_Tag;
+
+ };
+
+ struct Connection {
+ struct Session SessionReference;
+ Boolean SoFarInOrder;
+ int CID;
+ int State;
+
+ int CurrentTimeout;
+ int ExpectedStatSN;
+ int MissingStatSNList[MaxMissingSPDU];
+ Boolean PerformConnectionCleanup;
+ };
+
+ struct 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);
+
+E.2. Within-command Error Recovery Algorithms
+
+E.2.1. Procedure Descriptions
+
+ 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);
+
+
+
+Satran, et al. Standards Track [Page 234]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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.
+
+E.2.2. Initiator Algorithms
+
+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.
+
+
+
+Satran, et al. Standards Track [Page 235]
+
+RFC 3720 iSCSI April 2004
+
+
+ if ((CurrentPDU.type == Data)
+ or (CurrentPDU.type = R2T)) {
+ if (Data-Digest-Bad for Data) {
+ send-data-SNACK = TRUE;
+ LastRequiredDataSN = CurrentPDU.DataSN;
+ } else {
+ if (TCB.SoFarInOrder = TRUE) {
+ if (current DataSN is expected) {
+ Increment TCB.ExpectedDataSN.
+ } else {
+
+ TCB.SoFarInOrder = FALSE;
+ send-data-SNACK = TRUE;
+ }
+ } else {
+ if (current DataSN was considered missing) {
+ remove current DataSN from missing PDU list.
+ } else if (current DataSN is higher than expected)
+{
+ send-data-SNACK = TRUE;
+ } else {
+ discard, return;
+ }
+ Adjust TCB.ExpectedDataSN if appropriate.
+ }
+ LastRequiredDataSN = CurrentPDU.DataSN - 1;
+ }
+ if (send-data-SNACK is TRUE and
+ task is not already considered failed) {
+ Recover-Data-if-Possible(LastRequiredDataSN, TCB);
+ }
+ if (missing data PDU list is empty) {
+ TCB.SoFarInOrder = TRUE;
+ }
+ if (CurrentPDU.type == R2T) {
+ Increment ActiveR2Ts for this task.
+
+ Create a data-descriptor for the data burst.
+ Build-And-Send-A-Data-Burst(Connection, data-descriptor,
+
+ TCB);
+ }
+ } else if (CurrentPDU.type == Response) {
+ if (Data-Digest-Bad) {
+ send-status-SNACK = TRUE;
+ } else {
+ TCB.StatusXferd = TRUE;
+ Store the status information in TCB.
+
+
+
+Satran, et al. Standards Track [Page 236]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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);
+ }
+}
+
+E.2.3. Target Algorithms
+
+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[].
+ }
+
+
+
+Satran, et al. Standards Track [Page 237]
+
+RFC 3720 iSCSI April 2004
+
+
+ }
+ }
+ Increment TContext.ExpectedDataSN.
+ if (send-recovery-R2T is TRUE and
+ task is not already considered failed) {
+ if (operational ErrorRecoveryLevel > 0) {
+ Increment TCB.ActiveR2Ts.
+ Create a data-descriptor for the data burst
+ from MissingDataRange.
+ Build-And-Send-R2T(Connection, data-descriptor, TCB);
+ } else {
+ if (current PDU is the last unsolicited)
+ TCB.Reason = "Not enough unsolicited data";
+ else
+ TCB.Reason = "Protocol service CRC error";
+ }
+ }
+ if (TCB.ActiveR2Ts == 0) {
+ Build-And-Send-Status(Connection, TCB);
+ }
+ } else if (CurrentPDU.type == SNACK) {
+ snack-failure = FALSE;
+ if (operational ErrorRecoveryLevel > 0) {
+ if (CurrentPDU.type == Data/R2T) {
+ if (the request is satisfiable) {
+
+ if (request for Data) {
+ Create a data-descriptor for the data burst
+ from BegRun and RunLength.
+ Build-And-Send-A-Data-Burst(Connection,
+
+ data-descriptor, TCB);
+ } else { /* R2T */
+ Create a data-descriptor for the data burst
+ from BegRun and RunLength.
+ Build-And-Send-R2T(Connection, data-descriptor,
+ TCB);
+ }
+ } else {
+ snack-failure = TRUE;
+ }
+ } else if (CurrentPDU.type == status) {
+ Handle-Status-SNACK-request(Connection, CurrentPDU);
+ } else if (CurrentPDU.type == DataACK) {
+ Consider all data upto CurrentPDU.BegRun as
+ acknowledged.
+ Free up the retransmission resources for that data.
+ } else if (CurrentPDU.type == R-Data SNACK) {
+
+
+
+Satran, et al. Standards Track [Page 238]
+
+RFC 3720 iSCSI April 2004
+
+
+ Create a data descriptor for a data burst covering
+ all unacknowledged data.
+ Build-And-Send-A-Data-Burst(Connection,
+ data-descriptor, TCB);
+ TCB.SNACK_Tag = CurrentPDU.SNACK_Tag;
+ if (there's no more data to send) {
+ Build-And-Send-Status(Connection, TCB);
+ }
+ }
+ } else { /* operational ErrorRecoveryLevel = 0 */
+ snack-failure = TRUE;
+
+ }
+ if (snack-failure == TRUE) {
+ Build-And-Send-Reject(Connection, CurrentPDU,
+ SNACK-Reject);
+ if (TCB.StatusXferd != TRUE) {
+ TCB.Reason = "SNACK Rejected";
+ Build-And-Send-Status(Connection, TCB);
+ }
+ }
+
+ } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT SHOWN */
+ }
+}
+
+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);
+ }
+ }
+}
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 239]
+
+RFC 3720 iSCSI April 2004
+
+
+E.3. Within-connection Recovery Algorithms
+
+E.3.1. Procedure Descriptions
+
+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
+
+ 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.
+
+
+ - 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.
+
+ - The procedure Build-And-Send-Async is defined in the Connection
+ recovery algorithms.
+
+ - 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.
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 240]
+
+RFC 3720 iSCSI April 2004
+
+
+E.3.2. Initiator Algorithms
+
+Recover-Status-if-Possible(Connection, CurrentPDU)
+{
+ if ((Connection.state == LOGGED_IN) and
+ connection is not already considered failed) {
+ if (operational ErrorRecoveryLevel > 0) {
+ if (# of missing PDUs is trackable) {
+ Note the missing StatSNs in Connection
+ that were not already requested with SNACK;
+ Build-And-Send-SSnack(Connection);
+ } else {
+ Connection.PerformConnectionCleanup = TRUE;
+ }
+ } else {
+ Connection.PerformConnectionCleanup = TRUE;
+ }
+ if (Connection.PerformConnectionCleanup == TRUE) {
+ Start-Timer(Connection-Cleanup-Handler, Connection, 0);
+ }
+ }
+}
+
+Retransmit-Command-if-Possible(Connection, CmdSN)
+{
+
+ if (operational ErrorRecoveryLevel > 0) {
+ Retrieve the InitiatorTaskTag, and thus TCB for the CmdSN.
+ Build-And-Send-Command(Connection, TCB);
+ }
+}
+
+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;
+
+
+
+Satran, et al. Standards Track [Page 241]
+
+RFC 3720 iSCSI April 2004
+
+
+ } 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 */
+ }
+}
+
+Command-Acknowledge-Timeout-Handler(TCB)
+{
+ Retrieve the Connection for TCB.
+ Retransmit-Command-if-Possible(Connection, TCB.CmdSN);
+
+
+
+Satran, et al. Standards Track [Page 242]
+
+RFC 3720 iSCSI April 2004
+
+
+}
+
+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);
+ }
+ }
+}
+
+E.3.3. Target Algorithms
+
+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);
+ }
+}
+
+E.4. Connection Recovery Algorithms
+
+E.4.1. Procedure Descriptions
+
+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);
+
+
+
+Satran, et al. Standards Track [Page 243]
+
+RFC 3720 iSCSI April 2004
+
+
+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.
+
+E.4.2. Initiator Algorithms
+
+ 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;
+
+
+
+Satran, et al. Standards Track [Page 244]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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,
+
+ * 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 =
+
+
+
+Satran, et al. Standards Track [Page 245]
+
+RFC 3720 iSCSI April 2004
+
+
+ CreateTransportConnection(Session.OtherEndInfo);
+ Initiate an implicit Logout on NewConnection for
+ Connection.CID.
+ return;
+ }
+ }
+ Build-And-Send-Logout(NewConnection, Connection.CID,
+ RecoveryRemove); }
+
+ Transport_Exception_Handler(Connection) {
+ Connection.PerformConnectionCleanup = TRUE;
+ if (the event is an unexpected transport disconnect) {
+ Connection.State = CLEANUP_WAIT;
+
+ Connection.CurrentTimeout = DefaultTime2Retain;
+ Start-Timer(Connection-Cleanup-Handler, Connection,
+ DefaultTime2Wait);
+
+ } else {
+ Connection.State = FREE;
+ } }
+
+E.4.3. Target Algorithms
+
+ 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,
+
+
+
+Satran, et al. Standards Track [Page 246]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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 */
+ }
+ }
+
+ 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,
+
+
+
+Satran, et al. Standards Track [Page 247]
+
+RFC 3720 iSCSI April 2004
+
+
+ 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;
+ }
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 248]
+
+RFC 3720 iSCSI April 2004
+
+
+Appendix F. Clearing Effects of Various Events on Targets
+
+F.1. Clearing Effects on iSCSI Objects
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 249]
+
+RFC 3720 iSCSI April 2004
+
+
+ +-----+-----+-----+-----+-----+
+ |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.
+
+ 2. Immediate Commands - immediate commands, but waiting for
+ execution on a target. For example, Abort Task Set.
+
+
+
+
+
+Satran, et al. Standards Track [Page 250]
+
+RFC 3720 iSCSI April 2004
+
+
+ 5. Connection Tasks - tasks that are active on the iSCSI connection
+ in question.
+
+ 6. Session Tasks - tasks that are active on the entire iSCSI
+ session. A union of "connection tasks" on all participating
+ connections.
+
+ 7. Partial PDUs (if any) - PDUs that are partially sent and waiting
+ for transport window credit to complete the transmission.
+
+ 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.
+
+ 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).
+
+ 10. These are defined in Section 5.3.5 Session Reinstatement,
+ Closure, and Timeout.
+
+ 11. This clearing effect is "Y" only if it is a connection
+ reinstatement and the operational ErrorRecoveryLevel is less than 2.
+
+ 12. Session continuation is defined in Section 5.3.6 Session
+ Continuation and Failure.
+
+ 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".
+
+ 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".
+
+ 15. Only applicable if this leading connection login is a session
+ reinstatement. If this is not the case, it is "NA".
+
+ 16. This operation affects all logged-in initiators.
+
+ 18. Session failure is defined in Section 5.3.6 Session Continuation
+ and Failure.
+
+
+
+
+
+Satran, et al. Standards Track [Page 251]
+
+RFC 3720 iSCSI April 2004
+
+
+ 19. This operation affects all logged-in initiators and the clearing
+ effects are only applicable to the LU being reset.
+
+ +-----+-----+-----+-----+-----+
+ |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.
+
+
+
+
+
+Satran, et al. Standards Track [Page 252]
+
+RFC 3720 iSCSI April 2004
+
+
+ 2. Discontiguous Data - data PDUs received for the task in question
+ and waiting to be reordered due to prior discontiguities in DataSN.
+
+ 3. StatSN
+
+ 4. CmdSN
+
+ 5. DataSN
+
+ 7. It clears the StatSN on all the connections.
+
+ 8. This sequence number is instantiated on this event.
+
+ 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.
+
+ 10. This is cleared by virtue of the fact that all sessions with all
+ initiators are terminated.
+
+ 11. This clearing effect is "Y" if it is a connection reinstatement.
+
+ 12. This clearing effect is "Y" only if it is a connection
+ reinstatement and the operational ErrorRecoveryLevel is 2.
+
+ 13. This clearing effect is "N" only if it is a connection
+ reinstatement and the operational ErrorRecoveryLevel is 2.
+
+F.2. Clearing Effects on SCSI Objects
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+Satran, et al. Standards Track [Page 253]
+
+RFC 3720 iSCSI April 2004
+
+
+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).
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Satran, et al. Standards Track [Page 254]
+
+RFC 3720 iSCSI April 2004
+
+
+ Design Considerations" [RFC3347] and "SCSI Command Ordering
+ Considerations with iSCSI" [CORD].
+
+ The "iSCSI Naming & Discovery" document is authored by:
+
+ Mark Bakke (Cisco), Jim Hafner, John Hufferd, Kaladhar Voruganti
+ (IBM), and Marjorie Krueger (HP).
+
+ The "Bootstrapping Clients using the iSCSI Protocol" document is
+ authored by:
+
+ Prasenjit Sarkar (IBM), Duncan Missimer (HP), and Costa
+ Sapuntzakis (Cisco).
+
+ The "Securing Block Storage Protocols over IP" document is authored
+ by:
+
+ Bernard Aboba (Microsoft), Joshua Tseng (Nishan), Jesse Walker
+ (Intel), Venkat Rangan (Rhapsody Networks), and Franco
+ Travostino (Nortel Networks).
+
+ The "iSCSI Requirements and Design Considerations" document is
+ authored by:
+
+ Marjorie Krueger, Randy Haagens (HP), Costa Sapuntzakis, and Mark
+ Bakke (Cisco).
+
+ The "SCSI Command Ordering Considerations with iSCSI" document is
+ authored by:
+
+ Mallikarjun Chadalapaka, Rob Elliot (HP)
+
+ We are grateful to all of them for their good work and for helping us
+ correlate this document with the ones they produced.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 255]
+
+RFC 3720 iSCSI April 2004
+
+
+Authors' Addresses
+
+ Julian Satran
+ IBM Research Laboratory in Haifa
+ Haifa University Campus - Mount Carmel
+ Haifa 31905, Israel
+
+ Phone +972.4.829.6264
+ EMail: Julian_Satran@il.ibm.com
+
+
+ Kalman Meth
+ IBM Research Laboratory in Haifa
+ Haifa University Campus - Mount Carmel
+ Haifa 31905, Israel
+
+ Phone +972.4.829.6341
+ EMail: meth@il.ibm.com
+
+
+ Costa Sapuntzakis
+ Stanford University
+ 353 Serra Mall Dr #407
+ Stanford, CA 94305
+
+ Phone: +1.650.723.2458
+ EMail: csapuntz@alum.mit.edu
+
+
+ Efri Zeidner
+ XIV Ltd.
+ 1 Azrieli Center,
+ Tel-Aviv 67021, Israel
+
+ Phone: +972.3.607.4722
+ EMail: efri@xiv.co.il
+
+
+ Mallikarjun Chadalapaka
+ Hewlett-Packard Company
+ 8000 Foothills Blvd.
+ Roseville, CA 95747-5668, USA
+
+ Phone: +1.916.785.5621
+ EMail: cbm@rose.hp.com
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 256]
+
+RFC 3720 iSCSI April 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Satran, et al. Standards Track [Page 257]
+