RFC5048 日本語訳
5048 Internet Small Computer System Interface (iSCSI) Corrections andClarifications. M. Chadalapaka, Ed.. October 2007. (Format: TXT=80149 bytes) (Updates RFC3720) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Chadalapaka, Ed. Request for Comments: 5048 Hewlett-Packard Co. Updates: 3720 October 2007 Category: Standards Track
ワーキンググループM.Chadalapaka、エドをネットワークでつないでください。コメントのために以下を要求してください。 5048のヒューレット・パッカード社のアップデート: 3720 2007年10月のカテゴリ: 標準化過程
Internet Small Computer System Interface (iSCSI)
Corrections and Clarifications
インターネットスモールコンピュータシステムインタフェース(iSCSI)修正と明確化
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ.
インターネットSmallコンピュータSystem Interface(iSCSI)はSCSIトランスポート・プロトコルとSCSI構造とコマンドがTCP/IPに設定する地図です。 RFC3720はiSCSIプロトコルを定義します。 このドキュメントは、iSCSI implementersのための仲間ドキュメントとして機能するようにRFC3720へのオリジナルのプロトコル定義に明確化をコンパイルします。 このドキュメントはRFC3720をアップデートします、そして、テキストは2が異なるRFC3720年に本書ではテキストに取って代わります。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions, Acronyms, and Document Summary .....................3
2.1. Definitions ................................................3
2.2. Acronyms ...................................................4
2.3. Clarifications, Changes, and New Semantics .................5
3. iSCSI Semantics for SCSI Tasks ..................................7
3.1. Residual Handling ..........................................7
3.1.1. Overview ............................................7
3.1.2. SCSI REPORT LUNS and Residual Overflow ..............7
3.2. R2T Ordering ...............................................9
3.3. Model Assumptions for Response Ordering ....................9
3.3.1. Model Description ..................................10
3.3.2. iSCSI Semantics with the Interface Model ...........10
3.3.3. Current List of Fenced Response Use Cases ..........11
4. Task Management ................................................12
4.1. Requests Affecting Multiple Tasks .........................12
4.1.1. Scope of Affected Tasks ............................12
4.1.2. Clarified Multi-Task Abort Semantics ...............13
4.1.3. Updated Multi-Task Abort Semantics .................14
1. 序論…3 2. 定義、頭文字語、およびドキュメント概要…3 2.1. 定義…3 2.2. 頭文字語…4 2.3. 明確化、変化、および新しい意味論…5 3. SCSIタスクのためのiSCSI意味論…7 3.1. 残りの取り扱い…7 3.1.1. 概観…7 3.1.2. SCSI REPORTルンスと残差はあふれます…7 3.2. R2T注文…9 3.3. 応答注文のための仮定をモデル化してください…9 3.3.1. 記述をモデル化してください…10 インタフェースモデルがある3.3.2iSCSI意味論…10 3.3.3. 囲われた応答の現在のリストはケースを使用します…11 4. タスク管理…12 4.1. 複数のタスクに影響する要求…12 4.1.1. 影響を受けるタスクの範囲…12 4.1.2. マルチタスクアボート意味論をはっきりさせます…13 4.1.3. マルチタスクアボート意味論をアップデートします…14
Chadalapaka Standards Track [Page 1] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[1ページ]RFC5048iSCSI修正と明確化2007年10月
4.1.4. Affected Tasks Shared across RFC 3720 and
FastAbort Sessions .................................16
4.1.5. Implementation Considerations ......................17
4.1.6. Rationale behind the New Semantics .................17
5. Discovery Semantics ............................................19
5.1. Error Recovery for Discovery Sessions .....................19
5.2. Reinstatement Semantics of Discovery Sessions .............19
5.2.1. Unnamed Discovery Sessions .........................20
5.2.2. Named Discovery Sessions ...........................20
5.3. Target PDUs during Discovery ..............................20
6. Negotiation and Others .........................................21
6.1. TPGT Values ...............................................21
6.2. SessionType Negotiation ...................................21
6.3. Understanding NotUnderstood ...............................21
6.4. Outstanding Negotiation Exchanges .........................22
7. iSCSI Error Handling and Recovery ..............................22
7.1. ITT .......................................................22
7.2. Format Errors .............................................22
7.3. Digest Errors .............................................22
7.4. Message Error Checking ....................................23
8. iSCSI PDUs .....................................................23
8.1. Asynchronous Message ......................................23
8.2. Reject ....................................................24
9. Login/Text Operational Text Keys ...............................24
9.1. TaskReporting .............................................24
10. Security Considerations .......................................25
11. IANA Considerations ...........................................26
11.1. iSCSI-Related IANA Registries ............................26
11.2. iSCSI Opcodes ............................................26
11.3. iSCSI Login/Text Keys ....................................28
11.4. iSCSI Asynchronous Events ................................30
11.5. iSCSI Task Management Function Codes .....................31
11.6. iSCSI Login Response Status Codes ........................32
11.7. iSCSI Reject Reason Codes ................................34
11.8. iSER Opcodes .............................................35
12. References ....................................................36
12.1. Normative References .....................................36
12.2. Informative References ...................................36
Acknowledgements ..................................................37
4.1.4. 影響を受けるタスクはRFC3720とFastAbortセッションの向こう側に共有されました…16 4.1.5. 実現問題…17 4.1.6. 新しい意味論の後ろの原理…17 5. 発見意味論…19 5.1. 発見セッションのためのエラー回復…19 5.2. 発見セッションの復職意味論…19 5.2.1. 無名発見セッション…20 5.2.2. 発見をセッションと命名します…20 5.3. 発見の間、PDUsを狙ってください…20 6. 交渉と他のもの…21 6.1. TPGT値…21 6.2. SessionType交渉…21 6.3. NotUnderstoodを理解しています…21 6.4. 傑出している交渉交換…22 7のiSCSIエラー処理と回復…22 7.1. ITT…22 7.2. 誤りをフォーマットしてください…22 7.3. 誤りを読みこなしてください…22 7.4. メッセージ誤りの照合…23 8iSCSI PDUs…23 8.1. 非同期なメッセージ…23 8.2. 拒絶します。24 9. ログイン/テキストの操作上のテキストキー…24 9.1. TaskReporting…24 10. セキュリティ問題…25 11. IANA問題…26 11.1. iSCSI関連のIANA登録…26 11.2. iSCSI Opcodes…26 11.3. iSCSIログイン/テキストキー…28 11.4. iSCSI非同期的なイベント…30 11.5. iSCSIタスク管理機能コード…31 11.6. iSCSIログイン応答ステータスコード…32 11.7. iSCSIは理由コードを拒絶します…34 11.8. iSER Opcodes…35 12. 参照…36 12.1. 標準の参照…36 12.2. 有益な参照…36の承認…37
Chadalapaka Standards Track [Page 2] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[2ページ]RFC5048iSCSI修正と明確化2007年10月
1. Introduction
1. 序論
Several iSCSI implementations have been built since [RFC3720] was published and the iSCSI community is now richer by the resulting implementation expertise. The goal of this document is to leverage this expertise both to offer clarifications to the [RFC3720] semantics and to address defects in [RFC3720] as appropriate. This document intends to offer critical guidance to implementers with regard to non-obvious iSCSI implementation aspects so as to improve interoperability and accelerate iSCSI adoption. This document, however, does not purport to be an all-encompassing iSCSI how-to guide for implementers, nor a complete revision of [RFC3720]. Instead, this document is intended as a companion document to [RFC3720] for the iSCSI implementers.
[RFC3720]が発行されて以来、いくつかのiSCSI実現が組み込まれています、そして、iSCSI共同体は現在、結果として起こる実現専門的技術で、より豊かです。 このドキュメントの目標はともに[RFC3720]意味論に明確化を提供して、[RFC3720]に適宜欠陥を記述するためにこの専門的技術に投機することです。 このドキュメントは、相互運用性を改良して、iSCSI採用を加速するために非明白なiSCSI実現局面に関して批判的な指導をimplementersに提供するつもりです。 しかしながら、このドキュメントは、implementersのオール取り囲んでいるiSCSIハウツーもののガイドと、[RFC3720]の完全な改正であることを意味しません。 代わりに、このドキュメントはiSCSI implementersのために仲間ドキュメントとして[RFC3720]に意図します。
iSCSI implementers are required to reference [RFC3722] and [RFC3723] in addition to [RFC3720] for mandatory requirements. In addition, [RFC3721] also contains useful information for iSCSI implementers. The text in this document, however, updates and supersedes the text in [RFC3720] whenever there is such a question.
iSCSI implementersが[RFC3720]に加えた義務的な要件の参照[RFC3722]と[RFC3723]に必要です。 また、さらに、[RFC3721]はiSCSI implementersのための役に立つ情報を含んでいます。 そのような質問があるときはいつも、テキストは、本書ではしかしながら、[RFC3720]のテキストをアップデートして、取って代わります。
2. Definitions, Acronyms, and Document Summary
2. 定義、頭文字語、およびドキュメント概要
2.1. Definitions
2.1. 定義
I/O Buffer
A buffer that is used in a SCSI Read or Write operation so SCSI
data may be sent from or received into that buffer. For a read or
write data transfer to take place for a task, an I/O Buffer is
required on the initiator and at least one is required on the
target.
Buffer AがバッファリングするSCSI ReadかWrite操作に使用されて、したがって、SCSIデータはバッファを送るか、またはそれに受け取るかもしれないということである入出力。 入出力Bufferが創始者の上で必要です、そして、aに関しては、タスクのために行われるためにデータ転送を読むか、または書いてください、そして、少なくとも1が目標の上で必要です。
SCSI-Presented Data Transfer Length (SPDTL)
SPDTL is the aggregate data length of the data that the SCSI layer
logically "presents" to the iSCSI layer for a Data-In or Data-Out
transfer in the context of a SCSI task. For a bidirectional task,
there are two SPDTL values -- one for Data-In and one for Data-
Out. Note that the notion of "presenting" includes immediate data
per the data transfer model in [SAM2], and excludes overlapping
data transfers, if any, requested by the SCSI layer.
SCSIによって提示されたData Transfer Length(SPDTL)SPDTLはSCSI層がSCSIタスクの文脈における中のDataか外のData転送のためにiSCSI層に論理的に「提示する」データの集合体データの長さです。 双方向のタスクのために、2つのSPDTL値があります--中のDataのためのものとDataアウトのためのもの。 「提示」の概念が[SAM2]にデータ転送モデルあたりの即値データを含んで、もしあればデータ転送がSCSI層で要求した重なることを除くことに注意してください。
Third-party
A term used in this document to denote nexus objects (I_T or
I_T_L) and iSCSI sessions that reap the side effects of actions
that take place in the context of a separate iSCSI session, while
being third parties to the action that caused the side effects.
One example of a third-party session is an iSCSI session hosting
第三者A用語は、結びつき物(I_TかI_T_L)と別々のiSCSIセッションの文脈で行われる動作の副作用を刈り取るiSCSIセッションを指示するのに副作用を引き起こした動作への第三者である間、中でこのドキュメントを使用しました。 第三者セッションに関する1つの例はiSCSIセッション接待です。
Chadalapaka Standards Track [Page 3] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[3ページ]RFC5048iSCSI修正と明確化2007年10月
an I_T_L nexus to an LU that is reset with an LU Reset TMF via a
separate I_T nexus.
LU Reset TMFと共に別々のI_T結びつきでリセットされるLUへのI_T_L結びつき。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2.2. Acronyms
2.2. 頭文字語
Acronym Definition -------------------------------------------------------------
頭文字語定義-------------------------------------------------------------
EDTL Expected Data Transfer Length
EDTLはデータ転送の長さを予想しました。
IANA Internet Assigned Numbers Authority
IANAインターネット規定番号権威
IETF Internet Engineering Task Force
IETFインターネット・エンジニアリング・タスク・フォース
I/O Input - Output
入出力入力--出力
IP Internet Protocol
IPインターネットプロトコル
iSCSI Internet SCSI
iSCSIインターネットSCSI
iSER iSCSI Extensions for RDMA
RDMAのためのiSER iSCSI拡張子
ITT Initiator Task Tag
ITT創始者タスクタグ
LO Leading Only
最低気温先導専用
LU Logical Unit
Lu論理装置
LUN Logical Unit Number
LUN論理ユニット番号
PDU Protocol Data Unit
PDUプロトコルデータ単位
RDMA Remote Direct Memory Access
RDMAのリモートダイレクトメモリアクセス
R2T Ready To Transfer
移す準備ができているR2T
R2TSN Ready To Transfer Sequence Number
一連番号を移す準備ができているR2TSN
RFC Request For Comments
コメントを求めるRFC要求
SAM SCSI Architecture Model
サムSCSI構造モデル
SCSI Small Computer Systems Interface
SCSIの小さいコンピュータ・システムインタフェース
Chadalapaka Standards Track [Page 4] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[4ページ]RFC5048iSCSI修正と明確化2007年10月
SN Sequence Number
SN一連番号
SNACK Selective Negative Acknowledgment - also
Sequence Number Acknowledgement for data
SNACK Selective Negative Acknowledgment--データのためのSequence Number Acknowledgementも
TCP Transmission Control Protocol
TCP通信制御プロトコル
TMF Task Management Function
TMFタスク管理機能
TTT Target Transfer Tag
TTT目標転送タグ
UA Unit Attention
UAユニット注意
2.3. Clarifications, Changes, and New Semantics
2.3. 明確化、変化、および新しい意味論
This document specifies certain changes to [RFC3720] semantics as well as defines new iSCSI semantics. In addition, this document also clarifies the [RFC3720] semantics. This section summarizes the contents of the document, categorizing each section into one or more of a clarification, change, or new semantic.
このドキュメントは、[RFC3720]意味論へのある変化を指定して、新しいiSCSI意味論を定義します。 また、さらに、このドキュメントは[RFC3720]意味論をはっきりさせます。 このセクションはドキュメントのコンテンツをまとめます、各セクションを変化の、または、新しく意味のある一層の明確化に分類して。
Section 3.1.1: Clarification on iSCSI residuals computation
general principles
セクション3.1.1: iSCSI残差計算綱領における明確化
Section 3.1.2: Clarification on iSCSI residuals computation with
an example
セクション3.1.2: 例があるiSCSI残差計算の明確化
Section 3.2: Clarification on R2T ordering requirements
セクション3.2: 要件を命令するR2Tにおける明確化
Section 3.3: New Semantics for Response Ordering in multi-
connection iSCSI sessions
セクション3.3: マルチ接続iSCSIセッションにおけるResponse Orderingのための新しいSemantics
Section 4.1.2: Clarifications, changes, and new semantics on
multi-task abort semantics that all implementations must comply
with
セクション4.1.2: マルチタスクに関する明確化、変化、および新しい意味論はすべての実現が従わなければならない意味論を中止します。
Section 4.1.3: Changes and new semantics (FastAbort semantics) on
multi-task abort semantics that implementations should use for
faster error recovery
セクション4.1.3: マルチタスクに関する変化と新しい意味論(FastAbort意味論)は実現が、より速いエラー回復に使用するべきである意味論を中止します。
Section 4.1.3.1: Changes in iSCSI clearing effects semantics
resulting from new FastAbort semantics
セクション4.1 .3 .1、: 新しいFastAbort意味論から生じるiSCSI開拓地効果意味論における変化
Section 4.1.4: New Semantics on third-party session interactions
with the new FastAbort semantics
セクション4.1.4: 新しいFastAbort意味論との第三者セッション相互作用の新しいSemantics
Chadalapaka Standards Track [Page 5] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[5ページ]RFC5048iSCSI修正と明確化2007年10月
Section 4.1.5: Clarification on implementation considerations
related to outstanding data transfers in order to realize correct
iSCSI protocol behavior
セクション4.1.5: 正しいiSCSIプロトコルの振舞いがわかるために傑出しているデータ転送に関連する実現問題における明確化
Section 4.1.6: Clarification on the intent behind FastAbort
semantics (not clarifications to [RFC3720] semantics)
セクション4.1.6: FastAbort意味論の後ろの意図における明確化([RFC3720]意味論への明確化でない)
Section 5.1: Clarification on error recovery semantics as
applicable to Discovery sessions
セクション5.1: ディスカバリーセッションに適切であるとしてのエラー回復意味論における明確化
Section 5.2.1: Clarification and new semantics on applying the
Initiator Session Identifier (ISID) RULE ([RFC3720]) to Unnamed
Discovery Sessions
セクション5.2.1: Initiator Session Identifier(ISID)RULE([RFC3720])をUnnamed Discoveryセッションズに適用するときの明確化であって新しい意味論
Section 5.2.2: Clarification on applying the ISID RULE to Named
Discovery Sessions
セクション5.2.2: Named DiscoveryセッションズにISID RULEを適用するときの明確化
Section 5.3: Clarification on allowed PDU types and target Logout
notification behavior on a Discovery session
セクション5.3: ディスカバリーセッションの許容PDUタイプと目標Logout通知の振舞いの明確化
Section 6.1: Clarification on the legality of the Target Portal
Group Tag (TPGT) value of zero
セクション6.1: ゼロのTarget Portal Group Tag(TPGT)価値の合法における明確化
Section 6.2: Clarification on the negotiating order of SessionType
with respect to other keys
セクション6.2: 他のキーに関するSessionTypeの交渉注文の明確化
Section 6.3: Clarification on the NotUnderstood negotiation
response on declarative keys and the implied semantics
セクション6.3: 叙述的なキーと暗示している意味論におけるNotUnderstood交渉応答の明確化
Section 6.4: Clarification on the number of legal outstanding
negotiation PDUs (Text or Login-related)
セクション6.4: 法的な傑出している交渉PDUsの数における明確化(テキストかログイン関連)です。
Section 7.1: Clarification on usage of the ITT value of 0xffffffff
セクション7.1: 0xffffffffのITT価値の用法における明確化
Section 7.2: Clarification on what constitutes format errors for
the purpose of error recovery defined in [RFC3720]
セクション7.2: 中で定義されたエラー回復の目的のための形式誤りを構成することにおける明確化[RFC3720]
Section 7.3: Change in error recovery semantics for the case of
discarding unsolicited PDUs
セクション7.3: エラー回復意味論では、求められていないPDUsを捨てるケースには、変化してください。
Section 7.4: Clarification on the intended level of error checking
on inbound PDUs
セクション7.4: 本国行きのPDUsについて検査する意図しているレベルの誤りの明確化
Section 8.1: New semantics for a new AsyncEvent code
セクション8.1: 新しいAsyncEventコードのための新しい意味論
Section 8.2: Change of legal status for Reject reason code 0x0b;
it is now deprecated
セクション8.2: Reject理由コード0x0bのための法的な身分の変化。 それは現在、非難されます。
Chadalapaka Standards Track [Page 6] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[6ページ]RFC5048iSCSI修正と明確化2007年10月
Section 9.1: New semantics for a new text key TaskReporting
セクション9.1: 新しいテキスト主要なTaskReportingのための新しい意味論
3. iSCSI Semantics for SCSI Tasks
3. SCSIタスクのためのiSCSI意味論
3.1. Residual Handling
3.1. 残りの取り扱い
Section 10.4.1 of [RFC3720] defines the notion of "residuals" and specifies how the residual information should be encoded into the SCSI Response PDU in the Counts and Flags fields. Section 3.1.1 clarifies the intent of [RFC3720] and explains the general principles. Section 3.1.2 describes the residual handling in the REPORT LUNS scenario.
.1セクション10.4[RFC3720]が、カウンツとFlags分野で「残差」の概念を定義して、残りの情報がどうSCSI Response PDUにコード化されるべきであるかを指定します。 セクション3.1 .1 [RFC3720]の意図をはっきりさせて、綱領について説明します。 セクション3.1 .2 REPORT LUNSシナリオにおける残りの取り扱いについて説明します。
3.1.1. Overview
3.1.1. 概観
SCSI-Presented Data Transfer Length (SPDTL) is the term this document uses (see Section 1.1 for definition) to represent the aggregate data length that the target SCSI layer attempts to transfer using the local iSCSI layer for a task. Expected Data Transfer Length (EDTL) is the iSCSI term that represents the length of data that the iSCSI layer expects to transfer for a task. EDTL is specified in the SCSI Command PDU.
SCSIによって提示されたData Transfer Length(SPDTL)はこのドキュメントがタスクに地方のiSCSI層を使用することで目標SCSI層が移すのを試みる集合体データの長さを表すのに使用する(定義に関してセクション1.1を見ます)用語です。 予想されたData Transfer Length(EDTL)はiSCSI層がタスクのために移すと予想するデータの長さを表すiSCSI用語です。 EDTLはSCSI Command PDUで指定されます。
When SPDTL = EDTL for a task, the target iSCSI layer completes the task with no residuals. Whenever SPDTL differs from EDTL for a task, that task is said to have a residual.
SPDTLがタスクのためにEDTLと等しいと、目標iSCSI層は残差なしでタスクを完成します。 SPDTLがタスクのためのEDTLと異なっているときはいつも、そのタスクは残差を持っていると言われています。
If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST be set to the numerical value of (SPDTL - EDTL).
タスクのためのSPDTL>EDTLであるなら、[RFC3720]の指定されるとしてのSCSI Response PDUでiSCSI Overflowに合図しなければなりません。 Residual Countが数値に用意ができなければならない、(SPDTL--EDTL)。
If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST be set to the numerical value of (EDTL - SPDTL).
タスクのためのSPDTL<EDTLであるなら、[RFC3720]の指定されるとしてのSCSI Response PDUでiSCSI Underflowに合図しなければなりません。 Residual Countが数値に用意ができなければならない、(EDTL--SPDTL)。
Note that the Overflow and Underflow scenarios are independent of Data-In and Data-Out. Either scenario is logically possible in either direction of data transfer.
OverflowとUnderflowシナリオが中のDataと外のDataから独立していることに注意してください。 どちらかのシナリオがデータ転送のどちらかの方向に論理的に可能です。
3.1.2. SCSI REPORT LUNS and Residual Overflow
3.1.2. SCSI REPORTルンスと残りのオーバーフロー
This section discusses the residual overflow issues citing the example of the SCSI REPORT LUNS command. Note however that there are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH fields following the same underlying rules. The semantics in the rest of the section apply to all such SCSI commands.
このセクションはSCSI REPORT LUNSコマンドに関する例を引用する残りのオーバーフロー問題について論じます。 しかしながら、ALLOCATION LENGTH分野が同じ基本的な規則に従っているいくつかのSCSIコマンド(例えば、INQUIRY)があることに注意してください。 セクションの残りにおける意味論はそのようなすべてのSCSIコマンドに適用されます。
Chadalapaka Standards Track [Page 7] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[7ページ]RFC5048iSCSI修正と明確化2007年10月
The specification of the SCSI REPORT LUNS command requires that the SCSI target limit the amount of data transferred to a maximum size (ALLOCATION LENGTH) provided by the initiator in the REPORT LUNS CDB. If the Expected Data Transfer Length (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT LUNS command is set to at least as large as that ALLOCATION LENGTH, the SCSI layer truncation prevents an iSCSI Residual Overflow from occurring. A SCSI initiator can detect that such truncation has occurred via other information at the SCSI layer. The rest of the section elaborates this required behavior.
SCSI REPORT LUNSコマンドの仕様は、SCSIがデータ量がREPORT LUNS CDBの創始者によって提供された最大サイズ(ALLOCATION LENGTH)に移した限界を狙うのを必要とします。 REPORT LUNSコマンドのためのSCSI Command PDUのiSCSIヘッダーのExpected Data Transfer Length(EDTL)がそのALLOCATION LENGTHと少なくとも同じくらい大きい状態で用意ができているなら、SCSI層のトランケーションは、iSCSI Residual Overflowが起こるのを防ぎます。 SCSI創始者はトランケーションがSCSI層の他の情報で起こるようにするそのそのようなものを検出できます。 セクションの残りはこの必要な振舞いについて詳しく説明します。
iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI Response and the last SCSI Data-In PDUs to indicate that an iSCSI target was unable to transfer all of the SCSI data for a command to the initiator because the amount of data to be transferred exceeded the EDTL in the corresponding SCSI Command PDU (see Section 10.4.1 of [RFC3720]).
移されるべきデータの量が対応するSCSI Command PDUでEDTLを超えていたので(.1セクション10.4[RFC3720]を見てください)、iSCSIはコマンドに、SCSI ResponseとiSCSI目標がSCSIデータのすべてを移すことができなかったのを示す最後の中のSCSI Data PDUsのFlags分野で(O)ビット(ビット5)を創始者に使用します。
The SCSI REPORT LUNS command requests a target SCSI layer to return a logical unit inventory (LUN list) to the initiator SCSI layer (see Section 6.21 of SPC-3 [SPC3]). The size of this LUN list may not be known to the initiator SCSI layer when it issues the REPORT LUNS command; to avoid transferring more LUN list data than the initiator is prepared for, the REPORT LUNS CDB contains an ALLOCATION LENGTH field to specify the maximum amount of data to be transferred to the initiator for this command. If the initiator SCSI layer has under- estimated the number of logical units at the target, it is possible that the complete logical unit inventory does not fit in the specified ALLOCATION LENGTH. In this situation, Section 4.3.3.6 in [SPC3] requires that the target SCSI layer "shall terminate transfers to the Data-In Buffer" when the number of bytes specified by the ALLOCATION LENGTH field have been transferred.
SCSI REPORT LUNSコマンドは、論理装置在庫(LUNは記載する)を創始者SCSI層に返すよう目標SCSI層に要求します(SPC-3[SPC3]のセクション6.21を見てください)。 REPORT LUNSコマンドを発行するとき、このLUNリストのサイズは創始者SCSI層に知られていないかもしれません。 創始者より多くのLUNリストデータを移すのを避けることの用意をして、REPORT LUNS CDBはこのコマンドのために創始者に移すために最大のデータ量を指定するALLOCATION LENGTH分野を含んでいます。 目標で創始者SCSI層で論理装置の数であると下を見積もっているなら、完全な論理装置目録が指定されたALLOCATION LENGTHをうまくはめ込まないのは、可能です。 この状況、[SPC3]の.6が必要とするセクション4.3.3では、ALLOCATION LENGTH分野によって指定されたバイト数を移したとき、目標SCSIが層にするのが「中のData Bufferへの転送を終えるでしょう」。
Therefore, in response to a REPORT LUNS command, the SCSI layer at the target presents at most ALLOCATION LENGTH bytes of data (logical unit inventory) to iSCSI for transfer to the initiator. For a REPORT LUNS command, if the iSCSI EDTL is at least as large as the ALLOCATION LENGTH, the SCSI truncation ensures that the EDTL will accommodate all of the data to be transferred. If all of the logical unit inventory data presented to the iSCSI layer -- i.e., the data remaining after any SCSI truncation -- is transferred to the initiator by the iSCSI layer, an iSCSI Residual Overflow has not occurred and the iSCSI (O) bit MUST NOT be set in the SCSI Response or final SCSI Data-Out PDU. This is not a new requirement but is already required by the combination of [RFC3720] with the specification of the REPORT LUNS command in [SPC3]. However, if the iSCSI EDTL is larger than the ALLOCATION LENGTH in this scenario, note that the iSCSI Underflow MUST be signaled in the SCSI Response
したがって、REPORT LUNSコマンドに対応して、目標のSCSI層は創始者への転送のために、ALLOCATION LENGTHバイトのデータ(論理装置目録)をiSCSIに高々提示します。 REPORT LUNSコマンドのために、iSCSI EDTLがALLOCATION LENGTHと少なくとも同じくらい大きいなら、SCSIトランケーションは、EDTLが移すためにデータのすべてを収容するのを確実にします。 iSCSI層のそばでiSCSI層に提示された論理装置目録データのすべて(すなわち、どんなSCSIトランケーションの後にも残っているデータ)を創始者に移すなら、iSCSI Residual Overflowは起こっていません、そして、iSCSI(O)ビットはSCSI Responseか最終的な外のSCSI Data PDUに設定されてはいけません。 これが、新しい要件ではありませんが、REPORT LUNSコマンドの仕様への[RFC3720]の[SPC3]の組み合わせで既に必要です。 しかしながら、このシナリオでiSCSI EDTLがALLOCATION LENGTHより大きいなら、SCSI ResponseでiSCSI Underflowに合図しなければならないことに注意してください。
Chadalapaka Standards Track [Page 8] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[8ページ]RFC5048iSCSI修正と明確化2007年10月
PDU. An iSCSI Underflow MUST also be signaled when the iSCSI EDTL is equal to the ALLOCATION LENGTH but the logical unit inventory data presented to the iSCSI layer is smaller than the ALLOCATION LENGTH.
PDU。 また、iSCSI EDTLがALLOCATION LENGTHと等しいときにiSCSI Underflowに合図しなければなりませんが、iSCSI層に提示された論理装置目録データはALLOCATION LENGTHより小さいです。
The LUN LIST LENGTH field in the logical unit inventory (the first field in the inventory) is not affected by truncation of the inventory to fit in ALLOCATION LENGTH; this enables a SCSI initiator to determine that the received inventory is incomplete by noticing that the LUN LIST LENGTH in the inventory is larger than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A common initiator behavior in this situation is to re-issue the REPORT LUNS command with a larger ALLOCATION LENGTH.
論理装置目録(目録における最初の分野)のLUN LIST LENGTH分野は目録のトランケーションで影響を受けて、ALLOCATION LENGTHをうまくはめ込むことがないです。 これは、SCSI創始者が、目録のLUN LIST LENGTHがREPORT LUNS CDBで送られたALLOCATION LENGTHより大きいのに気付くことによって受け取られていている目録が不完全であると決心しているのを可能にします。 この状況における一般的な創始者の振舞いは、より大きいALLOCATION LENGTHとのREPORT LUNSコマンドを再発行することです。
3.2. R2T Ordering
3.2. R2T注文
Section 10.8 in [RFC3720] says the following:
[RFC3720]のセクション10.8は以下を言います:
The target may send several R2T PDUs. It, therefore, can have a
number of pending data transfers. The number of outstanding R2T
PDUs is limited by the value of the negotiated key
MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST be
fulfilled by the initiator in the order in which they were
received.
目標は数個のR2T PDUsを送るかもしれません。 したがって、それは多くの未定のデータ転送を持つことができます。 傑出しているR2T PDUsの数は交渉された主要なMaxOutstandingR2Tの値によって制限されます。 接続の中では、創始者は彼らが受け取られたオーダーに傑出しているR2Tsを実現させなければなりません。
The quoted [RFC3720] text was unclear on the scope of applicability -- either per task, or across all tasks on a connection -- and may be interpreted as either. This section is intended to clarify that the scope of applicability of the quoted text is a task. No R2T ordering relationship -- either in generation at the target or in fulfilling at the initiator -- across tasks is implied. That is, outstanding R2Ts within a task MUST be fulfilled by the initiator in the order in which they were received on a connection.
引用された[RFC3720]テキストは、タスクか、接続に関するすべてのタスクの向こう側の適用性の範囲で不明瞭であり、解釈されるかもしれません。 このセクションはそれをはっきりさせることを意図して、引用されたテキストの適用性の範囲がタスクであるということです。 タスクの向こう側に目標の世代か創始者での実現における関係を命令するR2Tが全く含意されません。 創始者は彼らが接続の上に受け取られたオーダーにすなわち、タスクの中の傑出しているR2Tsを実現させなければなりません。
3.3. Model Assumptions for Response Ordering
3.3. 応答注文のためのモデル仮定
Whenever an iSCSI session is composed of multiple connections, the Response PDUs (task responses or TMF responses) originating in the target SCSI layer are distributed onto the multiple connections by the target iSCSI layer according to iSCSI connection allegiance rules. This process generally may not preserve the ordering of the responses by the time they are delivered to the initiator SCSI layer. Since ordering is not expected across SCSI responses anyway, this approach works fine in the general case. However, to address the special cases where some ordering is desired by the SCSI layer, the following "Response Fence" semantics are defined with respect to handling SCSI response messages as they are handed off from the SCSI protocol layer to the iSCSI layer.
iSCSIセッションが複数の接続で構成されるときはいつも、iSCSI接続忠誠規則に従って、目標SCSI層で起こるResponse PDUs(タスク応答かTMF応答)は目標iSCSI層によって複数の接続に分配されます。 一般に、この過程は創始者SCSI層にそれらを渡す時までに応答の注文を保存しないかもしれません。 以来、注文はとにかく、このアプローチが一般的な場合できめ細かに扱うSCSI応答の向こう側に予想されません。 しかしながら、特別なケースを記述するために、以下の「応答フェンス」意味論はそれらがSCSIプロトコル層からiSCSI層まで渡されるのでSCSI応答メッセージを扱いながら、いくつかの注文がどこでSCSI層によって望まれているかが定義されます。
Chadalapaka Standards Track [Page 9] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[9ページ]RFC5048iSCSI修正と明確化2007年10月
3.3.1. Model Description
3.3.1. モデル記述
The target SCSI protocol layer hands off the SCSI response messages to the target iSCSI layer by invoking the "Send Command Complete" protocol data service ([SAM2], clause 5.4.2) and "Task Management Function Executed" ([SAM2], clause 6.9) service. On receiving the SCSI response message, the iSCSI layer exhibits the Response Fence behavior for certain SCSI response messages (Section 3.3.3 describes the specific instances where the semantics must be realized). Whenever the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST ensure that the following conditions are met in delivering the response message to the initiator iSCSI layer:
「完全な状態でコマンドを送ってください」を呼び出すのによる目標iSCSI層へのSCSI応答メッセージに目標SCSIプロトコル層干渉しないでくださいというのはデータサービス[SAM2]について議定書の中で述べます、節、5.4、.2、)、「実行されたタスク管理機能」[SAM2]6.9番目の節) (サービス) SCSI応答メッセージを受けると、iSCSI層はあるSCSI応答メッセージのためのResponse Fenceの振舞いを示します(セクション3.3.3は意味論を実現しなければならない特定の例について説明します)。 Response Fenceの振舞いがSCSI応答メッセージに必要であるときはいつも、目標iSCSI層は、以下の条件が創始者iSCSI層に応答メッセージを渡す際に満たされるのを確実にしなければなりません:
(1) Response with Response Fence MUST be delivered chronologically
after all the "preceding" responses on the I_T_L nexus, if the
preceding responses are delivered at all, to the initiator iSCSI
layer.
(1) I_T_L結びつきにおけるすべての「前」の応答の後に年代順にResponse Fenceとの応答を提供しなければなりません、前の応答を少しでも提供するなら、創始者iSCSI層に。
(2) Response with Response Fence MUST be delivered chronologically
prior to all the "following" responses on the I_T_L nexus.
(2) I_T_L結びつきにおけるすべての「次の」の応答の前に年代順にResponse Fenceとの応答を提供しなければなりません。
The "preceding" and "following" notions refer to the order of handoff of a response message from the target SCSI protocol layer to the target iSCSI layer.
「先行」と概念に「続く」と、応答メッセージの目標SCSIプロトコル層から目標iSCSI層までの移管の注文は示されます。
3.3.2. iSCSI Semantics with the Interface Model
3.3.2. インタフェースモデルがあるiSCSI意味論
Whenever the TaskReporting key (Section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session and the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST perform the actions described in this section for that session.
TaskReportingキー(セクション9.1)がiSCSIセッションのためにResponseFenceかFastAbortと交渉されて、Response Fenceの振舞いがSCSI応答メッセージに必要であるときはいつも、目標iSCSI層はそのセッションのためにこのセクションで説明された動作を実行しなければなりません。
a) If it is a single-connection session, no special processing is
required. The standard SCSI Response PDU build and dispatch
process happens.
a) それが単独結合セッションであるなら、どんな特別な処理も必要ではありません。 標準のSCSI Response PDUは建てます、そして、発信の過程は起こります。
b) If it is a multi-connection session, the target iSCSI layer
takes note of the last-sent and unacknowledged StatSN on each
of the connections in the iSCSI session, and waits for an
acknowledgement (NOP-In PDUs MAY be used to solicit
acknowledgements as needed in order to accelerate this process)
of each such StatSN to clear the fence. The SCSI response
requiring Response Fence behavior MUST NOT be sent to the
initiator before acknowledgements are received for each of the
unacknowledged StatSNs.
b) それがマルチ接続セッションであるなら、目標iSCSI層は、iSCSIセッションにおける接続各人のときに最後、送られて不承認のStatSNに注目して、そのようなそれぞれのStatSNの承認(中のNOP PDUsはこの過程を加速するために必要に応じて承認に請求するのに使用されるかもしれない)がフェンスをきれいにするのを待っています。 それぞれの不承認のStatSNsのために承認を受ける前にResponse Fenceの振舞いを必要とするSCSI応答を創始者に送ってはいけません。
Chadalapaka Standards Track [Page 10] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[10ページ]RFC5048iSCSI修正と明確化2007年10月
c) The target iSCSI layer must wait for an acknowledgement of the
SCSI Response PDU that carried the SCSI response requiring the
Response Fence behavior. The fence MUST be considered cleared
only after receiving the acknowledgement.
c) 目標iSCSI層はResponse Fenceの振舞いを必要とするSCSI応答を運んだSCSI Response PDUの承認を待たなければなりません。 承認を受けた後にだけクリアされているとフェンスを考えなければなりません。
d) All further status processing for the LU is resumed only after
clearing the fence. If any new responses for the I_T_L nexus
are received from the SCSI layer before the fence is cleared,
those Response PDUs MUST be held and queued at the iSCSI layer
until the fence is cleared.
d) フェンスをきれいにした後にだけ、LUのためのさらなるすべての状態処理が再開されます。 フェンスをきれいにする前にSCSI層から何かI_T_L結びつきのための新しい応答を受けるなら、フェンスがきれいにされるまで、iSCSI層にそれらのResponse PDUsを保持して、列に並ばせなければなりません。
3.3.3. Current List of Fenced Response Use Cases
3.3.3. 囲われた応答の現在のリストはケースを使用します。
This section lists the fenced response use cases that iSCSI implementations MUST comply with. However, this is not an exhaustive enumeration. It is expected that as SCSI protocol specifications evolve, the specifications will specify when response fencing is required on a case-by-case basis.
This section lists the fenced response use cases that iSCSI implementations MUST comply with. However, this is not an exhaustive enumeration. It is expected that as SCSI protocol specifications evolve, the specifications will specify when response fencing is required on a case-by-case basis.
Whenever the TaskReporting key (Section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session, the target iSCSI layer MUST assume that the Response Fence is required for the following SCSI completion messages:
Whenever the TaskReporting key (Section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session, the target iSCSI layer MUST assume that the Response Fence is required for the following SCSI completion messages:
1. The first completion message carrying the UA after the multi-
task abort on issuing and third-party sessions. See Section
4.1.1 for related TMF discussion.
1. The first completion message carrying the UA after the multi- task abort on issuing and third-party sessions. See Section 4.1.1 for related TMF discussion.
2. The TMF Response carrying the multi-task TMF Response on the
issuing session.
2. The TMF Response carrying the multi-task TMF Response on the issuing session.
3. The completion message indicating ACA establishment on the
issuing session.
3. The completion message indicating ACA establishment on the issuing session.
4. The first completion message carrying the ACA ACTIVE status
after ACA establishment on issuing and third-party sessions.
4. The first completion message carrying the ACA ACTIVE status after ACA establishment on issuing and third-party sessions.
5. The TMF Response carrying the Clear ACA response on the issuing
session.
5. The TMF Response carrying the Clear ACA response on the issuing session.
6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT
command.
6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT command.
Note: Due to the absence of ACA-related fencing requirements in [RFC3720], initiator implementations SHOULD NOT use ACA on multi- connection iSCSI sessions to targets complying only with [RFC3720]. Initiators that want to employ ACA on multi-connection iSCSI sessions
Note: Due to the absence of ACA-related fencing requirements in [RFC3720], initiator implementations SHOULD NOT use ACA on multi- connection iSCSI sessions to targets complying only with [RFC3720]. Initiators that want to employ ACA on multi-connection iSCSI sessions
Chadalapaka Standards Track [Page 11] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 11] RFC 5048 iSCSI Corrections and Clarifications October 2007
SHOULD first assess response-fencing behavior via negotiating for ResponseFence or FastAbort values for the TaskReporting (Section 9.1) key.
SHOULD first assess response-fencing behavior via negotiating for ResponseFence or FastAbort values for the TaskReporting (Section 9.1) key.
4. Task Management
4. Task Management
4.1. Requests Affecting Multiple Tasks
4.1. Requests Affecting Multiple Tasks
This section clarifies and updates the original text in Section 10.6.2 of [RFC3720]. The clarified semantics (Section 4.1.2) are a superset of the protocol behavior required in the original text and all iSCSI implementations MUST support the new behavior. The updated semantics (Section 4.1.3) on the other hand are mandatory only when the new key TaskReporting (Section 9.1) is negotiated to "FastAbort".
This section clarifies and updates the original text in Section 10.6.2 of [RFC3720]. The clarified semantics (Section 4.1.2) are a superset of the protocol behavior required in the original text and all iSCSI implementations MUST support the new behavior. The updated semantics (Section 4.1.3) on the other hand are mandatory only when the new key TaskReporting (Section 9.1) is negotiated to "FastAbort".
4.1.1. Scope of Affected Tasks
4.1.1. Scope of Affected Tasks
This section defines the notion of "affected tasks" in multi-task abort scenarios. Scope definitions in this section apply to both the clarified protocol behavior (Section 4.1.2) and the updated protocol behavior (Section 4.1.3).
This section defines the notion of "affected tasks" in multi-task abort scenarios. Scope definitions in this section apply to both the clarified protocol behavior (Section 4.1.2) and the updated protocol behavior (Section 4.1.3).
ABORT TASK SET: All outstanding tasks for the I_T_L nexus
identified by the LUN field in the ABORT TASK SET TMF Request
PDU.
ABORT TASK SET: All outstanding tasks for the I_T_L nexus identified by the LUN field in the ABORT TASK SET TMF Request PDU.
CLEAR TASK SET: All outstanding tasks in the task set for the LU
identified by the LUN field in the CLEAR TASK SET TMF Request
PDU. See [SPC3] for the definition of a "task set".
CLEAR TASK SET: All outstanding tasks in the task set for the LU identified by the LUN field in the CLEAR TASK SET TMF Request PDU. See [SPC3] for the definition of a "task set".
LOGICAL UNIT RESET: All outstanding tasks from all initiators for
the LU identified by the LUN field in the LOGICAL UNIT RESET
Request PDU.
LOGICAL UNIT RESET: All outstanding tasks from all initiators for the LU identified by the LUN field in the LOGICAL UNIT RESET Request PDU.
TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from
all initiators across all LUs to which the TMF-issuing session
has access on the SCSI target device hosting the iSCSI session.
TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from all initiators across all LUs to which the TMF-issuing session has access on the SCSI target device hosting the iSCSI session.
Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text is an iSCSI TMF Request PDU with the "Function" field set to "ABORT TASK SET" as defined in [RFC3720]. Similar usage is employed for other scope descriptions.
Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text is an iSCSI TMF Request PDU with the "Function" field set to "ABORT TASK SET" as defined in [RFC3720]. Similar usage is employed for other scope descriptions.
Chadalapaka Standards Track [Page 12] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 12] RFC 5048 iSCSI Corrections and Clarifications October 2007
4.1.2. Clarified Multi-Task Abort Semantics
4.1.2. Clarified Multi-Task Abort Semantics
All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
The initiator iSCSI layer:
The initiator iSCSI layer:
a. MUST continue to respond to each TTT received for the affected
tasks.
a. MUST continue to respond to each TTT received for the affected tasks.
b. SHOULD process any responses received for affected tasks in the
normal fashion. This is acceptable because the responses are
guaranteed to have been sent prior to the TMF response.
b. SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF response.
c. SHOULD receive the TMF Response concluding all the tasks in the
set of affected tasks unless the initiator has done something
(e.g., LU reset, connection drop) that may prevent the TMF
Response from being sent or received. The initiator MUST thus
conclude all affected tasks as part of this step in either
case, and MUST discard any TMF Response received after the
affected tasks are concluded.
c. SHOULD receive the TMF Response concluding all the tasks in the set of affected tasks unless the initiator has done something (e.g., LU reset, connection drop) that may prevent the TMF Response from being sent or received. The initiator MUST thus conclude all affected tasks as part of this step in either case, and MUST discard any TMF Response received after the affected tasks are concluded.
The target iSCSI layer:
The target iSCSI layer:
a. MUST wait for responses on currently valid target-transfer tags
of the affected tasks from the issuing initiator. MAY wait for
responses on currently valid target-transfer tags of the
affected tasks from third-party initiators.
a. MUST wait for responses on currently valid target-transfer tags of the affected tasks from the issuing initiator. MAY wait for responses on currently valid target-transfer tags of the affected tasks from third-party initiators.
b. MUST wait (concurrent with the wait in Step a) for all commands
of the affected tasks to be received based on the CmdSN
ordering. SHOULD NOT wait for new commands on third-party
affected sessions -- only the instantiated tasks have to be
considered for the purpose of determining the affected tasks.
In the case of target-scoped requests (i.e., TARGET WARM RESET
and TARGET COLD RESET), all of the commands that are not yet
received on the issuing session in the command stream however
can be considered to have been received with no command waiting
period -- i.e., the entire CmdSN space up to the CmdSN of the
task management function can be "plugged".
b. MUST wait (concurrent with the wait in Step a) for all commands of the affected tasks to be received based on the CmdSN ordering. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
c. MUST propagate the TMF request to and receive the response from
the target SCSI layer.
c. MUST propagate the TMF request to and receive the response from the target SCSI layer.
Chadalapaka Standards Track [Page 13] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 13] RFC 5048 iSCSI Corrections and Clarifications October 2007
d. MUST provide the Response Fence behavior for the TMF Response
on the issuing session as specified in Section 3.3.2.
d. MUST provide the Response Fence behavior for the TMF Response on the issuing session as specified in Section 3.3.2.
e. MUST provide the Response Fence behavior on the first post-TMF
Response on third-party sessions as specified in Section 3.3.2.
If some tasks originate from non-iSCSI I_T_L nexuses, then the
means by which the target ensures that all affected tasks have
returned their status to the initiator are defined by the
specific non-iSCSI transport protocol(s).
e. MUST provide the Response Fence behavior on the first post-TMF Response on third-party sessions as specified in Section 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses, then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
Technically, the TMF servicing is complete in Step d. Data transfers corresponding to terminated tasks may however still be in progress on third-party iSCSI sessions even at the end of Step e. The TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step d, and MAY be sent at the end of Step d despite these outstanding data transfers until after Step e.
Technically, the TMF servicing is complete in Step d. Data transfers corresponding to terminated tasks may however still be in progress on third-party iSCSI sessions even at the end of Step e. The TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step d, and MAY be sent at the end of Step d despite these outstanding data transfers until after Step e.
4.1.3. Updated Multi-Task Abort Semantics
4.1.3. Updated Multi-Task Abort Semantics
Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
The initiator iSCSI layer:
The initiator iSCSI layer:
a. MUST NOT send any more Data-Out PDUs for affected tasks on the
issuing connection of the issuing iSCSI session once the TMF is
sent to the target.
a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target.
b. SHOULD process any responses received for affected tasks in the
normal fashion. This is acceptable because the responses are
guaranteed to have been sent prior to the TMF response.
b. SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF response.
c. MUST respond to each Async Message PDU with AsyncEvent=5 as
defined in Section 8.1.
c. MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1.
d. MUST treat the TMF response as terminating all affected tasks
for which responses have not been received, and MUST discard
any responses for affected tasks received after the TMF
response is passed to the SCSI layer (although the semantics
d. MUST treat the TMF response as terminating all affected tasks for which responses have not been received, and MUST discard any responses for affected tasks received after the TMF response is passed to the SCSI layer (although the semantics
Chadalapaka Standards Track [Page 14] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 14] RFC 5048 iSCSI Corrections and Clarifications October 2007
defined in this section ensure that such an out-of-order
scenario will never happen with a compliant target
implementation).
defined in this section ensure that such an out-of-order scenario will never happen with a compliant target implementation).
The target iSCSI layer:
The target iSCSI layer:
a. MUST wait for all commands of the affected tasks to be received
based on the CmdSN ordering on the issuing session. SHOULD NOT
wait for new commands on third-party affected sessions -- only
the instantiated tasks have to be considered for the purpose of
determining the affected tasks. In the case of target-scoped
requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all
the commands that are not yet received on the issuing session
in the command stream can be considered to have been received
with no command waiting period -- i.e., the entire CmdSN space
up to the CmdSN of the task management function can be
"plugged".
a. MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
b. MUST propagate the TMF request to and receive the response from
the target SCSI layer.
b. MUST propagate the TMF request to and receive the response from the target SCSI layer.
c. MUST leave all active "affected TTTs" (i.e., active TTTs
associated with affected tasks) valid.
c. MUST leave all active "affected TTTs" (i.e., active TTTs associated with affected tasks) valid.
d. MUST send an Asynchronous Message PDU with AsyncEvent=5
(Section 8.1) on:
d. MUST send an Asynchronous Message PDU with AsyncEvent=5 (Section 8.1) on:
i) each connection of each third-party session to which at
least one affected task is allegiant if
TaskReporting=FastAbort is operational on that third-party
session, and
i) each connection of each third-party session to which at least one affected task is allegiant if TaskReporting=FastAbort is operational on that third-party session, and
ii) each connection except the issuing connection of the
issuing session that has at least one allegiant affected
task.
ii) each connection except the issuing connection of the issuing session that has at least one allegiant affected task.
If there are multiple affected LUs (say, due to a target reset),
then one Async Message PDU MUST be sent for each such LU on each
connection that has at least one allegiant affected task. The LUN
field in the Asynchronous Message PDU MUST be set to match the LUN
for each such LU.
If there are multiple affected LUs (say, due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task. The LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
e. MUST address the Response Fence flag on the TMF Response on the
issuing session as defined in Section 3.3.2.
e. MUST address the Response Fence flag on the TMF Response on the issuing session as defined in Section 3.3.2.
f. MUST address the Response Fence flag on the first post-TMF
Response on third-party sessions as defined in Section 3.3.2.
If some tasks originate from non-iSCSI I_T_L nexuses, then the
f. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in Section 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses, then the
Chadalapaka Standards Track [Page 15] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 15] RFC 5048 iSCSI Corrections and Clarifications October 2007
means by which the target ensures that all affected tasks have
returned their status to the initiator are defined by the
specific non-iSCSI transport protocol(s).
means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
g. MUST free up the affected TTTs (and STags, if applicable) and
the corresponding buffers, if any, once it receives each
associated NOP-Out acknowledgement that the initiator generated
in response to each Async Message.
g. MUST free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once it receives each associated NOP-Out acknowledgement that the initiator generated in response to each Async Message.
Technically, the TMF servicing is complete in Step e. Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step f. A TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step e, and MAY be sent at the end of Step e despite these outstanding Data transfers until Step g. Step g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers.
Technically, the TMF servicing is complete in Step e. Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step f. A TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step e, and MAY be sent at the end of Step e despite these outstanding Data transfers until Step g. Step g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers.
4.1.3.1. Clearing Effects Update
4.1.3.1. Clearing Effects Update
Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU resets on "Incomplete TTTs" as "Y". This meant that a target warm reset or a target cold reset or an LU reset would clear the active TTTs upon completion. However, the TaskReporting=FastAbort (Section 9.1) semantics defined by this section do not guarantee that the active TTTs are cleared by the end of the reset operations. In fact, the new semantics are designed to allow clearing the TTTs in a "lazy" fashion after the TMF Response is delivered. Thus, when TaskReporting=FastAbort is operational on a session, the clearing effects of reset operations on "Incomplete TTTs" is "N".
Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU resets on "Incomplete TTTs" as "Y". This meant that a target warm reset or a target cold reset or an LU reset would clear the active TTTs upon completion. However, the TaskReporting=FastAbort (Section 9.1) semantics defined by this section do not guarantee that the active TTTs are cleared by the end of the reset operations. In fact, the new semantics are designed to allow clearing the TTTs in a "lazy" fashion after the TMF Response is delivered. Thus, when TaskReporting=FastAbort is operational on a session, the clearing effects of reset operations on "Incomplete TTTs" is "N".
4.1.4. Affected Tasks Shared across RFC 3720 and FastAbort Sessions
4.1.4. Affected Tasks Shared across RFC 3720 and FastAbort Sessions
If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality (Section 9.1), it may end up in a situation where some sessions have TaskReporting=RFC3720 operational (RFC 3720 sessions) while some other sessions have TaskReporting=FastAbort operational (FastAbort sessions) even while accessing a shared set of affected tasks (Section 4.1.1).
If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality (Section 9.1), it may end up in a situation where some sessions have TaskReporting=RFC3720 operational (RFC 3720 sessions) while some other sessions have TaskReporting=FastAbort operational (FastAbort sessions) even while accessing a shared set of affected tasks (Section 4.1.1).
If the issuing session is an RFC 3720 session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is a FastAbort session, the following behavior SHOULD be exhibited by the iSCSI target layer:
If the issuing session is an RFC 3720 session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is a FastAbort session, the following behavior SHOULD be exhibited by the iSCSI target layer:
a. Between Steps c and d of the target behavior in Section 4.1.2,
send an Asynchronous Message PDU with AsyncEvent=5 (Section
8.1) on each connection of each third-party session to which at
least one affected task is allegiant. If there are multiple
a. Between Steps c and d of the target behavior in Section 4.1.2, send an Asynchronous Message PDU with AsyncEvent=5 (Section 8.1) on each connection of each third-party session to which at least one affected task is allegiant. If there are multiple
Chadalapaka Standards Track [Page 16] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 16] RFC 5048 iSCSI Corrections and Clarifications October 2007
affected LUs, then send one Async Message PDU for each such LU
on each connection that has at least one allegiant affected
task. When sent, the LUN field in the Asynchronous Message PDU
MUST be set to match the LUN for each such LU.
affected LUs, then send one Async Message PDU for each such LU on each connection that has at least one allegiant affected task. When sent, the LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
b. After Step e of the target behavior in Section 4.1.2, free up
the affected TTTs (and STags, if applicable) and the
corresponding buffers, if any, once each associated NOP-Out
acknowledgement is received that the third-party initiator
generated in response to each Async Message sent in Step a.
b. After Step e of the target behavior in Section 4.1.2, free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once each associated NOP-Out acknowledgement is received that the third-party initiator generated in response to each Async Message sent in Step a.
If the issuing session is a FastAbort session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is an RFC 3720 session, the following behavior MUST be exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST NOT be sent on the third-party session to prompt the FastAbort behavior.
If the issuing session is a FastAbort session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is an RFC 3720 session, the following behavior MUST be exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST NOT be sent on the third-party session to prompt the FastAbort behavior.
If the third-party affected session is a FastAbort session and the issuing session is a FastAbort session, the initiator in the third- party role MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1. Note that an initiator MAY thus receive these Async Messages on a third-party affected session even if the session is a single-connection session.
If the third-party affected session is a FastAbort session and the issuing session is a FastAbort session, the initiator in the third- party role MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1. Note that an initiator MAY thus receive these Async Messages on a third-party affected session even if the session is a single-connection session.
4.1.5. Implementation Considerations
4.1.5. Implementation Considerations
Both in clarified semantics (Section 4.1.2) and updated semantics (Section 4.1.3), there may be outstanding data transfers even after the TMF completion is reported on the issuing session. In the case of iSCSI/iSER [iSER], these would be tagged data transfers for STags not owned by any active tasks. Whether or not real buffers support these data transfers is implementation-dependent. However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases. A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-Out sequences (Section 4.1.2) or NOP- Out acknowledgements (Section 4.1.3) so as to reclaim the associated buffer, STag, and TTT resources as appropriate.
Both in clarified semantics (Section 4.1.2) and updated semantics (Section 4.1.3), there may be outstanding data transfers even after the TMF completion is reported on the issuing session. In the case of iSCSI/iSER [iSER], these would be tagged data transfers for STags not owned by any active tasks. Whether or not real buffers support these data transfers is implementation-dependent. However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases. A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-Out sequences (Section 4.1.2) or NOP- Out acknowledgements (Section 4.1.3) so as to reclaim the associated buffer, STag, and TTT resources as appropriate.
4.1.6. Rationale behind the New Semantics
4.1.6. Rationale behind the New Semantics
There are fundamentally three basic objectives behind the semantics specified in Sections 4.1.2 and 4.1.3.
There are fundamentally three basic objectives behind the semantics specified in Sections 4.1.2 and 4.1.3.
1. Maintaining an ordered command flow I_T nexus abstraction to
the target SCSI layer even with multi-connection sessions.
1. Maintaining an ordered command flow I_T nexus abstraction to the target SCSI layer even with multi-connection sessions.
Chadalapaka Standards Track [Page 17] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 17] RFC 5048 iSCSI Corrections and Clarifications October 2007
o Target iSCSI processing of a TMF request must maintain the
single flow illusion. Target behavior in Step b of Section
4.1.2 and Step a of Section 4.1.3 correspond to this
objective.
o Target iSCSI processing of a TMF request must maintain the single flow illusion. Target behavior in Step b of Section 4.1.2 and Step a of Section 4.1.3 correspond to this objective.
2. Maintaining a single ordered response flow I_T nexus
abstraction to the initiator SCSI layer even with multi-
connection sessions when one response (i.e., TMF response)
could imply the status of other unfinished tasks from the
initiator's perspective.
2. Maintaining a single ordered response flow I_T nexus abstraction to the initiator SCSI layer even with multi- connection sessions when one response (i.e., TMF response) could imply the status of other unfinished tasks from the initiator's perspective.
o The target must ensure that the initiator does not see "old"
task responses (that were placed on the wire chronologically
earlier than the TMF Response) after seeing the TMF
response. The target behavior in Step d of Section 4.1.2
and Step e of Section 4.1.3 correspond to this objective.
o The target must ensure that the initiator does not see "old" task responses (that were placed on the wire chronologically earlier than the TMF Response) after seeing the TMF response. The target behavior in Step d of Section 4.1.2 and Step e of Section 4.1.3 correspond to this objective.
o Whenever the result of a TMF action is visible across
multiple I_T_L nexuses, [SAM2] requires the SCSI device
server to trigger a UA on each of the other I_T_L nexuses.
Once an initiator is notified of such an UA, the application
client on the receiving initiator is required to clear its
task state (clause 5.5 in [SAM2]) for the affected tasks.
It would thus be inappropriate to deliver a SCSI Response
for a task after the task state is cleared on the initiator,
i.e., after the UA is notified. The UA notification
contained in the first SCSI Response PDU on each affected
Third-party I_T_L nexus after the TMF action thus MUST NOT
pass the affected task responses on any of the iSCSI
sessions accessing the LU. The target behavior in Step e of
Section 4.1.2 and Step f of Section 4.1.3 correspond to this
objective.
o Whenever the result of a TMF action is visible across multiple I_T_L nexuses, [SAM2] requires the SCSI device server to trigger a UA on each of the other I_T_L nexuses. Once an initiator is notified of such an UA, the application client on the receiving initiator is required to clear its task state (clause 5.5 in [SAM2]) for the affected tasks. It would thus be inappropriate to deliver a SCSI Response for a task after the task state is cleared on the initiator, i.e., after the UA is notified. The UA notification contained in the first SCSI Response PDU on each affected Third-party I_T_L nexus after the TMF action thus MUST NOT pass the affected task responses on any of the iSCSI sessions accessing the LU. The target behavior in Step e of Section 4.1.2 and Step f of Section 4.1.3 correspond to this objective.
3. Draining all active TTTs corresponding to affected tasks in a
deterministic fashion.
3. Draining all active TTTs corresponding to affected tasks in a deterministic fashion.
o Data-Out PDUs with stale TTTs arriving after the tasks are
terminated can create a buffer management problem even for
traditional iSCSI implementations, and is fatal for the
connection for iSCSI/iSER implementations. Either the
termination of affected tasks should be postponed until the
TTTs are retired (as in Step a of Section 4.1.2), or the
TTTs and the buffers should stay allocated beyond task
termination to be deterministically freed up later (as in
Steps c and g of Section 4.1.3).
o Data-Out PDUs with stale TTTs arriving after the tasks are terminated can create a buffer management problem even for traditional iSCSI implementations, and is fatal for the connection for iSCSI/iSER implementations. Either the termination of affected tasks should be postponed until the TTTs are retired (as in Step a of Section 4.1.2), or the TTTs and the buffers should stay allocated beyond task termination to be deterministically freed up later (as in Steps c and g of Section 4.1.3).
The only other notable optimization is the plugging. If all tasks on an I_T nexus will be aborted anyway (as with a target reset), there
The only other notable optimization is the plugging. If all tasks on an I_T nexus will be aborted anyway (as with a target reset), there
Chadalapaka Standards Track [Page 18] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 18] RFC 5048 iSCSI Corrections and Clarifications October 2007
is no need to wait to receive all commands to plug the CmdSN holes. The target iSCSI layer can simply plug all missing CmdSN slots and move on with TMF processing. The first objective (maintaining a single ordered command flow) is still met with this optimization because the target SCSI layer only sees ordered commands.
is no need to wait to receive all commands to plug the CmdSN holes. The target iSCSI layer can simply plug all missing CmdSN slots and move on with TMF processing. The first objective (maintaining a single ordered command flow) is still met with this optimization because the target SCSI layer only sees ordered commands.
5. Discovery Semantics
5. Discovery Semantics
5.1. Error Recovery for Discovery Sessions
5.1. Error Recovery for Discovery Sessions
The negotiation of the key ErrorRecoveryLevel is not required for Discovery sessions -- i.e., for sessions that negotiated "SessionType=Discovery" -- because the default value of 0 is necessary and sufficient for Discovery sessions. It is however possible that some legacy iSCSI implementations might attempt to negotiate the ErrorRecoveryLevel key on Discovery sessions. When such a negotiation attempt is made by the remote side, a compliant iSCSI implementation MUST propose a value of 0 (zero) in response. The operational ErrorRecoveryLevel for Discovery sessions thus MUST be 0. This naturally follows from the functionality constraints that [RFC3720] imposes on Discovery sessions.
The negotiation of the key ErrorRecoveryLevel is not required for Discovery sessions -- i.e., for sessions that negotiated "SessionType=Discovery" -- because the default value of 0 is necessary and sufficient for Discovery sessions. It is however possible that some legacy iSCSI implementations might attempt to negotiate the ErrorRecoveryLevel key on Discovery sessions. When such a negotiation attempt is made by the remote side, a compliant iSCSI implementation MUST propose a value of 0 (zero) in response. The operational ErrorRecoveryLevel for Discovery sessions thus MUST be 0. This naturally follows from the functionality constraints that [RFC3720] imposes on Discovery sessions.
5.2. Reinstatement Semantics of Discovery Sessions
5.2. Reinstatement Semantics of Discovery Sessions
Discovery sessions are intended to be relatively short-lived. Initiators are not expected to establish multiple Discovery sessions to the same iSCSI Network Portal (see [RFC3720]). An initiator may use the same iSCSI Initiator Name and ISID when establishing different unique sessions with different targets and/or different portal groups. This behavior is discussed in Section 9.1.1 of [RFC3720] and is, in fact, encouraged as conservative reuse of ISIDs. The ISID RULE in [RFC3720] states that there must not be more than one session with a matching 4-tuple: <InitiatorName, ISID, TargetName, TargetPortalGroupTag>. While the spirit of the ISID RULE applies to Discovery sessions the same as it does for Normal sessions, note that some Discovery sessions differ from the Normal sessions in two important aspects:
Discovery sessions are intended to be relatively short-lived. Initiators are not expected to establish multiple Discovery sessions to the same iSCSI Network Portal (see [RFC3720]). An initiator may use the same iSCSI Initiator Name and ISID when establishing different unique sessions with different targets and/or different portal groups. This behavior is discussed in Section 9.1.1 of [RFC3720] and is, in fact, encouraged as conservative reuse of ISIDs. The ISID RULE in [RFC3720] states that there must not be more than one session with a matching 4-tuple: <InitiatorName, ISID, TargetName, TargetPortalGroupTag>. While the spirit of the ISID RULE applies to Discovery sessions the same as it does for Normal sessions, note that some Discovery sessions differ from the Normal sessions in two important aspects:
Because [RFC3720] allows a Discovery session to be established
without specifying a TargetName key in the Login Request PDU (let
us call such a session an "Unnamed" Discovery session), there is
no Target Node context to enforce the ISID RULE.
Because [RFC3720] allows a Discovery session to be established without specifying a TargetName key in the Login Request PDU (let us call such a session an "Unnamed" Discovery session), there is no Target Node context to enforce the ISID RULE.
Portal Groups are defined only in the context of a Target Node.
When the TargetName key is NULL-valued (i.e., not specified), the
TargetPortalGroupTag thus cannot be ascertained to enforce the
ISID RULE.
Portal Groups are defined only in the context of a Target Node. When the TargetName key is NULL-valued (i.e., not specified), the TargetPortalGroupTag thus cannot be ascertained to enforce the ISID RULE.
Chadalapaka Standards Track [Page 19] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 19] RFC 5048 iSCSI Corrections and Clarifications October 2007
The following sections describe the two scenarios -- Named Discovery sessions and Unnamed Discovery sessions -- separately.
The following sections describe the two scenarios -- Named Discovery sessions and Unnamed Discovery sessions -- separately.
5.2.1. Unnamed Discovery Sessions
5.2.1. Unnamed Discovery Sessions
For Unnamed Discovery sessions, neither the TargetName nor the TargetPortalGroupTag is available to the targets in order to enforce the ISID RULE. So the following rule applies.
For Unnamed Discovery sessions, neither the TargetName nor the TargetPortalGroupTag is available to the targets in order to enforce the ISID RULE. So the following rule applies.
UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the following 4-tuple for Unnamed Discovery sessions: <InitiatorName, ISID, NULL, TargetAddress>. The following semantics are implied by this uniqueness requirement.
UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the following 4-tuple for Unnamed Discovery sessions: <InitiatorName, ISID, NULL, TargetAddress>. The following semantics are implied by this uniqueness requirement.
Targets SHOULD allow concurrent establishment of one Discovery session with each of its Network Portals by the same initiator port with a given iSCSI Node Name and an ISID. Each of the concurrent Discovery sessions, if established by the same initiator port to other Network Portals, MUST be treated as independent sessions -- i.e., one session MUST NOT reinstate the other.
Targets SHOULD allow concurrent establishment of one Discovery session with each of its Network Portals by the same initiator port with a given iSCSI Node Name and an ISID. Each of the concurrent Discovery sessions, if established by the same initiator port to other Network Portals, MUST be treated as independent sessions -- i.e., one session MUST NOT reinstate the other.
A new Unnamed Discovery session that has a matching <InitiatorName, ISID, NULL, TargetAddress> to an existing Discovery session MUST reinstate the existing Unnamed Discovery session. Note thus that only an Unnamed Discovery session may reinstate an Unnamed Discovery session.
A new Unnamed Discovery session that has a matching <InitiatorName, ISID, NULL, TargetAddress> to an existing Discovery session MUST reinstate the existing Unnamed Discovery session. Note thus that only an Unnamed Discovery session may reinstate an Unnamed Discovery session.
5.2.2. Named Discovery Sessions
5.2.2. Named Discovery Sessions
For a Named Discovery session, the TargetName key is specified by the initiator and thus the target can unambiguously ascertain the TargetPortalGroupTag as well. Since all the four elements of the 4- tuple are known, the ISID RULE MUST be enforced by targets with no changes from [RFC3720] semantics. A new session with a matching <InitiatorName, ISID, TargetName, TargetPortalGroupTag> thus will reinstate an existing session. Note in this case that any new iSCSI session (Discovery or Normal) with the matching 4-tuple may reinstate an existing Named Discovery iSCSI session.
For a Named Discovery session, the TargetName key is specified by the initiator and thus the target can unambiguously ascertain the TargetPortalGroupTag as well. Since all the four elements of the 4- tuple are known, the ISID RULE MUST be enforced by targets with no changes from [RFC3720] semantics. A new session with a matching <InitiatorName, ISID, TargetName, TargetPortalGroupTag> thus will reinstate an existing session. Note in this case that any new iSCSI session (Discovery or Normal) with the matching 4-tuple may reinstate an existing Named Discovery iSCSI session.
5.3. Target PDUs during Discovery
5.3. Target PDUs during Discovery
Targets SHOULD NOT send any responses other than a Text Response and Logout Response on a Discovery session, once in Full Feature Phase.
Targets SHOULD NOT send any responses other than a Text Response and Logout Response on a Discovery session, once in Full Feature Phase.
Implementation Note: A target may simply drop the connection in a Discovery session when it would have requested a Logout via an Async Message on Normal sessions.
Implementation Note: A target may simply drop the connection in a Discovery session when it would have requested a Logout via an Async Message on Normal sessions.
Chadalapaka Standards Track [Page 20] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka Standards Track [Page 20] RFC 5048 iSCSI Corrections and Clarifications October 2007
6. Negotiation and Others
6. Negotiation and Others
6.1. TPGT Values
6.1. TPGT Values
[SAM2] and [SAM3] specifications incorrectly note in their informative text that TPGT value should be non-zero, although [RFC3720] allows the value of zero for TPGT. This section is to clarify that a zero value is expressly allowed as a legal value for TPGT. This discrepancy currently stands corrected in [SAM4].
[SAM2]と[SAM3]仕様は、それらの有益なテキストでTPGT値が非ゼロであるべきであることに不当に注意します、[RFC3720]はTPGTのためのゼロの値を許容しますが。 このセクションはそれをはっきりさせるのがTPGTのための法定価格として明白に許されているというゼロが、評価することです。 この食い違いは現在、[SAM4]に間違っていたことを認めます。
6.2. SessionType Negotiation
6.2. SessionType交渉
During the Login Phase, the SessionType key is offered by the initiator to choose the type of session it wants to create with the target. The target may accept or reject the offer. Depending on the type of the session, a target may decide on resources to allocate and the security to enforce, etc. for the session. If the SessionType key is thus going to be offered as "Discovery", it SHOULD be offered in the initial Login request by the initiator.
Login Phaseの間、SessionTypeキーは、それが目標で作成したがっているセッションのタイプを選ぶために創始者によって提供されます。 目標は、申し出を受け入れるか、または拒絶するかもしれません。 セッションのタイプに頼っていて、目標はセッションのために割り当てるリソースと実施するセキュリティを決めるかもしれませんなど。 その結果、SessionTypeであるなら「発見」としてキーを提供して、それはSHOULDです。Loginが要求する初期では、創始者によって提供されます。
6.3. Understanding NotUnderstood
6.3. NotUnderstoodを理解しています。
[RFC3720] defines NotUnderstood as a valid answer during a negotiation text key exchange between two iSCSI nodes. NotUnderstood has the reserved meaning that the sending side did not understand the proposed key semantics. This section seeks to clarify that NotUnderstood is a valid answer for both declarative and negotiated keys. The general iSCSI philosophy is that comprehension precedes processing for any iSCSI key. A proposer of an iSCSI key, negotiated or declarative, in a text key exchange MUST thus be able to properly handle a NotUnderstood response.
[RFC3720]は2つのiSCSIノードの間の交渉のテキストの主要な交換の間、有効な答えとNotUnderstoodを定義します。 NotUnderstoodは送付側がした予約された意味に提案された主要な意味論を理解させません。 そのNotUnderstoodをはっきりさせるこのセクションシークは叙述的なものと同様に交渉されたキーのための有効な答えです。 一般的なiSCSI哲学は読解がどんなiSCSIキーのための処理にも先行するということです。 その結果、テキストの主要な交換で主要であるか、交渉されたか叙述的なiSCSIの提案者は適切にNotUnderstood応答を扱うことができなければなりません。
The proper way to handle a NotUnderstood response depends on where the key is specified and whether the key is declarative vs. negotiated. All keys defined in [RFC3720] MUST be supported by all compliant implementations; a NotUnderstood answer on any of the [RFC3720] keys therefore MUST be considered a protocol error and handled accordingly. For all other later keys, a NotUnderstood answer concludes the negotiation for a negotiated key whereas for a declarative key, a NotUnderstood answer simply informs the declarer of a lack of comprehension by the receiver.
NotUnderstood応答を扱う適切な方法はキーがどこで指定されるか、そして、キーが交渉にされるに対して叙述的であるかどうかよります。 すべての対応する実現で[RFC3720]で定義されたすべてのキーを支えなければなりません。 したがって、それに従って、[RFC3720]キーのどれかにおけるNotUnderstood答えをプロトコル誤りであると考えられて、扱わなければなりません。 他のすべての後のキーに関しては、NotUnderstood答えは交渉されたキーのために交渉を終えますが、叙述的なキーに関して、NotUnderstood答えは受信機で読解の不足について単に宣言者に知らせます。
In either case, a NotUnderstood answer always requires that the protocol behavior associated with that key not be used within the scope of the key (connection/session) by either side.
どちらの場合ではも、NotUnderstood答えは、いつもそのキーに関連しているプロトコルの振舞いがどちらかで主要な(接続/セッション)側の範囲の中で使用されないのを必要とします。
Chadalapaka Standards Track [Page 21] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[21ページ]RFC5048iSCSI修正と明確化2007年10月
6.4. Outstanding Negotiation Exchanges
6.4. 傑出している交渉交換
There was some uncertainty around the number of outstanding Login Response PDUs on a connection. [RFC3720] offers the analogy of SCSI linked commands to Login and Text negotiations in Sections 5.3 and 10.10.3, respectively, but does not make it fully explicit. This section is to offer a clarification in this regard.
傑出しているLogin Response PDUsの数の周りに接続には何らかの不確実性がありました。 [RFC3720]で、それぞれセクション5.3と10.10.3におけるLoginとText交渉にSCSIの繋がっているコマンドの類推を提供しますが、それは完全に明白になりません。 このセクションはこの点で明確化を提供することになっています。
There MUST NOT be more than one outstanding Login Request, Login Response, Text Request, or Text Response PDU on an iSCSI connection. An outstanding PDU in this context is one that has not been acknowledged by the remote iSCSI side.
iSCSI接続には1傑出しているLogin Request、Login Response、Text Request、またはText Response PDUがあるはずがありません。 傑出しているPDUはこのような関係においては遠く離れるiSCSI側によって承認されていないものです。
7. iSCSI Error Handling and Recovery
7. iSCSIエラー処理と回復
7.1. ITT
7.1. ITT
An ITT value of 0xffffffff is reserved and MUST NOT be assigned for a task by the initiator. The only instance in which it may be seen on the wire is in a target-initiated NOP-In PDU (and in the initiator response to that PDU, if necessary). Section 10.19 in [RFC3720] mentions this in passing but is noted here again to make it obvious since the semantics apply to the initiators in general.
0xffffffffのITT値は、予約されていて、タスクのために創始者によって割り当てられてはいけません。 そして、それがワイヤの上に見られるかもしれない唯一の例が目標で開始している中のNOP PDUにある、(そのPDUへの創始者応答で必要なら) セクション10.19 [RFC3720]言及では、それを意味論以来明白にするように再びここに述べられて、一般に、創始者に適用してください。
7.2. Format Errors
7.2. 形式誤り
Section 6.6 of [RFC3720] discusses format error handling. This section elaborates on the "inconsistent" PDU field contents noted in [RFC3720].
[RFC3720]のセクション6.6は形式エラー処理を論じます。 このセクションは[RFC3720]に述べられた「矛盾した」PDU分野コンテンツについて詳しく説明します。
All initiator-detected PDU construction errors MUST be considered as format errors. Some examples of such errors are:
形式誤りであるとすべての創始者によって検出されたPDU建設ミスをみなさなければなりません。 そのような誤りに関するいくつかの例は以下の通りです。
- NOP-In with a valid TTT but an invalid LUN
- 中の有効なTTTにもかかわらず、無効のLUNとNOP
- NOP-In with a valid ITT (i.e., a NOP-In response) and also a
valid TTT
- 中の有効なITT(すなわち、中のNOP応答)があるNOPと有効なTTTも
- SCSI Response PDU with Status=CHECK CONDITION, but
DataSegmentLength = 0
- 状態=があるSCSI応答PDUはしかし、状態、DataSegmentLength=0をチェックします。
7.3. Digest Errors
7.3. ダイジェスト誤り
Section 6.7 of [RFC3720] discusses digest error handling. It states that "No further action is necessary for initiators if the discarded PDU is an unsolicited PDU (e.g., Async, Reject)" on detecting a payload digest error. This is incorrect.
[RFC3720]のセクション6.7はダイジェストエラー処理を論じます。 ペイロードダイジェスト誤りを検出するとき、「さらなるどんな動作も捨てられたPDUが求められていないPDU(例えば、Async、Reject)であるなら創始者に必要ではありません。」と、それは述べます。 これは不正確です。
Chadalapaka Standards Track [Page 22] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[22ページ]RFC5048iSCSI修正と明確化2007年10月
An Asynchronous Message PDU or a Reject PDU carries the next StatSN value on an iSCSI connection, advancing the StatSN. When an initiator discards one of these PDUs due to a payload digest error, the entire PDU including the header MUST be discarded. Consequently, the initiator MUST treat the exception like a loss of any other solicited response PDU -- i.e., it MUST use one of the following options noted in [RFC3720]:
StatSNを進めて、Asynchronous Message PDUかReject PDUが次のStatSN値をiSCSI接続まで運びます。 創始者がペイロードダイジェスト誤りのためこれらのPDUsの1つを捨てるとき、ヘッダーを含む全体のPDUを捨てなければなりません。 その結果、創始者はいかなる他の請求された応答PDUの損失のようにも例外を扱わなければなりません--[RFC3720]に述べられた以下のオプションの1つを使用しなければなりません:
a) Request PDU retransmission with a status SNACK.
a) 状態SNACKとPDU retransmissionを要求してください。
b) Logout the connection for recovery and continue the tasks on a
different connection instance.
b) そして、ログアウト、回復のための接続、異なった接続例に関するタスクを続けてください。
c) Logout to close the connection (abort all the commands
associated with the connection).
c) ログアウトして(接続に関連しているすべてのコマンドを中止してください)、接続を終えてください。
7.4. Message Error Checking
7.4. メッセージ誤りの照合
There has been some uncertainty on the extent to which incoming messages have to be checked for protocol errors, beyond what is strictly required for processing the inbound message. This section addresses this question.
何らかの不確実性が入力メッセージがプロトコル誤りがないかどうかチェックされなければならない範囲にありました、本国行きのメッセージを処理するのに厳密に必要であることを超えて。 このセクションはこの質問を記述します。
Unless [RFC3720] or this document requires it, an iSCSI implementation is not required to do an exhaustive protocol conformance check on an incoming iSCSI PDU. The iSCSI implementation especially is not required to double-check the remote iSCSI implementation's conformance to protocol requirements.
[RFC3720]かこのドキュメントがそれを必要としない場合、iSCSI実現は、入って来るiSCSI PDUの徹底的なプロトコル順応チェックをするのに必要ではありません。 特にiSCSI実現は、要件について議定書の中で述べるためにリモートiSCSI実現の順応を再確認するのに必要ではありません。
8. iSCSI PDUs
8. iSCSI PDUs
8.1. Asynchronous Message
8.1. 非同期なメッセージ
This section defines additional semantics for the Asynchronous Message PDU defined in Section 10.9 of [RFC3720] using the same conventions.
このセクションは[RFC3720]のセクション10.9で同じコンベンションを使用することで定義されたAsynchronous Message PDUのために追加意味論を定義します。
The following new legal value for the AsyncEvent is defined:
AsyncEventのための以下の新しい法定価格は定義されます:
5: all active tasks for LU with a matching LUN field in the Async Message PDU are being terminated.
5: 合っているLUN分野がAsync Message PDUにあるLUのためのすべてのアクティブ・タスクが終えられています。
The receiving initiator iSCSI layer MUST respond to this Message by taking the following steps in order.
受信創始者iSCSI層は、整然とした状態で以下の方法を取ることによって、このMessageに応じなければなりません。
i) Stop Data-Out transfers on that connection for all active TTTs
for the affected LUN quoted in the Async Message PDU.
i) Async Message PDUで引用された影響を受けるLUNのためのすべてのアクティブなTTTsのために外のData転送をその接続に止めてください。
Chadalapaka Standards Track [Page 23] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[23ページ]RFC5048iSCSI修正と明確化2007年10月
ii) Acknowledge the StatSN of the Async Message PDU via a NOP-Out
PDU with ITT=0xffffffff (i.e., non-ping flavor), while copying
the LUN field from the Async Message to NOP-Out.
ii) Async Messageから外のNOPまでLUN分野をコピーしている間、ITTがある外のNOP PDUを通したAsync Message PDUのStatSNが0xffffffff(すなわち、非ピング風味)と等しいと認めてください。
The new AsyncEvent defined in this section however MUST NOT be used on an iSCSI session unless the new TaskReporting text key defined in Section 9.1 was negotiated to FastAbort on the session.
しかしながら、セクション9.1で定義された新しいTaskReportingテキストキーがセッションに関してFastAbortと交渉されなかったなら、iSCSIセッションのときにこのセクションで定義された新しいAsyncEventを使用してはいけません。
8.2. Reject
8.2. 廃棄物
Section 10.17.1 of [RFC3720] specifies the Reject reason code of 0x0b with an explanation of "Negotiation Reset". At this point, we do not see any legitimate iSCSI protocol use case for using this reason code. Thus, reason code 0x0b MUST be considered as deprecated and MUST NOT be sent by implementations that comply with the requirements of this document. An implementation receiving reason code 0x0b MUST treat it as a negotiation failure that terminates the Login Phase and the TCP connection, as specified in Section 6.10 of [RFC3720].
.1セクション10.17[RFC3720]が「交渉リセット」に関する説明で0x0bのReject理由コードを指定します。 ここに、私たちは、どんな正統のiSCSIプロトコルもこの理由コードを使用するのにケースを使用するのを見ません。 したがって、理由コード0x0bを推奨しないとみなさなければならなくて、このドキュメントの要件に従う実現で送ってはいけません。 理由コード0x0bを受ける実現はLogin PhaseとTCP接続を終える交渉失敗としてそれを扱わなければなりません、[RFC3720]のセクション6.10で指定されるように。
Section 5.4 of [RFC3720] states:
[RFC3720]州のセクション5.4:
Neither the initiator nor the target should attempt to declare or
negotiate a parameter more than once during any negotiation
sequence without an intervening operational parameter negotiation
reset, except for responses to specific keys that explicitly allow
repeated key declarations (e.g., TargetAddress).
創始者も目標も、介入している操作上のパラメタ交渉リセットなしでどんな交渉系列の間の一度より多くのパラメタも宣言するか、または交渉するのを試みるはずがありません、明らかに、繰り返された主要な宣言(例えば、TargetAddress)を許容する特定のキーへの応答を除いて。
The deprecation of reason code 0x0b eliminates the possibility of an operational parameter negotiation reset, causing the phrase "without an intervening operational parameter negotiation reset" in [RFC3720] to refer to an impossible event. The quoted phrase SHOULD be ignored by receivers that handle reason code 0x0b in the manner specified in this section.
理由コード0x0bの不賛成は操作上のパラメタ交渉リセットの可能性を排除します、[RFC3720]の「介入している操作上のパラメタ交渉リセット」という句が空事象について言及することを引き起こして。 引用はSHOULDを言葉で表します。方法によるコード0x0bがこのセクションで指定した理由を扱う受信機で、無視されてください。
9. Login/Text Operational Text Keys
9. ログイン/テキストの操作上のテキストキー
This section follows the same conventions as Section 12 of [RFC3720].
このセクションは[RFC3720]のセクション12と同じコンベンションに続きます。
9.1. TaskReporting
9.1. TaskReporting
Use: LO Senders: Initiator and Target Scope: SW
使用: 最低気温送付者: 創始者と目標範囲: SW
Irrelevant when: SessionType=Discovery TaskReporting=<list-of-values>
無関係である、いつ: SessionType=発見TaskReporting=<リスト、-、値の>。
Chadalapaka Standards Track [Page 24] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[24ページ]RFC5048iSCSI修正と明確化2007年10月
Default is RFC3720. Result function is AND.
デフォルトはRFC3720です。 結果機能はANDです。
This key is used to negotiate the task completion reporting semantics from the SCSI target. The following table describes the semantics that an iSCSI target MUST support for respective negotiated key values. Whenever this key is negotiated, at least the RFC3720 and ResponseFence values MUST be offered as options by the negotiation originator.
このキーは、SCSI目標から意味論を報告するタスク完成を交渉するのに使用されます。 以下のテーブルはiSCSI目標がそれぞれの交渉されたキー値のために支持しなければならない意味論について説明します。 このキーが交渉されるときはいつも、交渉創始者によるオプションとして少なくともRFC3720とResponseFence値を提供しなければなりません。
+--------------+------------------------------------------+ | Name | Description | +--------------+------------------------------------------+ | RFC3720 | RFC 3720-compliant semantics. Response | | | fencing is not guaranteed and fast | | | completion of multi-task aborting is not | | | supported | +--------------+------------------------------------------+ | ResponseFence| Response Fence (Section 3.3.1) semantics | | | MUST be supported in reporting task | | | completions | +--------------+------------------------------------------+ | FastAbort | Updated fast multi-task abort semantics | | | defined in Section 4.1.3 MUST be | | | supported. Support for Response Fence is| | | implied -- i.e., Section 3.3.1 semantics | | | MUST be supported as well | +--------------+------------------------------------------+
+--------------+------------------------------------------+ | 名前| 記述| +--------------+------------------------------------------+ | RFC3720| RFCの3720年の対応することの意味論。 応答| | | フェンシングは、保証されていて速くはありません。| | | マルチタスク中止の完成はそうではありません。| | | 支持されます。| +--------------+------------------------------------------+ | ResponseFence| 応答Fence(セクション3.3.1)意味論| | | 報告タスクで支持しなければなりません。| | | 落成| +--------------+------------------------------------------+ | FastAbort| アップデートされた速いマルチタスクアボート意味論| | | セクション4.1で定義されて、.3はそうであるに違いありません。| | | 支持にされる。 Response Fenceのサポートはそうです。| | | 暗示する--、すなわち、セクション3.3.1意味論| | | また、支持しなければなりません。| +--------------+------------------------------------------+
When TaskReporting is not negotiated to FastAbort, the [RFC3720] TMF semantics as clarified in Section 4.1.2 MUST be used.
TaskReportingがFastAbortと交渉されないとき、セクション4.1.2ではっきりさせられる[RFC3720]TMF意味論を使用しなければなりません。
10. Security Considerations
10. セキュリティ問題
This document does not introduce any new security considerations other than those already noted in [RFC3720]. Consequently, all the iSCSI-related security text in [RFC3723] is also directly applicable to this document.
このドキュメントは[RFC3720]に既に述べられたもの以外のどんな新しいセキュリティ問題も紹介しません。 その結果、また、[RFC3723]のすべてのiSCSI関連のセキュリティテキストも直接このドキュメントに適切です。
Chadalapaka Standards Track [Page 25] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[25ページ]RFC5048iSCSI修正と明確化2007年10月
11. IANA Considerations
11. IANA問題
11.1. iSCSI-Related IANA Registries
11.1. iSCSI関連のIANA登録
This document creates the following iSCSI-related registries for IANA to manage.
IANAが管理するように、このドキュメントは以下のiSCSI関連の登録を作成します。
1. iSCSI Opcodes
1. iSCSI Opcodes
2. iSCSI Login/Text Keys
2. iSCSIログイン/テキストキー
3. iSCSI Asynchronous Events
3. iSCSI非同期的なイベント
4. iSCSI Task Management Function Codes
4. iSCSIタスク管理機能コード
5. iSCSI Login Response Status Codes
5. iSCSIログイン応答ステータスコード
6. iSCSI Reject Reason Codes
6. iSCSIは理由コードを拒絶します。
7. iSER Opcodes
7. iSER Opcodes
Each of the following sections describes a registry, its sub- registries if any, and their administration policies in more detail. IANA has registered what this document calls the main "registries" as sub-registries of a larger iSCSI registry. However, wherever registry-to-sub-registry relationships are specified by this document, they have been preserved intact.
それぞれの以下のセクションはさらに詳細に登録、もしあればサブ登録、およびそれらの管理方針を説明します。 IANAはこのドキュメントが、より大きいiSCSI登録のサブ登録として主な「登録」と呼ぶことを登録しました。 しかしながら、登録からサブ登録への関係がどこでこのドキュメントによって指定されても、それらは完全な状態で保存されました。
[RFC3720] specifies three iSCSI-related registries -- extended key, authentication methods, and digests. This document recommends that these registries be published together with the registries defined by this document. Further, this document recommends that the three [RFC3720] registries be listed in between items 6 and 7 in the registry list above.
[RFC3720]は3つのiSCSI関連の登録を指定します--キー、認証方法、およびダイジェストを広げています。 このドキュメントは、これらの登録がこのドキュメントによって定義された登録と共に発行されることを勧めます。 さらに、このドキュメントは、3つ[RFC3720]の登録が上記の登記名簿の項目6と7の間に記載されることを勧めます。
11.2. iSCSI Opcodes
11.2. iSCSI Opcodes
Name of the registry: "iSCSI Opcodes"
登録の名前: 「iSCSI Opcodes」
Namespace details: Numerical values that can fit in one octet with the most significant two bits (bits 0 and 1) already designated by [RFC3720], bit 0 being reserved and bit 1 for immediate delivery. Bit 2 is designated to identify the originator of the opcode. Bit 2 = 0 for initiator and Bit 2 = 1 for target.
名前空間の詳細: 既に即座の配送のために[RFC3720]、予約されるビット0、およびビット1によって指定された中で最も重要な2ビット(ビット0と1)と1つの八重奏を合わせることができる数値。 ビット2は、opcodeの創始者を特定するために指定されます。 創始者のためのビット2 = 0と目標のためのBit2 = 1。
Chadalapaka Standards Track [Page 26] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[26ページ]RFC5048iSCSI修正と明確化2007年10月
Information that must be provided to assign a new value: An IESG- approved standards-track specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
新しい値を割り当てるために提供しなければならない情報: IESGは提案された新しい値と分野が登録に記録されるという意味論を定義する標準化過程仕様と相互運用性要件を承認しました。
Allocation request guidance to requesters:
リクエスタへの配分要求指導:
1) If the initiator opcode and target opcode used to identify the
request and response of a new type of protocol operation are
requested, assign the same lower five bits (i.e., Bit 3 through
Bit 7) for both opcodes, e.g., 0x13 and 0x33.
1) 新しいタイプのプロトコル操作の要求と応答を特定するのに使用される創始者opcodeと目標opcodeが要求されるなら、opcodes、例えば、0×13と0×33の両方のために、同じ低級5ビット(すなわち、Bit7を通したBit3)を割り当ててください。
2) If only the initiator opcode or target opcode is requested to
identify a one-way protocol message (i.e., request without a
response or a "response" without a request), assign an unused
number from the appropriate category (i.e., Bit 2 set to 0 or 1
for initiator category or target category) and add the other
pair member (i.e., same opcode with Bit 2 set to 1 or 0,
respectively) to "no opcode pair is available" list.
2) 片道プロトコルメッセージ(すなわち、要求のない応答も「応答」のない要求)を特定して、適切なカテゴリ(すなわち、Bit2は創始者カテゴリか目標カテゴリのために0か1にセットした)から未使用の数を割り当てて、創始者opcodeか目標opcodeだけがもう片方の組メンバー(すなわち、それぞれ1か0に用意ができているBit2と同じopcode)を「どんなopcode組も手があくこと」に加えないよう要求されるなら、記載してください。
3) If there are no other opcodes available in the appropriate
"Reserved to IANA" list to assign on a request for a new opcode
except the reserved opcodes in the "no opcode pair is
available" list, allocate the opcode from the appropriate
category (initiator or target) of the "no opcode pair is
available" list.
3) 「どんなopcode組も手があかない」というリストの予約されたopcodesを除いて、新しいopcodeを求める要求のときに割り当てるのが適切である「IANAに予約された」リストで利用可能な他のどんなopcodesもなければ、「どんなopcode組も手があかない」というリストの適切なカテゴリ(創始者か目標)からopcodeを割り当ててください。
Fields to record in the registry: Assigned value, Who can originate (Initiator or Target), Operation Name, and its associated RFC reference.
登録に記録する分野: Operation Name、値が割り当てられる場合、Whoは(創始者かTarget)を溯源できます、そして、それは関連しています。RFC参照。
Initial registry contents:
登録コンテンツに頭文字をつけてください:
0x00, Initiator, NOP-Out, [RFC3720]
0×00 創始者、外のNOP[RFC3720]
0x01, Initiator, SCSI Command, [RFC3720]
0×01 創始者、SCSIは命令します。[RFC3720]
0x02, Initiator, SCSI Task Management function request, [RFC3720]
0×02 Initiator、SCSI Task Management機能要求[RFC3720]
0x03, Initiator, Login Request, [RFC3720]
0×03 創始者、ログイン要求[RFC3720]
0x04, Initiator, Text Request, [RFC3720]
0×04 創始者、テキスト要求[RFC3720]
0x05, Initiator, SCSI Data-Out, [RFC3720]
0×05 創始者、外のSCSIデータ[RFC3720]
0x06, Initiator, Logout Request, [RFC3720]
0×06(創始者)がログアウトする、要求[RFC3720]
0x10, Initiator, SNACK Request, [RFC3720]
0×10 創始者、軽食要求[RFC3720]
Chadalapaka Standards Track [Page 27] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[27ページ]RFC5048iSCSI修正と明確化2007年10月
0x1c-0x1e, Initiator, Vendor specific codes, [RFC3720]
0x1c-0x1e、Initiator、Vendorの特定のコード[RFC3720]
0x20, Target, NOP-In, [RFC3720]
0×20 目標、中のNOP[RFC3720]
0x21, Target, SCSI Response, [RFC3720]
0×21 目標、SCSI応答[RFC3720]
0x22, Target, SCSI Task Management function response, [RFC3720]
0×22 Target、SCSI Task Management機能応答[RFC3720]
0x23, Target, Login Response, [RFC3720]
0×23 目標、ログイン応答[RFC3720]
0x24, Target, Text Response, [RFC3720]
0×24 目標、テキスト応答[RFC3720]
0x25, Target, SCSI Data-In, [RFC3720]
0×25 目標、中のSCSIデータ[RFC3720]
0x26, Target, Logout Response, [RFC3720]
0×26(目標)がログアウトする、応答[RFC3720]
0x31, Target, Ready To Transfer (R2T), [RFC3720]
0×31、移す準備ができている目標(R2T)[RFC3720]
0x32, Target, Asynchronous Message, [RFC3720]
0×32 目標、非同期なメッセージ[RFC3720]
0x3c-0x3e, Target, Vendor specific codes, [RFC3720]
0x3c-0x3e、Target、Vendorの特定のコード[RFC3720]
0x3f, Target, Reject, [RFC3720]
0x3f、目標、廃棄物[RFC3720]
Reserved to IANA:
0x07-0x0f, 0x13-0x1b (initiator codes)
0x27-0x2f, 0x33-0x3b (target codes)
IANAに予約されます: 0×07 0x0fの、そして、0×13 0x1b(創始者コード)の0×27 0x2f、0×33 0x3b(目標コード)
No opcode pair is available:
0x11, 0x12, 0x1f (initiator codes)
0x30 (target codes)
どんなopcode組も手があいていません: 0×11 0×12、0x1f(創始者コード)0×30(目標コード)
Allocation Policy:
配分方針:
Standards Action ([IANA]): This is required for defining the semantics of the opcode.
規格動作([IANA]): これが、opcodeの意味論を定義するのに必要です。
Expert Review ([IANA]): This is required for selecting the specific opcode(s) to allocate in order to ensure compliance with the earlier "Allocation request guidance to requesters".
専門のレビュー([IANA]): これが、特定のopcode(s)を選択するのにより初期の「リクエスタへの配分要求指導」へのコンプライアンスを確実にするために割り当てるのに必要です。
11.3. iSCSI Login/Text Keys
11.3. iSCSIログイン/テキストキー
Name of the registry: "iSCSI Text Keys"
登録の名前: 「iSCSIテキストキー」
Namespace details: Key=value pairs with "Key" names in UTF-8 Unicode, and the permissible "value" options for the "Key" are Key-dependent. [RFC3720] defines the rules on key names and allowed values.
名前空間の詳細: 主要な=値はUTF-8ユニコードによる「主要な」名前と対にされます、そして、「キー」のための許されている「値」オプションはKey依存しています。 [RFC3720]は主要な名前と許容値で規則を決めます。
Chadalapaka Standards Track [Page 28] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[28ページ]RFC5048iSCSI修正と明確化2007年10月
Information that must be provided to assign a new value: An IESG- approved standards-track specification defining the semantics and interoperability requirements of the proposed new Key per [RFC3720] key specification template and the fields to be recorded in the registry.
新しい値を割り当てるために提供しなければならない情報: IESGは[RFC3720]キー仕様テンプレートあたりの提案された新しいKeyと分野が登録に記録されるという意味論を定義する標準化過程仕様と相互運用性要件を承認しました。
Assignment policy:
課題方針:
If the requested Key name is not already assigned and is roughly representative of its proposed semantics, it may be assigned to the requester.
要求されたKey名が既に割り当てられないで、およそ提案された意味論を代表するなら、それはリクエスタに割り当てられるかもしれません。
Given the arbitrary nature of text strings, there is no maximum reserved by IANA for assignment in this registry.
テキスト文字列の任意の本質を考えて、課題のためにIANAによって予約された最大が全くこの登録にありません。
Fields to record in the registry: Assigned Key Name and its associated RFC reference.
登録に記録する分野: 割り当てられたKey Nameとその関連RFC参照。
Initial registry contents:
登録コンテンツに頭文字をつけてください:
AuthMethod, [RFC3720]
AuthMethod[RFC3720]
HeaderDigest, [RFC3720]
HeaderDigest[RFC3720]
DataDigest, [RFC3720]
DataDigest[RFC3720]
MaxConnections, [RFC3720]
MaxConnections[RFC3720]
SendTargets, [RFC3720]
SendTargets[RFC3720]
TargetName, [RFC3720]
TargetName[RFC3720]
InitiatorName, [RFC3720]
InitiatorName[RFC3720]
TargetAlias, [RFC3720]
TargetAlias[RFC3720]
InitiatorAlias, [RFC3720]
InitiatorAlias[RFC3720]
TargetAddress, [RFC3720]
TargetAddress[RFC3720]
TargetPortalGroupTag, [RFC3720]
TargetPortalGroupTag[RFC3720]
InitialR2T, [RFC3720]
InitialR2T[RFC3720]
ImmediateData, [RFC3720]
ImmediateData[RFC3720]
MaxRecvDataSegmentLength, [RFC3720]
MaxRecvDataSegmentLength[RFC3720]
Chadalapaka Standards Track [Page 29] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[29ページ]RFC5048iSCSI修正と明確化2007年10月
MaxBurstLength, [RFC3720]
MaxBurstLength[RFC3720]
FirstBurstLength, [RFC3720]
FirstBurstLength[RFC3720]
DefaultTime2Wait, [RFC3720]
DefaultTime2Wait[RFC3720]
DefaultTime2Retain, [RFC3720]
DefaultTime2Retain[RFC3720]
MaxOutstandingR2T, [RFC3720]
MaxOutstandingR2T[RFC3720]
DataPDUInOrder, [RFC3720]
DataPDUInOrder[RFC3720]
DataSequenceInOrder, [RFC3720]
DataSequenceInOrder[RFC3720]
ErrorRecoveryLevel, [RFC3720]
ErrorRecoveryLevel[RFC3720]
SessionType, [RFC3720]
SessionType[RFC3720]
RDMAExtensions, [iSER]
RDMAExtensions[iSER]
TargetRecvDataSegmentLength, [iSER]
TargetRecvDataSegmentLength[iSER]
InitiatorRecvDataSegmentLength, [iSER]
InitiatorRecvDataSegmentLength[iSER]
MaxOutstandingUnexpectedPDUs, [iSER]
MaxOutstandingUnexpectedPDUs[iSER]
TaskReporting, this document
TaskReporting、このドキュメント
Allocation Policy:
配分方針:
Standards Action ([IANA])
規格動作([IANA])
11.4. iSCSI Asynchronous Events
11.4. iSCSI非同期的なイベント
Name of the registry: "iSCSI Asynchronous Events"
登録の名前: 「iSCSI非同期的なイベント」
Namespace details: Numerical values that can fit in one octet.
名前空間の詳細: 1つの八重奏をうまくはめ込むことができる数値。
Information that must be provided to assign a new value: An IESG- approved standards-track specification defining the semantics and interoperability requirements of the proposed new Event and the fields to be recorded in the registry.
新しい値を割り当てるために提供しなければならない情報: IESGは提案された新しいEventと分野が登録に記録されるという意味論を定義する標準化過程仕様と相互運用性要件を承認しました。
Assignment policy:
課題方針:
If the requested value is not already assigned, it may be assigned to the requester.
要求された値が既に割り当てられないなら、それはリクエスタに割り当てられるかもしれません。
Chadalapaka Standards Track [Page 30] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[30ページ]RFC5048iSCSI修正と明確化2007年10月
6-247: range reserved by IANA for assignment in this registry.
6-247: この登録の課題のためにIANAによって予約された範囲。
Fields to record in the registry: Assigned Event number, Description and its associated RFC reference.
登録に記録する分野: Event番号、記述、およびその関連RFC参照は割り当てられます。
Initial registry contents:
登録コンテンツに頭文字をつけてください:
0, SCSI Async Event, [RFC3720]
0 SCSI Async出来事[RFC3720]
1, Logout Request, [RFC3720]
1、ログアウトしてください、要求[RFC3720]
2, Connection drop notification, [RFC3720]
2 Connectionは通知を落とします。[RFC3720]
3, Session drop notification, [RFC3720]
3 Sessionは通知を落とします。[RFC3720]
4, Negotiation Request, [RFC3720]
4 交渉要求[RFC3720]
5, Task termination, this document
5 Task終了、このドキュメント
248-254, Vendor-unique, this document
Vendorユニークな248-254はこのドキュメントです。
255, Vendor-unique, [RFC3720]
255 業者ユニークです。[RFC3720]
Allocation Policy:
配分方針:
Standards Action ([IANA])
規格動作([IANA])
11.5. iSCSI Task Management Function Codes
11.5. iSCSIタスク管理機能コード
Name of the registry: "iSCSI TMF Codes"
登録の名前: 「iSCSI TMFコード」
Namespace details: Numerical values that can fit in 7 bits.
名前空間の詳細: 7ビットをうまくはめ込むことができる数値。
Information that must be provided to assign a new value: An IESG- approved standards-track specification defining the semantics and interoperability requirements of the proposed new Code and the fields to be recorded in the registry.
新しい値を割り当てるために提供しなければならない情報: IESGは提案された新しいCodeと分野が登録に記録されるという意味論を定義する標準化過程仕様と相互運用性要件を承認しました。
Assignment policy:
課題方針:
If the requested value is not already assigned, it may be assigned to the requester.
要求された値が既に割り当てられないなら、それはリクエスタに割り当てられるかもしれません。
9-127: range reserved by IANA for assignment in this registry.
9-127: この登録の課題のためにIANAによって予約された範囲。
Fields to record in the registry: Assigned Code, Description, and its associated RFC reference.
登録に記録する分野: Code、記述、およびその関連RFC参照は割り当てられます。
Chadalapaka Standards Track [Page 31] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[31ページ]RFC5048iSCSI修正と明確化2007年10月
Initial registry contents:
登録コンテンツに頭文字をつけてください:
1, ABORT TASK, [RFC3720]
1 アボートタスク[RFC3720]
2, ABORT TASK SET, [RFC3720]
2 アボートタスクはセットしました。[RFC3720]
3, CLEAR ACA, [RFC3720]
3 明確なACA[RFC3720]
4, CLEAR TASK SET, [RFC3720]
4 明確なタスクはセットしました。[RFC3720]
5, LOGICAL UNIT RESET, [RFC3720]
5 論理装置リセット[RFC3720]
6, TARGET WARM RESET, [RFC3720]
6 目標ウォームリセット[RFC3720]
7, TARGET COLD RESET, [RFC3720]
7 目標コールドリセット[RFC3720]
8, TASK REASSIGN, [RFC3720]
8 タスクは再選任します。[RFC3720]
Allocation Policy:
配分方針:
Standards Action ([IANA])
規格動作([IANA])
11.6. iSCSI Login Response Status Codes
11.6. iSCSIログイン応答ステータスコード
Name of the registry: "iSCSI Login Response Status Codes"
登録の名前: 「iSCSIログイン応答ステータスコード」
Namespace details: Numerical values; Status-Class (one octet), Status-Detail (one octet) for each possible value of Status-Class except for Vendor-Unique Status-Class (0x0f).
名前空間の詳細: 数値。 状態クラス(1つの八重奏)、VendorユニークなStatus-クラス(0x0f)を除いたStatus-クラスのそれぞれの可能な値のためのStatus-詳細(1つの八重奏)。
Information that must be provided to assign a new value: An IESG- approved specification defining the semantics and interoperability requirements of the proposed new Code, its Status-Class affiliation (only if a new Status-Detail value is being proposed for a Status- Class), Status-Class definition (only if a new Status-Class is being proposed), and the fields to be recorded in the registry.
新しい値を割り当てるために提供しなければならない情報: IESGは提案された新しいCode、Status-クラス提携(新しいStatus-詳細値がStatusのクラスのために提案されている場合にだけ)、Status-クラス定義(新しいStatus-クラスが提案されている場合にだけ)、および分野が登録に記録されるという意味論を定義する仕様と相互運用性要件を承認しました。
Assignment policy:
課題方針:
If the requested value is not already assigned, it may be assigned to the requester.
要求された値が既に割り当てられないなら、それはリクエスタに割り当てられるかもしれません。
4-14 and 16-255: range reserved by IANA for assignment in this registry.
4-14と16-255: この登録の課題のためにIANAによって予約された範囲。
Fields to record in the Status-Class main registry: Assigned Code, Description, and its associated RFC reference.
Status-クラスの主な登録に記録する分野: Code、記述、およびその関連RFC参照は割り当てられます。
Chadalapaka Standards Track [Page 32] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[32ページ]RFC5048iSCSI修正と明確化2007年10月
Fields to record in the Status-Detail sub-registries: Status-Class, Assigned Code, Description, and its associated RFC reference.
Status-詳細サブ登録に記録する分野: 状態クラス、Assigned Code、記述、およびその関連RFC参照。
Initial registry contents (Status-Class):
登録コンテンツ(状態クラス)に頭文字をつけてください:
0x00, Success, [RFC3720]
0×00 成功[RFC3720]
0x01, Redirection, [RFC3720]
0×01 リダイレクション[RFC3720]
0x02, Initiator Error, [RFC3720]
0×02 創始者誤り[RFC3720]
0x03, Target Error, [RFC3720]
0×03 目標誤り[RFC3720]
0x0f, Vendor-Unique, this document
これが記録するVendorユニークな0x0f
Initial sub-registry contents (Status-Detail for Status-Class=0x00):
サブ登録コンテンツ(Status-クラス=0×00のための状態詳細)に頭文字をつけてください:
0x00, 0x00, Success, [RFC3720]
0×00 0×00 成功[RFC3720]
1-255: range reserved by IANA for assignment in Status-Class=0 sub- registry.
1-255: Status-クラスにおける課題のためにIANAによって予約された範囲は0サブ登録と等しいです。
Initial sub-registry contents (Status-Detail for Status-Class=0x01):
サブ登録コンテンツ(Status-クラス=0×01のための状態詳細)に頭文字をつけてください:
0x01, 0x01, Temporary move, [RFC3720]
0×01 0×01 Temporaryは動きます。[RFC3720]
0x01, 0x02, Permanent move, [RFC3720]
0×01 0×02 Permanentは動きます。[RFC3720]
3-255: range reserved by IANA for assignment in Status-Class=1 sub- registry.
3-255: Status-クラスにおける課題のためにIANAによって予約された範囲は1つのサブ登録と等しいです。
Initial sub-registry contents (Status-Detail for Status-Class=0x02):
サブ登録コンテンツ(Status-クラス=0×02のための状態詳細)に頭文字をつけてください:
0x02, 0x00, Miscellaneous, [RFC3720]
0×02 0×00 種々雑多です。[RFC3720]
0x02, 0x01, Authentication failure, [RFC3720]
0×02 0×01 Authenticationの故障[RFC3720]
0x02, 0x02, Authorization failure, [RFC3720]
0×02 0×02 Authorizationの故障[RFC3720]
0x02, 0x03, Not found, [RFC3720]
0×02 0×03 見つけられたNot[RFC3720]
0x02, 0x04, Target removed, [RFC3720]
0×02 0×04 Targetは取り外しました。[RFC3720]
0x02, 0x05, Unsupported version, [RFC3720]
0×02 0×05 Unsupportedバージョン[RFC3720]
0x02, 0x06, Too many connections, [RFC3720]
0×02 0×06 Too多くの接続[RFC3720]
0x02, 0x07, Missing parameter, [RFC3720]
0×02 0×07 Missingパラメタ[RFC3720]
Chadalapaka Standards Track [Page 33] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[33ページ]RFC5048iSCSI修正と明確化2007年10月
0x02, 0x08, Can't include in session, [RFC3720]
0×02 0×08 Canはセッションのときに含んでいません。[RFC3720]
0x02, 0x09, Unsupported session type, [RFC3720]
0×02 0×09 Unsupportedセッションタイプ[RFC3720]
0x02, 0x0a, Non-existent session, [RFC3720]
0×02 0x0a、Non目下のセッション[RFC3720]
0x02, 0x0b, Invalid during login, [RFC3720]
0×02 0x0b、ログインの間のInvalid[RFC3720]
12-255: range reserved by IANA for assignment in Status-Class=2 sub- registry.
12-255: Status-クラスにおける課題のためにIANAによって予約された範囲は2サブ登録と等しいです。
Initial sub-registry contents (Status-Detail for Status-Class=0x03):
サブ登録コンテンツ(Status-クラス=0×03のための状態詳細)に頭文字をつけてください:
0x03, 0x00, Target error, [RFC3720]
0×03 0×00 Target誤り[RFC3720]
0x03, 0x01, Service unavailable, [RFC3720]
0×03 0×01 入手できないService[RFC3720]
0x03, 0x02, Out of resources, [RFC3720]
0×03 0×02 リソースのOut[RFC3720]
3-255: range reserved by IANA for assignment in Status-Class=3 sub- registry.
3-255: Status-クラスにおける課題のためにIANAによって予約された範囲は3サブ登録と等しいです。
Allocation Policy:
配分方針:
Standards Action ([IANA])
規格動作([IANA])
11.7. iSCSI Reject Reason Codes
11.7. iSCSIは理由コードを拒絶します。
Name of the registry: "iSCSI Reject Reason Codes"
登録の名前: 「iSCSIは理由コードを拒絶します」
Namespace details: Numerical values that can fit in a single octet.
名前空間の詳細: ただ一つの八重奏をうまくはめ込むことができる数値。
Information that must be provided to assign a new value: A published specification defining the semantics and interoperability requirements of the proposed new Code and the fields to be recorded in the registry.
新しい値を割り当てるために提供しなければならない情報: 提案された新しいCodeと分野が登録に記録されるという意味論を定義する広められた仕様と相互運用性要件。
Assignment policy:
課題方針:
If the requested value is not already assigned, it may be assigned to the requester.
要求された値が既に割り当てられないなら、それはリクエスタに割り当てられるかもしれません。
13-255: range reserved by IANA for assignment in this registry.
13-255: この登録の課題のためにIANAによって予約された範囲。
Fields to record in the registry: Assigned Code, Description, and its associated RFC reference.
登録に記録する分野: Code、記述、およびその関連RFC参照は割り当てられます。
Chadalapaka Standards Track [Page 34] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[34ページ]RFC5048iSCSI修正と明確化2007年10月
Initial registry contents:
登録コンテンツに頭文字をつけてください:
0x01, Reserved, [RFC3720]
0×01 予約されています。[RFC3720]
0x02, Data digest error, [RFC3720]
0×02 Dataは誤りを読みこなします。[RFC3720]
0x03, SNACK Reject, [RFC3720]
0×03 軽食廃棄物[RFC3720]
0x04, Protocol Error, [RFC3720]
0×04 プロトコル誤り[RFC3720]
0x05, Command not supported, [RFC3720]
0×05 支持されなかったCommand[RFC3720]
0x06, Immediate command reject, [RFC3720]
0×06 Immediateは廃棄物を命令します。[RFC3720]
0x07, Task in progress, [RFC3720]
0×07 進行中のTask[RFC3720]
0x08, Invalid data ack, [RFC3720]
0×08 Invalidデータack[RFC3720]
0x09, Invalid PDU field, [RFC3720]
0×09 Invalid PDU分野[RFC3720]
0x0a, Long op reject, [RFC3720]
0x0a、Longオプアート廃棄物[RFC3720]
0x0b, "Deprecated reason code", this document
0x0b、「推奨しない理由コード」、このドキュメント
0x0c, Waiting for Logout, [RFC3720]
0x0c、待ち、ログアウトしてください。[RFC3720]
Allocation Policy:
配分方針:
Standards Action ([IANA])
規格動作([IANA])
11.8. iSER Opcodes
11.8. iSER Opcodes
Name of the registry: "iSER Opcodes"
登録の名前: 「iSER Opcodes」
Namespace details: Numerical values that can fit in 4 bits.
名前空間の詳細: 4ビットをうまくはめ込むことができる数値。
Information that must be provided to assign a new value: An IESG- approved specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
新しい値を割り当てるために提供しなければならない情報: IESGは提案された新しい値と分野が登録に記録されるという意味論を定義する仕様と相互運用性要件を承認しました。
Assignment policy:
課題方針:
If the requested value is not already assigned, it may be assigned to the requester.
要求された値が既に割り当てられないなら、それはリクエスタに割り当てられるかもしれません。
4-15: range reserved by IANA for assignment in this registry.
4-15: この登録の課題のためにIANAによって予約された範囲。
Chadalapaka Standards Track [Page 35] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[35ページ]RFC5048iSCSI修正と明確化2007年10月
Fields to record in the registry: Assigned value, Operation Name, and its associated RFC reference.
登録に記録する分野: 割り当てられた値、Operation Name、およびその関連RFC参照。
Initial registry contents:
登録コンテンツに頭文字をつけてください:
0x1, iSCSI control-type, [iSER]
0×1 iSCSIはコントロールしてタイプします。[iSER]
0x2, iSER Hello, [iSER]
0×2、iSER、こんにちは。[iSER]
0x3, iSER HelloReply, [iSER]
0×3 iSER HelloReply[iSER]
Allocation Policy:
配分方針:
Standards Action ([IANA])
規格動作([IANA])
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and
E. Zeidner, "Internet Small Computer Systems Interface
(iSCSI)", RFC 3720, April 2004.
[RFC3720] Satran、J.、メタンフェタミン、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE.Zeidner、「インターネットの小さいコンピュータ・システムは(iSCSI)を連結します」、RFC3720、2004年4月。
[SPC3] ANSI INCITS 408-2005, SCSI Primary Commands-3.
[SPC3]ANSI INCITS408-2005、SCSIの第一のコマンド-3。
[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月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[IANA]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H.,
and P. Thaler, "Internet Small Computer System Interface
(iSCSI) Extensions for Remote Direct Memory Access (RDMA)",
RFC 5046, October 2007.
[iSER] コー、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、シャー、H.、およびP.ターレル、「リモートダイレクトメモリアクセス(RDMA)のためのインターネットスモールコンピュータシステムインタフェース(iSCSI)拡大」、RFC5046(2007年10月)。
12.2. Informative References
12.2. 有益な参照
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M.
Krueger, "Internet Small Computer Systems Interface (iSCSI)
Naming and Discovery", RFC 3721, April 2004.
[RFC3721] バッキー、M.、ハーフナー、J.、Hufferd、J.、Voruganti、K.、およびM.クルーガー、「インターネットの小さいコンピュータ・システムは(iSCSI)命名と発見を連結します」、RFC3721、2004年4月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP", RFC
3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF.Travostino、「ブロック格納プロトコルをIPの上に保証します」、RFC3723(2004年4月)。
Chadalapaka Standards Track [Page 36] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[36ページ]RFC5048iSCSI修正と明確化2007年10月
[RFC3722] Bakke, M., "String Profile for Internet Small Computer
Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[RFC3722]バッキー、M.、「インターネットの小さいコンピュータ・システムインタフェース(iSCSI)名のためのストリングプロフィール」、RFC3722、2004年4月。
[SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-2).
[SAM2]ANSI INCITS366-2003、SCSI構造モデル-2(SAM-2。)
[SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM-a3).
[SAM3]ANSI INCITS402-2005、SCSI構造モデル-3(SAM-a3。)
[SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM-4),
Work in Progress.
[SAM4]T10は突出しています: 1683-D SCSI構造モデル-4(SAM-4)は進行中で働いています。
Acknowledgements
承認
The IP Storage (IPS) Working Group in the Transport Area of the IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group.
IETFのTransport AreaのIP Storage(IPS)作業部会はiSCSIプロトコル(他の多くの関連IP Storageプロトコルは別として)を定義するのに責任があります。 エディタは全体のワーキンググループの貢献を承諾します。
The following individuals directly contributed to identifying [RFC3720] issues and/or suggesting resolutions to the issues clarified in this document: David Black, Gwendal Grignou, Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh Gupta, Eddy Quicksall, Paul Koning. This document benefited from all of these contributions.
以下の個人は直接[RFC3720]問題を特定する、そして/または、本書でははっきりさせられた問題に解決を示すのに貢献しました: デヴィッドBlack、グェンダルGrignou、マイク・コー、Dmitryフォミチェフ、ビルStudenmund、ケンSandars(ボブ・ラッセル、ジュリアンSatran)はエリオットから略奪します、ジョゼフ・ピットマン、Someshグプタ、渦巻Quicksall、ポール・コウニング。 このドキュメントはこれらの貢献のすべての利益を得ました。
Editor's Address
エディタのアドレス
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd. Roseville, CA 95747-5668, USA Phone: +1-916-785-5621 EMail: cbm@rose.hp.com
Mallikarjun Chadalapakaヒューレット・パッカード会社8000山麓の丘Blvd. ローズビル、カリフォルニア95747-5668(米国)は以下に電話をします。 +1-916-785-5621 メールしてください: cbm@rose.hp.com
Chadalapaka Standards Track [Page 37] RFC 5048 iSCSI Corrections and Clarifications October 2007
Chadalapaka標準化過程[37ページ]RFC5048iSCSI修正と明確化2007年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんな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に情報を記述してください。
Chadalapaka Standards Track [Page 38]
Chadalapaka標準化過程[38ページ]
一覧
スポンサーリンク
