Network Working Group M. Chadalapaka, Ed.
Request for Comments: 5048 Hewlett-Packard Co.
Updates: 3720 October 2007
Category: Standards Track
Network Working Group M. Chadalapaka, Ed.
Request for Comments: 5048 Hewlett-Packard Co.
Updates: 3720 October 2007
Category: Standards Track
Internet Small Computer System Interface (iSCSI) Corrections and Clarifications
Internet小型计算机系统接口（iSCSI）更正和澄清
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ.
Internet小型计算机系统接口（iSCSI）是一种SCSI传输协议，它将SCSI体系结构和命令集映射到TCP/IP。RFC 3720定义了iSCSI协议。本文档汇编了对RFC 3720中原始协议定义的澄清，作为iSCSI实施者的配套文档。本文档更新RFC 3720，当两者不同时，本文档中的文本将取代RFC 3720中的文本。
Table of Contents
目录
1. Introduction ....................................................3
2. Definitions, Acronyms, and Document Summary .....................3
2.1. Definitions ................................................3
2.2. Acronyms ...................................................4
2.3. Clarifications, Changes, and New Semantics .................5
3. iSCSI Semantics for SCSI Tasks ..................................7
3.1. Residual Handling ..........................................7
3.1.1. Overview ............................................7
3.1.2. SCSI REPORT LUNS and Residual Overflow ..............7
3.2. R2T Ordering ...............................................9
3.3. Model Assumptions for Response Ordering ....................9
3.3.1. Model Description ..................................10
3.3.2. iSCSI Semantics with the Interface Model ...........10
3.3.3. Current List of Fenced Response Use Cases ..........11
4. Task Management ................................................12
4.1. Requests Affecting Multiple Tasks .........................12
4.1.1. Scope of Affected Tasks ............................12
4.1.2. Clarified Multi-Task Abort Semantics ...............13
4.1.3. Updated Multi-Task Abort Semantics .................14
1. Introduction ....................................................3
2. Definitions, Acronyms, and Document Summary .....................3
2.1. Definitions ................................................3
2.2. Acronyms ...................................................4
2.3. Clarifications, Changes, and New Semantics .................5
3. iSCSI Semantics for SCSI Tasks ..................................7
3.1. Residual Handling ..........................................7
3.1.1. Overview ............................................7
3.1.2. SCSI REPORT LUNS and Residual Overflow ..............7
3.2. R2T Ordering ...............................................9
3.3. Model Assumptions for Response Ordering ....................9
3.3.1. Model Description ..................................10
3.3.2. iSCSI Semantics with the Interface Model ...........10
3.3.3. Current List of Fenced Response Use Cases ..........11
4. Task Management ................................................12
4.1. Requests Affecting Multiple Tasks .........................12
4.1.1. Scope of Affected Tasks ............................12
4.1.2. Clarified Multi-Task Abort Semantics ...............13
4.1.3. Updated Multi-Task Abort Semantics .................14
4.1.4. Affected Tasks Shared across RFC 3720 and
FastAbort Sessions .................................16
4.1.5. Implementation Considerations ......................17
4.1.6. Rationale behind the New Semantics .................17
5. Discovery Semantics ............................................19
5.1. Error Recovery for Discovery Sessions .....................19
5.2. Reinstatement Semantics of Discovery Sessions .............19
5.2.1. Unnamed Discovery Sessions .........................20
5.2.2. Named Discovery Sessions ...........................20
5.3. Target PDUs during Discovery ..............................20
6. Negotiation and Others .........................................21
6.1. TPGT Values ...............................................21
6.2. SessionType Negotiation ...................................21
6.3. Understanding NotUnderstood ...............................21
6.4. Outstanding Negotiation Exchanges .........................22
7. iSCSI Error Handling and Recovery ..............................22
7.1. ITT .......................................................22
7.2. Format Errors .............................................22
7.3. Digest Errors .............................................22
7.4. Message Error Checking ....................................23
8. iSCSI PDUs .....................................................23
8.1. Asynchronous Message ......................................23
8.2. Reject ....................................................24
9. Login/Text Operational Text Keys ...............................24
9.1. TaskReporting .............................................24
10. Security Considerations .......................................25
11. IANA Considerations ...........................................26
11.1. iSCSI-Related IANA Registries ............................26
11.2. iSCSI Opcodes ............................................26
11.3. iSCSI Login/Text Keys ....................................28
11.4. iSCSI Asynchronous Events ................................30
11.5. iSCSI Task Management Function Codes .....................31
11.6. iSCSI Login Response Status Codes ........................32
11.7. iSCSI Reject Reason Codes ................................34
11.8. iSER Opcodes .............................................35
12. References ....................................................36
12.1. Normative References .....................................36
12.2. Informative References ...................................36
Acknowledgements ..................................................37
4.1.4. Affected Tasks Shared across RFC 3720 and
FastAbort Sessions .................................16
4.1.5. Implementation Considerations ......................17
4.1.6. Rationale behind the New Semantics .................17
5. Discovery Semantics ............................................19
5.1. Error Recovery for Discovery Sessions .....................19
5.2. Reinstatement Semantics of Discovery Sessions .............19
5.2.1. Unnamed Discovery Sessions .........................20
5.2.2. Named Discovery Sessions ...........................20
5.3. Target PDUs during Discovery ..............................20
6. Negotiation and Others .........................................21
6.1. TPGT Values ...............................................21
6.2. SessionType Negotiation ...................................21
6.3. Understanding NotUnderstood ...............................21
6.4. Outstanding Negotiation Exchanges .........................22
7. iSCSI Error Handling and Recovery ..............................22
7.1. ITT .......................................................22
7.2. Format Errors .............................................22
7.3. Digest Errors .............................................22
7.4. Message Error Checking ....................................23
8. iSCSI PDUs .....................................................23
8.1. Asynchronous Message ......................................23
8.2. Reject ....................................................24
9. Login/Text Operational Text Keys ...............................24
9.1. TaskReporting .............................................24
10. Security Considerations .......................................25
11. IANA Considerations ...........................................26
11.1. iSCSI-Related IANA Registries ............................26
11.2. iSCSI Opcodes ............................................26
11.3. iSCSI Login/Text Keys ....................................28
11.4. iSCSI Asynchronous Events ................................30
11.5. iSCSI Task Management Function Codes .....................31
11.6. iSCSI Login Response Status Codes ........................32
11.7. iSCSI Reject Reason Codes ................................34
11.8. iSER Opcodes .............................................35
12. References ....................................................36
12.1. Normative References .....................................36
12.2. Informative References ...................................36
Acknowledgements ..................................................37
Several iSCSI implementations have been built since [RFC3720] was published and the iSCSI community is now richer by the resulting implementation expertise. The goal of this document is to leverage this expertise both to offer clarifications to the [RFC3720] semantics and to address defects in [RFC3720] as appropriate. This document intends to offer critical guidance to implementers with regard to non-obvious iSCSI implementation aspects so as to improve interoperability and accelerate iSCSI adoption. This document, however, does not purport to be an all-encompassing iSCSI how-to guide for implementers, nor a complete revision of [RFC3720]. Instead, this document is intended as a companion document to [RFC3720] for the iSCSI implementers.
[RFC3720]发布以来，已构建了多个iSCSI实施，由此产生的实施专业知识使iSCSI社区更加丰富。本文档的目标是利用这些专业知识，对[RFC3720]语义进行澄清，并酌情解决[RFC3720]中的缺陷。本文档旨在为实施者提供有关非显而易见的iSCSI实施方面的重要指导，以提高互操作性并加快iSCSI的采用。但是，本文档并不打算为实施者提供全面的iSCSI操作指南，也不是[RFC3720]的完整修订版。相反，本文档旨在为iSCSI实施者提供[RFC3720]的配套文档。
iSCSI implementers are required to reference [RFC3722] and [RFC3723] in addition to [RFC3720] for mandatory requirements. In addition, [RFC3721] also contains useful information for iSCSI implementers. The text in this document, however, updates and supersedes the text in [RFC3720] whenever there is such a question.
iSCSI实施者需要参考[RFC3722]和[RFC3723]以及[RFC3720]了解强制性要求。此外，[RFC3721]还包含对iSCSI实施者有用的信息。但是，如果存在此类问题，本文件中的文本将更新并取代[RFC3720]中的文本。
I/O Buffer A buffer that is used in a SCSI Read or Write operation so SCSI data may be sent from or received into that buffer. For a read or write data transfer to take place for a task, an I/O Buffer is required on the initiator and at least one is required on the target.
I/O缓冲区在SCSI读写操作中使用的缓冲区，以便SCSI数据可以从该缓冲区发送或接收到该缓冲区。要对任务进行读或写数据传输，启动器上需要一个I/O缓冲区，目标上至少需要一个I/O缓冲区。
SCSI-Presented Data Transfer Length (SPDTL) SPDTL is the aggregate data length of the data that the SCSI layer logically "presents" to the iSCSI layer for a Data-In or Data-Out transfer in the context of a SCSI task. For a bidirectional task, there are two SPDTL values -- one for Data-In and one for Data-Out. Note that the notion of "presenting" includes immediate data per the data transfer model in [SAM2], and excludes overlapping data transfers, if any, requested by the SCSI layer.
SCSI Presented Data Transfer Length（SPDTL）SPDTL是SCSI层为SCSI任务上下文中的数据输入或数据输出传输而在逻辑上“呈现”给iSCSI层的数据的聚合数据长度。对于双向任务，有两个SPDTL值——一个用于数据输入，一个用于数据输出。注意，“呈现”的概念包括[SAM2]中每个数据传输模型的即时数据，并排除SCSI层请求的重叠数据传输（如果有）。
Third-party A term used in this document to denote nexus objects (I_T or I_T_L) and iSCSI sessions that reap the side effects of actions that take place in the context of a separate iSCSI session, while being third parties to the action that caused the side effects. One example of a third-party session is an iSCSI session hosting
第三方本文档中使用的一个术语，用于表示nexus对象（I_T或I_T_L）和iSCSI会话，这些对象和会话会获得在单独iSCSI会话上下文中发生的操作的副作用，同时是导致副作用的操作的第三方。第三方会话的一个示例是iSCSI会话托管
an I_T_L nexus to an LU that is reset with an LU Reset TMF via a separate I_T nexus.
与LU的I___L连接，通过单独的I_T连接使用LU reset TMF重置。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Acronym Definition
-------------------------------------------------------------
Acronym Definition
-------------------------------------------------------------
EDTL Expected Data Transfer Length
预期数据传输长度
IANA Internet Assigned Numbers Authority
IANA互联网分配号码管理局
IETF Internet Engineering Task Force
因特网工程任务组
I/O Input - Output
I/O输入-输出
IP Internet Protocol
网际协议
iSCSI Internet SCSI
iSCSI Internet SCSI
iSER iSCSI Extensions for RDMA
用于RDMA的iSER iSCSI扩展
ITT Initiator Task Tag
ITT启动器任务标记
LO Leading Only
LO仅领先
LU Logical Unit
逻辑单元
LUN Logical Unit Number
LUN逻辑单元号
PDU Protocol Data Unit
协议数据单元
RDMA Remote Direct Memory Access
远程直接内存访问
R2T Ready To Transfer
R2T准备转移
R2TSN Ready To Transfer Sequence Number
R2TSN准备传输序列号
RFC Request For Comments
征求意见
SAM SCSI Architecture Model
SAM SCSI体系结构模型
SCSI Small Computer Systems Interface
小型计算机系统接口
SN Sequence Number
序列号
SNACK Selective Negative Acknowledgment - also Sequence Number Acknowledgement for data
SNACK选择性否定确认-也是数据的序列号确认
TCP Transmission Control Protocol
TCP传输控制协议
TMF Task Management Function
任务管理功能
TTT Target Transfer Tag
目标转移标签
UA Unit Attention
行动单位注意
This document specifies certain changes to [RFC3720] semantics as well as defines new iSCSI semantics. In addition, this document also clarifies the [RFC3720] semantics. This section summarizes the contents of the document, categorizing each section into one or more of a clarification, change, or new semantic.
本文档指定了[RFC3720]语义的某些更改，并定义了新的iSCSI语义。此外，本文档还澄清了[RFC3720]语义。本节总结了文档的内容，将每个部分划分为一个或多个澄清、更改或新语义。
Section 3.1.1: Clarification on iSCSI residuals computation general principles
第3.1.1节：iSCSI残差计算一般原则的说明
Section 3.1.2: Clarification on iSCSI residuals computation with an example
第3.1.2节：通过示例说明iSCSI残差计算
Section 3.2: Clarification on R2T ordering requirements
第3.2节：R2T订购要求的澄清
Section 3.3: New Semantics for Response Ordering in multi-connection iSCSI sessions
第3.3节：多连接iSCSI会话中响应顺序的新语义
Section 4.1.2: Clarifications, changes, and new semantics on multi-task abort semantics that all implementations must comply with
第4.1.2节：关于所有实现必须遵守的多任务中止语义的澄清、更改和新语义
Section 4.1.3: Changes and new semantics (FastAbort semantics) on multi-task abort semantics that implementations should use for faster error recovery
第4.1.3节：关于多任务中止语义的更改和新语义（FastAbort语义），实现应使用这些语义来加快错误恢复
Section 4.1.3.1: Changes in iSCSI clearing effects semantics resulting from new FastAbort semantics
第4.1.3.1节：新的FastAbort语义导致iSCSI清除效果语义的更改
Section 4.1.4: New Semantics on third-party session interactions with the new FastAbort semantics
第4.1.4节：第三方会话交互的新语义与新的FastAbort语义
Section 4.1.5: Clarification on implementation considerations related to outstanding data transfers in order to realize correct iSCSI protocol behavior
第4.1.5节：澄清与未完成数据传输相关的实施注意事项，以实现正确的iSCSI协议行为
Section 4.1.6: Clarification on the intent behind FastAbort semantics (not clarifications to [RFC3720] semantics)
第4.1.6节：对FastAbort语义背后意图的澄清（不是对[RFC3720]语义的澄清）
Section 5.1: Clarification on error recovery semantics as applicable to Discovery sessions
第5.1节：适用于发现会话的错误恢复语义说明
Section 5.2.1: Clarification and new semantics on applying the Initiator Session Identifier (ISID) RULE ([RFC3720]) to Unnamed Discovery Sessions
第5.2.1节：将启动器会话标识符（ISID）规则（[RFC3720]）应用于未命名发现会话的说明和新语义
Section 5.2.2: Clarification on applying the ISID RULE to Named Discovery Sessions
第5.2.2节：关于将ISID规则应用于命名发现会话的说明
Section 5.3: Clarification on allowed PDU types and target Logout notification behavior on a Discovery session
第5.3节：澄清发现会话上允许的PDU类型和目标注销通知行为
Section 6.1: Clarification on the legality of the Target Portal Group Tag (TPGT) value of zero
第6.1节：澄清目标门户组标签（TPGT）值为零的合法性
Section 6.2: Clarification on the negotiating order of SessionType with respect to other keys
第6.2节：澄清SessionType与其他键的协商顺序
Section 6.3: Clarification on the NotUnderstood negotiation response on declarative keys and the implied semantics
第6.3节：澄清声明性密钥的未理解协商响应和隐含语义
Section 6.4: Clarification on the number of legal outstanding negotiation PDUs (Text or Login-related)
第6.4节：澄清法律未决谈判PDU的数量（文本或登录相关）
Section 7.1: Clarification on usage of the ITT value of 0xffffffff
第7.1节：关于0xFFFFFF ITT值用法的澄清
Section 7.2: Clarification on what constitutes format errors for the purpose of error recovery defined in [RFC3720]
第7.2节：澄清什么构成[RFC3720]中定义的错误恢复中的格式错误
Section 7.3: Change in error recovery semantics for the case of discarding unsolicited PDUs
第7.3节：丢弃未经请求的PDU时错误恢复语义的更改
Section 7.4: Clarification on the intended level of error checking on inbound PDUs
第7.4节：对入站PDU的预期错误检查级别的澄清
Section 8.1: New semantics for a new AsyncEvent code
第8.1节：新AsyncEvent代码的新语义
Section 8.2: Change of legal status for Reject reason code 0x0b; it is now deprecated
第8.2节：拒绝原因代码0x0b的法律状态变更；它现在已被弃用
Section 9.1: New semantics for a new text key TaskReporting
第9.1节：新文本键TaskReporting的新语义
Section 10.4.1 of [RFC3720] defines the notion of "residuals" and specifies how the residual information should be encoded into the SCSI Response PDU in the Counts and Flags fields. Section 3.1.1 clarifies the intent of [RFC3720] and explains the general principles. Section 3.1.2 describes the residual handling in the REPORT LUNS scenario.
[RFC3720]第10.4.1节定义了“剩余”的概念，并规定了剩余信息应如何编码到计数和标志字段中的SCSI响应PDU中。第3.1.1节澄清了[RFC3720]的意图，并解释了一般原则。第3.1.2节描述了报告LUN场景中的剩余处理。
SCSI-Presented Data Transfer Length (SPDTL) is the term this document uses (see Section 1.1 for definition) to represent the aggregate data length that the target SCSI layer attempts to transfer using the local iSCSI layer for a task. Expected Data Transfer Length (EDTL) is the iSCSI term that represents the length of data that the iSCSI layer expects to transfer for a task. EDTL is specified in the SCSI Command PDU.
SCSI呈现数据传输长度（SPDTL）是本文档使用的术语（定义见第1.1节），表示目标SCSI层尝试使用本地iSCSI层为任务传输的聚合数据长度。预期数据传输长度（EDTL）是iSCSI术语，表示iSCSI层预期为任务传输的数据长度。EDTL在SCSI命令PDU中指定。
When SPDTL = EDTL for a task, the target iSCSI layer completes the task with no residuals. Whenever SPDTL differs from EDTL for a task, that task is said to have a residual.
当任务的SPDTL=EDTL时，目标iSCSI层将完成该任务，且无剩余。当任务的SPDTL与EDTL不同时，该任务被称为有剩余。
If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST be set to the numerical value of (SPDTL - EDTL).
如果任务的SPDTL>EDTL，则必须按照[RFC3720]中的规定在SCSI响应PDU中发出iSCSI溢出信号。剩余计数必须设置为（SPDTL-EDTL）的数值。
If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST be set to the numerical value of (EDTL - SPDTL).
如果任务的SPDTL<EDTL，则必须按照[RFC3720]中的规定在SCSI响应PDU中发出iSCSI下溢信号。剩余计数必须设置为（EDTL-SPDTL）的数值。
Note that the Overflow and Underflow scenarios are independent of Data-In and Data-Out. Either scenario is logically possible in either direction of data transfer.
请注意，溢出和下溢场景独立于数据输入和数据输出。这两种情况在逻辑上都可能发生在数据传输的任何一个方向上。
This section discusses the residual overflow issues citing the example of the SCSI REPORT LUNS command. Note however that there are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH fields following the same underlying rules. The semantics in the rest of the section apply to all such SCSI commands.
本节以SCSI REPORT LUN命令为例讨论剩余溢出问题。但是请注意，有几个SCSI命令（例如查询）的分配长度字段遵循相同的基本规则。本节其余部分中的语义适用于所有此类SCSI命令。
The specification of the SCSI REPORT LUNS command requires that the SCSI target limit the amount of data transferred to a maximum size (ALLOCATION LENGTH) provided by the initiator in the REPORT LUNS CDB. If the Expected Data Transfer Length (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT LUNS command is set to at least as large as that ALLOCATION LENGTH, the SCSI layer truncation prevents an iSCSI Residual Overflow from occurring. A SCSI initiator can detect that such truncation has occurred via other information at the SCSI layer. The rest of the section elaborates this required behavior.
SCSI报告LUN命令的规范要求SCSI目标将传输的数据量限制为报告LUN CDB中启动器提供的最大大小（分配长度）。如果将报告LUN命令的SCSI命令PDU的iSCSI标头中的预期数据传输长度（EDTL）设置为至少与该分配长度相同，则SCSI层截断可防止发生iSCSI剩余溢出。SCSI启动器可以通过SCSI层的其他信息检测到发生了这种截断。本节的其余部分将详细说明此所需的行为。
iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI Response and the last SCSI Data-In PDUs to indicate that an iSCSI target was unable to transfer all of the SCSI data for a command to the initiator because the amount of data to be transferred exceeded the EDTL in the corresponding SCSI Command PDU (see Section 10.4.1 of [RFC3720]).
iSCSI使用SCSI响应标志字段中的（O）位（第5位）和PDU中的最后一个SCSI数据指示iSCSI目标无法将命令的所有SCSI数据传输到启动器，因为要传输的数据量超过了相应SCSI命令PDU中的EDTL（请参阅[RFC3720]的第10.4.1节）。
The SCSI REPORT LUNS command requests a target SCSI layer to return a logical unit inventory (LUN list) to the initiator SCSI layer (see Section 6.21 of SPC-3 [SPC3]). The size of this LUN list may not be known to the initiator SCSI layer when it issues the REPORT LUNS command; to avoid transferring more LUN list data than the initiator is prepared for, the REPORT LUNS CDB contains an ALLOCATION LENGTH field to specify the maximum amount of data to be transferred to the initiator for this command. If the initiator SCSI layer has under-estimated the number of logical units at the target, it is possible that the complete logical unit inventory does not fit in the specified ALLOCATION LENGTH. In this situation, Section 4.3.3.6 in [SPC3] requires that the target SCSI layer "shall terminate transfers to the Data-In Buffer" when the number of bytes specified by the ALLOCATION LENGTH field have been transferred.
SCSI报告LUN命令请求目标SCSI层将逻辑单元资源清册（LUN列表）返回到启动器SCSI层（请参阅SPC-3[SPC3]第6.21节）。启动器SCSI层在发出“报告LUN”命令时可能不知道此LUN列表的大小；为避免传输的LUN列表数据超过启动器准备的数量，报告LUN CDB包含一个分配长度字段，用于指定此命令传输到启动器的最大数据量。如果启动器SCSI层低估了目标上的逻辑单元数量，则完整的逻辑单元资源清册可能不符合指定的分配长度。在这种情况下，[SPC3]中的第4.3.3.6节要求目标SCSI层在传输分配长度字段指定的字节数时“应终止传输到缓冲区中的数据”。
Therefore, in response to a REPORT LUNS command, the SCSI layer at the target presents at most ALLOCATION LENGTH bytes of data (logical unit inventory) to iSCSI for transfer to the initiator. For a REPORT LUNS command, if the iSCSI EDTL is at least as large as the ALLOCATION LENGTH, the SCSI truncation ensures that the EDTL will accommodate all of the data to be transferred. If all of the logical unit inventory data presented to the iSCSI layer -- i.e., the data remaining after any SCSI truncation -- is transferred to the initiator by the iSCSI layer, an iSCSI Residual Overflow has not occurred and the iSCSI (O) bit MUST NOT be set in the SCSI Response or final SCSI Data-Out PDU. This is not a new requirement but is already required by the combination of [RFC3720] with the specification of the REPORT LUNS command in [SPC3]. However, if the iSCSI EDTL is larger than the ALLOCATION LENGTH in this scenario, note that the iSCSI Underflow MUST be signaled in the SCSI Response
因此，作为对报告LUN命令的响应，目标的SCSI层向iSCSI提供最多分配长度字节的数据（逻辑单元资源清册），以便传输到启动器。对于报告LUN命令，如果iSCSI EDTL至少与分配长度一样大，SCSI截断将确保EDTL将容纳要传输的所有数据。如果提供给iSCSI层的所有逻辑单元资源清册数据（即任何SCSI截断后剩余的数据）都由iSCSI层传输到启动器，则iSCSI剩余溢出未发生，并且iSCSI（O）位不得在SCSI响应或最终SCSI数据输出PDU中设置。这不是新的要求，但[RFC3720]与[SPC3]中的报告LUN命令的规范相结合已经要求这样做。但是，如果在此场景中iSCSI EDTL大于分配长度，请注意，iSCSI下溢必须在SCSI响应中发出信号
PDU. An iSCSI Underflow MUST also be signaled when the iSCSI EDTL is equal to the ALLOCATION LENGTH but the logical unit inventory data presented to the iSCSI layer is smaller than the ALLOCATION LENGTH.
PDU。当iSCSI EDTL等于分配长度，但呈现给iSCSI层的逻辑单元资源清册数据小于分配长度时，还必须发出iSCSI下溢信号。
The LUN LIST LENGTH field in the logical unit inventory (the first field in the inventory) is not affected by truncation of the inventory to fit in ALLOCATION LENGTH; this enables a SCSI initiator to determine that the received inventory is incomplete by noticing that the LUN LIST LENGTH in the inventory is larger than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A common initiator behavior in this situation is to re-issue the REPORT LUNS command with a larger ALLOCATION LENGTH.
逻辑单元清单中的LUN列表长度字段（清单中的第一个字段）不受截断清单以适应分配长度的影响；这使SCSI启动器能够通过注意到资源清册中的LUN列表长度大于报告LUN CDB中发送的分配长度来确定收到的资源清册是否不完整。在这种情况下，常见的启动器行为是以更大的分配长度重新发出REPORT LUNS命令。
Section 10.8 in [RFC3720] says the following:
[RFC3720]第10.8节规定如下：
The target may send several R2T PDUs. It, therefore, can have a number of pending data transfers. The number of outstanding R2T PDUs is limited by the value of the negotiated key MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST be fulfilled by the initiator in the order in which they were received.
目标可以发送多个R2T PDU。因此，它可以有许多挂起的数据传输。未完成R2T PDU的数量受协商密钥MaxOutstandingR2T的值限制。在连接中，未完成的R2T必须由启动器按照接收顺序完成。
The quoted [RFC3720] text was unclear on the scope of applicability -- either per task, or across all tasks on a connection -- and may be interpreted as either. This section is intended to clarify that the scope of applicability of the quoted text is a task. No R2T ordering relationship -- either in generation at the target or in fulfilling at the initiator -- across tasks is implied. That is, outstanding R2Ts within a task MUST be fulfilled by the initiator in the order in which they were received on a connection.
引用的[RFC3720]文本的适用范围不明确（每个任务或连接上的所有任务），可能被解释为：。本节旨在澄清引用文本的适用范围是一项任务。在任务之间不存在R2T排序关系——无论是在目标生成中还是在发起方实现中。也就是说，任务中未完成的R2T必须由启动器按照在连接上接收它们的顺序来完成。
Whenever an iSCSI session is composed of multiple connections, the Response PDUs (task responses or TMF responses) originating in the target SCSI layer are distributed onto the multiple connections by the target iSCSI layer according to iSCSI connection allegiance rules. This process generally may not preserve the ordering of the responses by the time they are delivered to the initiator SCSI layer. Since ordering is not expected across SCSI responses anyway, this approach works fine in the general case. However, to address the special cases where some ordering is desired by the SCSI layer, the following "Response Fence" semantics are defined with respect to handling SCSI response messages as they are handed off from the SCSI protocol layer to the iSCSI layer.
每当iSCSI会话由多个连接组成时，源于目标SCSI层的响应PDU（任务响应或TMF响应）将由目标iSCSI层根据iSCSI连接忠诚规则分布到多个连接上。此过程通常不会在响应传递到启动器SCSI层时保留响应的顺序。由于SCSI响应之间不需要排序，因此这种方法在一般情况下效果良好。但是，为了解决SCSI层需要某种顺序的特殊情况，定义了以下“响应围栏”语义，以处理从SCSI协议层传递到iSCSI层的SCSI响应消息。
The target SCSI protocol layer hands off the SCSI response messages to the target iSCSI layer by invoking the "Send Command Complete" protocol data service ([SAM2], clause 5.4.2) and "Task Management Function Executed" ([SAM2], clause 6.9) service. On receiving the SCSI response message, the iSCSI layer exhibits the Response Fence behavior for certain SCSI response messages (Section 3.3.3 describes the specific instances where the semantics must be realized). Whenever the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST ensure that the following conditions are met in delivering the response message to the initiator iSCSI layer:
目标SCSI协议层通过调用“发送命令完成”协议数据服务（[SAM2]，第5.4.2条）和“已执行任务管理功能”（[SAM2]，第6.9条）服务，将SCSI响应消息传递给目标iSCSI层。在接收SCSI响应消息时，iSCSI层显示特定SCSI响应消息的响应围栏行为（第3.3.3节描述了必须实现语义的特定实例）。每当SCSI响应消息需要响应围栏行为时，目标iSCSI层必须确保在将响应消息传递到启动器iSCSI层时满足以下条件：
(1) Response with Response Fence MUST be delivered chronologically after all the "preceding" responses on the I_T_L nexus, if the preceding responses are delivered at all, to the initiator iSCSI layer.
(1) 带有响应围栏的响应必须在I_T_L nexus上的所有“先前”响应之后按时间顺序交付，如果之前的响应都已交付到启动器iSCSI层。
(2) Response with Response Fence MUST be delivered chronologically prior to all the "following" responses on the I_T_L nexus.
(2) 带有响应围栏的响应必须在I_T_L nexus上的所有“以下”响应之前按时间顺序交付。
The "preceding" and "following" notions refer to the order of handoff of a response message from the target SCSI protocol layer to the target iSCSI layer.
“之前”和“之后”的概念是指响应消息从目标SCSI协议层切换到目标iSCSI层的顺序。
Whenever the TaskReporting key (Section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session and the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST perform the actions described in this section for that session.
每当将TaskReporting密钥（第9.1节）协商为iSCSI会话的ResponseFence或FastAbort，并且SCSI响应消息需要响应围栏行为时，目标iSCSI层必须针对该会话执行本节中描述的操作。
a) If it is a single-connection session, no special processing is required. The standard SCSI Response PDU build and dispatch process happens.
a) 如果是单个连接会话，则不需要特殊处理。标准SCSI响应PDU生成和分派过程会发生。
b) If it is a multi-connection session, the target iSCSI layer takes note of the last-sent and unacknowledged StatSN on each of the connections in the iSCSI session, and waits for an acknowledgement (NOP-In PDUs MAY be used to solicit acknowledgements as needed in order to accelerate this process) of each such StatSN to clear the fence. The SCSI response requiring Response Fence behavior MUST NOT be sent to the initiator before acknowledgements are received for each of the unacknowledged StatSNs.
b) 如果是多连接会话，目标iSCSI层将记录iSCSI会话中每个连接上最后发送和未确认的StatSN，并等待每个此类StatSN的确认（PDU中的NOP可用于根据需要请求确认，以加速此过程），以清除隔离。在收到每个未确认STATSN的确认之前，不得将需要响应围栏行为的SCSI响应发送给启动器。
c) The target iSCSI layer must wait for an acknowledgement of the SCSI Response PDU that carried the SCSI response requiring the Response Fence behavior. The fence MUST be considered cleared only after receiving the acknowledgement.
c) 目标iSCSI层必须等待SCSI响应PDU的确认，该PDU承载需要响应围栏行为的SCSI响应。只有在收到确认后，才能认为围栏已清理。
d) All further status processing for the LU is resumed only after clearing the fence. If any new responses for the I_T_L nexus are received from the SCSI layer before the fence is cleared, those Response PDUs MUST be held and queued at the iSCSI layer until the fence is cleared.
d) 只有在清除围栏后，LU的所有进一步状态处理才会恢复。如果在清除隔离之前从SCSI层接收到I_T_L nexus的任何新响应，则必须保留这些响应PDU并在iSCSI层排队，直到清除隔离。
This section lists the fenced response use cases that iSCSI implementations MUST comply with. However, this is not an exhaustive enumeration. It is expected that as SCSI protocol specifications evolve, the specifications will specify when response fencing is required on a case-by-case basis.
本节列出了iSCSI实施必须遵守的防护响应用例。然而，这并不是一个详尽的列举。预计随着SCSI协议规范的发展，规范将根据具体情况指定何时需要响应围栏。
Whenever the TaskReporting key (Section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session, the target iSCSI layer MUST assume that the Response Fence is required for the following SCSI completion messages:
每当将TaskReporting密钥（第9.1节）协商为iSCSI会话的ResponseFence或FastAbort时，目标iSCSI层必须假定以下SCSI完成消息需要响应围栏：
1. The first completion message carrying the UA after the multi-task abort on issuing and third-party sessions. See Section 4.1.1 for related TMF discussion.
1. 在发布和第三方会话的多任务中止后，承载UA的第一条完成消息。有关TMF的讨论，请参见第4.1.1节。
2. The TMF Response carrying the multi-task TMF Response on the issuing session.
2. 在发布会话上承载多任务TMF响应的TMF响应。
3. The completion message indicating ACA establishment on the issuing session.
3. 在发布会话上指示ACA建立的完成消息。
4. The first completion message carrying the ACA ACTIVE status after ACA establishment on issuing and third-party sessions.
4. 在发行和第三方会议上建立ACA后，第一条完成消息携带ACA活动状态。
5. The TMF Response carrying the Clear ACA response on the issuing session.
5. TMF响应在发布会议上包含明确的ACA响应。
6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT command.
6. 对持久保留输出/抢占和中止命令的响应。
Note: Due to the absence of ACA-related fencing requirements in [RFC3720], initiator implementations SHOULD NOT use ACA on multi-connection iSCSI sessions to targets complying only with [RFC3720]. Initiators that want to employ ACA on multi-connection iSCSI sessions
注意：由于[RFC3720]中没有与ACA相关的围栏要求，发起方实施不应在多连接iSCSI会话上使用ACA，而目标仅符合[RFC3720]的要求。希望在多连接iSCSI会话上使用ACA的启动器
SHOULD first assess response-fencing behavior via negotiating for ResponseFence or FastAbort values for the TaskReporting (Section 9.1) key.
应首先通过协商TaskReporting（第9.1节）键的ResponseFence或FastAbort值来评估响应围栏行为。
This section clarifies and updates the original text in Section 10.6.2 of [RFC3720]. The clarified semantics (Section 4.1.2) are a superset of the protocol behavior required in the original text and all iSCSI implementations MUST support the new behavior. The updated semantics (Section 4.1.3) on the other hand are mandatory only when the new key TaskReporting (Section 9.1) is negotiated to "FastAbort".
本节澄清并更新了[RFC3720]第10.6.2节中的原文。澄清的语义（第4.1.2节）是原始文本中要求的协议行为的超集，所有iSCSI实现都必须支持新行为。另一方面，仅当新的关键任务报告（第9.1节）协商为“快速中止”时，更新的语义（第4.1.3节）才是强制性的。
This section defines the notion of "affected tasks" in multi-task abort scenarios. Scope definitions in this section apply to both the clarified protocol behavior (Section 4.1.2) and the updated protocol behavior (Section 4.1.3).
本节定义了多任务中止场景中“受影响任务”的概念。本节中的范围定义适用于澄清的协议行为（第4.1.2节）和更新的协议行为（第4.1.3节）。
ABORT TASK SET: All outstanding tasks for the I_T_L nexus identified by the LUN field in the ABORT TASK SET TMF Request PDU.
中止任务集：由中止任务集TMF Request PDU中的LUN字段标识的I_T_L连接的所有未完成任务。
CLEAR TASK SET: All outstanding tasks in the task set for the LU identified by the LUN field in the CLEAR TASK SET TMF Request PDU. See [SPC3] for the definition of a "task set".
清除任务集：清除任务集TMF请求PDU中LUN字段标识的LU任务集中所有未完成的任务。有关“任务集”的定义，请参见[SPC3]。
LOGICAL UNIT RESET: All outstanding tasks from all initiators for the LU identified by the LUN field in the LOGICAL UNIT RESET Request PDU.
逻辑单元重置：逻辑单元重置请求PDU中LUN字段标识的LU所有启动器的所有未完成任务。
TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from all initiators across all LUs to which the TMF-issuing session has access on the SCSI target device hosting the iSCSI session.
目标热重设/目标冷重设：在托管iSCSI会话的SCSI目标设备上，TMF发出会话有权访问的所有LU中所有启动器的所有未完成任务。
Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text is an iSCSI TMF Request PDU with the "Function" field set to "ABORT TASK SET" as defined in [RFC3720]. Similar usage is employed for other scope descriptions.
用法：前文中的“中止任务集TMF请求PDU”是iSCSI TMF请求PDU，其“功能”字段设置为[RFC3720]中定义的“中止任务集”。其他范围描述也采用类似用法。
All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
所有iSCSI实施都必须支持本节中定义为默认行为的协议行为。中止任务集、清除任务集、逻辑单元重置、目标热重置和目标冷重置TMF请求的执行包括在指定方上按指定顺序执行以下操作序列。
The initiator iSCSI layer:
启动器iSCSI层：
a. MUST continue to respond to each TTT received for the affected tasks.
a. 必须继续响应针对受影响任务收到的每个TTT。
b. SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF response.
b. 应以正常方式处理收到的受影响任务的任何响应。这是可以接受的，因为保证在TMF响应之前发送响应。
c. SHOULD receive the TMF Response concluding all the tasks in the set of affected tasks unless the initiator has done something (e.g., LU reset, connection drop) that may prevent the TMF Response from being sent or received. The initiator MUST thus conclude all affected tasks as part of this step in either case, and MUST discard any TMF Response received after the affected tasks are concluded.
c. 应接收结束受影响任务集中所有任务的TMF响应，除非发起方已采取可能阻止发送或接收TMF响应的措施（如LU重置、连接断开）。因此，无论哪种情况，发起者都必须结束所有受影响的任务，作为该步骤的一部分，并且必须放弃在受影响的任务结束后收到的任何TMF响应。
The target iSCSI layer:
目标iSCSI层：
a. MUST wait for responses on currently valid target-transfer tags of the affected tasks from the issuing initiator. MAY wait for responses on currently valid target-transfer tags of the affected tasks from third-party initiators.
a. 必须等待发出启动器对受影响任务的当前有效目标传输标记的响应。可能会等待来自第三方启动器的受影响任务的当前有效目标传输标记的响应。
b. MUST wait (concurrent with the wait in Step a) for all commands of the affected tasks to be received based on the CmdSN ordering. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
b. 必须等待（与步骤a中的等待同时），才能根据CmdSN顺序接收受影响任务的所有命令。不应在受第三方影响的会话上等待新命令——只有实例化的任务才能确定受影响的任务。对于目标范围内的请求（即，目标温重设和目标冷重设），在命令流中的发出会话上尚未接收到的所有命令都可以被视为在没有命令等待期的情况下接收到——即，任务管理功能的CmdSN之前的整个CmdSN空间可以“堵塞”。
c. MUST propagate the TMF request to and receive the response from the target SCSI layer.
c. 必须将TMF请求传播到目标SCSI层并从中接收响应。
d. MUST provide the Response Fence behavior for the TMF Response on the issuing session as specified in Section 3.3.2.
d. 必须按照第3.3.2节的规定，在发布会话上为TMF响应提供响应围栏行为。
e. MUST provide the Response Fence behavior on the first post-TMF Response on third-party sessions as specified in Section 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses, then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
e. 必须按照第3.3.2节的规定，在第三方会话上的第一次TMF后响应上提供响应围栏行为。如果某些任务源自非iSCSI I_T_L nexuses，则目标公司确保所有受影响的任务已将其状态返回到启动器的方式由特定的非iSCSI传输协议定义。
Technically, the TMF servicing is complete in Step d. Data transfers corresponding to terminated tasks may however still be in progress on third-party iSCSI sessions even at the end of Step e. The TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step d, and MAY be sent at the end of Step d despite these outstanding data transfers until after Step e.
从技术上讲，TMF维修在步骤d中完成。但是，即使在步骤e结束时，第三方iSCSI会话上也可能仍在进行与已终止任务相对应的数据传输。在步骤d结束之前，目标iSCSI层不得发送TMF响应，并且可以在步骤d结束时发送TMF响应，尽管在步骤e之后仍有这些未完成的数据传输。
Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
本节中定义的协议行为必须由符合本文档要求的所有iSCSI实现来实现。本节中定义的协议行为必须由iSCSI会话上的iSCSI实现在该会话上协商TaskReporting（第9.1节）键到“FastAbort”时显示。中止任务集、清除任务集、逻辑单元重置、目标热重置和目标冷重置TMF请求的执行包括在指定方上按指定顺序执行以下操作序列。
The initiator iSCSI layer:
启动器iSCSI层：
a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target.
a. 一旦TMF被发送到目标，就不能在发出iSCSI会话的发出连接上为受影响的任务向PDU发送更多数据。
b. SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF response.
b. 应以正常方式处理收到的受影响任务的任何响应。这是可以接受的，因为保证在TMF响应之前发送响应。
c. MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1.
c. 必须使用第8.1节中定义的AsyncEvent=5响应每个异步消息PDU。
d. MUST treat the TMF response as terminating all affected tasks for which responses have not been received, and MUST discard any responses for affected tasks received after the TMF response is passed to the SCSI layer (although the semantics
d. 必须将TMF响应视为终止尚未收到响应的所有受影响任务，并且必须放弃在TMF响应传递到SCSI层后收到的受影响任务的任何响应（尽管
defined in this section ensure that such an out-of-order scenario will never happen with a compliant target implementation).
本节中定义了确保这种无序场景不会在符合要求的目标实现中发生）。
The target iSCSI layer:
目标iSCSI层：
a. MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
a. 必须等待根据发出会话上的CmdSN顺序接收受影响任务的所有命令。不应在受第三方影响的会话上等待新命令——只有实例化的任务才能确定受影响的任务。对于目标范围内的请求（即，目标温重设和目标冷重设），在命令流中的发出会话上尚未接收到的所有命令都可以被视为在没有命令等待期的情况下接收到——即，任务管理功能的CmdSN之前的整个CmdSN空间都可以“插入”。
b. MUST propagate the TMF request to and receive the response from the target SCSI layer.
b. 必须将TMF请求传播到目标SCSI层并从中接收响应。
c. MUST leave all active "affected TTTs" (i.e., active TTTs associated with affected tasks) valid.
c. 必须使所有活动的“受影响的TTT”（即与受影响任务关联的活动TTT）保持有效。
d. MUST send an Asynchronous Message PDU with AsyncEvent=5 (Section 8.1) on:
d. 必须在以下位置发送AsyncEvent=5（第8.1节）的异步消息PDU：
i) each connection of each third-party session to which at least one affected task is allegiant if TaskReporting=FastAbort is operational on that third-party session, and
i) 如果TaskReporting=FastAbort在该第三方会话上运行，则至少有一个受影响任务是allegiant的每个第三方会话的每个连接，以及
ii) each connection except the issuing connection of the issuing session that has at least one allegiant affected task.
ii）每个连接，但至少有一个allegiant受影响任务的发布会话的发布连接除外。
If there are multiple affected LUs (say, due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task. The LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
如果存在多个受影响的LU（例如，由于目标重置），则必须为至少有一个allegiant受影响任务的每个连接上的每个此类LU发送一条异步消息PDU。异步消息PDU中的LUN字段必须设置为与每个此类LU的LUN相匹配。
e. MUST address the Response Fence flag on the TMF Response on the issuing session as defined in Section 3.3.2.
e. 必须按照第3.3.2节的规定，在发布会话上处理TMF响应上的响应围栏标志。
f. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in Section 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses, then the
f. 必须按照第3.3.2节中的定义，在第三方会话的第一次TMF后响应上注明响应围栏标志。如果某些任务源于非iSCSI I\u\L连接，则
means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
目标公司确保所有受影响的任务都已将其状态返回到启动器的方式由特定的非iSCSI传输协议定义。
g. MUST free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once it receives each associated NOP-Out acknowledgement that the initiator generated in response to each Async Message.
g. 一旦收到启动器响应每个异步消息生成的每个相关NOP Out确认，必须释放受影响的TTT（和STAG，如果适用）和相应的缓冲区（如果有）。
Technically, the TMF servicing is complete in Step e. Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step f. A TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step e, and MAY be sent at the end of Step e despite these outstanding Data transfers until Step g. Step g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers.
从技术上讲，TMF维修在步骤e中完成。然而，即使在步骤f结束时，与终止的任务相对应的数据传输也可能仍在进行中。在步骤e结束之前，目标iSCSI层不得发送TMF响应，并且可以在步骤e结束时发送TMF响应，尽管在步骤g之前存在这些未完成的数据传输。步骤g指定一个事件来释放可能已保留以支持未完成数据传输的任何此类资源。
Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU resets on "Incomplete TTTs" as "Y". This meant that a target warm reset or a target cold reset or an LU reset would clear the active TTTs upon completion. However, the TaskReporting=FastAbort (Section 9.1) semantics defined by this section do not guarantee that the active TTTs are cleared by the end of the reset operations. In fact, the new semantics are designed to allow clearing the TTTs in a "lazy" fashion after the TMF Response is delivered. Thus, when TaskReporting=FastAbort is operational on a session, the clearing effects of reset operations on "Incomplete TTTs" is "N".
[RFC3720]的附录F.1规定了目标和LU重置对“不完整TTT”的清除效果为“Y”。这意味着目标热复位、目标冷复位或LU复位将在完成时清除活动TTT。但是，本节定义的TaskReporting=FastAbort（第9.1节）语义不能保证在重置操作结束时清除活动TTT。事实上，新语义的设计允许在TMF响应传递后以“惰性”方式清除TTT。因此，当TaskReporting=FastAbort在会话上运行时，重置操作对“不完整TTT”的清除效果为“N”。
If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality (Section 9.1), it may end up in a situation where some sessions have TaskReporting=RFC3720 operational (RFC 3720 sessions) while some other sessions have TaskReporting=FastAbort operational (FastAbort sessions) even while accessing a shared set of affected tasks (Section 4.1.1).
如果iSCSI目标实现能够支持TaskReporting=FastAbort功能（第9.1节），则可能会出现以下情况：某些会话的TaskReporting=RFC3720可操作（RFC 3720会话），而某些其他会话的TaskReporting=FastAbort可操作（FastAbort会话）即使在访问一组受影响的共享任务时（第4.1.1节）。
If the issuing session is an RFC 3720 session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is a FastAbort session, the following behavior SHOULD be exhibited by the iSCSI target layer:
如果发出会话是RFC 3720会话，iSCSI目标实现支持FastAbort，并且受影响的第三方会话是FastAbort会话，则iSCSI目标层应显示以下行为：
a. Between Steps c and d of the target behavior in Section 4.1.2, send an Asynchronous Message PDU with AsyncEvent=5 (Section 8.1) on each connection of each third-party session to which at least one affected task is allegiant. If there are multiple
a. 在第4.1.2节中目标行为的步骤c和d之间，在至少有一个受影响任务是allegiant的每个第三方会话的每个连接上发送异步消息PDU，其中AsyncEvent=5（第8.1节）。如果有多个
affected LUs, then send one Async Message PDU for each such LU on each connection that has at least one allegiant affected task. When sent, the LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
受影响的LU，然后在至少有一个allegiant受影响任务的每个连接上为每个此类LU发送一条异步消息PDU。发送时，异步消息PDU中的LUN字段必须设置为与每个此类LU的LUN相匹配。
b. After Step e of the target behavior in Section 4.1.2, free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once each associated NOP-Out acknowledgement is received that the third-party initiator generated in response to each Async Message sent in Step a.
b. 在第4.1.2节中目标行为的步骤e之后，一旦收到第三方启动器响应步骤a中发送的每个异步消息而生成的每个相关NOP Out确认，则释放受影响的TTT（和STAG，如果适用）和相应的缓冲区（如果有）。
If the issuing session is a FastAbort session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is an RFC 3720 session, the following behavior MUST be exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST NOT be sent on the third-party session to prompt the FastAbort behavior.
如果发出会话是FastAbort会话，iSCSI目标实现支持FastAbort，并且受影响的第三方会话是RFC 3720会话，则iSCSI目标层必须显示以下行为：不得在第三方会话上发送异步消息PDU以提示FastAbort行为。
If the third-party affected session is a FastAbort session and the issuing session is a FastAbort session, the initiator in the third-party role MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1. Note that an initiator MAY thus receive these Async Messages on a third-party affected session even if the session is a single-connection session.
如果受第三方影响的会话是FastAbort会话，而发出会话是FastAbort会话，则第三方角色的启动器必须按照第8.1节中的定义，以AsyncEvent=5响应每个异步消息PDU。请注意，即使会话是单个连接会话，启动器也可能因此在受影响的第三方会话上接收这些异步消息。
Both in clarified semantics (Section 4.1.2) and updated semantics (Section 4.1.3), there may be outstanding data transfers even after the TMF completion is reported on the issuing session. In the case of iSCSI/iSER [iSER], these would be tagged data transfers for STags not owned by any active tasks. Whether or not real buffers support these data transfers is implementation-dependent. However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases. A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-Out sequences (Section 4.1.2) or NOP-Out acknowledgements (Section 4.1.3) so as to reclaim the associated buffer, STag, and TTT resources as appropriate.
在澄清的语义（第4.1.2节）和更新的语义（第4.1.3节）中，即使在发布会话上报告TMF完成后，也可能存在未完成的数据传输。在iSCSI/iSER[iSER]的情况下，这些将被标记为不属于任何活动任务的STAG的数据传输。实际缓冲区是否支持这些数据传输取决于实现。但是，在任何情况下，目标iSCSI层都必须以静默方式放弃逻辑上的数据传输。在实现定义的内部超时上，目标还可以选择丢弃其未接收到预期数据输出序列（第4.1.2节）或NOP输出确认（第4.1.3节）的连接，以便酌情回收相关的缓冲区、STag和TTT资源。
There are fundamentally three basic objectives behind the semantics specified in Sections 4.1.2 and 4.1.3.
第4.1.2节和第4.1.3节中规定的语义背后有三个基本目标。
1. Maintaining an ordered command flow I_T nexus abstraction to the target SCSI layer even with multi-connection sessions.
1. 即使使用多连接会话，也要维护到目标SCSI层的有序命令流连接抽象。
o Target iSCSI processing of a TMF request must maintain the single flow illusion. Target behavior in Step b of Section 4.1.2 and Step a of Section 4.1.3 correspond to this objective.
o TMF请求的目标iSCSI处理必须保持单流错觉。第4.1.2节步骤b和第4.1.3节步骤a中的目标行为与该目标相对应。
2. Maintaining a single ordered response flow I_T nexus abstraction to the initiator SCSI layer even with multi-connection sessions when one response (i.e., TMF response) could imply the status of other unfinished tasks from the initiator's perspective.
2. 当一个响应（即TMF响应）可能从启动器的角度暗示其他未完成任务的状态时，即使使用多个连接会话，也要维护到启动器SCSI层的单个有序响应流I_T nexus抽象。
o The target must ensure that the initiator does not see "old" task responses (that were placed on the wire chronologically earlier than the TMF Response) after seeing the TMF response. The target behavior in Step d of Section 4.1.2 and Step e of Section 4.1.3 correspond to this objective.
o 目标必须确保启动器在看到TMF响应后不会看到“旧”任务响应（按时间顺序放置在TMF响应之前的连线上）。第4.1.2节步骤d和第4.1.3节步骤e中的目标行为与该目标相对应。
o Whenever the result of a TMF action is visible across multiple I_T_L nexuses, [SAM2] requires the SCSI device server to trigger a UA on each of the other I_T_L nexuses. Once an initiator is notified of such an UA, the application client on the receiving initiator is required to clear its task state (clause 5.5 in [SAM2]) for the affected tasks. It would thus be inappropriate to deliver a SCSI Response for a task after the task state is cleared on the initiator, i.e., after the UA is notified. The UA notification contained in the first SCSI Response PDU on each affected Third-party I_T_L nexus after the TMF action thus MUST NOT pass the affected task responses on any of the iSCSI sessions accessing the LU. The target behavior in Step e of Section 4.1.2 and Step f of Section 4.1.3 correspond to this objective.
o 每当TMF操作的结果在多个I_T_L nexus中可见时，[SAM2]要求SCSI设备服务器在每个其他I_T_L nexus上触发UA。一旦启动器收到此类UA的通知，接收启动器上的应用程序客户端需要清除受影响任务的任务状态（SAM2中的第5.5条）。因此，在启动器上清除任务状态之后，即在通知UA之后，为任务发送SCSI响应是不合适的。因此，在TMF操作之后，每个受影响的第三方I_T_L nexus上的第一个SCSI响应PDU中包含的UA通知不得在访问LU的任何iSCSI会话上传递受影响的任务响应。第4.1.2节步骤e和第4.1.3节步骤f中的目标行为与该目标相对应。
3. Draining all active TTTs corresponding to affected tasks in a deterministic fashion.
3. 以确定性方式排空与受影响任务对应的所有活动TTT。
o Data-Out PDUs with stale TTTs arriving after the tasks are terminated can create a buffer management problem even for traditional iSCSI implementations, and is fatal for the connection for iSCSI/iSER implementations. Either the termination of affected tasks should be postponed until the TTTs are retired (as in Step a of Section 4.1.2), or the TTTs and the buffers should stay allocated beyond task termination to be deterministically freed up later (as in Steps c and g of Section 4.1.3).
o 任务终止后到达的带有过时TTT的数据输出PDU可能会产生缓冲区管理问题，即使对于传统的iSCSI实施，这对于iSCSI/iSER实施的连接也是致命的。受影响任务的终止应推迟到TTT退役（如第4.1.2节步骤a所述），或者TTT和缓冲区应在任务终止后继续分配，以便稍后确定释放（如第4.1.3节步骤c和g所述）。
The only other notable optimization is the plugging. If all tasks on an I_T nexus will be aborted anyway (as with a target reset), there
唯一其他值得注意的优化是堵塞。如果I_T nexus上的所有任务仍将中止（如目标重置），则
is no need to wait to receive all commands to plug the CmdSN holes. The target iSCSI layer can simply plug all missing CmdSN slots and move on with TMF processing. The first objective (maintaining a single ordered command flow) is still met with this optimization because the target SCSI layer only sees ordered commands.
无需等待接收所有命令以堵塞CmdSN孔。目标iSCSI层可以简单地插入所有缺失的CmdSN插槽，然后继续进行TMF处理。第一个目标（维护单个有序的命令流）仍然可以通过此优化实现，因为目标SCSI层只看到有序的命令。
The negotiation of the key ErrorRecoveryLevel is not required for Discovery sessions -- i.e., for sessions that negotiated "SessionType=Discovery" -- because the default value of 0 is necessary and sufficient for Discovery sessions. It is however possible that some legacy iSCSI implementations might attempt to negotiate the ErrorRecoveryLevel key on Discovery sessions. When such a negotiation attempt is made by the remote side, a compliant iSCSI implementation MUST propose a value of 0 (zero) in response. The operational ErrorRecoveryLevel for Discovery sessions thus MUST be 0. This naturally follows from the functionality constraints that [RFC3720] imposes on Discovery sessions.
发现会话不需要协商密钥ErrorRecoveryLevel，即协商“SessionType=Discovery”的会话，因为默认值0对于发现会话来说是必要且足够的。但是，某些旧式iSCSI实施可能会尝试在发现会话上协商ErrorRecoveryLevel密钥。当远程端进行此类协商尝试时，符合要求的iSCSI实施必须提出0（零）作为响应。因此，发现会话的operational ErrorRecoveryLevel必须为0。这自然源于[RFC3720]对发现会话施加的功能约束。
Discovery sessions are intended to be relatively short-lived. Initiators are not expected to establish multiple Discovery sessions to the same iSCSI Network Portal (see [RFC3720]). An initiator may use the same iSCSI Initiator Name and ISID when establishing different unique sessions with different targets and/or different portal groups. This behavior is discussed in Section 9.1.1 of [RFC3720] and is, in fact, encouraged as conservative reuse of ISIDs. The ISID RULE in [RFC3720] states that there must not be more than one session with a matching 4-tuple: <InitiatorName, ISID, TargetName, TargetPortalGroupTag>. While the spirit of the ISID RULE applies to Discovery sessions the same as it does for Normal sessions, note that some Discovery sessions differ from the Normal sessions in two important aspects:
发现会话的寿命相对较短。启动器不应建立到同一iSCSI网络入口的多个发现会话（请参阅[RFC3720]）。当使用不同的目标和/或不同的门户组建立不同的唯一会话时，启动器可以使用相同的iSCSI启动器名称和ISID。[RFC3720]第9.1.1节讨论了这种行为，事实上，作为ISID的保守重用，鼓励这种行为。[RFC3720]中的ISID规则规定，具有匹配4元组的会话不得超过一个：<InitiatorName，ISID，TargetName，TargetPortalGroupTag>。虽然ISID规则的精神适用于发现会话，与适用于正常会话的精神相同，但请注意，某些发现会话在两个重要方面与正常会话不同：
Because [RFC3720] allows a Discovery session to be established without specifying a TargetName key in the Login Request PDU (let us call such a session an "Unnamed" Discovery session), there is no Target Node context to enforce the ISID RULE.
由于[RFC3720]允许在登录请求PDU中不指定TargetName密钥的情况下建立发现会话（让我们将此类会话称为“未命名”发现会话），因此没有目标节点上下文来强制执行ISID规则。
Portal Groups are defined only in the context of a Target Node. When the TargetName key is NULL-valued (i.e., not specified), the TargetPortalGroupTag thus cannot be ascertained to enforce the ISID RULE.
门户组仅在目标节点的上下文中定义。当TargetName键为空值（即未指定）时，无法确定TargetPortalGroupTag以强制执行ISID规则。
The following sections describe the two scenarios -- Named Discovery sessions and Unnamed Discovery sessions -- separately.
以下各节分别描述了两种场景——命名发现会话和未命名发现会话。
For Unnamed Discovery sessions, neither the TargetName nor the TargetPortalGroupTag is available to the targets in order to enforce the ISID RULE. So the following rule applies.
对于未命名的发现会话，目标无法使用TargetName或TargetPortalGroupTag来强制执行ISID规则。因此，以下规则适用。
UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the following 4-tuple for Unnamed Discovery sessions: <InitiatorName, ISID, NULL, TargetAddress>. The following semantics are implied by this uniqueness requirement.
未命名ISID规则：目标必须为未命名发现会话强制以下4元组的唯一性：<InitiatorName，ISID，NULL，TargetAddress>。此唯一性要求隐含了以下语义。
Targets SHOULD allow concurrent establishment of one Discovery session with each of its Network Portals by the same initiator port with a given iSCSI Node Name and an ISID. Each of the concurrent Discovery sessions, if established by the same initiator port to other Network Portals, MUST be treated as independent sessions -- i.e., one session MUST NOT reinstate the other.
目标应允许通过具有给定iSCSI节点名称和ISID的同一启动器端口与其每个网络入口同时建立一个发现会话。如果每个并发发现会话由同一启动器端口建立到其他网络门户，则必须将其视为独立会话——即，一个会话不得恢复另一个会话。
A new Unnamed Discovery session that has a matching <InitiatorName, ISID, NULL, TargetAddress> to an existing Discovery session MUST reinstate the existing Unnamed Discovery session. Note thus that only an Unnamed Discovery session may reinstate an Unnamed Discovery session.
如果新的未命名发现会话与现有发现会话具有匹配的<InitiatorName，ISID，NULL，TargetAddress>，则必须恢复现有的未命名发现会话。因此请注意，只有未命名的发现会话可以恢复未命名的发现会话。
For a Named Discovery session, the TargetName key is specified by the initiator and thus the target can unambiguously ascertain the TargetPortalGroupTag as well. Since all the four elements of the 4- tuple are known, the ISID RULE MUST be enforced by targets with no changes from [RFC3720] semantics. A new session with a matching <InitiatorName, ISID, TargetName, TargetPortalGroupTag> thus will reinstate an existing session. Note in this case that any new iSCSI session (Discovery or Normal) with the matching 4-tuple may reinstate an existing Named Discovery iSCSI session.
对于命名发现会话，TargetName密钥由启动器指定，因此目标也可以明确地确定TargetPortalGroupTag。由于4元组的所有四个元素都是已知的，因此目标必须在不改变[RFC3720]语义的情况下强制执行ISID规则。因此，具有匹配的<InitiatorName、ISID、TargetName、TargetPortalGroupTag>的新会话将恢复现有会话。请注意，在这种情况下，任何具有匹配的4元组的新iSCSI会话（发现或正常）都可能恢复现有的命名发现iSCSI会话。
Targets SHOULD NOT send any responses other than a Text Response and Logout Response on a Discovery session, once in Full Feature Phase.
一旦处于完整功能阶段，目标不应在发现会话上发送除文本响应和注销响应以外的任何响应。
Implementation Note: A target may simply drop the connection in a Discovery session when it would have requested a Logout via an Async Message on Normal sessions.
实现说明：当目标在正常会话上通过异步消息请求注销时，它可以在发现会话中简单地断开连接。
[SAM2] and [SAM3] specifications incorrectly note in their informative text that TPGT value should be non-zero, although [RFC3720] allows the value of zero for TPGT. This section is to clarify that a zero value is expressly allowed as a legal value for TPGT. This discrepancy currently stands corrected in [SAM4].
[SAM2]和[SAM3]规范在其信息性文本中错误地指出TPGT值应为非零，尽管[RFC3720]允许TPGT值为零。本节旨在澄清明确允许零值作为TPGT的法定值。该差异目前在[SAM4]中得到纠正。
During the Login Phase, the SessionType key is offered by the initiator to choose the type of session it wants to create with the target. The target may accept or reject the offer. Depending on the type of the session, a target may decide on resources to allocate and the security to enforce, etc. for the session. If the SessionType key is thus going to be offered as "Discovery", it SHOULD be offered in the initial Login request by the initiator.
在登录阶段，发起方提供SessionType键，以选择要与目标创建的会话类型。目标公司可以接受或拒绝报价。根据会话的类型，目标可能决定会话要分配的资源和要实施的安全性等。如果SessionType密钥因此将作为“发现”提供，则发起人应在初始登录请求中提供该密钥。
[RFC3720] defines NotUnderstood as a valid answer during a negotiation text key exchange between two iSCSI nodes. NotUnderstood has the reserved meaning that the sending side did not understand the proposed key semantics. This section seeks to clarify that NotUnderstood is a valid answer for both declarative and negotiated keys. The general iSCSI philosophy is that comprehension precedes processing for any iSCSI key. A proposer of an iSCSI key, negotiated or declarative, in a text key exchange MUST thus be able to properly handle a NotUnderstood response.
[RFC3720]将NotUnderstanding定义为两个iSCSI节点之间协商文本密钥交换期间的有效答案。NotUnderstand具有保留的含义，即发送端不理解提议的密钥语义。本节旨在澄清NotUnderstand对于声明性密钥和协商密钥都是有效的答案。iSCSI的一般原理是，对任何iSCSI密钥的处理都要先理解。因此，在文本密钥交换中协商或声明iSCSI密钥的提议者必须能够正确处理未理解的响应。
The proper way to handle a NotUnderstood response depends on where the key is specified and whether the key is declarative vs. negotiated. All keys defined in [RFC3720] MUST be supported by all compliant implementations; a NotUnderstood answer on any of the [RFC3720] keys therefore MUST be considered a protocol error and handled accordingly. For all other later keys, a NotUnderstood answer concludes the negotiation for a negotiated key whereas for a declarative key, a NotUnderstood answer simply informs the declarer of a lack of comprehension by the receiver.
处理NotUnderstanding响应的正确方法取决于指定密钥的位置以及密钥是声明性的还是协商的。[RFC3720]中定义的所有密钥必须得到所有兼容实现的支持；因此，任何[RFC3720]密钥上的未理解答案必须视为协议错误，并进行相应处理。对于以后的所有其他密钥，NotUnderstanding的答案结束协商密钥的协商，而对于声明性密钥，NotUnderstanding的答案只是通知声明方接收方不理解。
In either case, a NotUnderstood answer always requires that the protocol behavior associated with that key not be used within the scope of the key (connection/session) by either side.
在任何一种情况下，一个不可理解的答案总是要求与该密钥相关联的协议行为不在任何一方的密钥（连接/会话）范围内使用。
There was some uncertainty around the number of outstanding Login Response PDUs on a connection. [RFC3720] offers the analogy of SCSI linked commands to Login and Text negotiations in Sections 5.3 and 10.10.3, respectively, but does not make it fully explicit. This section is to offer a clarification in this regard.
连接上未完成的登录响应PDU的数量存在一些不确定性。[RFC3720]分别在第5.3节和第10.10.3节中提供了SCSI链接命令与登录和文本协商的类比，但没有完全明确。本节将对此进行澄清。
There MUST NOT be more than one outstanding Login Request, Login Response, Text Request, or Text Response PDU on an iSCSI connection. An outstanding PDU in this context is one that has not been acknowledged by the remote iSCSI side.
iSCSI连接上不能有多个未完成的登录请求、登录响应、文本请求或文本响应PDU。在此上下文中，未完成的PDU是远程iSCSI端尚未确认的PDU。
An ITT value of 0xffffffff is reserved and MUST NOT be assigned for a task by the initiator. The only instance in which it may be seen on the wire is in a target-initiated NOP-In PDU (and in the initiator response to that PDU, if necessary). Section 10.19 in [RFC3720] mentions this in passing but is noted here again to make it obvious since the semantics apply to the initiators in general.
ITT值0xFFFFFF为保留值，且启动器不得为任务分配该值。在线路上可以看到的唯一实例是在PDU中由目标启动的NOP中（以及在对该PDU的启动器响应中，如有必要）。[RFC3720]中的第10.19节顺便提到了这一点，但这里再次指出这一点是为了让它变得明显，因为语义通常适用于启动器。
Section 6.6 of [RFC3720] discusses format error handling. This section elaborates on the "inconsistent" PDU field contents noted in [RFC3720].
[RFC3720]第6.6节讨论了格式错误处理。本节详细说明了[RFC3720]中指出的“不一致”PDU字段内容。
All initiator-detected PDU construction errors MUST be considered as format errors. Some examples of such errors are:
所有启动器检测到的PDU构造错误都必须视为格式错误。此类错误的一些示例如下：
- NOP-In with a valid TTT but an invalid LUN
- NOP In具有有效的TTT，但LUN无效
- NOP-In with a valid ITT (i.e., a NOP-In response) and also a valid TTT
- NOP In带有有效的ITT（即NOP响应）和有效的TTT
- SCSI Response PDU with Status=CHECK CONDITION, but DataSegmentLength = 0
- SCSI响应PDU，状态=检查条件，但数据段长度=0
Section 6.7 of [RFC3720] discusses digest error handling. It states that "No further action is necessary for initiators if the discarded PDU is an unsolicited PDU (e.g., Async, Reject)" on detecting a payload digest error. This is incorrect.
[RFC3720]的第6.7节讨论了摘要错误处理。它指出，“如果丢弃的PDU是未经请求的PDU（例如，异步、拒绝）”，则在检测到有效负载摘要错误时，“发起方无需采取进一步行动”。这是不正确的。
An Asynchronous Message PDU or a Reject PDU carries the next StatSN value on an iSCSI connection, advancing the StatSN. When an initiator discards one of these PDUs due to a payload digest error, the entire PDU including the header MUST be discarded. Consequently, the initiator MUST treat the exception like a loss of any other solicited response PDU -- i.e., it MUST use one of the following options noted in [RFC3720]:
异步消息PDU或拒绝PDU在iSCSI连接上携带下一个StatSN值，从而推进StatSN。当启动器由于有效负载摘要错误而丢弃其中一个PDU时，必须丢弃整个PDU（包括标头）。因此，发起者必须将异常视为任何其他请求响应PDU的丢失——即，发起者必须使用[RFC3720]中说明的以下选项之一：
a) Request PDU retransmission with a status SNACK.
a) 请求PDU重新传输，并显示状态信息。
b) Logout the connection for recovery and continue the tasks on a different connection instance.
b) 注销连接以进行恢复，然后在其他连接实例上继续执行任务。
c) Logout to close the connection (abort all the commands associated with the connection).
c) 注销以关闭连接（中止与连接关联的所有命令）。
There has been some uncertainty on the extent to which incoming messages have to be checked for protocol errors, beyond what is strictly required for processing the inbound message. This section addresses this question.
除了处理入站消息所严格要求的范围外，还存在一些不确定性，即必须在多大程度上检查入站消息是否存在协议错误。本节讨论这个问题。
Unless [RFC3720] or this document requires it, an iSCSI implementation is not required to do an exhaustive protocol conformance check on an incoming iSCSI PDU. The iSCSI implementation especially is not required to double-check the remote iSCSI implementation's conformance to protocol requirements.
除非[RFC3720]或本文档要求，否则无需iSCSI实施即可对传入的iSCSI PDU执行详尽的协议一致性检查。特别是iSCSI实施不需要仔细检查远程iSCSI实施是否符合协议要求。
This section defines additional semantics for the Asynchronous Message PDU defined in Section 10.9 of [RFC3720] using the same conventions.
本节使用相同的约定为[RFC3720]第10.9节中定义的异步消息PDU定义了附加语义。
The following new legal value for the AsyncEvent is defined:
定义了AsyncEvent的以下新法律值：
5: all active tasks for LU with a matching LUN field in the Async Message PDU are being terminated.
5:正在终止异步消息PDU中具有匹配LUN字段的LU的所有活动任务。
The receiving initiator iSCSI layer MUST respond to this Message by taking the following steps in order.
接收启动器iSCSI层必须依次采取以下步骤响应此消息。
i) Stop Data-Out transfers on that connection for all active TTTs for the affected LUN quoted in the Async Message PDU.
i) 停止异步消息PDU中引用的受影响LUN的所有活动TTT在该连接上的数据输出传输。
ii) Acknowledge the StatSN of the Async Message PDU via a NOP-Out PDU with ITT=0xffffffff (i.e., non-ping flavor), while copying the LUN field from the Async Message to NOP-Out.
ii）通过NOP Out PDU确认异步消息PDU的StatSN，ITT=0xffffffff（即非ping风格），同时将LUN字段从异步消息复制到NOP Out。
The new AsyncEvent defined in this section however MUST NOT be used on an iSCSI session unless the new TaskReporting text key defined in Section 9.1 was negotiated to FastAbort on the session.
但是，本节中定义的新AsyncEvent不能用于iSCSI会话，除非第9.1节中定义的新TaskReporting文本键已协商为会话上的FastAbort。
Section 10.17.1 of [RFC3720] specifies the Reject reason code of 0x0b with an explanation of "Negotiation Reset". At this point, we do not see any legitimate iSCSI protocol use case for using this reason code. Thus, reason code 0x0b MUST be considered as deprecated and MUST NOT be sent by implementations that comply with the requirements of this document. An implementation receiving reason code 0x0b MUST treat it as a negotiation failure that terminates the Login Phase and the TCP connection, as specified in Section 6.10 of [RFC3720].
[RFC3720]第10.17.1节规定了0x0b的拒绝原因代码，并解释了“协商重置”。此时，我们看不到任何使用此原因码的合法iSCSI协议用例。因此，原因代码0x0b必须被视为已弃用，并且不得由符合本文档要求的实现发送。按照[RFC3720]第6.10节的规定，接收原因代码0x0b的实现必须将其视为终止登录阶段和TCP连接的协商失败。
Section 5.4 of [RFC3720] states:
[RFC3720]第5.4节规定：
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).
在任何协商序列中，发起者和目标都不应在没有干预操作参数协商重置的情况下多次尝试声明或协商参数，除非响应明确允许重复密钥声明的特定密钥（例如TargetAddress）。
The deprecation of reason code 0x0b eliminates the possibility of an operational parameter negotiation reset, causing the phrase "without an intervening operational parameter negotiation reset" in [RFC3720] to refer to an impossible event. The quoted phrase SHOULD be ignored by receivers that handle reason code 0x0b in the manner specified in this section.
原因代码0x0b的弃用消除了操作参数协商重置的可能性，导致[RFC3720]中的短语“无干预操作参数协商重置”指的是不可能发生的事件。以本节规定的方式处理原因代码0x0b的接收者应忽略引用的短语。
This section follows the same conventions as Section 12 of [RFC3720].
本节遵循与[RFC3720]第12节相同的惯例。
Use: LO Senders: Initiator and Target Scope: SW
使用：本地发送器：启动器和目标作用域：SW
Irrelevant when: SessionType=Discovery
TaskReporting=<list-of-values>
Irrelevant when: SessionType=Discovery
TaskReporting=<list-of-values>
Default is RFC3720. Result function is AND.
默认值为RFC3720。结果函数为和。
This key is used to negotiate the task completion reporting semantics from the SCSI target. The following table describes the semantics that an iSCSI target MUST support for respective negotiated key values. Whenever this key is negotiated, at least the RFC3720 and ResponseFence values MUST be offered as options by the negotiation originator.
此键用于协商SCSI目标的任务完成报告语义。下表描述了iSCSI目标必须支持各自协商键值的语义。每当协商此密钥时，协商发起人必须至少提供RFC3720和ResponseFence值作为选项。
+--------------+------------------------------------------+
| Name | Description |
+--------------+------------------------------------------+
| RFC3720 | RFC 3720-compliant semantics. Response |
| | fencing is not guaranteed and fast |
| | completion of multi-task aborting is not |
| | supported |
+--------------+------------------------------------------+
| ResponseFence| Response Fence (Section 3.3.1) semantics |
| | MUST be supported in reporting task |
| | completions |
+--------------+------------------------------------------+
| FastAbort | Updated fast multi-task abort semantics |
| | defined in Section 4.1.3 MUST be |
| | supported. Support for Response Fence is|
| | implied -- i.e., Section 3.3.1 semantics |
| | MUST be supported as well |
+--------------+------------------------------------------+
+--------------+------------------------------------------+
| Name | Description |
+--------------+------------------------------------------+
| RFC3720 | RFC 3720-compliant semantics. Response |
| | fencing is not guaranteed and fast |
| | completion of multi-task aborting is not |
| | supported |
+--------------+------------------------------------------+
| ResponseFence| Response Fence (Section 3.3.1) semantics |
| | MUST be supported in reporting task |
| | completions |
+--------------+------------------------------------------+
| FastAbort | Updated fast multi-task abort semantics |
| | defined in Section 4.1.3 MUST be |
| | supported. Support for Response Fence is|
| | implied -- i.e., Section 3.3.1 semantics |
| | MUST be supported as well |
+--------------+------------------------------------------+
When TaskReporting is not negotiated to FastAbort, the [RFC3720] TMF semantics as clarified in Section 4.1.2 MUST be used.
当TaskReporting未协商为FastAbort时，必须使用第4.1.2节中阐明的[RFC3720]TMF语义。
This document does not introduce any new security considerations other than those already noted in [RFC3720]. Consequently, all the iSCSI-related security text in [RFC3723] is also directly applicable to this document.
除了[RFC3720]中已经提到的安全注意事项外，本文件不引入任何新的安全注意事项。因此，[RFC3723]中所有与iSCSI相关的安全文本也直接适用于本文档。
This document creates the following iSCSI-related registries for IANA to manage.
本文档创建了以下与iSCSI相关的注册表，供IANA管理。
1. iSCSI Opcodes
1. iSCSI操作码
2. iSCSI Login/Text Keys
2. iSCSI登录/文本密钥
3. iSCSI Asynchronous Events
3. iSCSI异步事件
4. iSCSI Task Management Function Codes
4. iSCSI任务管理功能代码
5. iSCSI Login Response Status Codes
5. iSCSI登录响应状态代码
6. iSCSI Reject Reason Codes
6. iSCSI拒绝原因代码
7. iSER Opcodes
7. iSER操作码
Each of the following sections describes a registry, its sub-registries if any, and their administration policies in more detail. IANA has registered what this document calls the main "registries" as sub-registries of a larger iSCSI registry. However, wherever registry-to-sub-registry relationships are specified by this document, they have been preserved intact.
以下每一节都更详细地描述了注册表、其子注册表（如果有）及其管理策略。IANA已将本文档所称的主“注册表”注册为大型iSCSI注册表的子注册表。然而，无论本文档在何处指定了注册表到子注册表的关系，它们都保持不变。
[RFC3720] specifies three iSCSI-related registries -- extended key, authentication methods, and digests. This document recommends that these registries be published together with the registries defined by this document. Further, this document recommends that the three [RFC3720] registries be listed in between items 6 and 7 in the registry list above.
[RFC3720]指定三个与iSCSI相关的注册表--扩展密钥、身份验证方法和摘要。本文件建议将这些登记册与本文件定义的登记册一起公布。此外，本文件建议将三个[RFC3720]登记册列在上述登记册清单第6项和第7项之间。
Name of the registry: "iSCSI Opcodes"
注册表名称：“iSCSI操作码”
Namespace details: Numerical values that can fit in one octet with the most significant two bits (bits 0 and 1) already designated by [RFC3720], bit 0 being reserved and bit 1 for immediate delivery. Bit 2 is designated to identify the originator of the opcode. Bit 2 = 0 for initiator and Bit 2 = 1 for target.
名称空间详细信息：可以放入一个八位字节的数值，其中最高有效的两位（位0和1）已由[RFC3720]指定，位0保留，位1立即传递。位2用于识别操作码的发起人。对于启动器，位2=0；对于目标，位2=1。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
分配新值必须提供的信息：IESG批准的标准跟踪规范，定义了拟议新值的语义和互操作性要求以及要记录在注册表中的字段。
Allocation request guidance to requesters:
对申请者的分配申请指南：
1) If the initiator opcode and target opcode used to identify the request and response of a new type of protocol operation are requested, assign the same lower five bits (i.e., Bit 3 through Bit 7) for both opcodes, e.g., 0x13 and 0x33.
1) 如果请求用于识别新类型协议操作的请求和响应的启动器操作码和目标操作码，则为这两个操作码分配相同的低五位（即第3位到第7位），例如0x13和0x33。
2) If only the initiator opcode or target opcode is requested to identify a one-way protocol message (i.e., request without a response or a "response" without a request), assign an unused number from the appropriate category (i.e., Bit 2 set to 0 or 1 for initiator category or target category) and add the other pair member (i.e., same opcode with Bit 2 set to 1 or 0, respectively) to "no opcode pair is available" list.
2) 如果仅请求启动器操作码或目标操作码来识别单向协议消息（即，无响应的请求或无请求的“响应”），则从相应类别中分配一个未使用的编号（即，对于启动器类别或目标类别，位2设为0或1），并添加另一对成员（即，位2分别设置为1或0的相同操作码）至“无操作码对可用”列表。
3) If there are no other opcodes available in the appropriate "Reserved to IANA" list to assign on a request for a new opcode except the reserved opcodes in the "no opcode pair is available" list, allocate the opcode from the appropriate category (initiator or target) of the "no opcode pair is available" list.
3) 如果在请求新操作码时，除了“无操作码对可用”列表中的保留操作码外，相应的“保留给IANA”列表中没有其他操作码可供分配，则从“无操作码对可用”列表中的相应类别（启动器或目标）分配操作码。
Fields to record in the registry: Assigned value, Who can originate (Initiator or Target), Operation Name, and its associated RFC reference.
要在注册表中记录的字段：赋值、发起人（发起人或目标）、操作名称及其关联的RFC引用。
Initial registry contents:
初始注册表内容：
0x00, Initiator, NOP-Out, [RFC3720]
0x00，启动器，NOP输出，[RFC3720]
0x01, Initiator, SCSI Command, [RFC3720]
0x01，启动器，SCSI命令，[RFC3720]
0x02, Initiator, SCSI Task Management function request, [RFC3720]
0x02，启动器，SCSI任务管理功能请求[RFC3720]
0x03, Initiator, Login Request, [RFC3720]
0x03，启动器，登录请求，[RFC3720]
0x04, Initiator, Text Request, [RFC3720]
0x04，启动器，文本请求，[RFC3720]
0x05, Initiator, SCSI Data-Out, [RFC3720]
0x05，启动器，SCSI数据输出，[RFC3720]
0x06, Initiator, Logout Request, [RFC3720]
0x06，启动器，注销请求，[RFC3720]
0x10, Initiator, SNACK Request, [RFC3720]
0x10，发起人，零食请求，[RFC3720]
0x1c-0x1e, Initiator, Vendor specific codes, [RFC3720]
0x1c-0x1e，启动器，供应商特定代码，[RFC3720]
0x20, Target, NOP-In, [RFC3720]
0x20，目标，NOP输入，[RFC3720]
0x21, Target, SCSI Response, [RFC3720]
0x21，目标，SCSI响应，[RFC3720]
0x22, Target, SCSI Task Management function response, [RFC3720]
0x22，目标，SCSI任务管理功能响应[RFC3720]
0x23, Target, Login Response, [RFC3720]
0x23，目标，登录响应，[RFC3720]
0x24, Target, Text Response, [RFC3720]
0x24，目标，文本响应，[RFC3720]
0x25, Target, SCSI Data-In, [RFC3720]
0x25，目标，SCSI数据输入，[RFC3720]
0x26, Target, Logout Response, [RFC3720]
0x26，目标，注销响应，[RFC3720]
0x31, Target, Ready To Transfer (R2T), [RFC3720]
0x31，目标，准备传输（R2T），[RFC3720]
0x32, Target, Asynchronous Message, [RFC3720]
0x32，目标，异步消息[RFC3720]
0x3c-0x3e, Target, Vendor specific codes, [RFC3720]
0x3c-0x3e，目标，供应商特定代码，[RFC3720]
0x3f, Target, Reject, [RFC3720]
0x3f，目标，拒绝，[RFC3720]
Reserved to IANA: 0x07-0x0f, 0x13-0x1b (initiator codes) 0x27-0x2f, 0x33-0x3b (target codes)
保留给IANA的代码：0x07-0x0f、0x13-0x1b（启动器代码）0x27-0x2f、0x33-0x3b（目标代码）
No opcode pair is available: 0x11, 0x12, 0x1f (initiator codes) 0x30 (target codes)
没有可用的操作码对：0x11、0x12、0x1f（启动器代码）0x30（目标代码）
Allocation Policy:
分配政策：
Standards Action ([IANA]): This is required for defining the semantics of the opcode.
标准操作（[IANA]）：这是定义操作码语义所必需的。
Expert Review ([IANA]): This is required for selecting the specific opcode(s) to allocate in order to ensure compliance with the earlier "Allocation request guidance to requesters".
专家评审（[IANA]）：这是选择要分配的特定操作码所必需的，以确保符合先前的“请求者分配请求指南”。
Name of the registry: "iSCSI Text Keys"
注册表名称：“iSCSI文本键”
Namespace details: Key=value pairs with "Key" names in UTF-8 Unicode, and the permissible "value" options for the "Key" are Key-dependent. [RFC3720] defines the rules on key names and allowed values.
命名空间详细信息：Key=value对，具有UTF-8 Unicode格式的“Key”名称，“Key”允许的“value”选项取决于键。[RFC3720]定义键名称和允许值的规则。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new Key per [RFC3720] key specification template and the fields to be recorded in the registry.
分配新值必须提供的信息：IESG批准的标准跟踪规范，根据[RFC3720]密钥规范模板定义拟议新密钥的语义和互操作性要求，以及要记录在注册表中的字段。
Assignment policy:
派遣政策：
If the requested Key name is not already assigned and is roughly representative of its proposed semantics, it may be assigned to the requester.
如果请求的密钥名称尚未分配，并且大致代表其建议的语义，则可以将其分配给请求者。
Given the arbitrary nature of text strings, there is no maximum reserved by IANA for assignment in this registry.
鉴于文本字符串的任意性质，IANA没有为此注册表中的分配保留最大值。
Fields to record in the registry: Assigned Key Name and its associated RFC reference.
要在注册表中记录的字段：分配的键名及其关联的RFC引用。
Initial registry contents:
初始注册表内容：
AuthMethod, [RFC3720]
AuthMethod[RFC3720]
HeaderDigest, [RFC3720]
HeaderDigest，[RFC3720]
DataDigest, [RFC3720]
数据摘要，[RFC3720]
MaxConnections, [RFC3720]
MaxConnections，[RFC3720]
SendTargets, [RFC3720]
发送目标，[RFC3720]
TargetName, [RFC3720]
TargetName，[RFC3720]
InitiatorName, [RFC3720]
启动器名称，[RFC3720]
TargetAlias, [RFC3720]
TargetAlias，[RFC3720]
InitiatorAlias, [RFC3720]
倡议书[RFC3720]
TargetAddress, [RFC3720]
目标地址，[RFC3720]
TargetPortalGroupTag, [RFC3720]
TargetPortalGroupTag[RFC3720]
InitialR2T, [RFC3720]
首字母R2T，[RFC3720]
ImmediateData, [RFC3720]
即时数据，[RFC3720]
MaxRecvDataSegmentLength, [RFC3720]
MaxRecvDataSegmentLength，[RFC3720]
MaxBurstLength, [RFC3720]
最大长度，[RFC3720]
FirstBurstLength, [RFC3720]
FirstBurstLength，[RFC3720]
DefaultTime2Wait, [RFC3720]
DefaultTime2Wait，[RFC3720]
DefaultTime2Retain, [RFC3720]
DefaultTime2Retain，[RFC3720]
MaxOutstandingR2T, [RFC3720]
MaxOutstandingR2T[RFC3720]
DataPDUInOrder, [RFC3720]
DataPDUInOrder，[RFC3720]
DataSequenceInOrder, [RFC3720]
数据序列编号[RFC3720]
ErrorRecoveryLevel, [RFC3720]
ErrorRecoveryLevel[RFC3720]
SessionType, [RFC3720]
会话类型，[RFC3720]
RDMAExtensions, [iSER]
RDMAExtensions，[iSER]
TargetRecvDataSegmentLength, [iSER]
TargetRecvDataSegmentLength，[iSER]
InitiatorRecvDataSegmentLength, [iSER]
InitiatorRecvDataSegmentLength[iSER]
MaxOutstandingUnexpectedPDUs, [iSER]
最大未预期PDU，[iSER]
TaskReporting, this document
任务报告，此文档
Allocation Policy:
分配政策：
Standards Action ([IANA])
标准行动（[IANA]）
Name of the registry: "iSCSI Asynchronous Events"
注册表名称：“iSCSI异步事件”
Namespace details: Numerical values that can fit in one octet.
名称空间详细信息：可以放入一个八位字节的数值。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new Event and the fields to be recorded in the registry.
分配新值必须提供的信息：IESG批准的标准跟踪规范，定义了拟议新事件的语义和互操作性要求以及要记录在注册表中的字段。
Assignment policy:
派遣政策：
If the requested value is not already assigned, it may be assigned to the requester.
如果请求的值尚未分配，则可以将其分配给请求者。
6-247: range reserved by IANA for assignment in this registry.
6-247：IANA保留用于在此注册表中分配的范围。
Fields to record in the registry: Assigned Event number, Description and its associated RFC reference.
要在注册表中记录的字段：分配的事件编号、描述及其关联的RFC引用。
Initial registry contents:
初始注册表内容：
0, SCSI Async Event, [RFC3720]
0，SCSI异步事件[RFC3720]
1, Logout Request, [RFC3720]
1、注销请求[RFC3720]
2, Connection drop notification, [RFC3720]
2、连接断开通知[RFC3720]
3, Session drop notification, [RFC3720]
3、会话丢弃通知[RFC3720]
4, Negotiation Request, [RFC3720]
4、谈判请求[RFC3720]
5, Task termination, this document
5、任务终止，本文件
248-254, Vendor-unique, this document
248-254，供应商唯一，本文件
255, Vendor-unique, [RFC3720]
255，供应商唯一，[RFC3720]
Allocation Policy:
分配政策：
Standards Action ([IANA])
标准行动（[IANA]）
Name of the registry: "iSCSI TMF Codes"
注册表名称：“iSCSI TMF代码”
Namespace details: Numerical values that can fit in 7 bits.
名称空间详细信息：可容纳7位的数值。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new Code and the fields to be recorded in the registry.
分配新值时必须提供的信息：IESG批准的标准跟踪规范，定义了拟议新代码的语义和互操作性要求以及要记录在注册表中的字段。
Assignment policy:
派遣政策：
If the requested value is not already assigned, it may be assigned to the requester.
如果请求的值尚未分配，则可以将其分配给请求者。
9-127: range reserved by IANA for assignment in this registry.
9-127：IANA保留用于在此注册表中分配的范围。
Fields to record in the registry: Assigned Code, Description, and its associated RFC reference.
要在注册表中记录的字段：分配的代码、说明及其关联的RFC引用。
Initial registry contents:
初始注册表内容：
1, ABORT TASK, [RFC3720]
1，中止任务[RFC3720]
2, ABORT TASK SET, [RFC3720]
2、中止任务集[RFC3720]
3, CLEAR ACA, [RFC3720]
3，清除ACA，[RFC3720]
4, CLEAR TASK SET, [RFC3720]
4、清除任务集[RFC3720]
5, LOGICAL UNIT RESET, [RFC3720]
5、逻辑单元复位[RFC3720]
6, TARGET WARM RESET, [RFC3720]
6，目标温复位，[RFC3720]
7, TARGET COLD RESET, [RFC3720]
7，目标冷复位，[RFC3720]
8, TASK REASSIGN, [RFC3720]
8、任务重新分配[RFC3720]
Allocation Policy:
分配政策：
Standards Action ([IANA])
标准行动（[IANA]）
Name of the registry: "iSCSI Login Response Status Codes"
注册表名称：“iSCSI登录响应状态代码”
Namespace details: Numerical values; Status-Class (one octet), Status-Detail (one octet) for each possible value of Status-Class except for Vendor-Unique Status-Class (0x0f).
名称空间详细信息：数值；状态类（一个八位字节）、状态类每个可能值的状态详细信息（一个八位字节），供应商唯一状态类（0x0f）除外。
Information that must be provided to assign a new value: An IESG-approved specification defining the semantics and interoperability requirements of the proposed new Code, its Status-Class affiliation (only if a new Status-Detail value is being proposed for a Status-Class), Status-Class definition (only if a new Status-Class is being proposed), and the fields to be recorded in the registry.
分配新值时必须提供的信息：IESG批准的规范，定义了拟议新代码的语义和互操作性要求、其状态类从属关系（仅当为状态类提议新状态详细值时）、状态类定义（仅当提议新状态类时），以及要记录在注册表中的字段。
Assignment policy:
派遣政策：
If the requested value is not already assigned, it may be assigned to the requester.
如果请求的值尚未分配，则可以将其分配给请求者。
4-14 and 16-255: range reserved by IANA for assignment in this registry.
4-14和16-255：IANA保留用于在此注册表中分配的范围。
Fields to record in the Status-Class main registry: Assigned Code, Description, and its associated RFC reference.
要在状态类主注册表中记录的字段：分配的代码、说明及其关联的RFC引用。
Fields to record in the Status-Detail sub-registries: Status-Class, Assigned Code, Description, and its associated RFC reference.
要在状态详细信息子注册表中记录的字段：状态类、分配的代码、描述及其关联的RFC引用。
Initial registry contents (Status-Class):
初始注册表内容（状态类）：
0x00, Success, [RFC3720]
0x00，成功，[RFC3720]
0x01, Redirection, [RFC3720]
0x01，重定向，[RFC3720]
0x02, Initiator Error, [RFC3720]
0x02，启动器错误[RFC3720]
0x03, Target Error, [RFC3720]
0x03，目标错误[RFC3720]
0x0f, Vendor-Unique, this document
0x0f，供应商唯一，此文档
Initial sub-registry contents (Status-Detail for Status-Class=0x00):
初始子注册表内容（状态类的状态详细信息=0x00）：
0x00, 0x00, Success, [RFC3720]
0x00，0x00，成功，[RFC3720]
1-255: range reserved by IANA for assignment in Status-Class=0 sub-registry.
1-255:IANA为状态类=0子注册表中的分配保留的范围。
Initial sub-registry contents (Status-Detail for Status-Class=0x01):
初始子注册表内容（状态类的状态详细信息=0x01）：
0x01, 0x01, Temporary move, [RFC3720]
0x01，0x01，临时移动，[RFC3720]
0x01, 0x02, Permanent move, [RFC3720]
0x01，0x02，永久移动，[RFC3720]
3-255: range reserved by IANA for assignment in Status-Class=1 sub-registry.
3-255：IANA为状态类=1子注册表中的分配保留的范围。
Initial sub-registry contents (Status-Detail for Status-Class=0x02):
初始子注册表内容（状态类的状态详细信息=0x02）：
0x02, 0x00, Miscellaneous, [RFC3720]
0x02，0x00，杂项，[RFC3720]
0x02, 0x01, Authentication failure, [RFC3720]
0x02，0x01，身份验证失败，[RFC3720]
0x02, 0x02, Authorization failure, [RFC3720]
0x02，0x02，授权失败，[RFC3720]
0x02, 0x03, Not found, [RFC3720]
0x02，0x03，未找到[RFC3720]
0x02, 0x04, Target removed, [RFC3720]
0x02，0x04，目标已删除，[RFC3720]
0x02, 0x05, Unsupported version, [RFC3720]
0x02、0x05，不支持的版本，[RFC3720]
0x02, 0x06, Too many connections, [RFC3720]
0x02、0x06，连接太多，[RFC3720]
0x02, 0x07, Missing parameter, [RFC3720]
0x02、0x07，缺少参数[RFC3720]
0x02, 0x08, Can't include in session, [RFC3720]
0x02、0x08，不能包含在会话中[RFC3720]
0x02, 0x09, Unsupported session type, [RFC3720]
0x02，0x09，不支持的会话类型，[RFC3720]
0x02, 0x0a, Non-existent session, [RFC3720]
0x02，0x0a，不存在会话[RFC3720]
0x02, 0x0b, Invalid during login, [RFC3720]
0x02，0x0b，登录期间无效，[RFC3720]
12-255: range reserved by IANA for assignment in Status-Class=2 sub-registry.
12-255:IANA为状态类=2子注册表中的分配保留的范围。
Initial sub-registry contents (Status-Detail for Status-Class=0x03):
初始子注册表内容（状态类的状态详细信息=0x03）：
0x03, 0x00, Target error, [RFC3720]
0x03，0x00，目标错误[RFC3720]
0x03, 0x01, Service unavailable, [RFC3720]
0x03，0x01，服务不可用，[RFC3720]
0x03, 0x02, Out of resources, [RFC3720]
0x03，0x02，资源不足[RFC3720]
3-255: range reserved by IANA for assignment in Status-Class=3 sub-registry.
3-255：IANA为状态类=3子注册表中的分配保留的范围。
Allocation Policy:
分配政策：
Standards Action ([IANA])
标准行动（[IANA]）
Name of the registry: "iSCSI Reject Reason Codes"
注册表名称：“iSCSI拒绝原因代码”
Namespace details: Numerical values that can fit in a single octet.
名称空间详细信息：可以放入单个八位字节的数值。
Information that must be provided to assign a new value: A published specification defining the semantics and interoperability requirements of the proposed new Code and the fields to be recorded in the registry.
分配新值必须提供的信息：一个已发布的规范，定义了建议的新代码的语义和互操作性要求，以及要记录在注册表中的字段。
Assignment policy:
派遣政策：
If the requested value is not already assigned, it may be assigned to the requester.
如果请求的值尚未分配，则可以将其分配给请求者。
13-255: range reserved by IANA for assignment in this registry.
13-255:IANA保留用于在此注册表中分配的范围。
Fields to record in the registry: Assigned Code, Description, and its associated RFC reference.
要在注册表中记录的字段：分配的代码、说明及其关联的RFC引用。
Initial registry contents:
初始注册表内容：
0x01, Reserved, [RFC3720]
0x01，保留[RFC3720]
0x02, Data digest error, [RFC3720]
0x02，数据摘要错误[RFC3720]
0x03, SNACK Reject, [RFC3720]
0x03，零食拒收，[RFC3720]
0x04, Protocol Error, [RFC3720]
0x04，协议错误[RFC3720]
0x05, Command not supported, [RFC3720]
0x05，不支持命令[RFC3720]
0x06, Immediate command reject, [RFC3720]
0x06，立即命令拒绝[RFC3720]
0x07, Task in progress, [RFC3720]
0x07，任务进行中，[RFC3720]
0x08, Invalid data ack, [RFC3720]
0x08，无效数据确认[RFC3720]
0x09, Invalid PDU field, [RFC3720]
0x09，无效的PDU字段[RFC3720]
0x0a, Long op reject, [RFC3720]
0x0a，长op拒绝[RFC3720]
0x0b, "Deprecated reason code", this document
0x0b，“不推荐使用的原因代码”，此文档
0x0c, Waiting for Logout, [RFC3720]
0x0c，正在等待注销，[RFC3720]
Allocation Policy:
分配政策：
Standards Action ([IANA])
标准行动（[IANA]）
Name of the registry: "iSER Opcodes"
注册表名称：“iSER操作码”
Namespace details: Numerical values that can fit in 4 bits.
名称空间详细信息：可以容纳4位的数值。
Information that must be provided to assign a new value: An IESG-approved specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
分配新值必须提供的信息：IESG批准的规范，该规范定义了拟议新值的语义和互操作性要求以及要记录在注册表中的字段。
Assignment policy:
派遣政策：
If the requested value is not already assigned, it may be assigned to the requester.
如果请求的值尚未分配，则可以将其分配给请求者。
4-15: range reserved by IANA for assignment in this registry.
4-15：IANA保留用于在此注册表中分配的范围。
Fields to record in the registry: Assigned value, Operation Name, and its associated RFC reference.
要在注册表中记录的字段：赋值、操作名称及其关联的RFC引用。
Initial registry contents:
初始注册表内容：
0x1, iSCSI control-type, [iSER]
0x1，iSCSI控制类型，[iSER]
0x2, iSER Hello, [iSER]
0x2，iSER你好，[iSER]
0x3, iSER HelloReply, [iSER]
0x3，iSER HelloReply，[iSER]
Allocation Policy:
分配政策：
Standards Action ([IANA])
标准行动（[IANA]）
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720]Satran，J.，Meth，K.，Sapuntzakis，C.，Chadalapaka，M.，和E.Zeidner，“互联网小型计算机系统接口（iSCSI）”，RFC 3720，2004年4月。
[SPC3] ANSI INCITS 408-2005, SCSI Primary Commands-3.
[SPC3]ANSI INCITS 408-2005，SCSI主命令-3。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
[iSER]Ko，M.，Chadalapaka，M.，Hufferd，J.，Elzur，U.，Shah，H.，和P.Thaler，“用于远程直接内存访问（RDMA）的互联网小型计算机系统接口（iSCSI）扩展”，RFC 50462007年10月。
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[RFC3721]Bakke，M.，Hafner，J.，Hufferd，J.，Voruganti，K.，和M.Krueger，“互联网小型计算机系统接口（iSCSI）命名和发现”，RFC 37212004年4月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723]Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.，和F.Travostino，“通过IP保护块存储协议”，RFC 37232004年4月。
[RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[RFC3722]Bakke，M.，“互联网小型计算机系统接口（iSCSI）名称的字符串配置文件”，RFC 3722，2004年4月。
[SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-2).
[SAM2]ANSI INCITS 366-2003，SCSI体系结构模型2（SAM-2）。
[SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM-a3).
[SAM3]ANSI INCITS 402-2005，SCSI体系结构模型3（SAM-a3）。
[SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM-4), Work in Progress.
[SAM4]T10项目：1683-D，SCSI体系结构模型4（SAM-4），正在进行中。
Acknowledgements
致谢
The IP Storage (IPS) Working Group in the Transport Area of the IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group.
IETF传输领域的IP存储（IPS）工作组负责定义iSCSI协议（除一系列其他相关IP存储协议外）。编辑感谢整个工作组的贡献。
The following individuals directly contributed to identifying [RFC3720] issues and/or suggesting resolutions to the issues clarified in this document: David Black, Gwendal Grignou, Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh Gupta, Eddy Quicksall, Paul Koning. This document benefited from all of these contributions.
以下个人直接参与了确定[RFC3720]问题和/或对本文件中澄清的问题提出解决方案：大卫·布莱克、格温达尔·格里尼奥、迈克·高、德米特里·福米切夫、比尔·斯图登蒙德、肯·桑达尔、鲍勃·拉塞尔、朱利安·萨特兰、罗伯·埃利奥特、约瑟夫·皮特曼、萨默什·古普塔、艾迪·Quicksall、保罗·科宁。本文件得益于所有这些贡献。
Editor's Address
编辑地址
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd. Roseville, CA 95747-5668, USA Phone: +1-916-785-5621 EMail: cbm@rose.hp.com
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd。美国加利福尼亚州罗斯维尔95747-5668电话：+1-916-785-5621电子邮件：cbm@rose.hp.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.