RFC5048 Internet Small Computer System Interface (iSCSI)

RFC 5048 - iSCSI Corrections and Clarifications
Network Working Group
Request for Comments: 5048
Updates: 3720
Category: Standards Track
RFC5048
Internet Small Computer System Interface (iSCSI)
Corrections and Clarifications
2007.10
日本語版
このメモの位置づけ
本書はインターネットコミュニティにおける、インターネット標準化過
程プロトコルを規定し、改善のための議論と提唱を求めるものである。標
準化の状態と本プロトコルのステータスについては "Internet Official
Protocol Standards"(STD 1) を参照のこと。このメモの配布は制限されな
い。
概要
インターネット小型コンピュータシステムインタフェース（ Internet
Small Computer System Interface:iSCSI ）は SCSI 転送プロトコルであり
、 SCSI アーキテクチャとコマンドセットを TCP/IP 上に対応付けるもので
ある。 iSCSI プロトコルは RFC3720 で規定される。本書は、 RFC3720 で規定
されるオリジナルのプロトコルに対して明瞭化のための解釈を加え、 iSCSI
実装者に対する手引書を提供する。本書は RFC3720 を更新する。 RFC3720
の記述と本書の記述に相違がある場合には、本書の内容が優先される。
本書は nabiki_t が勝手に和訳したものであり、内容の正確性等、全ての事項について一切の保証は存在しない。
2014 年 2 月 3 日
1
RFC 5048 - iSCSI Corrections and Clarifications
目次
1 概要...................................................................................4
2 定義、頭字語、ドキュメントサマリ.......................................................5
2.1 定義...............................................................................5
2.2 頭字語.............................................................................5
2.3 明確化、変更、新規の定義...........................................................6
3 SCSI タスクに関する iSCSI の定義.........................................................8
3.1 残留数の扱い.......................................................................8
3.1.1 概要.........................................................................8
3.1.2 SCSI REPORT LUNS と残留オーバーフロー.........................................8
3.2 R2T の順序付け......................................................................9
3.3 レスポンス順序付けにおけるモデルの仮定..............................................9
3.3.1 モデルの説明................................................................10
3.3.2 インタフェースモデルにおける iSCSI の定義.....................................10
3.3.3 現時点におけるレスポンスフェンスが使用されるユースケースのリスト.............10
4 タスク管理............................................................................12
4.1 複数タスクに影響するリクエスト....................................................12
4.1.1 影響を受けるタスクのスコープ................................................12
4.1.2 複数タスクを中断させる動作の明確化..........................................12
4.1.3 複数タスクを中断させる動作の更新............................................13
4.1.3.1 破棄による影響の更新....................................................15
4.1.4 影響を受けるタスクが RFC3720 と FastAbort セッションで共有される場合...........15
4.1.5 実装上の考慮点..............................................................15
4.1.6 新しい定義の背後にある論理的説明............................................16
5 発見の定義............................................................................17
5.1 発見セッションにおけるエラーリカバリ..............................................17
5.2 発見セッションの再生成の定義......................................................17
5.2.1 無名発見セッション..........................................................17
5.2.2 名前付き発見セッション......................................................18
5.3 発見セッションにおけるターゲット PDU...............................................18
6 ネゴシエーションおよびその他..........................................................19
6.1 TGPT の値..........................................................................19
6.2 SessionType のネゴシエーション.....................................................19
6.3 NotUnderstood の使用法.............................................................19
6.4 未解決のネゴシエーション交換......................................................19
7 iSCSI エラー処理とリカバリ............................................................20
7.1 ITT...............................................................................20
7.2 フォーマットエラー................................................................20
7.3 ダイジェストエラー................................................................20
7.4 メッセージエラー検証..............................................................20
8 iSCSI PDU.............................................................................21
8.1 非同期メッセージ..................................................................21
8.2 リジェクト........................................................................21
9 ログイン/テキスト操作テキストキー.....................................................22
9.1 TaskReporting.....................................................................22
10 セキュリティ上の考慮点...............................................................23
11 IANA の考慮点........................................................................24
2
RFC 5048 - iSCSI Corrections and Clarifications
11.1
11.2
11.3
11.4
11.5
11.6
11.7
11.8
iSCSI に関する IANA レジストリ.....................................................24
iSCSI Opcode.....................................................................24
iSCSI ログイン／テキストキー......................................................26
iSCSI 非同期イベント..............................................................27
iSCSI タスク管理機能コード........................................................28
iSCSI ログインレスポンスステータスコード..........................................28
iSCSI リジェクト理由コード........................................................30
iSER Opcodes.....................................................................30
12 参考文献.............................................................................32
12.1 引用規格.........................................................................32
12.2 参考となる規格...................................................................32
3
RFC 5048 - iSCSI Corrections and Clarifications
1
概要
[RFC3720]が公開されて以降、いくつかの iSCSI 実装が構築され、今日では実装に関する専門知
識により iSCSI コミュニティも拡大している。本書の目的は、[RFC3720]の内容を明確化すること
と、[RFC3720]の欠陥を修正するために、これらの専門知識を活用することである。本書では、
iSCSI を実装する観点から不明瞭な箇所に関するガイドラインを提供し、それにより相互接続性を
向上し、iSCSI の採用を推進する。しかしながら本書は、iSCSI 実装者に対する包括的なハウツー
ガイドや、あるいは[RFC3720]の完全版となることを目指すものではない。その代わり、本書は、
iSCSI 実装者に対する[RFC3720]の手引書となることを目的とする。
iSCSI 実装者には、必須の要求である[RFC3720]に加えて、[RFC3722]と[RFC3723]を参照するこ
とが要求される。さらに、[RFC3721]にもまた iSCSI を実装する上で有用な情報が記述されている。
しかしながら、本書は[RFC3720]の内容に存在する問題点を修正する。本書の内容は[RFC3720]に
優先する。
4
RFC 5048 - iSCSI Corrections and Clarifications
2
定義、頭字語、ドキュメントサマリ
2.1
定義
•
I/O バッファ：SCSI の読み込みないし書き込み操作で使用されるバッファであり、SCSI
データはバッファに対して送受信が行われる。あるタスクに対して読み込みないし書き込
みのデータ転送を行うためには、イニシエータでは 1 つの I/O バッファが、ターゲットには
少なくとも 1 つの I/O バッファが存在することが要求される。
•
SCSI 提示のデータ転送長（SCSI-Presented Data Transfer Length：SPDTL）：SPDTL は、
ある SCSI タスクのコンテキストにおいて、Data-In ないし Data-Out 転送を行うために、
SCSI レイヤが iSCSI レイヤに対して論理的に"提示"したデータの、合計長の事である。双
方向タスクにおいては 2 つの SPDTL の値が存在する。すなわち、1 つは Data-In のものであ
り、もう 1 つは Data-Out のものである。"提示"の概念には[SAM2]のデータ転送モデルにお
ける即時データが含まれ、SCSI レイヤにより要求されるオーバーラップしたデータ転送は
含まれない事に注意すること。
•
サードパーティ：本書では、ある独立した iSCSI セッションのコンテキスト内で実行され
た動作により副作用が生じた時に、その副作用の影響を受ける iSCSI セッションとネクサ
スオブジェクト（I_T ネクサスもしくは I_T_L ネクサス）が存在する場合、本書ではそれら
を示す用語として本単語を使用する。例えば、サードパーティセッションは、ある別の I_T
ネクサスで実行された LU リセット TMF により LU リセットが行われた際、当該 LU に接続す
いた I_T_L ネクサスをホストする iSCSI セッションの事を示す。
本書で使用されるキーワード、"しなければならない（MUST）"、"してはならない（MUST
NOT）"、"要求される（REQUIRED）"、"しなければならない（SHALL）"、"してはならない（SHALL
NOT）"、"するべきである（SHOULD）"、"するべきではない（SHOULD NOT）"、"推奨される
（RECOMMENDED）"、"可能である／可能性がある（MAY）イ"、"オプションで（OPTIONAL）"は、
[RFC2119]の規定に従い解釈される。
2.2
頭字語
頭字語
元の定義
訳語
EDTL
Expected Data Transfer Length
予測されるデータ転送長
IANA
Internet Assigned Numbers Authority
Internet Assigned Numbers
Authority
IETF
Internet Engineering Task Force
インターネット技術標準化委員会
I/O
Input - Output
入出力
IP
Internet Protocol
インターネットプロトコル
iSCSI
Internet SCSI
インターネット SCSI
iSER
iSCSI Extensions for RDMA
RDMA における iSCSI 拡張
ITT
Initiator Task Tag
イニシエータタスクタグ
LO
Leading Only
Leading Only
LU
Logical Unit
論理ユニット
LUN
Logical Unit Number
論理ユニット番号
PDU
Protocol Data Unit
プロトコルデータユニット
RDMA
Remote Direct Memory Access
遠隔直接メモリアクセス
R2T
Ready To Transfer
転送準備完了
イ MAY は日本語の読みやすさに応じて「可能である」と「可能性がある」のいずれかに訳しているが、意味は同じである。
5
RFC 5048 - iSCSI Corrections and Clarifications
R2TSN
Ready To Transfer Sequence Number
転送準備完了シーケンス番号
RFC
Request For Comments
Request For Comments
SAM
SCSI Architecture Model
SCSI アーキテクチャモデル
SCSI
Small Computer Systems Interface
小型コンピュータシステムインタ
フェース
Sequence Number
シーケンス番号
SN
SNACK
2.3
Selective Negative Acknowledgment ま選択的否定応答またはシーケンス番
たは Sequence Number Acknowledgement 号受信応答
for data
TCP
Transmission Control Protocol
転送制御プロトコル
TMF
Task Management Function
タスク管理機能
TTT
Target Transfer Tag
ターゲット転送タグ
UA
Unit Attention
ユニット警告
明確化、変更、新規の定義
本書は[RFC3720]の定義に対して特定の変更を加え、同様に、新しく iSCSI の定義を規定する。
さらに、本書はまた[RFC3720]の定義に対して明確化を図る。本章では、本書の内容について概要
を述べ、かつ、それぞれの節について、明確化、変更、新規の定義の内の 1 つないし複数にカテ
ゴリ分けを行う。
•
セクション 3.1.1：iSCSI 残留数の計算についての、一般原則の明確化を行う。
•
セクション 3.1.2：例を示し、iSCSI 残留数の計算について明確化を行う。
•
セクション 3.2：R2T 順序付けの要求について明確化を行う。
•
セクション 3.3：複数コネクションの iSCSI セッションにおける、レスポンス順序付けにつ
いて、新規の定義を行う。
•
セクション 4.1.2：全ての実装が従わなければならない、複数のタスクを中断させることに
関する、明確化、変更、新規の定義を行う。
•
セクション 4.1.3：高速なエラーリカバリのために実装で使用されるべき、複数タスクを中
断させることに関する、変更と新規の定義（FastAbort セマンティクス）を行う。
•
セクション 4.1.3.1：FastAbort セマンティクスの結果による、iSCSI オブジェクトに対す
る破棄の影響について変更を行う。
•
セクション 4.1.4：FastAbort セマンティクスとサードパーティセッションの相互作用に関
する、新規の定義を行う。
•
セクション 4.1.5：正しい iSCSI プロトコルの動作を実現する上で求められる、未解決の
データ転送に関する実装上の考慮点について明確化を行う。
•
セクション 4.1.6：FastAbort セマンティクスの背後にある意図について明確化を行う
（[RFC3720]の定義に関する明確化ではない）。
•
セクション 5.1：発見セッションに適用される、エラーリカバリの定義に関する明確化を行
う。
•
セクション 5.2.1：無名発見セッションにおける、イニシエータセッション識別子（ISID）
ルール（[RFC3720]）に対する明確化と新規の定義を行う。
6
RFC 5048 - iSCSI Corrections and Clarifications
•
セクション 5.2.2：名前付き発見セッションにおける、ISID ルールに対する明確化と新規
の定義を行う。
•
セクション 5.3：発見セッションにおいて、許可される PDU の種別と、ターゲットのログア
ウト通知の動作に関する明確化を行う。
•
セクション 6.1：ターゲットポータルグループタグ（TGPT）で 0 が使用される事の合法性に
関する明確化を行う。
•
セクション 6.2：SessionType と他のキーとの間の、ネゴシエーションを行う順番について
明確化を行う。
•
セクション 6.3：宣言キーに対する NotUnderstood のネゴシエーション応答と、暗黙的な意
味について、明確化を行う。
•
セクション 6.4：正当な未解決ネゴシエーション PDU（テキスト、もしくはログインに関係
する）の個数について明確化を行う。
•
セクション 7.1：ITT の値として 0xffffffff を使用する方法に関する明確化を行う。
•
セクション 7.2：[RFC3720]で定義されるエラーリカバリの目的において、フォーマットエ
ラーを構成する事項に関して明確化を行う。
•
セクション 7.3：非要請 PDU を破棄する場合における、エラーリカバリの定義を変更する。
•
セクション 7.4：入力 PDU に対するエラー検証で目的とするレベルについて明確化する。
•
セクション 8.1：新規の AsyncEvent コードを定義する。
•
セクション 8.2：正当な Reject の理由コード 0x0b を変更する。これは現在では非推奨であ
る。
•
セクション 9.1：新規のテキストキー TaskReporting を新規に定義する。
7
RFC 5048 - iSCSI Corrections and Clarifications
3
SCSI タスクに関する iSCSI の定義
3.1
残留数の扱い
[RFC3720]のセクション 10.4.1 では、"残留数"の概念について定義を行い、残留数を SCSI レス
ポンス PDU の Counts と Flags フィールドに対してどのようにエンコードするべきかについて規定
している。セクション 3.1.1 では、[RFC3720]の意図するところの明確化を行い、一般規則につい
て説明する。セクション 3.1.2 では、REPORT LUNS コマンドを例として、残留数の取り扱いについ
て記述する。
3.1.1
概要
SCSI 提示のデータ転送長（SCSI-Presented Data Transfer Length ：SPDTL）は、あるタスクに
関してターゲットの SCSI レイヤがローカルの iSCSI レイヤを用いて転送を試みる、データの合計
長を表す本書で使用される単語である（セクション 2.1 定義を参照）。予測されるデータ転送
長（SCSI-Presented Data Transfer Length：SPDTL）は、あるタスクについて iSCSI レイヤが転
送されるものと予測したデータの長さである。EDTL は SCSI コマンド PDU により指定される。
あるタスクについて SPDTL = EDTL であれば、ターゲットの iSCSI レイヤは、残留数が 0 でタス
クを完了する。あるタスクについて SPDTL が EDTL と異なる場合、そのタスクは残留数が存在する
ものと報告される。
あるタスクについて SPDTL > EDTL であれば、[RFC3720]の規定に従い、iSCSI のオーバーフロー
が SCSI レスポンス PDU で示されなければならない。残留数には(SPDTL - EDTL)の数値が設定され
なければならない。
あるタスクについて SPDTL < EDTL であれば、[RFC3720]の規定に従い、iSCSI アンダーフローが
SCSI レスポンス PDU で示されなければならない。残留数には(EDTL - SPDTL)の数値が設定されな
ければならない。
オーバーフローとアンダーフローのシナリオは、Data-In と Data-Out からは独立であることに
注意すること。どちらのシナリオも、どちらの方向のデータ転送においても論理的に発生しうる。
3.1.2
SCSI REPORT LUNS と残留オーバーフロー
本セクションでは SCSI REPORT LUNS コマンドの例を引用して、残留オーバーフローの問題につ
いて議論する。ALLOCATION LENGTH フィールドが存在するいくつかの SCSI コマンド（例えば、
INQUIRY）は、どのようなものでも同一のルールに従う事に注意すること。本セクションの後半の
定義は、そのような SCSI コマンドの全てに対して適用される。
SCSI REPORT LUNS コマンドの仕様は、ターゲットが転送するデータ量を、REPORT LUNS CDB によ
りイニシエータが指定した最大サイズ（ALLOCATION LENGTH）に制限することを要求する。ある
REPORT LUNS コマンドのための SCSI コマンド PDU において、iSCSI ヘッダ内の予測されるデータ転
送長（EDTL）に、少なくとも ALLOCATION LENGTH と同じ値が設定されていた場合には、SCSI レイ
ヤによる切り詰めが行われる事により、iSCSI 残留オーバーフローの発生が防止される。SCSI イ
ニシエータは、SCSI レイヤの他の情報により、そのような切り詰めが発生したことを検知するこ
とが可能である。本セクションの後半では、この要求される動作について詳しく解説する。
iSCSI は、SCSI レスポンス PDU ないし最後の SCSI Data-In PDU 内に存在する Flags フィールド
の(O)ビット（ビット 5）を、転送されるべきデータ量が対象となる SCSI コマンド PDU における
EDTL を超えたために、iSCSI ターゲットが、当該コマンドのための SCSI データの全体をイニシ
エータに転送できなかった事を示すために使用する（[RFC3720]のセクション 10.4.1 を参照）。
SCSI REPORT LUNS コマンドはターゲットの SCSI レイヤに対して、論理ユニットの目録（LUN リ
スト）をイニシエータの SCSI レイヤに転送するよう要求する（SPC-3 のセクション 6.21 を参照
[SPC3]）。REPORT LUNS コマンドを発行する際、イニシエータの SCSI レイヤには LUN リストのサ
イズを知ることができない可能性がある。イニシエータが準備していたものよりも多量の LUN リ
8
RFC 5048 - iSCSI Corrections and Clarifications
ストのデータが転送されることを防止するため、REPORT LUNS CDB には、当該コマンドのためにイ
ニシエータに転送されるべきデータの最大量を指定する ALLOCATION LENGTH フィールドが存在す
る。イニシエータ SCSI レイヤがターゲット側の論理ユニットの個数を過小に見積もった場合、完
全な論理ユニットの目録は、ALLOCATION LENGTH で指定された範囲内に格納できない可能性がある。
この状況下では、[SPC3]のセクション 4.3.4.6 ではターゲット側の SCSI レイヤに対して、
ALLOCATION LENGTH フィールドで指定されたバイト数まで転送してしまったら「Data-In バッファ
への転送を中断しなければならない」ことを要求している。
従って、REPORT LUNS コマンドのレスポンスで、ターゲット側の SCSI レイヤは多くとも
ALLOCATION LENGTH バイトのデータ（論理ユニットの目録）を、イニシエータへの転送のために
iSCSI レイヤに提示する。REPORT LUNS コマンドにおいて、iSCSI EDTL が少なくとも ALLOCATION
LENGTH と同じであれば、SCSI による切り詰めが行われる事により、EDTL が転送されるべきデータ
全体に適合することが保証される。iSCSI レイヤに提示された論理ユニットの目録データ全体--す
なわち、SCSI により切り詰められた後半部分--が iSCSI によりイニシエータへ転送された場合、
iSCSI 残留オーバーフローは発生せず、SCSI レスポンス PDU ないし最後の SCSI Data-Out PDU 内の
(O)ビットが設定されてはならない。これは新しい要求ではなく、[RFC3720]と[SPC3]の REPORT
LUNS コマンドの組み合わせにより、すでに要求されている事項である。しかしながらこのシナリ
オにおいて、iSCSI EDTL が ALLOCATION LENGTH よりも大きかった場合、SCSI レスポンス PDU で
iSCSI アンダーフローが報告されなければならないことに注意すること。iSCSI EDTL が
ALLOCATION LENGTH と等しかったが、iSCSI レイヤに対して提示された論理ユニットの目録が
ALLOCATION LENGTH よりも小さかった場合にも、iSCSI アンダーフローは報告されなければならな
い。
論理ユニットの目録に存在する LUN LIST LENGTH フィールド（論理ユニットの目録の最初に存在
するフィールド）は、ALLOCATION LENGTH に適合させるための目録の切り詰めによる影響を受けな
い。これは、SCSI イニシエータが、目録内の LUN LIST LENGTH が REPORT LUNS CDB で送信された
ALLOCATION LENGTH よりも大きい事を検知することにより、受信した目録が不完全なものであるこ
とを検知することを可能とする。この状況下における一般的なイニシエータの動作は、より大き
な ALLOCATION LENGTH を指定した REPORT LUNS コマンドを再発行することである。
3.2
R2T の順序付け
[RFC3720]のセクション 10.8 では下記のように規定されている。
ターゲットは、複数個の R2T PDU を送信することが可能である。そのため、未解決のデー
タ転送が複数個存在しうる。未解決の R2T PDU の個数は、MaxOutstandingR2T のネゴシ
エーションキーの値により制限される。コネクション内では、未解決の R2T は、イニシ
エータによりそれらが受信された順に解決されなければならない。
引用された[RFC3720]の記述は、適用されるべきスコープ--タスク毎なのか、コネクション内の
全てのタスクを跨ってなのか--が不明瞭であり、かつ、どちらとも解釈可能である。本セクショ
ンでは、引用された記述の適用対象がタスクであるものと言明する。R2T の順序付けと、タスクを
跨ったターゲットでの生成順やイニシエータでの解決順との間の関係は暗示されない。すなわち、
タスク内での未解決の R2T は、コネクション内でそれらが受信された順に、イニシエータにより
解決されなければならない。
3.3
レスポンス順序付けにおけるモデルの仮定
iSCSI セッションが複数のコネクションから構成される場合、ターゲット側の SCSI レイヤによ
り生成されるレスポンス PDU（タスクのレスポンスないし TMF のレスポンス）は、ターゲット側
iSCSI レイヤにより iSCSI コネクション忠実性のルールに従い、複数のコネクションに分散される。
この処理は一般的に、イニシエータ側 SCSI レイヤへそれらが配信される時間に関して、レスポン
スの順序性を維持しない。SCSI レスポンス間の順序性は期待されないが、このアプローチは一般
的なケースにおいては問題なく動作する。しかしながら、SCSI レイヤによりある種の順序付けが
期待される特別なケースにおいては、SCSI レスポンスメッセージが SCSI プロトコルレイヤから
9
RFC 5048 - iSCSI Corrections and Clarifications
iSCSI レイヤへ手渡される際の取り扱いを考慮に入れ、後述する"レスポンスフェンス"セマンティ
クスを定義する。
3.3.1
モデルの説明
ターゲット側 SCSI プロトコルレイヤは、"Send Command Complete"プロトコルデータサービス
（[SAM2]、5.4.2 を参照）と、"Task Management Function Executed"サービス（[SAM2]、6.9 を
参照）を呼び出すことにより、ターゲット側 iSCSI レイヤに SCSI レスポンスメッセージを手渡す。
SCSI レスポンスメッセージを受信した時、iSCSI レイヤは、特定の SCSI レスポンスメッセージに
おいて、レスポンスフェンスの動作を行う（本セマンティクスの適用対象となる特定のインスタ
ンスについてはセクション 3.3.3 に示す）。ある SCSI レスポンスメッセージにレスポンスフェン
スの動作が要求される場合、ターゲット側 iSCSI レイヤは、イニシエータ側 iSCSI レイヤにレス
ポンスメッセージを配信する際に、下記の条件に適合することを保証しなければならない。
1. レスポンスフェンスが適用されるレスポンスは、当該 I_T_L ネクサス上に存在する"先行す
る"レスポンス全てに対して時間的に後、すなわち、先行するレスポンスの全てがイニシ
エータ側 iSCSI レイヤに配信された後で、配信されなければならない。
2. レスポンスフェンスが適用されるレスポンスは、当該 I_T_L ネクサス上に存在する"後続す
る"レスポンスに対して時間的に後で、配信されなければならない。
"先行する"と"後続する"という概念は、レスポンスメッセージがターゲット側 SCSI レイヤから
ターゲット側 iSCSI レイヤに手渡された順番を意味する。
3.3.2
インタフェースモデルにおける iSCSI の定義
ある iSCSI セッションにおいて TaskReporting キー（セクション 9.1）の値が ResponseFence な
いし FastAbort としてネゴシエーションされており、かつ、ある SCSI レスポンスメッセージに対
してレスポンスフェンスの動作が要求される場合には、ターゲット側 iSCSI レイヤは当該セッ
ションにおいて、本セクションで規定される動作を実行しなければならない。
a) 単一コネクションのセッションであれば、特別な処理は不要である。標準的な SCSI レスポ
ンス PDU の構築と配信処理が行われる。
b) 複数コネクションのセッションであれば、ターゲット側 iSCSI レイヤは、iSCSI セッション
内のコネクション毎に、最後に送信されてからまだ受信応答が得られていない StatSN を記
録し、そのような StatSN のそれぞれについて受信応答を待ち合わせ（本処理を高速化する
ために、必要に応じて受信応答を要求する NOP-IN を使用することが可能である）、その後
フェンスを解除する。レスポンスフェンスを要求する SCSI レスポンスは、受信応答が得ら
れていない各 StatSN について、受信応答が得られるよりも前に送信されてはならない。
c) ターゲット側 iSCSI レイヤは、レスポンスフェンスの動作を要求する SCSI レスポンスを搬
送する SCSI レスポンス PDU に対する、受信応答を待ち合わせなければならない。当該受信
応答が得られた後でのみ、当該のフェンスが解除されたものと見なされなければならない。
d) 当該 LU における全ての詳細なステータス処理は、フェンスが解除された後でのみ続行され
なければならない。当該 I_T_L ネクサスにおける何らかの新規レスポンスを、フェンスが
解除されるより前に SCSI レイヤから受信した場合、それらのレスポンス PDU はフェンスが
解除されるまで、iSCSI レイヤでキューに格納され、保持されていなければならない。
3.3.3
現時点におけるレスポンスフェンスが使用されるユースケースのリスト
本セクションでは、iSCSI 実装が準拠しなければならない、レスポンスフェンスが使用される
ユースケースのリストを示す。しかしながら、これは完全なリストではない。SCSI プロトコル仕
様の拡張に伴い、その時々の状況に応じてレスポンスフェンスが仕様として規定されることが予
測される。
10
RFC 5048 - iSCSI Corrections and Clarifications
ある iSCSI セッションで TaskReporting キー（セクション 9.1 を参照）が ResponseFence ないし
FastAbort としてネゴシエーションされている場合、ターゲット側 iSCSI レイヤは、下記の SCSI
完了メッセージに対してレスポンスフェンスが要求されるものと仮定しなければならない。
1. 複数タスクを中断させるタスク管理機能を発行した後、当該セッションおよびサードパー
ティセッションにおいて、UA を搬送する最初の完了メッセージ。
2. 当該セッションにおける、複数タスクに対する TMF レスポンス。
3. 当該セッションにおける ACA の確立を示す完了メッセージ。
4. 当該セッションおよびサードパーティセッションにおける、ACA 確立後に ACA ACTIVE ス
テータスを通知する最初の完了メッセージ。
5. 当該セッションにおける CLEAR ACA のレスポンスを搬送する、TMF レスポンス。
6. PERSISTENT RESERVE OUT / PREEMPT AND ABORT コマンドに対するレスポンス。
注意：ACA に関係するフェンスの要求が[RFC3720]で規定されていないことから、イニシエータ
の実装は、[RFC3720]にのみ準拠するターゲットに対して複数コネクションのセッションを使用す
る場合は、ACA を使用するべきではない。複数コネクションのセッションで ACA の使用を要求する
イニシエータは、最初のアクセスで TaskReporting キー（セクション 9.1 を参照）で
ResponseFence ないし FastAbort の値をネゴシエーションすることにより、レスポンスフェンスの
動作について確認するべきである。
11
RFC 5048 - iSCSI Corrections and Clarifications
4
タスク管理
4.1
複数タスクに影響するリクエスト
本セクションでは、[RFC3720]セクション 10.6.2 の、オリジナルの記載に対して明確化と変更を
行う。明確化する定義（セクション 4.1.2 を参照）は、オリジナルの記載により要求されるプロ
トコル動作のスーパーセットであり、全ての iSCSI 実装がこの新しい動作をサポートしなければ
ならない。他方の、更新される定義（セクション 4.1.3 を参照）は、新規の TaskReporting キー
（セクション 9.1 を参照）が"FastAbort"としてネゴシエーションされた場合にのみ必須となる。
4.1.1
影響を受けるタスクのスコープ
本セクションでは、複数タスクを中断させるシナリオにおける、"影響を受けるタスク"の概念
を定義する。本セクションで定義するスコープは、プロトコル動作の明確化（セクション 4.1.2
を参照）と、プロトコル動作の更新（セクション 4.1.3 を参照）の両方に適用される。
ABORT TASK SET：ABORT TASK SET TMF リクエスト PDU 内の LUN フィールドにより識別される
I_T_L ネクサスにおける、全ての未解決のタスク。
CLEAR TASK SET：CLEAR TASK SET TMF リクエスト PDU 内の LUN フィールドにより識別される LU
のタスクセットにおける、全ての未解決のタスク。タスクセットの定義については[SPC3]を参照
のこと。
LOGICAL UNIT RESET：LOGICAL UNIT RESET リクエスト PDU 内の LUN フィールドで識別される LU
における、全てのイニシエータから受信した全ての未解決タスク。
TARGET WARM RESET/TARGET COLD RESET：当該 TMF が発行されたセッションがアクセスしている
先となるターゲットに存在する全ての LU において、全てのイニシエータから受信した全ての未解
決タスク。
表記について：上記の記載における"ABORT TASK SET TMF リクエスト PDU"は、"Function"フィー
ルドに[RFC3720]で規定される"ABORT TASK SET"が設定された、iSCSI TMF リクエスト PDU の事を
示す。他のスコープの記述においても同様の表記が使用される。
4.1.2
複数タスクを中断させる動作の明確化
全ての iSCSI 実装は、デフォルトの動作として本セクションで定義されるプロトコルの動作をサ
ポートしなければならない。TARGET WARM RESET、TARGET COLD RESET TMF リクエストは、イニシ
エータとターゲットのそれぞれで定義される、後述する動作のシーケンスから構成される。
イニシエータ側 iSCSI レイヤ：
a) イニシエータ側 iSCSI レイヤは、影響を受けるタスクにおける、受信した TTT に対する応答
を継続しなければならない。
b) イニシエータ側 iSCSI レイヤは、影響を受けるタスクから受信した全てのレスポンスを、
通常の方法により処理するべきである。レスポンスは TMF レスポンスの前に送信されるこ
とが保証されているため、これは許容可能である。
c) イニシエータが TMF レスポンスの送受信が不可能となるような何らかの動作（例えば、LU
リセットやコネクションの破棄）を行った場合を除き、イニシエータ側 iSCSI レイヤは、
影響を受ける全てのタスクの終了メッセージとして、TMF レスポンスを受信するべきである。
どちらの場合においても、イニシエータは、本ステップの一部として、影響を受けるタス
クを終了させなければならない。かつ、影響を受けるタスクが終了された後に受信されさ
れた TMF レスポンスを破棄しなければならない。
ターゲット側 iSCSI レイヤ：
12
RFC 5048 - iSCSI Corrections and Clarifications
a) ターゲット側 iSCSI レイヤは、影響を受けるタスクにおける現在有効なターゲット転送タ
グについて、TMF リクエストを発行したイニシエータからのレスポンスを待ち受けなければ
ならない。ターゲット側 iSCSI レイヤは、影響を受けるタスクにおける現在有効なター
ゲット転送タグについて、サードパーティのイニシエータからのレスポンスを待ち受ける
ことが可能である。
b) ターゲット側 iSCSI レイヤは、CmdSN に基づき、影響を受けるタスクの受信されるべき全て
のコマンドを待ち受けなければならない（ステップ a の受信待機と同時に行う）。サード
パーティの影響を受けるセッションで、新規のコマンドを待ち受けるべきではない。イン
スタンス化されたタスクは、影響を受けるタスクか否か判断する目的のためであると見な
されなければならない。ターゲットスコープのリクエスト（すなわち、TARGET WARM RESET
と TARGET COLD RESET）の場合、当該セッションのコマンドストリームにおいて、まだ受信
されていない全てのコマンドは、コマンド待ち合わせの期間を設けることなくすでに受信
されたものと見なすことが可能である。すなわち、タスク管理機能の CmdSN までの全ての
CmdSN は"栓がされた"ものと見なすことが可能である。
c) ターゲット側 iSCSI レイヤは、ターゲット側 SCSI レイヤに対して TMF リクエストを通知し、
かつ、ターゲット側 SCSI レイヤからレスポンスを受信しなければならない。
d) ターゲット側 iSCSI レイヤはセクション 3.3.2 の規定に従い、TMF リクエストが発行され
たセッション上で、TMF レスポンスに対してレスポンスフェンスの動作を行わなければなら
ない。
e) ターゲット側 iSCSI レイヤはセクション 3.3.2 の規定に従い、サードパーティセッション
上で、TMF レスポンスに後続する初回のレスポンスに対してレスポンスフェンスの動作を行
わなければならない。いくつかのタスクが iSCSI ではない I_T_L ネクサスで開始されていた
場合に、影響を受けた全てのタスクがイニシエータにステータスを返す事を、ターゲット
で保証する方法については、iSCSI ではない当該転送プロトコルで規定される。
技術的に、TMF のサービスはステップ d で完了する。しかしながら、終了されるタスクに対応す
るデータ転送は、ステップ e の終了までサードパーティセッションで継続される可能性がある。
ターゲット側 iSCSI レイヤは、ステップ d の終了時点まで TMF レスポンスを送信してはならず、そ
れらタスクの未解決のデータ転送がステップ e の後まで継続している場合においても、ステップ d
の終了時点で TMF レスポンスを送信することが可能である。
4.1.3
複数タスクを中断させる動作の更新
本書に準拠する全ての iSCSI 実装は、本セクションで規定されるプロトコルの動作を実装しなけ
ればならない。本セクションで規定されるプロトコル動作は、セッションの TaskReporting キー
（セクション 9.1 を参照）が"FastAbort"としてネゴシエーションされている iSCSI セッションに
おいて、iSCSI 実装により実行されなければならない。ABORT TASK SET、CLEAR TASK
SET、LOGICAL UNIT RESET、TARGET WARM RESET、TARGET COLD RESET の各 TMF リクエストは、イニ
シエータとターゲットのぞれそれで規定される、下記に記載された順に従い実行される動作から
構成される。
イニシエータ側 iSCSI レイヤ：
a) イニシエータ側 iSCSI レイヤは、一度当該 TMF がターゲットに送信されたら、それを送信し
たセッション内のコネクションで、影響を受けるタスクに関する Data-Out PDU を送信して
はならない。
b) イニシエータ側 iSCSI レイヤは、影響を受けるタスクから送られたレスポンスを、通常の
方法に従い処理するべきである。これは、当該レスポンスが TMF レスポンスより前に送信
されることが保証されるため、受け入れ可能である。
c) イニシエータ側 iSCSI レイヤは、AsyncEvent=5 の非同期メッセージに対して、セクション
8.1 の定義に従い応答しなければならない。
13
RFC 5048 - iSCSI Corrections and Clarifications
d) イニシエータ側 iSCSI レイヤは TMF レスポンスを、影響を受けるタスクの内でレスポンスを
受信していないものを終了させるものとして取り扱わなければならない。かつ、TMF レスポ
ンスが SCSI レイヤに渡された後に受信した、影響を受けたタスクのレスポンスを全て破棄
しなければならない（しかしながら本セクションの定義により、規格に準拠するターゲッ
トの実装に対しては、実行順序が不定となるシナリオは発生し得ないことが保証される）。
ターゲット側 iSCSI レイヤ：
a) ターゲット側 iSCSI レイヤは、当該セッション上における CmdSN の順に基づき、影響を受け
るタスクにおける受信されるべき全てのコマンドの受信を待ち受ける。ターゲット側 iSCSI
レイヤは、影響を受けるサードパーティセッションで新規のコマンドを待機するべきでは
ない。インスタンス化されたタスクは、影響を受けるタスクか否か判断するためだけであ
ると見なすべきである。ターゲットスコープのリクエスト（すなわち、TARGET WARM RESET
と TARGET COLD RESET）の場合、コマンドストリーム中の、当該セッションで未だに受信し
ていないコマンドは、コマンドの受信待機を行うことなくすでに受信されたものと見なす
ことが可能である。すなわち、タスク管理機能自身の CmdSN までの、全ての CmdSN 空間は"
栓がされた"と見なすことが可能である。
b) ターゲット側 iSCSI レイヤは、ターゲット側 SCSI レイヤに対して TMF リクエストを通知し、
あるいはターゲット側 SCSI レイヤからレスポンスを受信しなければならない。
c) ターゲット側 iSCSI レイヤは、現在有効な"影響を受ける TTT"（すなわち、影響を受けるタ
スクに関連づけられた TTT）を有効なまま維持しなければならない。
d) ターゲット側 iSCSI レイヤは、AsyncEvent=5 である非同期メッセージ（セクション 8.1 を
参照）を下記のコネクションで送信しなければならない。
1. TaskReporting=FastAbort であるサードパーティセッションにおいて、影響を受けるタ
スクが少なくとも 1 つ以上忠実性が割り当てられている全てのコネクション。
2. TMF リクエストが送信された当該セッション内の当該コネクションを除く、少なくとも
1 つ以上の影響を受けるタスクの忠実性が割り当てられた全てのコネクション。
影響を受ける LU が複数存在する場合（すなわち、ターゲットリセットにより）、そのような LU
のそれぞれについて、少なくとも 1 つ以上影響を受けるタスクの忠実性が割り当てられたコネク
ションで非同期メッセージの PDU が送信されなければならない。非同期メッセージの LUN フィー
ルドには、そのような LU の LUN の値が設定されなければならない。
e) ターゲット側 iSCSI レイヤは、セクション 3.3.2 の定義に従い、TMF リクエストが発行さ
れたセッションにおいて、TMF レスポンスのレスポンスフェンスフラグを取り扱わなければ
ならない。
f) ターゲット側 iSCSI レイヤは、セクション 3.3.2 の定義に従い、サードパーティセッショ
ンにおける TMF レスポンス後の最初のレスポンスで、レスポンスフェンスフラグを取り扱
わなければならない。いくつかのタスクが iSCSI ではない I_T_L ネクサスで開始されていた
場合には、影響を受ける全てのタスクがステータスをイニシエータに返す事をターゲット
で保証する方法については、iSCSI 以外の当該転送プロトコルで規定される。
g) ターゲット側 iSCSI レイヤは、各非同期メッセージに対するレスポンスとしてイニシエー
タにより生成された NOP-Out の受信応答を受信したら、影響を受けた TTT（および、使用さ
れる場合には STag）と、対応するバッファを解放しなければならない。
技術的に、TMF のサービスはステップ e で完了する。しかしながら、終了されるタスクに対応す
るデータ転送は、ステップ f の終了時点においても継続している可能性がある。ターゲット側
iSCSI レイヤはステップ e の終了時点まで TMF レスポンスを返してはならず、かつ、未解決のデー
タ転送がステップ g まで継続する場合においても、ステップ e の終了時点で送信することが可能
である。ステップ g は、未解決のデータ転送をサポートするために予約されていた全てのリソー
14
RFC 5048 - iSCSI Corrections and Clarifications
スが解放されたイベントを規定する。
4.1.3.1 破棄による影響の更新
[RFC3720]の Appendix F,1 ではターゲットにおける破棄の影響を規定しており、LU リセット時
に"不完全な TTT"が"Y"であるものと規定している。これは、ターゲットウォームリセット、ター
ゲットコールドリセット、LU リセットの完了時に有効な TTT が破棄される事を示している。しか
しながら、本セクションで規定される TaskReporting=FastAbort の定義（セクション 9.1 を参
照）では、リセット操作の終了時に有効な TTT が破棄される事を保証していない。事実、新規の
定義は TMF レスポンスが配信された後に、"怠惰な"TTT の破棄を許容するよう設計されている。そ
のため、セッションで TaskReporting=FastAbort である場合に、リセット操作時の"不完全な TTT"
の破棄は"N"となる。
4.1.4
影響を受けるタスクが RFC3720 と FastAbort セッションで共有される場合
ターゲットの実装が TaskReporting=FastAbort 機能（セクション 9.1 を参照）をサポートする場
合、いくつかのセッションで TaskReporting=RFC3720 が使用され（RFC3720 セッション）、他の
セッションで TaskReporting=FastAbort が使用され（FastAbort セッション）、かつ、それらの
セッションが影響を受けるタスクのセットを共有してアクセスする（セクション 4.1.1 を参照）
状況に陥る可能性がある。
当該セッションが RFC3720 セッションであり、iSCSI ターゲットの実装で FastAbort がサポート
され、影響を受けるサードパーティセッションが FastAbort セッションである場合、ターゲット
側 iSCSI レイヤは下記の動作を行うべきである。
a) セクション 4.1.2 のターゲットの動作におけるステップ c と d の間で、影響を受けるタス
クが少なくとも 1 つ以上忠実性が割り当てられている、サードパーティセッション内のコ
ネクションにおいて、AsyncEvent=5（セクション 8.1 を参照）である非同期メッセージの
PDU を送信する。影響を受ける LU が複数存在する場合、そのような LU の各々について、影
響を受けるタスクが少なくとも 1 つ以上忠実性が割り当てられている各コネクション上で
非同期メッセージを 1 つづつ送信する。送信時に、非同期メッセージ PDU の LUN フィールド
には、そのような LU における LUN に対応する値が設定されなければならない。
b) セクション 4.1.2 のターゲットの動作におけるステップ e の後で、ステップ a の非同期
メッセージに対するレスポンスとしてサードパーティのイニシエータが生成した NOP-Out
の受信応答を受信したら、影響を受ける TTT（と、使用される場合には STag）と、対応す
るバッファを解放する。
当該セッションが FastAbort セッションであり、iSCSI ターゲットの実装が FastAbort をサポー
トし、かつ、影響を受けるサードパーティセッションが RFC3720 セッションであった場合、iSCSI
ターゲットレイヤにより次の動作が行われなければならない。すなわち、サードパーティセッ
ションで FastAbort の動作を通知する非同期メッセージ PDU が送信されてはならない。
影響を受けるサードパーティセッションが FastAbort セッションであり、当該セッションが
FastAbort セッションであれば、サードパーティ側のイニシエータは、セクション 8.1 の規定に従
い、AsyncEvent=5 である非同期メッセージ PDU に対して応答しなければならない。セッションが
単一コネクションのセッションである場合においても、イニシエータは、影響を受けたサード
パーティセションでそれらの非同期メッセージを受信する可能性があることに注意すること。
4.1.5
実装上の考慮点
定義の明確化（セクション 4.1.2 ）と、定義の更新（セクション 4.1.3 ）の両方で、当該
セッション上で TMF の完了が報告された後においても、未解決のデータ転送が存在する可能性が
ある。iSCSI/iSER[iSER]の場合、それらはいかなる有効なタスクにも所有されない、STag により
タグ付けされたデータ転送である可能性がある。実際のバッファがこれらのデータ転送をサポー
トするか否かは実装依存である。しかしながら、全ての場合において、データ転送は論理的に、
15
RFC 5048 - iSCSI Corrections and Clarifications
ターゲットにより黙殺されなければならない。ターゲットはまた、実装定義の内部タイムアウト
に従い、関連するバッファや STag、TTT のリソースを適切に回収するために、予測されうる DataOut シーケンス（セクション 4.1.2 を参照）や NOP-Out の受信応答（セクション 4.1.3 を参照）
を受信しないコネクションを破棄することが可能である。
4.1.6
新しい定義の背後にある論理的根拠
セクション 4.1.2 と 4.1.3 で規定される定義の背後には、3 つの基本的な目標が存在する。
1. 複数コネクションのセッションの場合も含め、ターゲット側 SCSI レイヤに対して I_T ネク
サスとして抽象化される、順序付けされたコマンドの配送を維持する。
◦ ターゲット側 iSCSI による TMF リクエストの処理は、抽象化された単一のフローを維持
しなければならない。セクション 4.1.2 のステップ b、およびセクション 4.1.3 のス
テップ a におけるターゲット動作は、この目的に対応している。
2. あるレスポンス（すなわち、TMF レスポンス）が、イニシエータの視点から見て完了してい
ない他のタスクのステータスを暗示する際に、複数コネクションのセッションの場合も含
めて、イニシエータ側 SCSI レイヤに対して I_T ネクサスとして抽象化される、順序付けさ
れたレスポンスの配送を維持する。
◦ ターゲットは、イニシエータが TMF レスポンスを受信した後に、"古い"タスクのレスポ
ンス（TMF レスポンスより物理的に前に存在するもの）を受信することがないよう保証
しなければならない。セクション 4.1.2 のステップ d、およびセクション 4.1.3 のス
テップ e のターゲットの動作は、この目的に対応する。
◦ TMF の動作が複数の I_T_L ネクサスを通じて観測可能となった際、[SAM2]では、SCSI デ
バイスサーバが他の I_T_L ネクサスのそれぞれで、UA を確立するよう要求している。一
度イニシエータがそのような UA について通知を受けると、受信したイニシエータにお
けるアプリケーションクライアントは、影響を受けたタスクにおけるタスク状態
（[SAM2]の 5.5 節）をクリアするよう要求される。そのため、イニシエータにおいてタ
スク状態がクリアされた後、すなわち、UA が通知された後で、SCSI レスポンスが不適
切に配送されることとなる。UA 通知は、TMF 動作の後の、影響を受けるサードパーティ
の I_T_L ネクサスにおける最初の SCSI レスポンスに含まれており、当該 LU にアクセス
する全ての iSCSI セッションで、影響を受けるタスクのレスポンスが返されてはならな
い。セクション 4.1.2 のステップ e と、セクション 4.1.3 のステップ f におけるター
ゲットの動作は、この目的に対応している。
3. 確実な方法により影響を受けたタスクに関連する有効な TTT を破棄する。
◦ タスクが終了したああとに到達した、古い TTT を保持する Data-Out PDU は、古い iSCSI
の実装においてはバッファ管理の問題を引き起こす可能性があり、iSCSI/iSER 実装の
コネクションにおいて致命的となり得る。（セクション 4.1.2 のステップ a で）TTT が
破棄されるまで影響を受けたタスクの終了を遅延するか、あるいは、後に確実な解放
（セクション 4.1.3 のステップ c により）を行うことができるよう、タスクが終了さ
れるまで TTT とバッファを割り当てたままとするべきである。
他に注目すべき最適化は、コマンドシーケンスに栓をする動作のみである。ある I_T ネクサスに
おける全てのタスクが（ターゲットリセットにより）中断されるのであれば、CmdSN の穴に栓をす
るために、全てのコマンドの受信を待機する必要はない。ターゲット側 iSCSI レイヤは、単純に
喪失した CmdSN のスロット全てを埋めて、TMF の処理に進行すればよい。最初の目的（単一の順序
付けされたコマンドフローを維持する）は、ターゲット側 SCSI レイヤは順序付けされたコマンド
を観測するのみであるため、本最適化を行ったとしても維持される事となる。
16
RFC 5048 - iSCSI Corrections and Clarifications
5
発見の定義
5.1
発見セッションにおけるエラーリカバリ
ErrorRecoveryLevel キーのネゴシエーションは、発見セッション--すなわち、
"SessionType=Discovery"としてネゴシエーションされたセッション--では必要ではない。なぜな
らば、デフォルト値 0 は、発見セッションでは必要十分なためである。しかしながら、いくつか
の古い iSCSI 実装では、発見セッションで ErrorRecoveryLevel キーのネゴシエーションを試みる
可能性がある。相手側によりそのようなネゴシエーションが試みられた場合、規格に準拠する
iSCSI 実装は、レスポンスとして 0 を提案しなければならない。そのため、発見セッションにおけ
る有効な ErrorRecoveryLevel は 0 でなければならない。これは、[RFC3720]が発見セッションに
課す制約から必然的に導き出される。
5.2
発見セッションの再生成の定義
発見セションは、比較的寿命が短いものであることが想定されている。イニシエータが、同一
の iSCSI ネットワークポータル（[RFC3720]を参照）に対して、複数の発見セションを構築するこ
とは無いものと考えられる。イニシエータは、異なるターゲットおよび異なるポータルグループ
に対して、同一の iSCSI イニシエータ名および ISID を用いて、一意な異なるセッションを構築す
ることが可能である。この動作は[RFC3720]のセクション 9.1.1 で述べられており、ISID の保守的
な再利用として推奨されている。[RFC3720]の ISID ルールでは、4 つのタプル
<InitiatorName、ISID、TargetName、TargetPortalGroupTag>が一致するセッションは、高々 1 で
あることが述べられている。通常セッションにおける場合と同様に、ISID ルールの意図を発見
セッションに適用した場合、発見セッションは 2 つの側面について通常セッションとは相違する
ことに注意が必要である。
[RFC3720]では、ログインリクエスト PDU で TargetName キーの指定を省略して発見セッ
ションを構築することを許容しているため（ここで我々は、このようなセッションを"無
名"発見セッションと呼ぶ）、ISID ルールを強制するためのターゲットノードのコンテキ
ストが存在しない。
ポータルグループはターゲットノード内のコンテキストにおいてのみ定義される。その
ため、TargetName キーが NULL 値（すなわち、指定されていない）場合には、
TargetPortalGroupTag は ISID ルールを強制するために使用することが不可能である。
下記のセクションでは 2 つのシナリオ、すなわち名前付き発見セッションと無名発見セッション
について、個別に説明する。
5.2.1
無名発見セッション
無名発見セッションでは、ターゲットで ISID ルールを強制するために、TargetName と
TargetPortalGroupTag のどちらも利用することができない。そのため、下記のルールが適用され
る。
無名 ISID ルール：ターゲットは、無名発見セッションに対して、4 つのタプル
<InitiatorName、ISID、NULL、TargetAddress>の一意性を強制しなければならない。この一意性
の要求により、下記の定義が暗示される。
ターゲットは、ある iSCSI ノード名と ISID を有する同一のイニシエータポートから、ターゲッ
トが有するそれぞれのネットワークポータルに対して、1 つずつ発見セッションが同時に確立され
ることを許容するべきである。同一のイニシエータポートから異なるネットワークポータルに対
して構築された、同時に存在する発見セッションは、それぞれ異なるセッションとして取り扱わ
れなければならない。すなわち、あるセッションが他のセッションに対する再構築を行ってはな
らない。
既存の発見セッションと<InitiatorName、ISID、NULL、TargetAddress>が一致する新規の無名
17
RFC 5048 - iSCSI Corrections and Clarifications
発見セションは、既存の無名発見セッションに対する再構築を行わなければならない。無名発見
セッションのみが、無名発見セッションの再構築を行うことが可能であることに注意すること。
5.2.2
名前付き発見セッション
名前付き発見セッションにおいては、イニシエータにより TargetName キーが指定され、それに
よりターゲットは TargetPortalGroupTag を明確に確認することが可能である。4 つのタプルの全
ての値が分かっていることから、[RFC3720]のルールを変更することなく、ターゲットにより ISID
ルールが強制されなければならない。一致する
<InitiatorName、ISID、TargetName、TargetPortalGroupTag>を持つ新規のセッションは、既存の
セッションを再構築する。この場合、4 つのタプルが一致する新規の iSCSI セッション（発見およ
び通常）は全て、既存の名前付き発見セッションに対する再構築を行うことに注意すること。
5.3
発見セッションにおけるターゲット PDU
ターゲットは、発見セッションで全機能フェーズに移行した後には、テキストレスポンスとロ
グアウトレスポンス以外のレスポンスを送信するべきではない。
実装上の注意：ターゲットは、通常セッションであれば非同期メッセージによりログアウトを
要求するべき時に、発見セッションでは単純にコネクションを切断することが可能である。
18
RFC 5048 - iSCSI Corrections and Clarifications
6
ネゴシエーションおよびその他
6.1
TGPT の値
[SAM2]と[SAM3]では、TGPT は 0 以外の値とするべきであると誤った注意書きが記されているが、
[RFC3720]では TGPT に 0 を使用することを許容している。本セクションでは、TGPT の値として 0
を使用することが明らかに合法である旨を明確化する。この矛盾は現在[SAM4]で解消されている。
6.2
SessionType のネゴシエーション
ログイン処理中、SessionType のネゴシエーションキーは、当該ターゲットに対して構築したい
セッションの種別を選択するために、イニシエータにより提案される。ターゲットはこの提案を
受け入れるか、あるいは拒絶することが可能である。セッションの種別に依存して、ターゲット
は当該セッションに割り当てるべきリソースや、セキュリティを強制するべきか否かなどを決定
する可能性がある。そのため、SessionType キーが"Discovery"として提案されるのであれば、イ
ニシエータにより、初回のログインリクエストで提案されるべきである。
6.3
NotUnderstood の使用法
[RFC3720]では、2 つの iSCSI ノード間でテキストキー交換のネゴシエーションを行っている間
に使用可能な、正当な値として NotUnderstood を規定している。NotUnderstood は、送信者が提案
された値の意味を解釈できない事を示す、予約された意味を有する。本セクションでは、宣言
キーとネゴシエーションキーの両方で使用可能な正当な値であることを明らかにする。一般的に
iSCSI の思想では、全ての iSCSI キーにおいて解釈は実行に先立つものとしている。テキストキー
交換における、宣言キーないしネゴシエーションキーの提案者は、NotUnderstood のレスポンスを
正しく取り扱う事ができなければならない。
NotUnderstood のレスポンスを正しく取り扱う方法は、キーがどこで規定されたものなのかと、
キーが宣言キーなのかネゴシエーションキーなのかに依存する。[RFC3720]で規定される全ての
キーは、規格に準拠する全ての実装でサポートされなければならない。すなわち、[RFC3720]で規
定されたキーに対する NotUnderstood のレスポンスはプロトコルエラーと見なされなければなら
ず、そのためそのように取り扱わなければならない。それ以外の最近のキーにおいては、
NotUnderstood のレスポンスは、ネゴシエーションキーに対しては当該キーのネゴシエーションを
終了させる。一方で宣言キーの場合は、NotUnderstood の応答は宣言側に対して受信者が解釈する
能力がないことを単純に通知する。
どちらの場合においても NotUnderstood の応答は、当該キーのスコープ（コネクションないし
セッション）の範囲内で当該キーが使用されなかった場合におけるプロトコル動作を行う様、両
方の側に対して要求する。
6.4
未解決のネゴシエーション交換
あるコネクションおいて、未解決のログインレスポンス PDU の個数に関しては不明瞭な領域が存
在する。[RFC3720]では、セクション 5.3 と 10.10.3 で、ログインとテキストネゴシエーションに
対してそれぞれ、SCSI のリンクされたコマンドとの類推を提案しているが、全てが明確に規定さ
れているわけではない。このセクションでは、本事項について明確な提案を行う。
ある iSCSI コネクションにおいて、未解決のログインリクエスト、ログインレスポンス、テキス
トリクエスト、テキストレスポンス PDU は、1 つ以上存在してはならない。このコンテキストにお
ける未解決の PDU とは、相手側の iSCSI により受信応答がなされていない PDU を意味する。
19
RFC 5048 - iSCSI Corrections and Clarifications
7
iSCSI エラー処理とリカバリ
7.1
ITT
ITT の値で 0xffffffff は予約済みの値であり、イニシエータによりタスクに割り当てられては
ならない。通信路上で実際に検知されうる唯一の例は、ターゲットが生成した NOP-In PDU におけ
る場合（および、必要に応じてイニシエータがレスポンスを返す場合）のみである。[RFC3720]の
セクション 10.19 でこの事項について言及しているが、ここでこの定義がイニシエータに対して
一般的に適用されるものであることを再度明確化する。
7.2
フォーマットエラー
[RFC3720]のセクション 6.6 で、フォーマットエラーの取り扱いについて規定している。本セク
ションでは、[RFC3720]の注記される"矛盾した"PDU フィールドの規定に関して詳細化を行う。
イニシエータが検知した全ての PDU 構成エラーはフォーマットエラーと見なされなければならな
い。このようなエラーには下記の様な例が存在する。
•
正しい TTT が指定されているが、不正な LUN が設定されている NOP-In PDU。
•
NOP-In PDU に正しい ITT が指定されているが（すなわち、NOP-In レスポンス）、TTT にも
正しい値が設定されている。
•
SCSI レスポンス PDU で、ステータスが CHECK CONDITION であるが DataSegmentLength が 0 で
ある。
7.3
ダイジェストエラー
[RFC3720]のセクション 6.7 では、ダイジェストエラーの取り扱いについて記述している。そこ
では、ペイロードダイジェストエラーの発生時に"破棄された PDU が非要請 PDU（例えば、非同期
メッセージ、リジェクト）であれば、イニシエータ側では追加の動作は不要である"と記載してい
る。しかしこれは誤りである。
非同期メッセージ PDU ないしリジェクト PDU は、iSCSI コネクションにおける次の StatSN を配送
し、StatSN の加算を行う。イニシエータがペイロードダイジェストエラーによりこれらの PDU の
1 つを破棄した場合、ヘッダを含む PDU 全体が破棄されなければならない。その結果イニシエータ
は、この例外を他の要請レスポンス PDU の喪失と同様に取り扱わなければならない。すなわち、
[RFC3720]に記載された下記の内の 1 つを使用しなければならない。
a) ステータス SNACK により PDU の再送を要求する。
b) リカバリのためにコネクションをログアウトし、タスクを他のコネクションのインスタン
スで継続する。
c) コネクションをクローズするためのログアウトする（当該コネクションに割り当てられて
いた全てのコマンドを破棄する）
7.4
メッセージエラー検証
入力メッセージを処理する上で、最小限必要になる範囲を超えて、どの程度の範囲でプロトコ
ルエラーの検証を行うべきかについては、不明確な部分が存在する。本セクションではこの問題
を取り扱う。
[RFC3720]ないし本書が要求しない限り、入力メッセージがプロトコルに準拠しているか否かに
ついて、iSCSI 実装が網羅的に検証することは必要とされない。特に、リモートの iSCSI 実装がプ
ロトコル要求に準拠しているか否か二重に検証する必要はない。
20
RFC 5048 - iSCSI Corrections and Clarifications
8
iSCSI PDU
8.1
非同期メッセージ
本セクションでは、[RFC3720]のセクション 10.9 で規定されている非同期メッセージ PDU につい
て、同じ表記を用いて追加の定義を規定する。
非同期メッセージおける正当な値として、下記の値を定義する。
コード
説明
5
非同期メッセージ PDU の LUN フィールドで指定された LU における、全ての有効
なタスクが終了された。
受信したイニシエータ側 iSCSI レイヤは、このメッセージに対して下記のステップを実行するこ
とにより応答しなければならない。
1. 非同期メッセージ PDU で指定された LUN における、現在有効な全ての TTT に対する、コネク
ション上でのデータ出力転送を停止する。
2. ITT=0xffffffff（すなわち、ping ではない事を示す）を設定した NOP-Out PDU により、非
同期メッセージの StatSN に対する受信応答を返す。このとき、NOP-Out の LUN フィールド
には非同期メッセージの LUN フィールドの値をコピーする。
本章で定義される新規の AsyncEvent は、セクション 9.1 で定義される TaskReporting テキスト
キーの値が FastAbort としてネゴシエーションされたセッション以外の iSCSI セッションでは使
用されてはならない。
8.2
リジェクト
[RFC3720]のセクション 10.17.1 では、リジェクトの理由コードで"ネゴシエーションリセット
（Negotiation Reset）"を表す値として 0x0b を規定している。しかしながら、この理由コードを
使用する、iSCSI プロトコルとして合法的な使用方法は存在しない。そのため、理由コード 0x0b
は非推奨であると見なされなければならず、本書の要求に準拠する実装はこの値を使用してはな
らない。理由コード 0x0b を受信した実装はネゴシエーション失敗として取り扱わなければならな
ず、[RFC3720]のセクション 6.10 の規定に従い、ログインフェーズを終了し TCP コネクションを
切断しなければならない。
[RFC3720]のセクション 5.4 では下記のように規定している。
イニシエータとターゲットはどちらも、キーの宣言を繰り返し行うことが明示的に許可さ
れた特定のキー（例えば、TargetAddress）に対して応答を返す場合を除いて、操作パラ
メタネゴシエーションのリセットによる介入が無い限り、ネゴシエーションシーケンスで
パラメタの宣言やネゴシエーションを複数回行うべきではない。
理由コード 0x0b が非推奨となることにより、操作パラメタネゴシエーションのリセットが生じ
る可能性が排除される。それにより、[RFC3720]の"操作パラメタネゴシエーションのリセットに
よる介入が無い限り"という記載が不可能なイベントを参照することとなる。理由コード 0x0b を
本章での規定に従い取り扱う実装は、引用された記述は無視するべきである。
21
RFC 5048 - iSCSI Corrections and Clarifications
9
ログイン/テキスト操作テキストキー
本章では、[RFC3720]の 12 章における表記に従う。
9.1
TaskReporting
使用時
LO
送信者
イニシエータ、ターゲット
スコープ
SW
無効時
SessionType=Discovery
用例
TaskReporting=<list-of-values>
デフォルト値
RFC3720
結果関数
AND
このキーは、SCSI ターゲットからのタスク完了報告の定義をネゴシエーションするために使用
される。下記の表は、iSCSI ターゲットがサポートしなければならない、ネゴシエーションされた
キーの値について、それぞれの定義を示す。このキーがネゴシエーションされる場合、ネゴシ
エーションのオリジネータは、少なくとも RFC3720 と ResponseFence は提案しなければならない。
名前
説明
RFC3720
RFC3720 準拠。レスポンスフェンスの動作は保証されない。複
数タスクに対する高速な中断はサポートされない。
ResponseFence
タスク完了の報告において、レスポンスフェンス（セクション
3.3.1 ）の定義がサポートされなければならない。
FastAbort
セクション 4.1.3 で定義される、複数タスクの高速な中断の定
義がサポートされなければならない。レスポンスフェンスは暗
黙的にサポートされる。すなわち、セクション 3.3.1 の定義が
サポートされなければならない。
TaskReporting が FastAbort としてネゴシエーションされていない場合、セクション 4.1.2 で
明確化されるタスク管理機能の定義が使用されなければならない。
22
RFC 5048 - iSCSI Corrections and Clarifications
10
セキュリティ上の考慮点
本書では、[RFC3720]ですでに示された事項を除き、新しいセキュリティ上の考慮点を生じさせ
ることはない。その結果、[RFC3720]における iSCSI に関するセキュリティの記述は、本書におい
てもそのまま適用される。
23
RFC 5048 - iSCSI Corrections and Clarifications
11
IANA の考慮点
11.1
iSCSI に関する IANA レジストリ
本書では、下記の iSCSI に関する IANA レジストリを定義する。
1. iSCSI Opcode
2. iSCSI ログイン／テキストキー
3. iSCSI 非同期イベント
4. iSCSI タスク管理機能コード
5. iSCSI ログインレスポンスステータスコード
6. iSCSI リジェクト理由コード
7. iSER Opcode
後続のセクションでは、レジストリ、サブレジストリ、およびそれらの管理ポリシーについて
より詳細に記述する。IANA では、本書で主"レジストリ"と呼ぶ項目を、より大きな iSCSI レジス
トリのサブレジストリとして登録している。しかしながら、本書で規定されるレジストリとサブ
レジストリの関係は、そのままの形式で常に維持される。
[RFC3720]では、iSCSI 関連のレジストリとして、拡張キー、認証方法、ダイジェストの 3 種類
を規定している。本書は、これらのレジストリが、本書で規定されるレジストリと共に併せて公
開されることを要求する。さらに本書は、[RFC3720]の 3 つのレジストリが、上記レジストリリス
トの項番 6 と 7 の間に配置されることを要求する。
11.2
iSCSI Opcode
レジストリ名："iSCSI Opcodes"
名前空間の詳細：1 オクテット内に入る数値であり、最上位 2 ビット（ビット 0 とビット 1）は
すでに[RFC3720]により指定されている。ビット 0 は予約済みであり、ビット 1 は即時配信を表す。
ビット 2 は opcode のオリジネータを指定する。ビット 2 が 0 である場合はイニシエータであり、
ビット 2 が 1 である場合はターゲットであることを示す。
新規の値を割り当てるために必要となる情報：提案される新規の値についての定義と相互接続
性の要求を規定する、標準化過程の仕様に対する IESG の承認と、レジストリへ登録するための
フィールドが必要である。
要求者に対する割り当て要求の手引き：
1. ある新規プロトコル操作のリクエストとレスポンスを識別する、イニシエータ opcode と
ターゲット opcode が要求される場合、両方の opcode で下位 5 ビット（すなわち、ビット 3
からビット 7）に同一の値を割り当てる。例えば、0x13 と 0x33。
2. 一方向のプロトコルメッセージ（すなわち、レスポンスがないリクエストや、リクエスト
がない"レスポンス"）を識別する、イニシエータ opcode とターゲット opcode のどちらか一
方のみが要求される場合、適切なカテゴリ（すなわち、イニシエータカテゴリかターゲッ
トカテゴリかで、それぞれビット 2 に 0 か 1 を設定する）内の未使用の番号を割り当て、か
つ、他方の対になる番号（すなわち、ビット 2 にそれぞれ 1 ないし 0 を設定した、同一の
opcode）を、"未使用の opcode ペア"リストに追加する。
3. "未使用の opcode ペア"リストで予約済みとされている opcode を除き、要求された新規の
opcode を割り当てるために利用可能な opcode が、"IANA により予約済み"リストに存在しな
い場合、"未使用の opcode ペア"リスト内の該当するカテゴリ（イニシエータないしター
24
RFC 5048 - iSCSI Corrections and Clarifications
ゲット）から割り当てる。
レジストリに登録するためのフィールド：割り当てられた値, （イニシエータとターゲット
の）どちら側から送信可能か, 操作名ロ, 参照先の RFC
初期レジストリの内容：
0x00, Initiator, NOP-Out（NOP-Out）, [RFC3720]
0x01, Initiator, SCSI Command（SCSI コマンド）, [RFC3720]
0x02, Initiator, SCSI Task Management function request（SCSI タスク管理リクエスト）,
[RFC3720]
0x03, Initiator, Login Request（ログインリクエスト）, [RFC3720]
0x04, Initiator, Text Request（テキストリクエスト）, [RFC3720]
0x05, Initiator, SCSI Data-Out（SCSI Data-Out）, [RFC3720]
0x06, Initiator, Logout Request（ログアウトリクエスト）, [RFC3720]
0x10, Initiator, SNACK Request（SNACK リクエスト）, [RFC3720]
0x1c-0x1e, Initiator, Vendor specific codes（ベンダ固有コード）, [RFC3720]
0x20, Target, NOP-In（NOP-In）, [RFC3720]
0x21, Target, SCSI Response（SCSI レスポンス）, [RFC3720]
0x22, Target, SCSI Task Management function response（SCSI タスク管理機能レスポンス）,
[RFC3720]
0x23, Target, Login Response（ログインレスポンス）, [RFC3720]
0x24, Target, Text Response（テキストレスポンス）, [RFC3720]
0x25, Target, SCSI Data-In（SCSI Data-In）, [RFC3720]
0x26, Target, Logout Response（ログアウトレスポンス）, [RFC3720]
0x31, Target, Ready To Transfer (R2T)（転送準備完了）, [RFC3720]
0x32, Target, Asynchronous Message（非同期メッセージ）, [RFC3720]
0x3c-0x3e, Target, Vendor specific codes（ベンダ固有コード）, [RFC3720]
0x3f, Target, Reject（リジェクト）, [RFC3720]
IANA により予約済み：
0x07-0x0f, 0x13-0x1b (イニシエータコード)
0x27-0x2f, 0x33-0x3b (ターゲットコード)
未使用の opcode ペア：
0x11, 0x12, 0x1f(イニシエータコード)
0x30(ターゲットコード)
アロケーションポリシハ：
ロ括弧内に RFC3720 の日本語版で示した訳名を示す。これは IANA レジストリの内容ではない。
ハ Allocation Policy と Assignment policy の両方が同時に使用されており区別が付かないのでカタカナで示す。
25
RFC 5048 - iSCSI Corrections and Clarifications
標準動作（[IANA]）：opcode の定義を規定する際に要求される。
専門家のレビュー（[IANA]）：先に示した"要求者に対する割り当て要求の手引き"への準拠を
保証するために、割り当てるべき opcode を選択する際に要求される。
11.3
iSCSI ログイン／テキストキー
レジストリ名："iSCSI Text Keys"
名前空間の詳細：UTF-8 でエンコードされた"キー"名と、キーに依存する"値"のオプションから
なる、Key=value の組み合わせである。[RFC3720]では、キー名と許容される値のルールを規定し
ている。
新規の値を割り当てるために必要となる情報：[RFC3720]におけるキー仕様テンプレートによる、
提案される新規のキーについての定義と相互接続性の要求を規定する、標準化過程の仕様に対す
る IESG の承認と、レジストリへ登録するためのフィールドが必要である。
アサイメントポリシ：要求されたキー名がすでに割り当てられたものではなく、かつ、キー名
が提案された定義をおおよそ表現しているものであれば、要求に従い当該のキーを割り当てるこ
とが可能である。
任意のテキストであることから、本レジストリの登録について IANA による最大値の予約は存在
しない。
レジストリに登録するためのフィールド：割り当てられたキー名と参照先の RFC。
初期レジストリの内容：
AuthMethod, [RFC3720]
HeaderDigest, [RFC3720]
DataDigest, [RFC3720]
MaxConnections, [RFC3720]
SendTargets, [RFC3720]
TargetName, [RFC3720]
InitiatorName, [RFC3720]
TargetAlias, [RFC3720]
InitiatorAlias, [RFC3720]
TargetAddress, [RFC3720]
TargetPortalGroupTag, [RFC3720]
InitialR2T, [RFC3720]
ImmediateData, [RFC3720]
MaxRecvDataSegmentLength, [RFC3720]
MaxBurstLength, [RFC3720]
FirstBurstLength, [RFC3720]
DefaultTime2Wait, [RFC3720]
DefaultTime2Retain, [RFC3720]
26
RFC 5048 - iSCSI Corrections and Clarifications
MaxOutstandingR2T, [RFC3720]
DataPDUInOrder, [RFC3720]
DataSequenceInOrder, [RFC3720]
ErrorRecoveryLevel, [RFC3720]
SessionType, [RFC3720]
RDMAExtensions, [iSER]
TargetRecvDataSegmentLength, [iSER]
InitiatorRecvDataSegmentLength, [iSER]
MaxOutstandingUnexpectedPDUs, [iSER]
TaskReporting, this document
アロケーションポリシ：
通常動作（[IANA]）
11.4
iSCSI 非同期イベント
レジストリ名："iSCSI Asynchronous Events"
名前空間の詳細：1 オクテット内に収まる数値。
新規の値を割り当てるために必要となる情報：提案される新規のイベントについての定義と相
互接続性の要求を規定する、標準化過程の仕様に対する IESG の承認と、レジストリへ登録するた
めのフィールドが必要である。
アサイメントポリシ：
要求された値がまだ割り当てられていない場合には、要求に従い当該の値を割り当てることが
可能である。
6～247：本レジストリにおける割り当てのために、IANA による予約済みの範囲である。
レジストリに登録するためのフィールド：割り当てられたイベント番号, 説明, 参照先の RFC。
初期レジストリの内容：
0, SCSI Async Event（SCSI 非同期イベント）, [RFC3720]
1, Logout Request（ログアウトリクエスト）, [RFC3720]
2, Connection drop notification（コネクション切断通知）, [RFC3720]
3, Session drop notification（セッション切断通知）, [RFC3720]
4, Negotiation Request（ネゴシエーションリセット）, [RFC3720]
5, Task termination（タスク終了）, this document
248-254, Vendor-unique（ベンダ固有）, this document
255, Vendor-unique（ベンダ固有）, [RFC3720]
アロケーションポリシ：
標準動作（[IANA]）
27
RFC 5048 - iSCSI Corrections and Clarifications
11.5
iSCSI タスク管理機能コード
レジストリ名："iSCSI TMF Codes"
名前空間の詳細：7 ビット内に収まる数値。
新規の値を割り当てるために必要となる情報：提案される新規の値についての定義と相互接続
性の要求を規定する、標準化過程の仕様に対する IESG の承認と、レジストリへ登録するための
フィールドが必要である。
アサイメントポリシ：
要求された値がまだ割り当てられていない場合には、要求に従い当該の値を割り当てることが
可能である。
9～127：本レジストリにおける割り当てのために、IANA による予約済みの範囲である。
レジストリに登録するためのフィールド：割り当てられた値, 説明, 参照先の RFC。
初期レジストリの内容：
1, ABORT TASK, [RFC3720]
2, ABORT TASK SET, [RFC3720]
3, CLEAR ACA, [RFC3720]
4, CLEAR TASK SET, [RFC3720]
5, LOGICAL UNIT RESET, [RFC3720]
6, TARGET WARM RESET, [RFC3720]
7, TARGET COLD RESET, [RFC3720]
8, TASK REASSIGN, [RFC3720]
アロケーションポリシ：
標準動作（[IANA]）
11.6
iSCSI ログインレスポンスステータスコード
レジストリ名："iSCSI Login Response Status Codes"
名前空間の詳細：ステータスクラス（1 オクテット）と、ベンダ固有ステータスクラス（0x0f）
を除く各ステータスクラス毎のステータス詳細（1 オクテット）。
新規の値を割り当てるために必要となる情報：提案される新規の値、すなわち、所属するス
テータスクラス（あるステータスクラスに対してステータス詳細の値が新規に提案される場合の
み）とステータス詳細の定義（新規のステータスクラスが提案される場合のみ）についての定義
と相互接続性の要求を規定する、標準化過程の仕様に対する IESG の承認と、レジストリへ登録す
るためのフィールドが必要である。
アサイメントポリシ：
要求された値がまだ割り当てられていない場合には、要求に従い当該の値を割り当てることが
可能である。
4～14 と 16～255：本レジストリへの割り当てにおいて IANA により予約済み。
Status-Class メインレジストリに登録するためのフィールド：割り当てられた値, 説明, 参照
28
RFC 5048 - iSCSI Corrections and Clarifications
先の RFC。
初期レジストリの内容：
0x00, Success（成功）, [RFC3720]
0x01, Redirection（リダイレクト）, [RFC3720]
0x02, Initiator Error（イニシエータエラー）, [RFC3720]
0x03, Target Error（ターゲットエラー）, [RFC3720]
0x0f, Vendor-Unique（ベンダ固有）, 本書
初期サブレジストリの内容（Status-Class=0x00 における Status-Detail）：
0x00, 0x00, Success（成功）, [RFC3720]
1-255：Status-Class=0 に対するサブレジストリの割り当てにおいて IANA により予約済み。
初期サブレジストリの内容（Status-Class=0x01 における Status-Detail）：
0x01, 0x01, Temporary move（ターゲットは一時的に移動している）, [RFC3720]
0x01, 0x02, Permanent move（ターゲットは永続的に移動している）, [RFC3720]
3-255：Status-Class=1 に対するサブレジストリの割り当てにおいて IANA により予約済み。
初期サブレジストリの内容（Status-Class=0x02 における Status-Detail）：
0x02, 0x00, Miscellaneous（イニシエータエラーニ）, [RFC3720]
0x02, 0x01, Authentication failure（認証失敗）, [RFC3720]
0x02, 0x02, Authorization failure（認可失敗）, [RFC3720]
0x02, 0x03, Not found（見つからない）, [RFC3720]
0x02, 0x04, Target removed（ターゲット削除済み）, [RFC3720]
0x02, 0x05, Unsupported version（未サポートのバージョン）, [RFC3720]
0x02, 0x06, Too many connections（接続が多すぎる）, [RFC3720]
0x02, 0x07, Missing parameter（パラメタが存在しない）, [RFC3720]
0x02, 0x08, Can't include in session（セッションに含められない）, [RFC3720]
0x02, 0x09, Unsupported session type（セッション種別が未サポート）, [RFC3720]
0x02, 0x0a, Non-existent session（セッションが存在しない）, [RFC3720]
0x02, 0x0b, Invalid during login（ログイン中には不正）, [RFC3720]
12-255：Status-Class=2 に対するサブレジストリの割り当てにおいて IANA により予約済み。
初期サブレジストリの内容（Status-Class=0x03 における Status-Detail）：
0x03, 0x00, Target error（ターゲットエラー）, [RFC3720]
0x03, 0x01, Service unavailable（サービスが使用できない）, [RFC3720]
0x03, 0x02, Out of resources（リソース不足）, [RFC3720]
ニ RFC3720 10.13.5 におけるステータス詳細の説明では、ステータスの名称が「イニシエータエラー」であり、説明文が
「Miscellaneous iSCSI initiator errors.」と記載されている。
29
RFC 5048 - iSCSI Corrections and Clarifications
3-255：Status-Class=3 に対するサブレジストリの割り当てにおいて IANA により予約済み。
アロケーションポリシ：
標準動作（[IANA]）
11.7
iSCSI リジェクト理由コード
レジストリ名："iSCSI Reject Reason Codes"
名前空間の詳細：1 オクテット内に収まる数値。
新規の値を割り当てるために必要となる情報：提案される新規のコードについての定義と相互
接続性の要求を規定する、公開された仕様と、レジストリへ登録するためのフィールドが必要で
ある。
アサイメントポリシ：
要求された値がまだ割り当てられていない場合には、要求に従い当該の値を割り当てることが
可能である。
13～255：本レジストリへの割り当てにおいて IANA により予約済み。
レジストリに登録するためのフィールド：割り当てられた値, 説明, 参照先の RFC。
初期レジストリの内容：
0x01, Reserved（予約済み）, [RFC3720]
0x02, Data digest error（データ（ペイロード）ダイジェストエラー）, [RFC3720]
0x03, SNACK Reject（SNACK リジェクト）, [RFC3720]
0x04, Protocol Error（プロトコルエラー）, [RFC3720]
0x05, Command not supported（コマンドがサポートされない）, [RFC3720]
0x06, Immediate command reject（即時コマンド拒否）, [RFC3720]
0x07, Task in progress（タスクが実行中）, [RFC3720]
0x08, Invalid data ack（不正な DataACK）, [RFC3720]
0x09, Invalid PDU field（不正な PDU フィールド）, [RFC3720]
0x0a, Long op reject（長期操作リジェクト）, [RFC3720]
0x0b, "Deprecated reason code（非推奨の理由コード）", 本書
0x0c, Waiting for Logout（ログアウトの待機中）, [RFC3720]
アロケーションポリシ：
標準動作（[IANA]）
11.8
iSER Opcodes
レジストリ名："iSER Opcodes"
名前空間の詳細：4 ビット内に収まる数値。
新規の値を割り当てるために必要となる情報：提案される新規の値についての定義と相互接続
性の要求を規定する、標準化過程の仕様に対する IESG の承認と、レジストリへ登録するための
30
RFC 5048 - iSCSI Corrections and Clarifications
フィールドが必要である。
アサイメントポリシ：
要求された値がまだ割り当てられていない場合には、要求に従い当該の値を割り当てることが
可能である。
4～15：本レジストリにおける割り当てのために、IANA による予約済みの範囲である。
レジストリに登録するためのフィールド：割り当てられた値, 操作名, 参照先の RFC。
初期レジストリの内容：
0x1, iSCSI control-type, [iSER]
0x2, iSER Hello, [iSER]
0x3, iSER HelloReply, [iSER]
アロケーションポリシ：
標準動作（[IANA]）
31
RFC 5048 - iSCSI Corrections and Clarifications
12
参考文献
12.1
引用規格
[RFC3720]
Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner,
"Internet Small Computer Systems Interface(iSCSI)", RFC 3720, April 2004.
[SPC3]
ANSI INCITS 408-2005, SCSI Primary Commands-3.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997.
[IANA]
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[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.
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.
[RFC3723]
Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino,
"Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3722]
Bakke, M., "String Profile for Internet Small Computer Systems Interface
(iSCSI) Names", RFC 3722, April 2004.
[SAM2]
ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-2).
[SAM3]
ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM-a3).
[SAM4]
T10 Project: 1683-D, SCSI Architecture Model-4 (SAM-4), Work in Progress.
32
RFC 5048 - iSCSI Corrections and Clarifications
RFC5048
Internet Small Computer System Interface (iSCSI)
Corrections and Clarifications
本書は nabiki_t が勝手に和訳したものであり、内容の正確等、一切の保証は存在しない。
http://www.syuhitu.org/
2014 年 2 月 3 日
33

Download Report