Network Working Group M. Chadalapaka
Request for Comments: 3783 R. Elliott
Category: Informational Hewlett-Packard Co.
May 2004
Network Working Group M. Chadalapaka
Request for Comments: 3783 R. Elliott
Category: Informational Hewlett-Packard Co.
May 2004
Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI
使用iSCSI的小型计算机系统接口（SCSI）命令排序注意事项
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
Internet Small Computer Systems Interface (iSCSI) is a Small Computer Systems Interface (SCSI) transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the classic SCSI "I_T nexus", which represents the logical relationship between an Initiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI.
Internet小型计算机系统接口（iSCSI）是一种小型计算机系统接口（SCSI）传输协议，旨在运行在TCP之上。iSCSI会话抽象相当于经典的SCSI“I_T nexus”，它表示通过SCSI协议系列进行通信所需的启动器和目标（I和T）之间的逻辑关系。iSCSI会话提供从SCSI启动器到SCSI目标的有序命令传递。本文档介绍了导致今天定义的iSCSI会话模型的设计注意事项，将T10规范中定义的SCSI命令排序功能与iSCSI概念联系起来，最后就如何基于iSCSI构建真正的命令排序解决方案向系统设计人员提供指导。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the iSCSI Protocol . . . . . . . . . . . . . . . . 4
3.1. Protocol Mapping Description . . . . . . . . . . . . . . 4
3.2. The I_T Nexus Model. . . . . . . . . . . . . . . . . . . 5
3.3. Ordered Command Delivery . . . . . . . . . . . . . . . . 6
3.3.1. Questions. . . . . . . . . . . . . . . . . . . . 6
3.3.2. The Session Guarantee. . . . . . . . . . . . . . 6
3.3.3. Ordering Onus. . . . . . . . . . . . . . . . . . 7
3.3.4. Design Intent. . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the iSCSI Protocol . . . . . . . . . . . . . . . . 4
3.1. Protocol Mapping Description . . . . . . . . . . . . . . 4
3.2. The I_T Nexus Model. . . . . . . . . . . . . . . . . . . 5
3.3. Ordered Command Delivery . . . . . . . . . . . . . . . . 6
3.3.1. Questions. . . . . . . . . . . . . . . . . . . . 6
3.3.2. The Session Guarantee. . . . . . . . . . . . . . 6
3.3.3. Ordering Onus. . . . . . . . . . . . . . . . . . 7
3.3.4. Design Intent. . . . . . . . . . . . . . . . . . 7
4. The Command Ordering Scenario. . . . . . . . . . . . . . . . . 8
4.1. SCSI Layer . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Command Reference Number (CRN) . . . . . . . . . 8
4.1.2. Task Attributes. . . . . . . . . . . . . . . . . 8
4.1.3. Auto Contingent Allegiance (ACA) . . . . . . . . 8
4.1.4. UA Interlock . . . . . . . . . . . . . . . . . . 9
4.2. iSCSI Layer. . . . . . . . . . . . . . . . . . . . . . . 9
5. Connection Failure Considerations. . . . . . . . . . . . . . . 9
6. Command Ordering System Considerations . . . . . . . . . . . . 10
7. Reservation Considerations . . . . . . . . . . . . . . . . . . 11
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
9. References and Bibliography. . . . . . . . . . . . . . . . . . 12
9.1. Normative References.. . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
4. The Command Ordering Scenario. . . . . . . . . . . . . . . . . 8
4.1. SCSI Layer . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Command Reference Number (CRN) . . . . . . . . . 8
4.1.2. Task Attributes. . . . . . . . . . . . . . . . . 8
4.1.3. Auto Contingent Allegiance (ACA) . . . . . . . . 8
4.1.4. UA Interlock . . . . . . . . . . . . . . . . . . 9
4.2. iSCSI Layer. . . . . . . . . . . . . . . . . . . . . . . 9
5. Connection Failure Considerations. . . . . . . . . . . . . . . 9
6. Command Ordering System Considerations . . . . . . . . . . . . 10
7. Reservation Considerations . . . . . . . . . . . . . . . . . . 11
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
9. References and Bibliography. . . . . . . . . . . . . . . . . . 12
9.1. Normative References.. . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
iSCSI is a SCSI transport protocol ([iSCSI]) designed to enable running SCSI application protocols on TCP/IP networks, including potentially the Internet. Given the size and scope of the Internet, iSCSI thus enables some exciting new SCSI applications. Potential new application areas for exploiting iSCSI's value include the following:
iSCSI是一种SCSI传输协议（[iSCSI]），旨在支持在TCP/IP网络（可能包括Internet）上运行SCSI应用程序协议。鉴于Internet的规模和范围，iSCSI因此支持一些激动人心的新SCSI应用程序。利用iSCSI价值的潜在新应用领域包括：
a) Larger (diameter) Storage Area Networks (SANs) than had been possible until now b) Asynchronous remote mirroring c) Remote tape vaulting
a) 比现在更大（直径）的存储区域网络（SAN）b）异步远程镜像c）远程磁带保险存储
Each of these applications takes advantage of the practically unlimited geographical distance that iSCSI enables between a SCSI initiator and a SCSI target. In each of these cases, because of the long delays involved, there is a very high incentive for the initiator to stream SCSI commands back-to-back without waiting for the SCSI status of previous commands. Command streaming may be employed primarily by two classes of applications - while one class may not particularly care about ordered command execution, the other class does rely on ordered command execution (i.e. there is an application-level dependency on the ordering among SCSI commands). As an example, cases b) and c) listed earlier clearly require ordered command execution. A mirroring application does not want the writes to be committed out of order on the remote SCSI target, so as to
这些应用程序中的每一个都利用了iSCSI在SCSI启动器和SCSI目标之间几乎无限的地理距离。在上述每种情况下，由于所涉及的延迟时间很长，发起方都有很高的动机在不等待以前命令的SCSI状态的情况下背对背地传输SCSI命令。命令流主要可由两类应用程序使用-一类可能不特别关心命令的有序执行，另一类则依赖命令的有序执行（即，应用程序级依赖于SCSI命令之间的顺序）。例如，前面列出的情况b）和c）显然需要有序的命令执行。镜像应用程序不希望在远程SCSI目标上无序提交写操作，以便
preserve the transactional integrity of the data on that target. To summarize, SCSI command streaming, when coupled with the guarantee of ordered command execution on the SCSI target, is extremely valuable for a critical class of applications in long-latency networks.
保留该目标上数据的事务完整性。总之，SCSI命令流与保证在SCSI目标上有序执行命令相结合，对于长延迟网络中的一类关键应用程序来说非常有价值。
This document reviews the various protocol considerations in designing storage solutions that employ SCSI command ordering. This document also analyzes and explains the design intent of [iSCSI] with respect to command ordering.
本文档回顾了在设计采用SCSI命令排序的存储解决方案时的各种协议注意事项。本文档还分析和解释了[iSCSI]在命令排序方面的设计意图。
- I_T nexus: [SAM2] defines the I_T nexus as a relationship between a SCSI initiator port and a SCSI target port. [iSCSI] defines an iSCSI session as the iSCSI representation of an I_T nexus. In the iSCSI context, the I_T nexus (i.e. the iSCSI session) is a relationship between an iSCSI initiator's end of the session (SCSI Initiator Port) and the iSCSI target's Portal Group (SCSI Target Port).
- I_T nexus:[SAM2]将I_T nexus定义为SCSI启动器端口和SCSI目标端口之间的关系。[iSCSI]将iSCSI会话定义为I_T nexus的iSCSI表示。在iSCSI上下文中，I_T nexus（即iSCSI会话）是iSCSI启动器的会话结束（SCSI启动器端口）与iSCSI目标的门户组（SCSI目标端口）之间的关系。
- PDU (Protocol Data Unit): An iSCSI initiator and iSCSI target communicate using iSCSI protocol messages. These messages are called "iSCSI protocol data units" (iSCSI PDUs).
- PDU（协议数据单元）：iSCSI启动器和iSCSI目标使用iSCSI协议消息进行通信。这些消息称为“iSCSI协议数据单元”（iSCSI PDU）。
- SCSI device: A SCSI device is an entity that contains one or more SCSI ports that are connected to a service delivery subsystem and supports SCSI application protocols. In the iSCSI context, the SCSI Device is the component within an iSCSI Node that provides the SCSI functionality. The SCSI Device Name is defined to be the iSCSI Name of the node.
- SCSI设备：SCSI设备是包含一个或多个连接到服务交付子系统并支持SCSI应用程序协议的SCSI端口的实体。在iSCSI上下文中，SCSI设备是iSCSI节点中提供SCSI功能的组件。SCSI设备名称定义为节点的iSCSI名称。
- Session: A group of logically related iSCSI connections that link an initiator with a target form a session (equivalent to a SCSI I-T nexus). The number of participating iSCSI connections within an iSCSI session may vary over time. The multiplicity of connections at the iSCSI level is completely hidden for the SCSI layer - each SCSI port in an I_T nexus sees only one peer SCSI port across all the connections of a session.
- 会话：一组逻辑相关的iSCSI连接，将启动器与目标连接起来，形成会话（相当于SCSI I-T nexus）。iSCSI会话中参与的iSCSI连接数可能随时间而变化。iSCSI级别的连接的多样性对于SCSI层是完全隐藏的—I_T nexus中的每个SCSI端口在会话的所有连接中只能看到一个对等SCSI端口。
Acronym Definition
--------------------------------------------------------------
ACA Auto Contingent Allegiance
ASC Additional Sense Code
ASCQ Additional Sense Code Qualifier
CRN Command Reference Number
IETF Internet Engineering Task Force
ISID Initiator Session Identifier
ITT Initiator Task Tag
LU Logical Unit
LUN Logical Unit Number
NIC Network Interface Card
PDU Protocol Data Unit
TMF Task Management Function
TSIH Target Session Identifying Handle
SAN Storage Area Network
SCSI Small Computer Systems Interface
TCP Transmission Control Protocol
UA Unit Attention
WG Working Group
Acronym Definition
--------------------------------------------------------------
ACA Auto Contingent Allegiance
ASC Additional Sense Code
ASCQ Additional Sense Code Qualifier
CRN Command Reference Number
IETF Internet Engineering Task Force
ISID Initiator Session Identifier
ITT Initiator Task Tag
LU Logical Unit
LUN Logical Unit Number
NIC Network Interface Card
PDU Protocol Data Unit
TMF Task Management Function
TSIH Target Session Identifying Handle
SAN Storage Area Network
SCSI Small Computer Systems Interface
TCP Transmission Control Protocol
UA Unit Attention
WG Working Group
The iSCSI protocol is a mapping of the SCSI remote procedure invocation model (see [SAM2]) over the TCP protocol.
iSCSI协议是SCSI远程过程调用模型（参见[SAM2]）在TCP协议上的映射。
SCSI's notion of a task maps to an iSCSI task. Each iSCSI task is uniquely identified within that I_T nexus by a 32-bit unique identifier called Initiator Task Tag (ITT). The ITT is both an iSCSI identifier of the task and a classic SCSI task tag.
SCSI的任务概念映射到iSCSI任务。每个iSCSI任务都通过一个称为启动器任务标签（ITT）的32位唯一标识符在该I_T nexus中进行唯一标识。ITT既是任务的iSCSI标识符，也是典型的SCSI任务标记。
SCSI commands from the initiator to the target are carried in iSCSI requests called SCSI Command PDUs. SCSI status back to the initiator is carried in iSCSI responses called SCSI Response PDUs. SCSI Data-out from the initiator to the target is carried in SCSI Data-Out PDUs, and the SCSI Data-in back to the initiator is carried in SCSI Data-in PDUs.
从启动器到目标的SCSI命令在称为SCSI命令PDU的iSCSI请求中传输。SCSI状态返回到启动器是在称为SCSI响应PDU的iSCSI响应中进行的。从启动器输出到目标的SCSI数据在SCSI数据输出PDU中携带，返回到启动器的SCSI数据在PDU中的SCSI数据中携带。
In the iSCSI model, the SCSI I_T nexus maps directly to the iSCSI session, which is an iSCSI protocol abstraction spanning one or more TCP connections. The iSCSI protocol defines the semantics in order to realize one logical flow of bidirectional communication on the I_T nexus, potentially spanning multiple TCP connections (as many as 2^16). The multiplicity of iSCSI connections is thus completely contained at the iSCSI layer, while the SCSI layer is presented with a single I_T nexus, even in a multi-connection session. A session between a pair of given iSCSI nodes is identified by the session identifier (SSID) and each connection within a given session is uniquely identified by a connection identifier (CID) in iSCSI. The SSID itself has two components - Initiator Session Identifier (ISID) and a Target Session Identifying Handler (TSIH) - each identifying one end of the same session.
在iSCSI模型中，SCSI I_T nexus直接映射到iSCSI会话，该会话是跨越一个或多个TCP连接的iSCSI协议抽象。iSCSI协议定义了语义，以便在I_T nexus上实现一个双向通信逻辑流，可能跨越多个TCP连接（多达2^16）。因此，iSCSI连接的多样性完全包含在iSCSI层中，而SCSI层提供了单个I_T连接，即使在多连接会话中也是如此。一对给定iSCSI节点之间的会话由会话标识符（SSID）标识，给定会话中的每个连接由iSCSI中的连接标识符（CID）唯一标识。SSID本身有两个组件—启动器会话标识符（ISID）和目标会话标识处理程序（TSIH）—每个组件标识同一会话的一端。
There are four crucial functional facets of iSCSI that together present this single logical flow abstraction to the SCSI layer, even with an iSCSI session spanning across multiple iSCSI connections.
iSCSI有四个关键的功能方面，它们共同向SCSI层提供了这一单一的逻辑流抽象，即使iSCSI会话跨越多个iSCSI连接。
a) Ordered command delivery: A sequence of SCSI commands that is striped across all the connections in the session is "reordered" by the target iSCSI layer into an identical sequence based on a Command Sequence Number (CmdSN) that is unique across the session. The goal is to achieve bandwidth aggregation from multiple TCP connections, but to still make it appear to the target SCSI layer as if all the commands had travelled in one flow.
a) 有序命令传递：跨会话中的所有连接条带化的SCSI命令序列由目标iSCSI层根据整个会话中唯一的命令序列号（CmdSN）“重新排序”为相同的序列。我们的目标是从多个TCP连接实现带宽聚合，但仍使其在目标SCSI层中显示为所有命令都在一个流中传输。
b) Connection allegiance: All the PDU exchanges for a SCSI Command, up to and including the SCSI Response PDU for the Command, are required to flow on the same iSCSI connection at any given time. This again is intended to hide the multi-connection nature of a session because the SCSI layer on either side will never see the PDU contents out of order (e.g., status cannot bypass read data for an initiator).
b) 连接忠诚度：SCSI命令的所有PDU交换，包括命令的SCSI响应PDU，都需要在任何给定时间在同一iSCSI连接上流动。这同样是为了隐藏会话的多连接性质，因为任意一侧的SCSI层都不会看到PDU内容出现错误（例如，状态无法绕过启动器的读取数据）。
c) Task set management function handling: [iSCSI] specifies an ordered sequence of steps for the iSCSI layer on the SCSI target in handling the two SCSI task management functions (TMFs) that manage SCSI task sets. The two TMFs are ABORT TASK SET that aborts all active tasks in a session, and CLEAR TASK SET that clears the tasks in the task set. The goal of the sequence of steps is to guarantee that the initiator receives the SCSI Response PDUs of all unaffected tasks before the TMF Response itself arrives, regardless of the number of connections in the iSCSI session. This operational model is
c) 任务集管理功能处理：[iSCSI]为SCSI目标上的iSCSI层指定处理管理SCSI任务集的两个SCSI任务管理功能（TMF）的有序步骤序列。这两个TMF是中止会话中所有活动任务的中止任务集和清除任务集中任务的清除任务集。步骤序列的目标是确保启动器在TMF响应本身到达之前收到所有未受影响任务的SCSI响应PDU，而不管iSCSI会话中的连接数如何。这种运作模式是
again intended to preserve the single flow abstraction to the SCSI layer.
再次旨在保留对SCSI层的单流抽象。
d) Immediate task management function handling: Even when a TMF request is marked as "immediate" (i.e. only has a position in the command stream, but does not consume a CmdSN), [iSCSI] defines semantics that require the target iSCSI layer to ensure that the TMF request is executed as if the commands and the TMF request were all flowing on a single logical channel. This ensures that the TMF request will act on tasks that it was meant to manage.
d) 即时任务管理功能处理：即使TMF请求标记为“即时”（即仅在命令流中有一个位置，但不使用CmdSN），[iSCSI]定义要求目标iSCSI层确保执行TMF请求的语义，就像命令和TMF请求都在单个逻辑通道上流动一样。这确保了TMF请求将对其要管理的任务执行操作。
The following sections will analyze the "Ordered command delivery" aspect in more detail, since command ordering is the focus of this document.
以下各节将更详细地分析“有序命令交付”方面，因为命令排序是本文档的重点。
A couple of important questions related to iSCSI command ordering were considered early on in the design of the iSCSI protocol. The questions were:
在iSCSI协议的设计早期，考虑了与iSCSI命令顺序相关的两个重要问题。问题是：
a) What should be the command ordering behavior required of iSCSI implementations in the presence of transport errors, such as errors that corrupt the data in a fashion that is not detected by the TCP checksum (e.g., two offsetting bit flips in the same bit position), but is detected by the iSCSI CRC digest?
a) 在存在传输错误的情况下，iSCSI实施所需的命令排序行为应该是什么？例如，TCP校验和（例如，在同一位位置有两个偏移位翻转）检测不到但iSCSI CRC摘要检测到的损坏数据的错误？
b) Should [iSCSI] require both initiators and targets to use ordered command delivery?
b) [iSCSI]是否应该要求启动器和目标都使用有序的命令传递？
Since the answers to these questions are critical to the understanding of the ordering behavior required by the iSCSI protocol, the following sub-sections consider them in more detail.
由于这些问题的答案对于理解iSCSI协议所要求的排序行为是至关重要的，下面的子部分更详细地考虑它们。
The final disposition of question a) in section 3.3.1 was reflected in [RFC3347], "iSCSI MUST specify strictly ordered delivery of SCSI commands over an iSCSI session between an initiator/target pair, even in the presence of transport errors." Stated differently, an iSCSI digest failure, or an iSCSI connection termination, must not cause the iSCSI layer on a target to allow executing the commands in an order different from that intended (as indicated by the CmdSN order) by the initiator. This design choice is enormously helpful in building storage systems and solutions that can now always assume
第3.3.1节中问题a）的最终处理反映在[RFC3347]，“iSCSI必须指定在启动器/目标对之间的iSCSI会话上严格有序地传递SCSI命令，即使存在传输错误。”与此不同的是，iSCSI摘要故障或iSCSI连接终止，不得导致目标上的iSCSI层允许以不同于启动器预期的顺序（如CmdSN顺序所示）执行命令。这种设计选择在构建存储系统和解决方案方面非常有帮助，而这些存储系统和解决方案现在总是可以采用
command ordering to be a service characteristic of an iSCSI substrate.
命令排序是iSCSI基板的服务特征。
Note that by taking the position that an iSCSI session always guarantees command ordering, [iSCSI] was indirectly implying that the principal reason for the multi-connection iSCSI session abstraction was to allow ordered bandwidth aggregation for an I_T nexus. In deployment models where this cross-connection ordering mandated by [iSCSI] is deemed expensive, a serious consideration should be given to deploying multiple single-connection sessions instead.
请注意，通过采取iSCSI会话始终保证命令顺序的立场，[iSCSI]间接地意味着多连接iSCSI会话抽象的主要原因是允许I_T nexus的有序带宽聚合。在部署模型中，[iSCSI]强制执行的这种交叉连接订购被认为是昂贵的，因此应该认真考虑部署多个单连接会话。
The final resolution of b) in section 3.3.1 by the iSCSI protocol designers was in favor of not always requiring the initiators to use command ordering. This resolution is reflected in dropping the mandatory ACA usage requirement on the initiators, and allowing an ABORT TASK TMF to plug a command hole etc., since these are conscious choices an initiator makes in favor of not using ordered command delivery. The net result can be discerned by a careful reader of [iSCSI] - the onus of ensuring ordered command delivery is always on the iSCSI targets, while the initiators may or may not utilize command ordering. iSCSI targets, being the servers in the client-server model, do not really attempt to establish whether or not a client (initiator) intends to take advantage of command ordering service, but instead simply always provide the guaranteed delivery service. The rationale here is that there are inherent SCSI and application-level dependencies, as we shall see in building a command ordered solution, that are beyond the scope of [iSCSI], to mandate or even discern the intent with respect to the usage of command ordering.
iSCSI协议设计者在第3.3.1节中对b）的最终解决方案是不总是要求启动器使用命令排序。这一解决方案反映在取消对启动器的强制ACA使用要求，允许中止任务TMF堵塞命令漏洞等方面，因为这些都是启动器有意识地选择不使用有序命令传递。仔细阅读[iSCSI]可以看出最终结果——确保命令有序传递的责任始终在iSCSI目标上，而启动器可能会也可能不会利用命令顺序。作为客户机-服务器模型中的服务器，iSCSI目标并不真正尝试确定客户机（启动器）是否打算利用命令订购服务，而是始终提供有保证的交付服务。这里的基本原理是，正如我们将在构建命令排序解决方案时看到的那样，存在固有的SCSI和应用程序级依赖关系，这些依赖关系超出了[iSCSI]的范围，以强制执行或甚至识别命令排序的使用意图。
To summarize the design intent of [iSCSI]:
要总结[iSCSI]的设计意图，请执行以下操作：
The service delivery subsystem (see [SAM2]) abstraction provided by an iSCSI session is guaranteed to have the intrinsic property of ordered delivery of commands to the target SCSI layer under all conditions. Consequently, the guarantee of the ordered command delivery is across the entire I_T nexus spanning all the LUs that the nexus is authorized to access. It is the initiator's discretion as to whether or not this property will be used.
iSCSI会话提供的服务交付子系统（参见[SAM2]）抽象保证在所有条件下都具有命令有序交付到目标SCSI层的固有属性。因此，整个I_T nexus（跨越该nexus有权访问的所有LU）都可以保证有序的命令传递。发起人可自行决定是否使用此属性。
A storage systems designer working with SCSI and iSCSI has to consider the following protocol features in SCSI and iSCSI layers, each of which has a role to play in realizing the command ordering goal.
与SCSI和ISCSI一起工作的存储系统设计器必须考虑SCSI和ISCSI层中的以下协议特征，它们各自在实现命令排序目标中起作用。
The SCSI application layer has several tools to enforce ordering.
SCSI应用层有几个工具来执行排序。
CRN is an ordered sequence number which, when enabled for a device server, increments by one for each I_T_L nexus (see [SAM2]). The one notable drawback with CRN is that there is no SCSI-generic way (such as through mode pages) to enable or disable the CRN feature. [SAM2] also leaves the usage semantics of CRN for the SCSI transport protocol, such as iSCSI, to specify. [iSCSI] chose not to support the CRN feature for various reasons.
CRN是一个有序的序列号，当为设备服务器启用时，每个I_T_L nexus增加一个序列号（参见[SAM2]）。CRN的一个显著缺点是没有SCSI通用方式（如通过模式页面）来启用或禁用CRN功能。[SAM2]还将CRN的使用语义留给SCSI传输协议（如iSCSI）指定。[iSCSI]出于各种原因选择不支持CRN功能。
[SAM2] defines the following four task attributes - SIMPLE, ORDERED, HEAD OF QUEUE, and ACA. Each task to an LU may be assigned an attribute. [SAM2] defines the ordering constraints that each of these attributes conveys to the device server that is servicing the task. In particular, judicious use of ORDERED and SIMPLE attributes applied to a stream of pipelined commands could convey the precise execution schema for the commands that the initiator issues, provided the commands are received in the same order on the target.
[SAM2]定义了以下四个任务属性-简单、有序、队列头和ACA。可以为LU的每个任务分配一个属性。[SAM2]定义了这些属性中的每个属性传递给为任务提供服务的设备服务器的顺序约束。特别是，明智地使用应用于流水线命令流的有序和简单属性可以传达启动器发出的命令的精确执行模式，前提是命令在目标上以相同的顺序接收。
ACA is an LU-level condition that is triggered when a command (with the NACA bit set to 1) completes with CHECK CONDITION. When ACA is triggered, it prevents all commands other than those with the ACA attribute from executing until the CLEAR ACA task management function is executed, while blocking all the other tasks already in the task set. See [SAM2] for the detailed semantics of ACA. Since ACA is closely tied to the notion of a task set, one would ideally have to select the scope of the task set (by setting the TST bit to 1 in the control mode page of the LU) to be per-initiator in order to prevent command failures in one I_T_L nexus from impacting other I_T_L nexuses through ACA.
ACA是一种LU级条件，在命令（NACA位设置为1）完成检查条件时触发。触发ACA时，它会阻止除具有ACA属性的命令以外的所有命令执行，直到执行清除ACA任务管理功能，同时阻止任务集中已存在的所有其他任务。有关ACA的详细语义，请参见[SAM2]。由于ACA与任务集的概念密切相关，因此理想情况下必须选择每个启动器的任务集范围（通过在LU的控制模式页面中将TST位设置为1），以防止一个I__L连接中的命令故障通过ACA影响其他I__L连接。
When UA interlock is enabled, the logical unit does not clear any standard Unit Attention condition reported with autosense, and in addition, establishes a Unit Attention condition when a task is terminated with one of BUSY, TASK SET FULL, or RESERVATION CONFLICT statuses. This so-called "interlocked UA" is cleared only when the device server executes an explicit REQUEST SENSE ([SPC3]) command from the same initiator. From a functionality perspective, the scope of UA interlock today is slightly different from ACA's because it enforces ordering behavior for completion statuses other than CHECK CONDITION, but otherwise conceptually has the same design intent as ACA. On the other hand, ACA is somewhat more sophisticated because it allows special "cleanup" tasks (ones with ACA attribute) to execute when ACA is active. One of the principal reasons UA interlock came into being was that SCSI designers wanted a command ordering feature without the side effects of using the aforementioned TST bit in the control mode page.
启用UA联锁时，逻辑单元不会清除autosense报告的任何标准单元注意条件，此外，当任务以忙碌、任务集已满或保留冲突状态之一终止时，会建立单元注意条件。只有当设备服务器执行来自同一启动器的显式请求感知（[SPC3]）命令时，才会清除所谓的“联锁UA”。从功能角度来看，UA联锁的范围与ACA略有不同，因为它强制执行除检查条件外的完成状态的订购行为，但在概念上与ACA具有相同的设计意图。另一方面，ACA有些复杂，因为它允许在ACA处于活动状态时执行特殊的“清理”任务（具有ACA属性的任务）。UA interlock产生的主要原因之一是SCSI设计者希望命令排序功能不会因在控制模式页面中使用上述TST位而产生副作用。
As noted in section 3.2 and section 3.3, the iSCSI protocol enforces and guarantees ordered command delivery per iSCSI session using the CmdSN, and this is an attribute of the SCSI transport layer. Note further that any command ordering solution that seeks to realize ordering from the initiator SCSI layer to the target SCSI layer would be of practical value only when the command ordering is guaranteed by the SCSI transport layer. In other words, the related SCSI application layer protocol features such as ACA etc. are based on the premise of an ordered SCSI transport. Thus, iSCSI's command ordering is the last piece in completing the puzzle of building solutions that rely on ordered command execution, by providing the crucial guarantee that all the commands handed to the initiator iSCSI layer will be transported and handed to the target SCSI layer in the same order.
如第3.2节和第3.3节所述，iSCSI协议使用CmdSN强制并保证每个iSCSI会话的命令传递有序，这是SCSI传输层的一个属性。进一步注意，任何试图实现从启动器SCSI层到目标SCSI层的命令排序解决方案只有在SCSI传输层保证命令排序时才具有实用价值。换句话说，相关的SCSI应用层协议功能（如ACA等）基于有序SCSI传输的前提。因此，iSCSI的命令顺序是完成构建依赖命令执行顺序的解决方案之谜的最后一步，它提供了关键的保证，即传递给启动器iSCSI层的所有命令都将以相同的顺序传输并传递给目标SCSI层。
[iSCSI] mandates that when an iSCSI connection fails, the active tasks on that connection must be terminated if not recovered within a certain negotiated time limit. When an iSCSI target does terminate some subset of tasks due to iSCSI connection dynamics, there is a danger that the SCSI layer would simply move on to the next tasks waiting to be processed and execute them out-of-order unbeknownst to the initiator SCSI layer. To preclude this danger, [iSCSI] further mandates the following:
[iSCSI]规定，当iSCSI连接失败时，如果未在特定协商时间限制内恢复，则必须终止该连接上的活动任务。当iSCSI目标确实由于iSCSI连接动态而终止某些任务子集时，SCSI层可能会直接转到下一个等待处理的任务，并在启动器SCSI层不知情的情况下无序执行这些任务。为了避免这种危险，[iSCSI]进一步要求：
a) The tasks terminated due to the connection failure must be internally terminated by the iSCSI target "as if" due to a CHECK CONDITION. While this particular completion status is never communicated back to the initiator, the "as if" is still meaningful and required because if the initiator were using ACA as the command ordering mechanism of choice, a SCSI-level ACA will be triggered due to this mandatory CHECK CONDITION. This addresses the aforementioned danger.
a) 由于连接故障而终止的任务必须由iSCSI目标根据检查条件“如同”在内部终止。虽然此特定完成状态从未传回启动器，但“好像”仍然有意义且是必需的，因为如果启动器使用ACA作为选择的命令排序机制，则由于此强制检查条件，将触发SCSI级别的ACA。这解决了上述危险。
b) After the tasks are terminated due to the connection failure, the iSCSI target must report a Unit Attention condition on the next command processed on any connection for each affected I_T_L nexus of that session. This is required because if the initiator were using UA interlock as the command ordering mechanism of choice, a SCSI-level UA will trigger a UA-interlock. This again addresses the aforementioned danger. iSCSI targets must report this UA with the status of CHECK CONDITION, and the ASC/ASCQ value of 47h/7Fh ("SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT").
b) 由于连接失败而终止任务后，iSCSI目标必须在该会话的每个受影响的I\u T\L连接的任何连接上处理的下一个命令上报告单元注意情况。这是必需的，因为如果启动器使用UA互锁作为所选的命令排序机制，SCSI级别的UA将触发UA互锁。这再次解决了上述危险。iSCSI目标必须报告此UA的检查状态，ASC/ASCQ值为47h/7Fh（“某些命令被iSCSI协议事件清除”）。
In general, command ordering is automatically enforced if targets and initiators comply with the iSCSI specification. However, listed below are certain additional related implementation considerations for the iSCSI initiators and targets to take note of.
通常，如果目标和启动器符合iSCSI规范，则会自动执行命令排序。但是，下面列出了iSCSI启动器和目标需要注意的某些其他相关实施注意事项。
a) Even when all iSCSI and SCSI command ordering considerations earlier noted in this document were applied, it is beneficial for iSCSI initiators to proactively avoid scenarios that would otherwise lead to out-of-order command execution. This is simply because the SCSI command ordering features such as UA interlock are likely to be costlier in performance when they are allowed to be triggered. [iSCSI] provides enough guidance on how to implement this proactive detection of PDU ordering errors.
a) 即使应用了本文档前面提到的所有iSCSI和SCSI命令排序注意事项，iSCSI启动器也可以主动避免可能导致命令执行无序的情况。这仅仅是因为SCSI命令排序功能（如UA互锁）在允许触发时，其性能可能会更昂贵。[iSCSI]提供了有关如何实施PDU订购错误主动检测的足够指导。
b) The whole notion of command streaming does of course assume that the target in question supports command queueing. An iSCSI target desirous of supporting command ordering solutions should ensure that the SCSI layer on the target supports command queuing. The remote backup (tape vaulting) applications that iSCSI enables make an especially compelling case that tape devices should give a very serious consideration to supporting command queuing, at least when used in conjunction with iSCSI.
b) 当然，命令流的整个概念都假定所讨论的目标支持命令排队。希望支持命令排序解决方案的iSCSI目标应确保目标上的SCSI层支持命令队列。iSCSI支持的远程备份（磁带保险存储）应用程序特别令人信服，磁带设备应该非常认真地考虑支持命令队列，至少在与iSCSI结合使用时是如此。
c) An iSCSI target desirous of supporting high-performance command ordering solutions that involve specifying a description of execution schema should ensure that the SCSI layer on the target in fact does support the ORDERED and SIMPLE task attributes.
c) 希望支持涉及指定执行模式描述的高性能命令排序解决方案的iSCSI目标应确保目标上的SCSI层实际上支持有序和简单的任务属性。
d) There is some consideration of expanding the scope of UA interlock to encompass CHECK CONDITION status, and thus make it the only required command ordering functionality of implementations to build command ordering solutions. Until this is resolved in T10, the currently defined semantics of UA interlock and ACA warrant implementing both features by iSCSI targets desirous of supporting command ordering solutions.
d) 考虑将UA联锁的范围扩大到包括检查条件状态，从而使其成为构建命令排序解决方案的实现中唯一需要的命令排序功能。在T10中解决此问题之前，UA联锁和ACA的当前定义语义保证由希望支持命令排序解决方案的iSCSI目标实现这两个功能。
[iSCSI] describes a "principle of conservative reuse" that encourages iSCSI initiators to reuse the same ISIDs (see section 3.2) to various SCSI target ports, in order to present the same SCSI initiator port name to those target ports. This is in fact a very crucial implementation consideration that must be complied with. [SPC3] mandates the SCSI targets to associate persistent reservations and the related registrations with the SCSI initiator port names whenever they are required by the SCSI transport protocol. Since [iSCSI] requires the mandatory SCSI initiator port names based on ISIDs, iSCSI targets are required to work off the SCSI initiator port names, and thus indirectly the ISIDs, in enforcing the persistent reservations.
[iSCSI]描述了一种“保守重用原则”，鼓励iSCSI启动器将相同的ISID（见第3.2节）重用到各种SCSI目标端口，以便向这些目标端口提供相同的SCSI启动器端口名。事实上，这是一个必须遵守的非常关键的执行考虑。[SPC3]要求SCSI目标在SCSI传输协议要求时，将持久保留和相关注册与SCSI启动器端口名相关联。由于[iSCSI]需要基于ISID的强制性SCSI启动器端口名，因此iSCSI目标需要在实施持久保留时取消SCSI启动器端口名，从而间接取消ISID。
This fact has the following implications for the implementations:
这一事实对实施有以下影响：
a) If a persistent reservation/registration is intended to be used across multiple SCSI ports of a SCSI device, the initiator iSCSI implementation must use the same ISID across associated iSCSI sessions connecting to different iSCSI target portal groups of the SCSI device.
a) 如果打算跨SCSI设备的多个SCSI端口使用持久保留/注册，则启动器iSCSI实施必须在连接到SCSI设备的不同iSCSI目标门户组的关联iSCSI会话中使用相同的ISID。
b) If a persistent reservation/registration is intended to be used across the power loss of a SCSI target, the initiator iSCSI implementation must use the same ISIDs as before in re-establishing the associated iSCSI sessions upon subsequent reboot in order to rely on the persist through power loss capability.
b) 如果打算在SCSI目标断电时使用持久保留/注册，则启动器iSCSI实施必须使用与以前相同的ISID，以便在随后重新启动时重新建立关联的iSCSI会话，从而依赖持久通过断电功能。
For security considerations in using the iSCSI protocol, refer to the Security Considerations section in [iSCSI]. This document does not introduce any additional security considerations other than those already discussed in [iSCSI].
有关使用iSCSI协议时的安全注意事项，请参阅[iSCSI]中的安全注意事项部分。除[iSCSI]中已讨论的安全注意事项外，本文档不介绍任何其他安全注意事项。
[iSCSI] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M. and E. Zeidner, "Internet Small Computer Systems Inferface (iSCSI)", RFC 3720, May 2004.
[iSCSI]Satran，J.，Meth，K.，Sapuntzakis，C.，Chadalapaka，M.和E.Zeidner，“互联网小型计算机系统接口（iSCSI）”，RFC 3720，2004年5月。
[SAM2] ANSI INCITS.366:2003 SCSI Architecture Model - 2 (SAM-2).
[SAM2]ANSI INCITS.366:2003 SCSI体系结构模型-2（SAM-2）。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[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月。
[RFC3347] Krueger, M. and R. Haagens, "iSCSI Requirements and Design Considerations", RFC 3347, July 2002.
[RFC3347]Krueger，M.和R.Haagens，“iSCSI要求和设计注意事项”，RFC 3347，2002年7月。
[SPC3] INCITS T10/1416-D, SCSI Primary Commands-3 (SPC-3).
[SPC3]事件T10/1416-D，SCSI主命令-3（SPC-3）。
We are grateful to the IPS working group whose work defined the iSCSI protocol. Thanks also to David Black (EMC) who encouraged the publication of this document. Special thanks to Randy Haagens (HP) for his insights on the topic of command ordering. Thanks are also due to Elizabeth Rodriguez for carefully reviewing this document.
我们感谢IPS工作组，他们的工作定义了iSCSI协议。还要感谢David Black（EMC）鼓励发布本文档。特别感谢Randy Haagens（HP）对命令排序主题的见解。感谢Elizabeth Rodriguez仔细审阅本文件。
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd. Roseville, CA 95747-5668, USA
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd。美国加利福尼亚州罗斯维尔95747-5668
Phone: +1.916.785.5621
EMail: cbm@rose.hp.com
Phone: +1.916.785.5621
EMail: cbm@rose.hp.com
Rob Elliott Hewlett-Packard Company MC140801 PO Box 692000 Houston, TX 77269-2000 USA
Rob Elliott Hewlett-Packard Company MC140801美国德克萨斯州休斯顿692000邮箱77269-2000
Phone: +1.281.518.5037
EMail: elliott@hp.com
Phone: +1.281.518.5037
EMail: elliott@hp.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。