[要約] 要約：RFC 3783は、iSCSIにおけるSCSIコマンドの順序に関する考慮事項を提供しています。 目的：このRFCの目的は、iSCSI環境でのSCSIコマンドの正確な順序付けと処理を確保するためのガイドラインを提供することです。
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
Small Computer Systems Interface（SCSI）ISCSIを使用したコマンド注文の考慮事項
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）The Internet Society（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 Small Computer Systems Interface（ISCSI）は、TCPの上で実行されるように設計された小さなコンピューターシステムインターフェイス（SCSI）トランスポートプロトコルです。ISCSIセッションの抽象化は、SCSIファミリーのプロトコルを介して通信するために必要なイニシエーターとターゲット（IおよびT）との論理的な関係を表すクラシックSCSI「I_T Nexus」と同等です。ISCSIセッションは、SCSIイニシエーターからSCSIターゲットへの順序付けられたコマンド配信を提供します。このドキュメントは、今日定義されているISCSIセッションモデルにつながった設計上の考慮事項に入り、ISCSIの概念にT10仕様で定義されているSCSIコマンドの順序付け機能に関連し、最終的に真のコマンド順序付けソリューションがどのようにできるかについてシステムデザイナーにガイダンスを提供します。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
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は、インターネットを含むTCP/IPネットワークでSCSIアプリケーションプロトコルを実行できるように設計されたSCSIトランスポートプロトコル（[ISCSI]）です。インターネットのサイズと範囲を考えると、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) より大きな（直径）ストレージエリアネットワーク（SANS）これまで可能だったよりも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 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.
これらの各アプリケーションは、ISCSIがSCSIイニシエーターとSCSIターゲットの間で有効にする実質的に無制限の地理的距離を利用しています。これらの各ケースでは、長い遅延がかかるため、イニシエーターが以前のコマンドのSCSIステータスを待たずにSCSIコマンドを連続してストリーミングするための非常に高いインセンティブがあります。コマンドストリーミングは主に2つのクラスのアプリケーションによって採用される場合があります - 1つのクラスは順序付けられたコマンド実行に特に気にしない場合がありますが、もう1つのクラスは順序付けられたコマンド実行に依存しています（つまり、SCSIコマンド間の順序付けにアプリケーションレベルの依存関係があります）。例として、ケースb）およびc）以前にリストされたc）は、明確に順序付けられたコマンド実行が必要です。ミラーリングアプリケーションでは、そのターゲット上のデータのトランザクション整合性を維持するために、リモートSCSIターゲットに故障しないことを執筆することを望まない。要約すると、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 PDUS）と呼ばれます。
- 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アプリケーションプロトコルをサポートする1つ以上のSCSIポートを含むエンティティです。ISCSIコンテキストでは、SCSIデバイスは、SCSI機能を提供するISCSIノード内のコンポーネントです。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.
- セッション：イニシエーターとターゲットフォームAセッション（SCSI I-T Nexusに相当）をリンクする論理的に関連するISCSI接続のグループ。ISCSIセッション内の参加するISCSI接続の数は、時間とともに異なる場合があります。ISCSIレベルでの接続の多様性は、SCSIレイヤーに対して完全に隠されています。I_TNexusの各SCSIポートは、セッションのすべての接続にわたって1つのピア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
The iSCSI protocol is a mapping of the SCSI remote procedure invocation model (see [SAM2]) over the TCP protocol.
ISCSIプロトコルは、TCPプロトコルを介したSCSIリモートプロシージャの呼び出しモデル（[SAM2]を参照）のマッピングです。
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タスクは、I_T Nexus内で、Initiatorタスクタグ（ITT）と呼ばれる32ビットの一意の識別子によって一意に識別されます。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データインはイニシエーターに戻り、SCSIデータインPDUで運ばれます。
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は、1つ以上のTCP接続にまたがるISCSIプロトコル抽象化であるISCSIセッションに直接マッピングします。ISCSIプロトコルは、複数のTCP接続（最大2^16）にまたがる可能性があるI_T Nexusでの双方向通信の1つの論理的な流れを実現するために、セマンティクスを定義します。したがって、ISCSI接続の多様性はISCSI層に完全に含まれていますが、SCSI層には、マルチ接続セッションであっても、単一のI_T Nexusが表示されます。特定のISCSIノードのペア間のセッションは、セッション識別子（SSID）によって識別され、特定のセッション内の各接続は、ISCSIの接続識別子（CID）によって一意に識別されます。SSID自体には、イニシエーターセッション識別子（ISID）とターゲットセッション識別ハンドラー（TSIH）の2つのコンポーネントがあります。それぞれが同じセッションの片端を識別します。
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の4つの重要な機能的ファセットがあり、複数のISCSI接続にまたがるISCSIセッションでも、この単一の論理フロー抽象化をSCSI層に提示します。
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接続から帯域幅集約を実現することですが、すべてのコマンドが1つのフローで移動したかのように、ターゲット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 again intended to preserve the single flow abstraction to the SCSI layer.
c) タスクセット管理機能処理：[ISCSI] SCSIタスクセットを管理する2つのSCSIタスク管理関数（TMF）の処理において、SCSIターゲットのISCSIレイヤーの一連のステップシーケンスを指定します。2つのTMFは、セッションですべてのアクティブなタスクを中止する中止タスクセットと、タスクセットのタスクをクリアするクリアタスクセットです。一連の手順の目標は、ISCSIセッションの接続の数に関係なく、TMF応答自体が到着する前に、開始者が影響を受けていないすべてのタスクのSCSI応答PDUを受信することを保証することです。この運用モデルは、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) TCPチェックサムによって検出されないファッションでデータを破損するエラーなど、トランスポートエラーの存在下でISCSI実装に必要なコマンド順序付け動作とはどうなりますか（たとえば、同じビット位置で2つの相殺ビットフリップ）、しかし、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 command ordering to be a service characteristic of an iSCSI substrate.
質問a）セクション3.3.1の最終処分は[RFC3347]に反映されていました。違った方法で、ISCSIダイジェストの故障、またはISCSI接続終了は、ターゲット上のISCSI層を、イニシエーターが意図した（CMDSN順序で示されているように）とは異なる順序でコマンドを実行できるようにしてはなりません。この設計の選択は、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の最終解決策は、イニシエーターにコマンドの順序付けを常に要求することではないことを支持していました。この解像度は、イニシエーターの必須のACA使用要件を削除し、中止タスクTMFがコマンドホールなどを差し込むことを許可することに反映されています。[ISCSI]の慎重な読者によって最終的な結果を識別できます - 順序付けられたコマンド配信を保証する責任は常にISCSIターゲットにありますが、イニシエーターはコマンド順序を使用する場合と使用できない場合があります。ISCSIターゲットは、クライアントサーバーモデルのサーバーであるため、クライアント（イニシエーター）がコマンドオーダーングサービスを利用する予定かどうかを実際に確立しようとするのではなく、常に保証された配信サービスを提供します。ここでの理論的根拠は、コマンドの使用に関する範囲を超えて、[iSCSI]の範囲を超えたコマンド順序付きのソリューションを構築する際に見られるように、固有のSCSIとアプリケーションレベルの依存関係があるということです。注文。
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レイヤーに順序付けられたコマンドを配信する本質的なプロパティを持つことが保証されています。したがって、順序付けられたコマンド配信の保証は、Nexusがアクセスすることが許可されているすべてのLUSに及ぶI_T Nexus全体にわたってあります。このプロパティが使用されるかどうかについてのイニシエーターの裁量です。
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に対して1つずつ増加する順序付けされたシーケンス番号です（[sam2]を参照）。CRNの注目すべき欠点の1つは、CRN機能を有効または無効にするためのSCSI-GENERICの方法（モードページなど）がないことです。[SAM2]は、ISCSIなどのSCSI輸送プロトコルのCRNの使用セマンティクスも指定します。[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]は、次の4つのタスク属性を定義します - シンプル、順序付け、キューの責任者、および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は、コマンド（NACAビットが1に設定されている）がチェック条件で完了するとトリガーされるLUレベルの条件です。ACAがトリガーされると、ACA属性を持つもの以外のすべてのコマンドが実行されないようにし、ACAタスク管理関数が実行されるまで実行され、タスクセットに既に他のすべてのタスクをブロックします。ACAの詳細なセマンティクスについては、[SAM2]を参照してください。ACAはタスクセットの概念に密接に結びついているため、タスクセットの範囲を選択する必要があります（LUのコントロールモードページでTSTビットを1に設定することで）。1つのi_t_l Nexusのコマンド障害を防ぎ、ACAを介して他のI_T_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で報告された標準ユニットの注意条件をクリアせず、さらに、忙しいタスクセットフル、または予約競合ステータスのいずれかでタスクが終了する場合、ユニットの注意条件を確立します。このいわゆる「インターロックUA」は、デバイスサーバーが同じイニシエーターから明示的な要求センス（[SPC3]）コマンドを実行する場合にのみクリアされます。機能性の観点から見ると、今日のUAインターロックの範囲はACAとはわずかに異なります。これは、チェック条件以外の完了ステータスの順序付け動作を強制するため、概念的にはACAと同じ設計意図を持っています。一方、ACAは、ACAがアクティブなときに特別な「クリーンアップ」タスク（ACA属性を持つもの）が実行できるため、やや洗練されています。UAインターロックが生まれた主な理由の1つは、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輸送層によってコマンドの順序が保証されている場合にのみ実用的な価値があることに注意してください。言い換えれば、ACAなどなどの関連するSCSIアプリケーション層プロトコル機能は、順序付けられた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_T_Lネクサスの接続で処理された次のコマンドの単位注意条件を報告する必要があります。これは、イニシエーターが選択のコマンド順序付けメカニズムとしてUAインターロックを使用していた場合、SCSIレベルのUAがUAインターロックをトリガーするためです。これは再び前述の危険に対処します。ISCSIターゲットは、このUAをチェック条件のステータスと47H/7FHのASC/ASCQ値を報告する必要があります（「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開始者が順序外のコマンド実行につながるシナリオを積極的に回避することが有益です。これは、UAインターロックなどのSCSIコマンドの順序付け機能が、トリガーを許可されたときにパフォーマンスがコストがかかる可能性が高いためです。[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ターゲットポートに再利用することを奨励する「保守的な再利用の原則」を説明しています。実際、これは非常に重要な実装の考慮事項であり、遵守しなければなりません。[SPC3]は、SCSIターゲットがSCSI輸送プロトコルで必要な場合はいつでも、SCSIターゲットに永続的な予約と関連する登録をSCSIイニシエーターポート名に関連付けることを義務付けています。[ISCSI]にはISIDに基づいた強制SCSIイニシエーターポート名が必要なため、SCSIイニシエーターポート名、したがってISIDSを間接的に操作するためにISCSIターゲットが必要です。
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実装は、以前のISCSIセッションを再確立する際に以前と同じISIDを使用して、その後の再起動時にリブートを再起動して、永続的に依存するために使用する必要があります。電源損失能力。
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. and 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。、「トランスミッションコントロールプロトコル」、STD 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.
ISCSIプロトコルを定義したIPSワーキンググループに感謝しています。この文書の公開を奨励してくれたDavid Black（EMC）にも感謝します。Randy Haagens（HP）がコマンド注文のトピックに関する洞察に感謝します。また、このドキュメントを慎重にレビューしてくれたエリザベスロドリゲスにも感謝します。
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
Rob Elliott Hewlett-Packard Company MC140801 PO Box 692000 Houston, TX 77269-2000 USA
Rob Elliott Hewlett-Packard Company MC140801 PO Box 692000ヒューストン、テキサス77269-2000 USA
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。