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
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.
インターネット小型コンピュータシステムインタフェース（iSCSIは）TCPの上で実行するように設計された小型コンピュータシステムインタフェース（SCSI）トランスポートプロトコルです。 iSCSIセッション抽象化は、プロトコルのSCSIファミリーを介して通信するために必要なイニシエータとターゲット（I及びT）の間の論理関係を示す古典的なSCSI「I_Tネクサス」に相当します。 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
今b）は非同期リモートCをミラーリングするまで可能であったよりもA）拡大（直径）ストレージエリアネットワーク（SAN））リモートテープボールト
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クラスで主に使用することができる - 一つのクラスは、特に注文したコマンドの実行を気にしないかもしれないが、他のクラスは、注文したコマンドの実行に依存しない（すなわち、SCSIコマンド間の順序でアプリケーションレベルの依存関係があります）。一例として、先に明確に記載されている場合b）および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ネクサス：[SAM2]はSCSIイニシエータポート及びSCSIターゲットポートとの間の関係としてI_Tネクサスを定義します。 【のiSCSI] I_TネクサスのiSCSIの表現としてiSCSIセッションを定義します。 iSCSIの文脈において、I_Tネクサス（すなわち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アプリケーションプロトコルをサポートしている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.
- セッション：ターゲットフォームで（SCSI I-Tネクサスに相当）セッションを開始するリンク論理的に関連するiSCSI接続のグループ。 iSCSIセッション内のiSCSI接続を参加の数は時間とともに変化してもよいです。 iSCSIのレベルでの接続の多数は完全にSCSI層に隠されている - I_Tネクサスの各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
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タスクを一意イニシエータタスクタグ（ITT）と呼ばれる32ビットの一意の識別子によってそのI_Tネクサス内で識別されます。 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ネクサスは、一の以上のTCP接続にまたがるiSCSIプロトコル抽象化であるiSCSIセッションに直接マッピングされます。 iSCSIプロトコルは、潜在的に（2 ^ 16のような多くのように）複数のTCP接続にまたがる、I_Tネクサス上の双方向通信の論理的な流れを実現するために意味論を定義します。 SCSI層があっても、マルチ接続セッションに、単一のI_Tネクサスが提示されている間のiSCSI接続の多重度は、このように完全に、iSCSI層に含有されています。与えられたiSCSIノードの対の間のセッションは、セッション識別子（SSID）によって識別され、所与のセッション内の各接続は、一意のiSCSIの接続識別子（CID）によって識別されます。イニシエータセッション識別子（ISID）とハンドラを識別ターゲットセッション（TSIH） - - 同じセッションの各識別一端SSID自体は、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接続にまたがっiSCSIセッションで、SCSI層にこの単一の論理フローの抽象化を提示したiSCSIの4つの重要な機能の面があります。
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コマンドのシーケンスは、セッション全体で一意であるコマンドシーケンス番号（CmdSN）に基づいて、同一の配列へのターゲットのiSCSI層によって「並べ替え」されます。目標は、複数の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 again intended to preserve the single flow abstraction to the SCSI layer.
C）タスク管理機能処理を設定：[たiSCSI] SCSIタスクセットを管理すること（TMFs）は、2つのSCSIタスク管理機能の処理にSCSIターゲット上のiSCSI層のためのステップの順序付きシーケンスを指定します。 2 TMFsは、タスクセットのタスクをクリアし、セッション内のすべてのアクティブなタスクを中止しますABORT TASK SET、およびCLEAR TASK設定されています。一連のステップの目標は、TMFのレスポンス自体が到着する前に、イニシエータは関係なく、iSCSIセッション内の接続数の、すべての影響を受けていないタスクの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?
TCPチェックサムによって検出されていない方法で、破損したデータ（例えば、2つの相殺ビットが同じビット位置で反転することa）はどのようなエラーなどの転送エラーの存在下でのiSCSI実装に必要なコマンドの順序の動作をする必要があります）が、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.
セクション3.3.1に質問Aの最終的な配置）は、[RFC3347]に反映された「iSCSIはSCSIの厳密な順序付き配信を指定しなければならないにも搬送エラーの存在下で、イニシエータ/ターゲットペアの間のiSCSIセッションを介して指示します。」別の言い方をすれば、イニシエータによって（CmdSN順序によって示されるように）意図とは異なる順序でコマンドを実行できるように、ターゲットのiSCSI層を引き起こしてはならないのiSCSIダイジェスト障害、またはiSCSI接続終了。この設計の選択は現在、常にコマンドの順序が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ネクサスのための注文の帯域幅集約を可能にしたことを示唆していることに注意してください。 [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のa、bの最終的な解決には）必ず、コマンドの順序付けを使用するイニシエータを必要としないに賛成していました。この解像度は、イニシエータに必須のACAの使用要求をドロップし、これらは、イニシエータは、順序付けられたコマンドの配信を使用しない場合に有利になり意識的な選択であるため、等のコマンド穴を塞ぐためにABORT TASK 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層へのコマンドの順序付き配信の固有の特性を持つことが保証されています。そのため、注文したコマンドの配信の保証はネクサスがアクセスを許可されているすべてのLUにまたがる全体I_Tネクサス渡っあります。これは、このプロパティが使用されるか否かのイニシエータの裁量です。
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ネクサスのための1つインクリメント（[SAM2]参照します）。 CRNと1つの顕著な欠点は、CRNの機能を有効または無効にする（このようなモードのページを介するなど）がSCSI-一般的な方法がないことです。 [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.
SIMPLE、ORDERED、キューの先頭、およびACAを - [SAM2]は、以下の4つのタスク属性を定義します。 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は、（1に設定NACAビットで）コマンドがチェック条件で完了したときにトリガされるLUレベルの状態です。 ACAがトリガされるとタスクセットにすでに他のすべてのタスクをブロックしながら、それは、CLEAR ACAタスク管理機能が実行されるまで実行からACA属性を持つもの以外のすべてのコマンドを防ぐことができます。 ACAの詳細なセマンティクスのため[SAM2]を参照してください。 ACAは密接タスクセットの概念に関連付けられているので、一方は、理想的にするために当たり開始剤であること（LUの制御モードページ1にTSTビットをセットすることにより）タスクセットの範囲を選択しなければなりませんACAを介して他のI_T_Lのnexusesに影響を与えるから1つの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インターロックが有効になっている場合、論理ユニットは、自動感知して報告された任意の標準ユニットアテンション条件をクリアしないと、タスクはBUSYの1、TASK SET FULL、または予約の競合ステータスで終了したときだけでなく、ユニットアテンション条件を確立します。デバイスサーバは、同じイニシエータからの明示的な要求のSENSE（[SPC3]）コマンドを実行した場合にのみ「連動UA」いわゆるこれがクリアされます。それはチェック条件以外の完了ステータスのための発注行動を強制し、それ以外は概念的にACAと同じ設計意図を持っているので、機能性の観点から、UAインターロックの範囲、今日は、ACAの若干異なっています。それはACAがアクティブなときに実行するために、特別な「クリーンアップ」タスク（ACA属性を持つもの）を可能にするため、一方、ACAはもう少し洗練されています。 UAのインターロックがされて入ってきた主な理由の一つは、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ターゲットは、チェック条件の状況、および47H / 7FhののASC / ASCQ値（「iSCSIプロトコルイベントでクリアいくつかのコマンド」）と、このUAを報告しなければなりません。
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層が注文しSIMPLEタスクの属性をサポートしないことを保証しなければなりません。
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インターロックの現在定義されているセマンティクスとコマンドの順序付けのソリューションをサポートすることを望んiSCSIターゲットの両方の機能を実装するACA令状で解決されます。
[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の】これらのターゲットポートに同一のSCSIイニシエータポート名を提示するために、様々なSCSIターゲットポートに同じISIDs（セクション3.2を参照）を再利用するiSCSIイニシエータを奨励「保存的再利用の原理」を記載しています。これは、実際に遵守しなければならない非常に重要な実装上の考慮事項です。 [SPC3]はそれらがSCSIトランスポートプロトコルによって必要とされるたびにSCSIイニシエータポート名で永続予約や関連の登録を関連付けるためにSCSIターゲットを義務付け。 [iSCSIの】ISIDsに基づいて必須のSCSIイニシエータポート名を必要とするため、iSCSIターゲットは、永続予約を実施するには、SCSIイニシエータポート名をオフ動作させる必要があり、従って間接的ISIDsれます。
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ポート間で使用されることが意図されている場合は、SCSIデバイスの異なるiSCSIターゲットポータルグループに接続する関連するiSCSIセッションで同じISIDを使用する必要があり、イニシエータのiSCSI実装。
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セッションを再確立する前と同じISIDsを使用する必要があります電力損失機能を通じて持続。
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.、メタ、K.、Sapuntzakis、C.、Chadalapaka、M.およびE. Zeidner、 "インターネットの小さいコンピュータシステムInferface（iSCSIの）"、RFC 3720、2004年5月。
[SAM2] ANSI INCITS.366:2003 SCSI Architecture Model - 2 (SAM-2).
[SAM2] ANSI INCITS.366：2003 SCSIアーキテクチャモデル - 2（SAM2）。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3347] Krueger, M. and R. Haagens, "iSCSI Requirements and Design Considerations", RFC 3347, July 2002.
[RFC3347]クルーガー、M.とR. Haagens、 "iSCSIの要件と設計上の考慮事項"、RFC 3347、2002年7月。
[SPC3] INCITS T10/1416-D, SCSI Primary Commands-3 (SPC-3).
[SPC3] INCITS T10 / 1416-D、SCSIプライマリコマンド-3（SPC3）。
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ワーキンググループに感謝しています。また、本書の出版を奨励デヴィッド・ブラック（EMC）に感謝します。コマンドの順序付けのトピックに関する彼の洞察力のためのランディHaagens（HP）に感謝します。おかげで慎重にこの文書をレビューするためにも、エリザベス・ロドリゲスによるものです。
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd. Roseville, CA 95747-5668, USA
Mallikarjun cadalapaka havaletta-pakkard同社は8000ブルバードをphuthils。ローズ、K 95747-5668、USA
Phone: +1.916.785.5621 EMail: cbm@rose.hp.com
電話：+1.916.785.5621電子メール：cbm@rose.hp.com
Rob Elliott Hewlett-Packard Company MC140801 PO Box 692000 Houston, TX 77269-2000 USA
ロブ・エリオット、米国Hewlett-Packard Company MC140801私書箱692000ヒューストン、TX 77269から2000 USA
Phone: +1.281.518.5037 EMail: elliott@hp.com
電話：+1.281.518.5037電子メール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。