RFC3783 日本語訳
3783 Small Computer Systems Interface (SCSI) Command OrderingConsiderations with iSCSI. M. Chadalapaka, R. Elliott. May 2004. (Format: TXT=32358 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Chadalapaka
Request for Comments: 3783 R. Elliott
Category: Informational Hewlett-Packard Co.
May 2004
Chadalapakaがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3783年のR.エリオットカテゴリ: 情報のヒューレット・パッカード社の2004年5月
Small Computer Systems Interface (SCSI)
Command Ordering Considerations with iSCSI
iSCSIと共に問題を注文する小さいコンピュータ・システムインタフェース(SCSI)コマンド
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
インターネットSmallコンピュータシステムズInterface(iSCSI)はTCPの上を走るように設計されたSmallコンピュータシステムズInterface(SCSI)トランスポート・プロトコルです。 iSCSIセッション抽象化は古典的なSCSI「I_T結びつき」に同等です。(それは、プロトコルのSCSI家を通って交信するのに必要であるInitiatorとTarget(私と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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 定義と頭文字語. . . . . . . . . . . . . . . . . . . 3 2.1。 定義。 . . . . . . . . . . . . . . . . . . . . . . 3 2.2. 頭文字語. . . . . . . . . . . . . . . . . . . . . . . . 4 3。 iSCSIプロトコル. . . . . . . . . . . . . . . . 4 3.1の概観。 記述. . . . . . . . . . . . . . 4 3.2を写像して、議定書を作ってください。 I_T結びつきモデル。 . . . . . . . . . . . . . . . . . . 5 3.3. 命令されたコマンド配送. . . . . . . . . . . . . . . . 6 3.3.1。 問題。 . . . . . . . . . . . . . . . . . . . 6 3.3.2. セッション保証。 . . . . . . . . . . . . . 6 3.3.3. 重荷を命令します。 . . . . . . . . . . . . . . . . . 7 3.3.4. 意図を設計してください。 . . . . . . . . . . . . . . . . . 7
Chadalapaka & Elliott Informational [Page 1] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[1ページ]のRFC3783Command
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. コマンド注文シナリオ。 . . . . . . . . . . . . . . . . 8 4.1. SCSI層. . . . . . . . . . . . . . . . . . . . . . . 8 4.1の.1。 参照番号(CRN). . . . . . . . . 8 4.1.2を命令してください。 属性に仕事を課してください。 . . . . . . . . . . . . . . . . 8 4.1.3. 自動偶然な忠誠(ACA). . . . . . . . 8 4.1.4。 UAは.94.2iSCSI層を連動させます。 . . . . . . . . . . . . . . . . . . . . . . 9 5. 接続失敗問題。 . . . . . . . . . . . . . . 9 6. システム問題. . . . . . . . . . . . 10 7を注文して、命令してください。 予約問題. . . . . . . . . . . . . . . . . . 11 8。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 9. 参照と図書目録。 . . . . . . . . . . . . . . . . . 12 9.1. 引用規格。 . . . . . . . . . . . . . . . . . 12 9.2. 有益な参照. . . . . . . . . . . . . . . . . 12 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 12 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 13 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 14
1. Introduction
1. 序論
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) より大きい(直径) 格納Area Networks(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
それぞれのこれらのアプリケーションはiSCSIがSCSI創始者とSCSI目標の間で可能にする実際に無制限な地理的な距離を利用します。 それぞれのこれらの場合には、かかわった長時間の遅延のために、創始者が前のコマンドのSCSI状態を待たないで背中合わせの状態でSCSIコマンドを流す非常に高い誘因があります。 コマンドストリーミングは主として2つのクラスのアプリケーションで使われるかもしれません--1つのクラスが特に命令されたコマンド実行を心配していないかもしれない間、もう片方のクラスは命令されたコマンド実行に依存します(すなわち、SCSIコマンドの中の注文にはアプリケーションレベルの依存があります)。 例として、より早く明確に記載されたケースb)とc)は命令されたコマンド実行を必要とします。 ミラーリングアプリケーションは必要でない、リモートSCSI目標で故障していた状態で遂行されるために、書きます。
Chadalapaka & Elliott Informational [Page 2] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[2ページ]のRFC3783Command
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]のデザイン意図が分析して、わかります。
2. Definitions and Acronyms
2. 定義と頭文字語
2.1. Definitions
2.1. 定義
- 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 Initiator Port)とiSCSI目標のPortal Group(SCSI Target Port)との関係です。
- 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装置はサービス配送サブシステムにつなげられる1つ以上のSCSIポートを含んでいて、SCSIアプリケーション・プロトコルをサポートする実体です。 iSCSI文脈では、SCSI DeviceはSCSIの機能性を提供するiSCSI Nodeの中のコンポーネントです。 SCSI Device Nameは、ノードのiSCSI Nameになるように定義されます。
- 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結びつきに同等な)を形成します。 iSCSIセッション以内のiSCSI接続が時間がたつにつれて変えるかもしれない参加する数。 iSCSIレベルにおける接続の多様性はSCSI層のために完全に隠されます--I_T結びつきにおけるSCSIポートが、ある同輩SCSIだけがセッションのすべての接続の向こう側に移植するのを見るそれぞれ。
Chadalapaka & Elliott Informational [Page 3] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[3ページ]のRFC3783Command
2.2. Acronyms
2.2. 頭文字語
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
頭文字語定義-------------------------------------------------------------- 小さいハンドルの通信制御プロトコルUAユニット注意WG SANストレージエリアネットワークSCSIコンピュータシステムズインタフェースTCP作業部会を特定する自動偶然な追加追加ACAのTMFタスク管理機能TSIH目標忠誠ASCセンス・コードASCQセンス・コード資格を与える人CRN命令基準値数のIETFインターネット・エンジニアリング・タスク・フォースのISID創始者セッション識別子ITT創始者タスクタグLu論理装置LUN論理ユニット番号NICネットワーク・インターフェース・カードPDUプロトコルデータ単位セッション
3. Overview of the iSCSI Protocol
3. iSCSIプロトコルの概観
3.1. Protocol Mapping Description
3.1. 記述を写像するプロトコル
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結びつきの中でInitiator Task Tag(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 Command PDUsと呼ばれるiSCSI要求で運ばれます。 創始者へのSCSI状態はSCSI Response PDUsと呼ばれるiSCSI応答で運ばれます。 創始者から目標までのSCSI Dataは外のSCSI Data PDUsで運ばれます、そして、創始者への中のSCSI Data後部は中のSCSI Data PDUsで運ばれます。
Chadalapaka & Elliott Informational [Page 4] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[4ページ]のRFC3783Command
3.2. The I_T Nexus Model
3.2. I_T結びつきモデル
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モデル、直接iSCSIセッションまでのSCSI I_T結びつき地図で。(セッションは1つ以上のTCP接続にかかるiSCSIプロトコル抽象化です)。 iSCSIプロトコルは双方向のコミュニケーションのI_T結びつきに関する、ある論理的な流れがわかるために意味論を定義します、潜在的に複数のTCP接続(最大2^16)にかかっていて。 iSCSI接続の多様性はiSCSI層にこのようにして完全に含まれています、独身の私が_T結びつきであって、同等の状態でマルチ接続セッションのときにSCSI層を贈りますが。 セッション識別子(SSID)によって1組の与えられたiSCSIノードの間のセッションは特定されます、そして、iSCSIの接続識別子(CID)によって与えられたセッション以内の各接続は唯一特定されます。 SSID自身は2つのコンポーネント(創始者Session Identifier(ISID)とTarget Session Identifying Handler(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層へのこのただ一つの論理的な流れ抽象化を提示する4があります、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層によってセッションの向こう側にユニークなCommand Sequence Number(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) 接続忠誠: CommandのためのSCSI Response PDUを含めて、SCSI Commandへのすべての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タスクセットを管理する2つのSCSIタスク管理機能(TMFs)を扱う際にSCSI目標の上のiSCSI層のためのステップの規則正しい系列を指定します。 2TMFsがセッションのときにすべてのアクティブ・タスクを中止して、タスクセットでタスクをクリアするCLEAR TASK SETを中止するABORT TASK SETです。 ステップの系列の目標はTMF Response自身が到着する前に創始者がすべての影響を受けないタスクのSCSI Response PDUsを受け取るのを保証することです、iSCSIセッションにおけるポートの数にかかわらず。 このオペレーショナル・モデルはそうです。
Chadalapaka & Elliott Informational [Page 5] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[5ページ]のRFC3783Command
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]はTMF要求がまるでコマンドとTMF要求がすべてかのようにただ一つの論理チャネルを流れながら実行されるのを保証するために目標iSCSI層を必要とする意味論を定義します。 これは、TMF要求がそれが管理することになっていたタスクに影響するのを確実にします。
The following sections will analyze the "Ordered command delivery" aspect in more detail, since command ordering is the focus of this document.
以下のセクションはさらに詳細に「命令されたコマンド配送」局面を分析するでしょう、コマンド注文がこのドキュメントの焦点であるので。
3.3. Ordered Command Delivery
3.3. 命令されたコマンド配送
3.3.1. Questions
3.3.1. 問題
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コマンド注文に関連する2、3の重要な質問が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チェックサム(例えば2相殺ビットは同じビット位置で宙返りする)によって検出されませんが、iSCSI CRCダイジェストによって検出されるファッションによるデータを崩壊させる誤りなどの輸送誤りがあるときiSCSI実現を振舞いに要求するよう命令するコマンドは何であるべきですか?
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プロトコル、以下の小区分で必要とした注文では、さらに詳細にそれらを考えてください。
3.3.2. The Session Guarantee
3.3.2. セッション保証
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層で創始者によって意図された(CmdSNオーダーで示されるように)それと異なったオーダーにおけるコマンドを異なって、実行してはいけないとiSCSIダイジェストの故障、またはiSCSI接続終了で述べました。 このデザイン選択はビル格納システムとそれが現在いつも仮定できる解決策に途方もないほど役立っています。
Chadalapaka & Elliott Informational [Page 6] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[6ページ]のRFC3783Command
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結びつきのために帯域幅集合を命令したのを間接的に含意していたことに注意してください。 [iSCSI]によって強制されたこの交差接続注文が高価であると考えられる展開モデルで、代わりに複数の単独結合セッションに展開するのに真剣な考慮を与えるべきです。
3.3.3. Ordering Onus
3.3.3. 重荷を命令します。
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用法要件を落として、ABORT TASK TMFがコマンド穴のなどをふさぐのを許容するのにこの解決は反映されます、これらが創始者が命令されたコマンド配送を使用しないことを支持してする意識的な選択であるので。 [iSCSI]の慎重な読者は最終結果について明察できます--いつもiSCSI目標の上に命令されたコマンド配送を確実にする重荷があります、創始者はコマンド注文を利用するかもしれませんが。クライアントサーバモデルのサーバでありiSCSI目標は、本当にクライアント(創始者)がサービスを命令するコマンドを利用するつもりであるかどうか証明するのを試みませんが、代わりにいつも単に保証されたデリバリ・サービスを提供してください。 ここの原理が私たちが解決策が注文されたコマンドを組み込む際に見るように固有のSCSIとアプリケーションレベルの依存があるということである、それは、コマンド注文の用法に関して意図について強制するか、または明察するのさえ[iSCSI]の範囲を超えています。
3.3.4. Design Intent
3.3.4. デザイン意図
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層に持つために保証されます。 その結果結びつきがすべてのLUsにかかる全体のI_T結びつきですが、アクセサリーに認可されて、配送がある規則正しいコマンドの保証 それはこの特性が使用されるかどうかに関する創始者の思慮深さです。
Chadalapaka & Elliott Informational [Page 7] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[7ページ]のRFC3783Command
4. The Command Ordering Scenario
4. コマンド注文シナリオ
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層で以下のプロトコル機能を考えなければなりません。それはコマンド注文目標がわかる際にそれぞれ担当役割を持っています。
4.1. SCSI Layer
4.1. SCSI層
The SCSI application layer has several tools to enforce ordering.
SCSI応用層には、注文を実施する数個のツールがあります。
4.1.1. Command Reference Number (CRN)
4.1.1. 命令基準値番号(CRN)
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]は、指定するためにSCSIトランスポート・プロトコルのためのiSCSIなどのCRNの意味論に用法を残します。 [iSCSI]は、様々な理由でCRNの特徴を支持しないのを選びました。
4.1.2. Task Attributes
4.1.2. タスク属性
[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つのタスク属性を定義します--SIMPLE、ORDERED、HEAD OF QUEUE、およびACA。 属性はLUへの各タスクに割り当てられるかもしれません。 [SAM2]はそれぞれのこれらの属性がタスクを修理している装置サーバに伝える注文規制を定義します。 特に、pipelinedコマンドの流れに適用されたORDEREDとSIMPLE属性の賢明な使用は創始者が発行するコマンドのために正確な実行図式を伝えるかもしれません、目標の上に同次でコマンドを受け取るなら。
4.1.3. Auto Contingent Allegiance (ACA)
4.1.3. 自動偶然な忠誠(ACA)
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にセットする)です。CHECK CONDITIONと共に完成します。 ACAが引き起こされるとき、CLEAR ACAタスク管理機能が実行されるまで、それは既にタスクセットにおける他のすべてのタスクを妨げている間、ACA属性で実行からそれら以外のすべてのコマンドを防ぎます。 ACAの詳細な意味論に関して[SAM2]を見てください。 ACAが密接に1つのタスクセットの概念に結ばれるので、人は、あるI_T_L結びつきにおけるコマンド失敗がACAを通して他のI_T_L結びつきに影響を与えるのを防ぐためにタスクセット(LUのコントロールモードページの1にTSTビットを設定するのによる)の範囲が創始者であることを理想的に選択しなければならないでしょう。
Chadalapaka & Elliott Informational [Page 8] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[8ページ]のRFC3783Command
4.1.4. UA Interlock
4.1.4. UAインタロック
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と共に終えられるとき、autosense、および添加で報告されたどんな標準のUnit Attention状態もUnit Attention状態を確立するのをRESERVATION CONFLICT状態もしません。 装置サーバが同じ創始者から明白なREQUEST SENSE([SPC3])コマンドを実行するときだけ、このいわゆる「連動しているUA」はクリアされます。 機能性見解から、UAインタロックの範囲には、CHECK CONDITION以外の完成状態に注文の振舞いを実施するので今日、ACAのものとわずかに異なりますが、そうでなければ、ACAとして熱心な同じデザインが概念的にあります。 他方では、ACAがアクティブであるときに、実行するタスク(ACA属性があるもの)を特別な「クリーンアップ」に許すので、ACAはいくらか高性能です。 UAインタロックが生まれた主要な理由の1つはSCSIデザイナーが、コマンドにコントロールモードページで前述のTSTビットを使用する副作用なしで特徴を命令して欲しかったということでした。
4.2. iSCSI Layer
4.2. iSCSIは層にします。
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層に輸送されて、手渡されるという重要な保証を提供することによって。
5. Connection Failure Considerations
5. 接続失敗問題
[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]はさらに以下を強制します:
Chadalapaka & Elliott Informational [Page 9] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[9ページ]のRFC3783Command
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目標“as if"はCHECK CONDITIONのため内部的に接続失敗のため終えられたタスクを終えなければなりません。 この特定の完成状態は創始者に決して伝えて戻されませんが、創始者が選択のコマンド注文メカニズムとしてACAを使用していたなら、SCSI-レベルACAがこの義務的なCHECK CONDITIONのため引き起こされるので、“as if"がまだ重要であって、必要です。 これは前述の危険を記述します。
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目標は、次のコマンドに関するUnit Attention状態がそのセッションのそれぞれの影響を受けるI_T_L結びつきのためのどんな接続のときにも処理されたと報告しなければなりません。 創始者が選択のコマンド注文メカニズムとしてUAインタロックを使用していたなら、SCSI-レベルUAがUAインタロックの引き金となるので、これが必要です。 これは再び前述の危険を記述します。iSCSI目標はCHECK CONDITIONの状態、および47h/7FhのASC/ASCQ値でこのUAを報告しなければなりません(「いくつかのコマンドがISCSIプロトコルイベントによってクリアしました」)。
6. Command Ordering System Considerations
6. システム問題を注文するコマンド
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に関連して使用されるいつというコマンドの列を作りを支持するようにするか。
Chadalapaka & Elliott Informational [Page 10] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[10ページ]のRFC3783Command
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層がORDEREDと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) CHECK CONDITION状態を包含して、その結果、コマンド注文に解決策を築き上げるよう実現の機能性に命令するのを唯一の必要なコマンドにするようにUAインタロックの範囲を広げる何らかの考慮があります。 これがT10で決議されるまで、UAインタロックと両方を実行するACA証明書の現在定義された意味論はコマンド注文を支持するのを願ってやまないiSCSI目標で解決策を特徴とします。
7. Reservation Considerations
7. 予約問題
[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創始者が同じISIDs(セクション3.2を見る)を様々なSCSI目標ポートに再利用するよう奨励する「保守的な再利用の原則」について説明します、同じSCSI創始者ポート名をそれらの目標ポートに提示するために。 事実上、これは従わなければならない非常に重要な実現の考慮です。 [SPC3]は、それらがSCSIトランスポート・プロトコルによって必要とされるときはいつも、しつこい予約と関連する登録証明書をSCSI創始者ポート名に関連づけるためにSCSI目標を強制します。 [iSCSI]が義務的なSCSIを必要とするので、創始者ポート名はISIDs、目標がSCSI創始者ポート名で働かせていなければならないiSCSI的に、その結果、間接的に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ポートの向こう側にしつこい予約/登録が使用されることを意図するなら、創始者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を復職させるのにおいてオンな同じISIDsを使用しなければならない、電力損能力で、固執してください。
Chadalapaka & Elliott Informational [Page 11] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[11ページ]のRFC3783Command
8. Security Considerations
8. セキュリティ問題
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]のSecurity Considerations部を参照してください。 このドキュメントは[iSCSI]で既に議論したもの以外のどんな追加担保問題も紹介しません。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[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)」RFC3720)は2004がそうするかもしれません。
[SAM2] ANSI INCITS.366:2003 SCSI Architecture Model - 2 (SAM-2).
[SAM2]ANSI INCITS.366: 2003年のSCSI構造モデル--2 (SAM-2。)
9.2. Informative References
9.2. 有益な参照
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のための主要なワーズ」、BCP14、RFC2119、1997年3月。
[RFC3347] Krueger, M. and R. Haagens, "iSCSI Requirements and Design
Considerations", RFC 3347, July 2002.
[RFC3347] クルーガーとM.とR.Haagens、「iSCSI要件とデザイン問題」、RFC3347、2002年7月。
[SPC3] INCITS T10/1416-D, SCSI Primary Commands-3 (SPC-3).
[SPC3]INCITS T10/1416-D、SCSIの第一のコマンド-3(SPC-3)。
10. Acknowledgments
10. 承認
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ワーキンググループに感謝しています。 また、このドキュメントの公表を奨励したデヴィッドBlack(EMC)をありがとうございます。 彼の洞察のためのランディHaagens(ヒューレット・パッカード)のおかげで、コマンド注文の話題に関して特別です。 感謝は慎重にこのドキュメントを再検討するためのエリザベス・ロドリゲスのもためです。
Chadalapaka & Elliott Informational [Page 12] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[12ページ]のRFC3783Command
11. Authors' Addresses
11. 作者のアドレス
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd. Roseville, CA 95747-5668, USA
Mallikarjun Chadalapakaヒューレット・パッカード会社8000山麓の丘Blvd. ローズビル、カリフォルニア95747-5668(米国)
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
ロブエリオットヒューレット・パッカード社のMC140801PO Box692000ヒューストン、テキサス77269-2000米国
Phone: +1.281.518.5037 EMail: elliott@hp.com
以下に電話をしてください。 +1.281 .518 .5037 メール: elliott@hp.com
Chadalapaka & Elliott Informational [Page 13] RFC 3783 Command Ordering May 2004
2004年5月に注文されるChadalapakaとエリオット情報[13ページ]のRFC3783Command
12. Full Copyright Statement
12. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Chadalapaka & Elliott Informational [Page 14]
ChadalapakaとエリオットInformationalです。[14ページ]
一覧
スポンサーリンク
