RFC3720 日本語訳
3720 Internet Small Computer Systems Interface (iSCSI). J. Satran, K.Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner. April 2004. (Format: TXT=578468 bytes) (Updated by RFC3980, RFC4850, RFC5048) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Satran
Request for Comments: 3720 K. Meth
Category: Standards Track IBM
C. Sapuntzakis
Cisco Systems
M. Chadalapaka
Hewlett-Packard Co.
E. Zeidner
IBM
April 2004
Satranがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3720年のK.メタンフェタミンカテゴリ: 標準化過程IBM C.SapuntzakisシスコシステムズM.Chadalapakaヒューレット・パッカード社のE.Zeidner IBM2004年4月
Internet Small Computer Systems Interface (iSCSI)
インターネットの小さいコンピュータ・システムインタフェース(iSCSI)
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model.
このドキュメントはTCPの上で働いているインターネットSmallコンピュータシステムズInterface(iSCSI)のためにトランスポート・プロトコルについて説明します。 iSCSIプロトコルは、標準化されたSCSI構造モデルと共に完全に言いなりになることを目指します。
SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.).
SCSIはシステムが入出力装置とコミュニケートするのを可能にするプロトコル、特に記憶装置のポピュラーな家族です。 SCSIプロトコルが一般的な標準化された構造モデルとの要求/応答アプリケーション・プロトコルであり、基本コマンドは、セットして、異なった装置クラス(ディスク、メディア切換器テープなど)のためにコマンドセットを標準化しました。
As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI.
システム内部連絡が古典的なバス構造からネットワーク構造まで動くとき、SCSIはネットワークトランスポート・プロトコルに写像されなければなりません。 IPネットワークは、現在、速いシステム内部連絡に関する性能必要条件を満たして、そういうものとして「運んでください」SCSIの良い候補です。
Satran, et al. Standards Track [Page 1] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[1ページ]。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Definitions and Acronyms. . . . . . . . . . . . . . . . . . . 10
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . 10
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Conventions. . . . . . . . . . . . . . . . . . . . . . 16
2.3.1. Word Rule. . . . . . . . . . . . . . . . . . 16
2.3.2. Half-Word Rule . . . . . . . . . . . . . . . 17
2.3.3. Byte Rule. . . . . . . . . . . . . . . . . . 17
3. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. SCSI Concepts. . . . . . . . . . . . . . . . . . . . . 17
3.2. iSCSI Concepts and Functional Overview . . . . . . . . 18
3.2.1. Layers and Sessions. . . . . . . . . . . . . 19
3.2.2. Ordering and iSCSI Numbering . . . . . . . . 19
3.2.2.1. Command Numbering and
Acknowledging . . . . . . . . . . 20
3.2.2.2. Response/Status Numbering and
Acknowledging . . . . . . . . . . 23
3.2.2.3. Data Sequencing . . . . . . . . 24
3.2.3. iSCSI Login. . . . . . . . . . . . . . . . . 24
3.2.4. iSCSI Full Feature Phase . . . . . . . . . . 25
3.2.4.1. Command Connection Allegiance . . 26
3.2.4.2. Data Transfer Overview. . . . . . 27
3.2.4.3. Tags and Integrity Checks . . . . 28
3.2.4.4. Task Management . . . . . . . . . 28
3.2.5. iSCSI Connection Termination . . . . . . . . 29
3.2.6. iSCSI Names. . . . . . . . . . . . . . . . . 29
3.2.6.1. iSCSI Name Properties . . . . . . 30
3.2.6.2. iSCSI Name Encoding . . . . . . . 31
3.2.6.3. iSCSI Name Structure. . . . . . . 32
3.2.6.3.1. Type "iqn." (iSCSI
Qualified Name) . . . 32
3.2.6.3.2. Type "eui." (IEEE
EUI-64 format). . . . 34
3.2.7. Persistent State . . . . . . . . . . . . . . 34
3.2.8. Message Synchronization and Steering . . . . 35
3.2.8.1. Sync/Steering and iSCSI PDU
Length . . . . . . . . . . . . . 36
3.3. iSCSI Session Types. . . . . . . . . . . . . . . . . . 36
3.4. SCSI to iSCSI Concepts Mapping Model . . . . . . . . . 37
3.4.1. iSCSI Architecture Model . . . . . . . . . . 37
3.4.2. SCSI Architecture Model. . . . . . . . . . . 39
3.4.3. Consequences of the Model. . . . . . . . . . 41
3.4.3.1. I_T Nexus State . . . . . . . . . 42
3.5. Request/Response Summary . . . . . . . . . . . . . . . 42
3.5.1. Request/Response Types Carrying SCSI Payload 43
3.5.1.1. SCSI-Command . . . . . . . . . . 43
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 9 2. 定義と頭文字語… 10 2.1。 定義。 . . . . . . . . . . . . . . . . . . . . . 10 2.2. 頭文字語. . . . . . . . . . . . . . . . . . . . . . . 14 2.3。 コンベンション。 . . . . . . . . . . . . . . . . . . . . . 16 2.3.1. 規則を言い表してください。 . . . . . . . . . . . . . . . . . 16 2.3.2. 規則. . . . . . . . . . . . . . . 17 2.3.3を半分言い表してください。 バイト規則。 . . . . . . . . . . . . . . . . . 17 3. 概観。 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. SCSI概念。 . . . . . . . . . . . . . . . . . . . . 17 3.2iSCSI概念と機能概要. . . . . . . . 18 3.2.1。 層とセッション。 . . . . . . . . . . . . 19 3.2.2. 注文とiSCSI付番. . . . . . . . 19 3.2.2.1。 コマンド付番と承認. . . . . . . . . . 20 3.2.2.2。 応答/状態の達して.233.2に.3に.2を承認すること。 データ配列. . . . . . . . 24 3.2.3iSCSIはログインします。 . . . . . . . . . . . . . . . . 24 3.2.4iSCSIの完全な特徴フェーズ. . . . . . . . . . 25 3.2.4.1。 接続忠誠. . 26 3.2.4.2を命令してください。 データ転送概観。 . . . . . 27 3.2.4.3. タグと保全は.283.2に.4に.4をチェックします。 タスク管理. . . . . . . . . 28 3.2.5iSCSI接続終了. . . . . . . . 29 3.2.6のiSCSI名。 . . . . . . . . . . . . . . . . 3.2.6.1iSCSIが特性と命名する29、.303.2、.6、.2. iSCSIがコード化を命名する、.313.2、.6、.3. iSCSIは構造を命名します。 . . . . . . 32 3.2.6.3.1. "iqn"をタイプしてください。 (iSCSIの適切な名) . . . 32 3.2.6.3.2. "eui"をタイプしてください。 (IEEE EUI-64形式。) . . . 34 3.2.7. しつこい州. . . . . . . . . . . . . . 34 3.2の.8。 メッセージ同期と操縦. . . . 35 3.2.8.1。 同時性/操縦とiSCSI PDUの長さ. . . . . . . . . . . . . 36 3.3のiSCSIセッションタイプ。 . . . . . . . . . . . . . . . . . 36 3.4. iSCSI概念マッピングへのSCSIは.373.4.1iSCSI構造モデル. . . . . . . . . . 37 3.4.2をモデル化します。 SCSI構造モデル。 . . . . . . . . . . 39 3.4.3. モデルの結果。 . . . . . . . . . 41 3.4.3.1. I_T結びつき州. . . . . . . . . 42 3.5。 要求/応答概要. . . . . . . . . . . . . . . 42 3.5.1。 .1にSCSI有効搭載量43 3.5.1を運ぶ要求/応答タイプ SCSI-コマンド.43
Satran, et al. Standards Track [Page 2] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[2ページ]。
3.5.1.2. SCSI-Response . . . . . . . . . 43
3.5.1.3. Task Management Function Request. 44
3.5.1.4. Task Management Function Response 44
3.5.1.5. SCSI Data-Out and SCSI Data-In. . 44
3.5.1.6. Ready To Transfer (R2T) . . . . . 45
3.5.2. Requests/Responses carrying SCSI and iSCSI
Payload. . . . . . . . . . . . . . . . . . . 46
3.5.2.1. Asynchronous Message. . . . . . . 46
3.5.3. Requests/Responses Carrying iSCSI Only
Payload. . . . . . . . . . . . . . . . . . . 46
3.5.3.1. Text Request and Text Response. . 46
3.5.3.2. Login Request and Login Response. 47
3.5.3.3. Logout Request and Response . . . 47
3.5.3.4. SNACK Request . . . . . . . . . . 48
3.5.3.5. Reject. . . . . . . . . . . . . . 48
3.5.3.6. NOP-Out Request and NOP-In
Response . . . . . . . . . . . . 48
4. SCSI Mode Parameters for iSCSI. . . . . . . . . . . . . . . . 48
5. Login and Full Feature Phase Negotiation. . . . . . . . . . . 48
5.1. Text Format. . . . . . . . . . . . . . . . . . . . . . 50
5.2. Text Mode Negotiation. . . . . . . . . . . . . . . . . 53
5.2.1. List negotiations. . . . . . . . . . . . . . 56
5.2.2. Simple-value Negotiations. . . . . . . . . . 56
5.3. Login Phase. . . . . . . . . . . . . . . . . . . . . . 57
5.3.1. Login Phase Start. . . . . . . . . . . . . . 60
5.3.2. iSCSI Security Negotiation . . . . . . . . . 62
5.3.3. Operational Parameter Negotiation During
the Login Phase. . . . . . . . . . . . . . . 63
5.3.4. Connection Reinstatement . . . . . . . . . . 64
5.3.5. Session Reinstatement, Closure, and Timeout. 64
5 5.3.5.1. Loss of Nexus
Notification. . . . . 65
5.3.6. Session Continuation and Failure . . . . . . 65
5.4. Operational Parameter Negotiation Outside the Login
Phase. . . . . . . . . . . . . . . . . . . . . . . . . 66
6. iSCSI Error Handling and Recovery . . . . . . . . . . . . . . 67
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 67
6.1.1. Background . . . . . . . . . . . . . . . . . 67
6.1.2. Goals. . . . . . . . . . . . . . . . . . . . 67
6.1.3. Protocol Features and State Expectations . . 68
6.1.4. Recovery Classes . . . . . . . . . . . . . . 69
6.1.4.1. Recovery Within-command . . . . . 69
6.1.4.2. Recovery Within-connection. . . . 70
6.1.4.3. Connection Recovery . . . . . . . 71
6.1.4.4. Session Recovery. . . . . . . . . 72
6.1.5. Error Recovery Hierarchy . . . . . . . . . . . 72
6.2. Retry and Reassign in Recovery . . . . . . . . . . . . 74
6.2.1. Usage of Retry . . . . . . . . . . . . . . . 74
3.5.1.2. SCSI-応答.433.5、.1 .3。 タスク管理機能要求。 44 3.5.1.4. タスク管理機能応答44 3.5.1.5。 外のSCSIデータと中のSCSIデータ。 . 44 3.5.1.6. (R2T). . . . . 45 3.5.2を移す準備ができています。 SCSIとiSCSI有効搭載量を運ぶ要求/応答。 . . . . . . . . . . . . . . . . . . 46 3.5.2.1. 非同期なメッセージ。 . . . . . . 46 3.5.3. iSCSIだけを運ぶ要求/応答、有効搭載量。 . . . . . . . . . . . . . . . . . . 46 3.5.3.1. テキスト要求とテキスト応答。 . 46 3.5.3.2. ログイン要求とログイン応答。 47 3.5.3.3. ログアウト、要求と応答. . . 47 3.5.3、.4 軽食要求. . . . . . . . . . 48 3.5.3.5。 拒絶します。 . . . . . . . . . . . . . 48 3.5.3.6. 外のNOP要求と中のNOP応答. . . . . . . . . . . . 48 4。 iSCSIのためのSCSIモードパラメタ。 . . . . . . . . . . . . . . . 48 5. ログインと完全な特徴は交渉の位相を合わせます。 . . . . . . . . . . 48 5.1. テキスト形式。 . . . . . . . . . . . . . . . . . . . . . 50 5.2. テキストモード交渉。 . . . . . . . . . . . . . . . . 53 5.2.1. 交渉を記載してください。 . . . . . . . . . . . . . 56 5.2.2. 簡単な値の交渉。 . . . . . . . . . 56 5.3. ログインフェーズ。 . . . . . . . . . . . . . . . . . . . . . 57 5.3.1. ログインフェーズ始め。 . . . . . . . . . . . . . 60 5.3.2iSCSIセキュリティ交渉. . . . . . . . . 62 5.3.3。 ログイン段階の間の操作上のパラメタ交渉。 . . . . . . . . . . . . . . 63 5.3.4. 接続復職. . . . . . . . . . 64 5.3.5。 セッション復職、閉鎖、およびタイムアウト。 64 5 5.3.5.1. 結びつき通知の損失。 . . . . 65 5.3.6. セッション継続と失敗. . . . . . 65 5.4。 ログインフェーズの外における操作上のパラメタ交渉。 . . . . . . . . . . . . . . . . . . . . . . . . 66 6iSCSIエラー処理と回復. . . . . . . . . . . . . . 67 6.1。 概観. . . . . . . . . . . . . . . . . . . . . . . 67 6.1.1。 バックグラウンド. . . . . . . . . . . . . . . . . 67 6.1.2。 目標。 . . . . . . . . . . . . . . . . . . . 67 6.1.3. 特徴と州の期待. . 68 6.1.4について議定書の中で述べてください。 回復クラス. . . . . . . . . . . . . . 69 6.1.4.1。 回復は中で命令します。.696.1 .4 .2。 回復、接続しています。 . . . 70 6.1.4.3. 接続回復. . . . . . . 71 6.1.4.4。 セッション回復。 . . . . . . . . 72 6.1.5. エラー回復階層構造. . . . . . . . . . . 72 6.2。 回復. . . . . . . . . . . . 74 6.2.1で再試行して、再選任します。 再試行. . . . . . . . . . . . . . . 74の用法
Satran, et al. Standards Track [Page 3] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[3ページ]。
6.2.2. Allegiance Reassignment. . . . . . . . . . . 75
6.3. Usage Of Reject PDU in Recovery. . . . . . . . . . . . 76
6.4. Connection Timeout Management. . . . . . . . . . . . . 76
6.4.1. Timeouts on Transport Exception Events . . . 77
6.4.2. Timeouts on Planned Decommissioning. . . . . 77
6.5. Implicit Termination of Tasks. . . . . . . . . . . . . 77
6.6. Format Errors. . . . . . . . . . . . . . . . . . . . . 78
6.7. Digest Errors. . . . . . . . . . . . . . . . . . . . . 78
6.8. Sequence Errors. . . . . . . . . . . . . . . . . . . . 80
6.9. SCSI Timeouts. . . . . . . . . . . . . . . . . . . . . 81
6.10. Negotiation Failures . . . . . . . . . . . . . . . . . 81
6.11. Protocol Errors. . . . . . . . . . . . . . . . . . . . 82
6.12. Connection Failures. . . . . . . . . . . . . . . . . . 82
6.13. Session Errors . . . . . . . . . . . . . . . . . . . . 83
7. State Transitions . . . . . . . . . . . . . . . . . . . . . . 84
7.1. Standard Connection State Diagrams . . . . . . . . . . 84
7.1.1. State Descriptions for Initiators and
Targets. . . . . . . . . . . . . . . . . . . 84
7.1.2. State Transition Descriptions for Initiators
and Targets. . . . . . . . . . . . . . . . . 85
7.1.3. Standard Connection State Diagram for an
Initiator. . . . . . . . . . . . . . . . . . 88
7.1.4. Standard Connection State Diagram for a
Target . . . . . . . . . . . . . . . . . . . 90
7.2. Connection Cleanup State Diagram for Initiators and
Targets. . . . . . . . . . . . . . . . . . . . . . . . 92
7.2.1. State Descriptions for Initiators and
Targets. . . . . . . . . . . . . . . . . . . 94
7.2.2. State Transition Descriptions for Initiators
and Targets. . . . . . . . . . . . . . . . . 94
7.3. Session State Diagrams . . . . . . . . . . . . . . . . 95
7.3.1. Session State Diagram for an Initiator . . . 95
7.3.2. Session State Diagram for a Target . . . . . 96
7.3.3. State Descriptions for Initiators and
Targets. . . . . . . . . . . . . . . . . . . 97
7.3.4. State Transition Descriptions for Initiators
and Targets. . . . . . . . . . . . . . . . . 98
8. Security Considerations . . . . . . . . . . . . . . . . . . . 99
8.1. iSCSI Security Mechanisms. . . . . . . . . . . . . . . 100
8.2. In-band Initiator-Target Authentication. . . . . . . . 100
8.2.1. CHAP Considerations. . . . . . . . . . . . . 101
8.2.2. SRP Considerations . . . . . . . . . . . . . 103
8.3. IPsec. . . . . . . . . . . . . . . . . . . . . . . . . 104
8.3.1. Data Integrity and Authentication. . . . . . 104
8.3.2. Confidentiality. . . . . . . . . . . . . . . 105
8.3.3. Policy, Security Associations, and
Cryptographic Key Management . . . . . . . . 105
9. Notes to Implementers . . . . . . . . . . . . . . . . . . . . 106
6.2.2. 忠誠再割当て。 . . . . . . . . . . 75 6.3. 回復における廃棄物PDUの使用法。 . . . . . . . . . . . 76 6.4. 接続タイムアウト管理。 . . . . . . . . . . . . 76 6.4.1. 輸送例外イベント. . . 77 6.4.2におけるタイムアウト。 計画された廃炉におけるタイムアウト。 . . . . 77 6.5. タスクの暗黙の終了。 . . . . . . . . . . . . 77 6.6. 誤りをフォーマットしてください。 . . . . . . . . . . . . . . . . . . . . 78 6.7. 誤りを読みこなしてください。 . . . . . . . . . . . . . . . . . . . . 78 6.8. 系列誤り。 . . . . . . . . . . . . . . . . . . . 80 6.9. SCSIタイムアウト。 . . . . . . . . . . . . . . . . . . . . 81 6.10. 交渉失敗. . . . . . . . . . . . . . . . . 81 6.11。 誤りについて議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . 82 6.12. 接続失敗。 . . . . . . . . . . . . . . . . . 82 6.13. セッション誤り. . . . . . . . . . . . . . . . . . . . 83 7。 変遷. . . . . . . . . . . . . . . . . . . . . . 84 7.1を述べてください。 標準の接続州は.1に.847.1を図解します。 創始者と目標のための記述を述べてください。 . . . . . . . . . . . . . . . . . . 84 7.1.2. 創始者と目標のための変遷記述を述べてください。 . . . . . . . . . . . . . . . . 85 7.1.3. 創始者のための標準の接続州のダイヤグラム。 . . . . . . . . . . . . . . . . . 88 7.1.4. 目標. . . . . . . . . . . . . . . . . . . 90 7.2のための標準の接続州のダイヤグラム。 創始者と目標のための接続クリーンアップ州のダイヤグラム。 . . . . . . . . . . . . . . . . . . . . . . . 92 7.2.1. 創始者と目標のための記述を述べてください。 . . . . . . . . . . . . . . . . . . 94 7.2.2. 創始者と目標のための変遷記述を述べてください。 . . . . . . . . . . . . . . . . 94 7.3. セッション州は.1に.957.3を図解します。 創始者. . . 95 7.3.2のためのセッション州のダイヤグラム。 目標. . . . . 96 7.3.3のためのセッション州のダイヤグラム。 創始者と目標のための記述を述べてください。 . . . . . . . . . . . . . . . . . . 97 7.3.4. 創始者と目標のための変遷記述を述べてください。 . . . . . . . . . . . . . . . . 98 8. セキュリティ問題. . . . . . . . . . . . . . . . . . . 99 8.1iSCSIセキュリティー対策100 8.2……………。 バンドにおける創始者目標認証。 . . . . . . . 100 8.2.1. 問題のひびが切れてください。 . . . . . . . . . . . . 101 8.2.2. SRP問題. . . . . . . . . . . . . 103 8.3。 IPsec。 . . . . . . . . . . . . . . . . . . . . . . . . 104 8.3.1. データの保全と認証。 . . . . . 104 8.3.2. 秘密性。 . . . . . . . . . . . . . . 105 8.3.3. 方針、セキュリティ協会、および暗号化キー管理. . . . . . . . 105 9。 Implementers. . . . . . . . . . . . . . . . . . . . 106への注意
Satran, et al. Standards Track [Page 4] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[4ページ]。
9.1. Multiple Network Adapters. . . . . . . . . . . . . . . 106
9.1.1. Conservative Reuse of ISIDs. . . . . . . . . 107
9.1.2. iSCSI Name, ISID, and TPGT Use . . . . . . . 107
9.2. Autosense and Auto Contingent Allegiance (ACA) . . . . 109
9.3. iSCSI Timeouts . . . . . . . . . . . . . . . . . . . . 109
9.4. Command Retry and Cleaning Old Command Instances . . . 110
9.5. Synch and Steering Layer and Performance . . . . . . . 110
9.6. Considerations for State-dependent Devices and
Long-lasting SCSI Operations . . . . . . . . . . . . . 111
9.6.1. Determining the Proper ErrorRecoveryLevel. . 112
10. iSCSI PDU Formats . . . . . . . . . . . . . . . . . . . . . . 112
10.1. iSCSI PDU Length and Padding . . . . . . . . . . . . . 113
10.2. PDU Template, Header, and Opcodes. . . . . . . . . . . 113
10.2.1. Basic Header Segment (BHS) . . . . . . . . . 114
10.2.1.1. I . . . . . . . . . . . . . . . . 115
10.2.1.2. Opcode. . . . . . . . . . . . . . 115
10.2.1.3. Final (F) bit . . . . . . . . . . 116
10.2.1.4. Opcode-specific Fields. . . . . . 116
10.2.1.5. TotalAHSLength. . . . . . . . . . 116
10.2.1.6. DataSegmentLength . . . . . . . . 116
10.2.1.7. LUN . . . . . . . . . . . . . . . 116
10.2.1.8. Initiator Task Tag. . . . . . . . 117
10.2.2. Additional Header Segment (AHS) . . . . . . . 117
10.2.2.1. AHSType . . . . . . . . . . . . . 117
10.2.2.2. AHSLength . . . . . . . . . . . . 117
10.2.2.3. Extended CDB AHS. . . . . . . . . 118
10.2.2.4. Bidirectional Expected Read-Data
Length AHS. . . . . . . . . . . . 118
10.2.3. Header Digest and Data Digest. . . . . . . . 118
10.2.4. Data Segment . . . . . . . . . . . . . . . . 119
10.3. SCSI Command . . . . . . . . . . . . . . . . . . . . . 119
10.3.1. Flags and Task Attributes (byte 1) . . . . . 120
10.3.2. CmdSN - Command Sequence Number. . . . . . . 120
10.3.3. ExpStatSN. . . . . . . . . . . . . . . . . . 120
10.3.4. Expected Data Transfer Length. . . . . . . . 121
10.3.5. CDB - SCSI Command Descriptor Block. . . . . 121
10.3.6. Data Segment - Command Data. . . . . . . . . 121
10.4. SCSI Response. . . . . . . . . . . . . . . . . . . . . 122
10.4.1. Flags (byte 1) . . . . . . . . . . . . . . . 123
10.4.2. Status . . . . . . . . . . . . . . . . . . . 123
10.4.3. Response . . . . . . . . . . . . . . . . . . 124
10.4.4. SNACK Tag. . . . . . . . . . . . . . . . . . 125
10.4.5. Residual Count . . . . . . . . . . . . . . . 125
10.4.6. Bidirectional Read Residual Count. . . . . . 125
10.4.7. Data Segment - Sense and Response Data
Segment. . . . . . . . . . . . . . . . . . . 125
10.4.7.1. SenseLength . . . . . . . . . . . 126
10.4.7.2. Sense Data. . . . . . . . . . . . 126
9.1. 複数のネットワークアダプター。 . . . . . . . . . . . . . . 106 9.1.1. ISIDsの保守的な再利用。 . . . . . . . . 107 9.1.2. iSCSI名、ISID、およびTPGTは.107 9.2を使用します。 Autosenseと自動偶然な忠誠(ACA). . . . 109 9.3iSCSIタイムアウト. . . . . . . . . . . . . . . . . . . . 109 9.4。 再試行と掃除の古いコマンド例. . . 110 9.5を命令してください。 同時性、操縦層、およびパフォーマンス. . . . . . . 110 9.6。 州の依存する装置と持続的なSCSI操作. . . . . . . . . . . . . 111 9.6.1のための問題。 適切なErrorRecoveryLevelを決定します。 . 112 10iSCSI PDUは.11210.1iSCSI PDUの長さと詰め物. . . . . . . . . . . . . 113 10.2をフォーマットします。 PDUテンプレート、ヘッダー、およびOpcodes。 . . . . . . . . . . 113 10.2.1. 基本的なヘッダーセグメント(BHS). . . . . . . . . 114 10.2.1.1。 私、.11510.2 .1 .2。 Opcode。 . . . . . . . . . . . . . 115 10.2.1.3. 最終的な(F)ビット. . . . . . . . . . 116 10.2.1.4。 Opcode特有の分野。 . . . . . 116 10.2.1.5. TotalAHSLength。 . . . . . . . . . 116 10.2.1.6. DataSegmentLength、.11610.2 .1 .7。 LUN、.11610.2 .1 .8。 創始者タスクタグ。 . . . . . . . 117 10.2.2. 追加ヘッダーセグメント(AHS). . . . . . . 117 10.2.2.1。 AHSType、.11710.2 .2 .2。 AHSLength、.11710.2 .2 .3。 拡張CDB AHS。 . . . . . . . . 118 10.2.2.4. データを読んでいる双方向の予想された長さのAHS。 . . . . . . . . . . . 118 10.2.3. ヘッダーダイジェストとデータは読みこなされます。 . . . . . . . 118 10.2.4. データ・セグメント. . . . . . . . . . . . . . . . 119 10.3。 SCSIコマンド. . . . . . . . . . . . . . . . . . . . . 119 10.3.1。 旗とタスク属性(バイト1). . . . . 120 10.3.2。 CmdSN--系列番号を命令してください。 . . . . . . 120 10.3.3. ExpStatSN。 . . . . . . . . . . . . . . . . . 120 10.3.4. データ転送の長さを予想しました。 . . . . . . . 121 10.3.5. CDB--SCSIは記述子ブロックを命令します。 . . . . 121 10.3.6. データ・セグメント--データを命令してください。 . . . . . . . . 121 10.4. SCSI応答。 . . . . . . . . . . . . . . . . . . . . 122 10.4.1. (バイト1).12310.4.2に旗を揚げさせます。 状態. . . . . . . . . . . . . . . . . . . 123 10.4.3。 応答. . . . . . . . . . . . . . . . . . 124 10.4.4。 軽食タグ。 . . . . . . . . . . . . . . . . . 125 10.4.5. 残りのカウント. . . . . . . . . . . . . . . 125 10.4.6。 双方向の読書残りのカウント。 . . . . . 125 10.4.7. データ・セグメント--感覚と応答データ・セグメント。 . . . . . . . . . . . . . . . . . . 125 10.4.7.1. SenseLength、.12610.4 .7 .2。 データを理解してください。 . . . . . . . . . . . 126
Satran, et al. Standards Track [Page 5] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[5ページ]。
10.4.8. ExpDataSN. . . . . . . . . . . . . . . . . . 127
10.4.9. StatSN - Status Sequence Number. . . . . . . 127
10.4.10. ExpCmdSN - Next Expected CmdSN from this
Initiator. . . . . . . . . . . . . . . . . . 128
10.4.11. MaxCmdSN - Maximum CmdSN from this Initiator 128
10.5. Task Management Function Request . . . . . . . . . . . 129
10.5.1. Function . . . . . . . . . . . . . . . . . . 129
10.5.2. TotalAHSLength and DataSegmentLength . . . . 132
10.5.3. LUN. . . . . . . . . . . . . . . . . . . . . 132
10.5.4. Referenced Task Tag. . . . . . . . . . . . . 132
10.5.5. RefCmdSN . . . . . . . . . . . . . . . . . . 132
10.5.6. ExpDataSN. . . . . . . . . . . . . . . . . . 133
10.6. Task Management Function Response. . . . . . . . . . . 134
10.6.1. Response . . . . . . . . . . . . . . . . . . 134
10.6.2. Task Management Actions on Task Sets . . . . 136
10.6.3. TotalAHSLength and DataSegmentLength . . . . 137
10.7. SCSI Data-Out & SCSI Data-In . . . . . . . . . . . . . 137
10.7.1. F (Final) Bit. . . . . . . . . . . . . . . . 139
10.7.2. A (Acknowledge) Bit. . . . . . . . . . . . . 139
10.7.3. Flags (byte 1) . . . . . . . . . . . . . . . 140
10.7.4. Target Transfer Tag and LUN. . . . . . . . . 140
10.7.5. DataSN . . . . . . . . . . . . . . . . . . . 141
10.7.6. Buffer Offset. . . . . . . . . . . . . . . . 141
10.7.7. DataSegmentLength. . . . . . . . . . . . . . 141
10.8. Ready To Transfer (R2T). . . . . . . . . . . . . . . . 142
10.8.1. TotalAHSLength and DataSegmentLength . . . . 143
10.8.2. R2TSN. . . . . . . . . . . . . . . . . . . . 143
10.8.3. StatSN . . . . . . . . . . . . . . . . . . . 144
10.8.4. Desired Data Transfer Length and Buffer
Offset . . . . . . . . . . . . . . . . . . . 144
10.8.5. Target Transfer Tag. . . . . . . . . . . . . 144
10.9. Asynchronous Message . . . . . . . . . . . . . . . . . 145
10.9.1. AsyncEvent . . . . . . . . . . . . . . . . . 146
10.9.2. AsyncVCode . . . . . . . . . . . . . . . . . 147
10.9.3. LUN. . . . . . . . . . . . . . . . . . . . . 147
10.9.4. Sense Data and iSCSI Event Data. . . . . . . 148
10.9.4.1. SenseLength . . . . . . . . . . . 148
10.10. Text Request . . . . . . . . . . . . . . . . . . . . . 149
10.10.1. F (Final) Bit. . . . . . . . . . . . . . . . 150
10.10.2. C (Continue) Bit . . . . . . . . . . . . . . 150
10.10.3. Initiator Task Tag . . . . . . . . . . . . . 150
10.10.4. Target Transfer Tag. . . . . . . . . . . . . 150
10.10.5. Text . . . . . . . . . . . . . . . . . . . . 151
10.11. Text Response. . . . . . . . . . . . . . . . . . . . . 152
10.11.1. F (Final) Bit. . . . . . . . . . . . . . . . 152
10.11.2. C (Continue) Bit . . . . . . . . . . . . . . 153
10.11.3. Initiator Task Tag . . . . . . . . . . . . . 153
10.11.4. Target Transfer Tag. . . . . . . . . . . . . 153
10.4.8. ExpDataSN。 . . . . . . . . . . . . . . . . . 127 10.4.9. StatSN--状態一連番号。 . . . . . . 127 10.4.10. ExpCmdSN--このInitiatorからの次のExpected CmdSN。 . . . . . . . . . . . . . . . . . 128 10.4.11. MaxCmdSN--このInitiator128 10.5からの最大のCmdSN。 タスク管理機能要求. . . . . . . . . . . 129 10.5.1。 機能. . . . . . . . . . . . . . . . . . 129 10.5.2。 TotalAHSLengthとDataSegmentLength. . . . 132 10.5.3。 LUN。 . . . . . . . . . . . . . . . . . . . . 132 10.5.4. 参照をつけられたタスクタグ。 . . . . . . . . . . . . 132 10.5.5. RefCmdSN. . . . . . . . . . . . . . . . . . 132 10.5.6。 ExpDataSN。 . . . . . . . . . . . . . . . . . 133 10.6. タスク管理機能応答。 . . . . . . . . . . 134 10.6.1. 応答. . . . . . . . . . . . . . . . . . 134 10.6.2。 タスクセット. . . . 136 10.6.3へのタスク管理動作。 TotalAHSLengthとDataSegmentLength. . . . 137 10.7。 外のSCSIデータとSCSI中のデータ. . . . . . . . . . . . . 137 10.7.1。 F(最終的な)に噛み付きました。 . . . . . . . . . . . . . . . 139 10.7.2. (承認します)ビット。 . . . . . . . . . . . . 139 10.7.3. (バイト1).14010.7.4に旗を揚げさせます。 転送タグとLUNを狙ってください。 . . . . . . . . 140 10.7.5. DataSN. . . . . . . . . . . . . . . . . . . 141 10.7.6。 バッファオフセット。 . . . . . . . . . . . . . . . 141 10.7.7. DataSegmentLength。 . . . . . . . . . . . . . 141 10.8. (R2T)を移す準備ができています。 . . . . . . . . . . . . . . . 142 10.8.1. TotalAHSLengthとDataSegmentLength. . . . 143 10.8.2。 R2TSN。 . . . . . . . . . . . . . . . . . . . 143 10.8.3. StatSN. . . . . . . . . . . . . . . . . . . 144 10.8.4。 必要なデータ転送の長さとバッファオフセット. . . . . . . . . . . . . . . . . . . 144 10.8.5。 転送タグを狙ってください。 . . . . . . . . . . . . 144 10.9. 非同期なメッセージ. . . . . . . . . . . . . . . . . 145 10.9.1。 AsyncEvent. . . . . . . . . . . . . . . . . 146 10.9.2。 AsyncVCode. . . . . . . . . . . . . . . . . 147 10.9.3。 LUN。 . . . . . . . . . . . . . . . . . . . . 147 10.9.4. データとiSCSIイベントデータを理解してください。 . . . . . . 148 10.9.4.1. SenseLength. . . . . . . . . . . 148 10.10。 テキスト要求. . . . . . . . . . . . . . . . . . . . . 149 10.10.1。 F(最終的な)に噛み付きました。 . . . . . . . . . . . . . . . 150 10.10.2. C(続けている)ビット. . . . . . . . . . . . . . 150 10.10.3。 創始者タスクタグ. . . . . . . . . . . . . 150 10.10.4。 転送タグを狙ってください。 . . . . . . . . . . . . 150 10.10.5. テキスト. . . . . . . . . . . . . . . . . . . . 151 10.11。 テキスト応答。 . . . . . . . . . . . . . . . . . . . . 152 10.11.1. F(最終的な)に噛み付きました。 . . . . . . . . . . . . . . . 152 10.11.2. C(続けている)ビット. . . . . . . . . . . . . . 153 10.11.3。 創始者タスクタグ. . . . . . . . . . . . . 153 10.11.4。 転送タグを狙ってください。 . . . . . . . . . . . . 153
Satran, et al. Standards Track [Page 6] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[6ページ]。
10.11.5. StatSN . . . . . . . . . . . . . . . . . . . 154
10.11.6. Text Response Data . . . . . . . . . . . . . 154
10.12. Login Request. . . . . . . . . . . . . . . . . . . . . 154
10.12.1. T (Transit) Bit. . . . . . . . . . . . . . . 155
10.12.2. C (Continue) Bit . . . . . . . . . . . . . . 155
10.12.3. CSG and NSG. . . . . . . . . . . . . . . . . 156
10.12.4. Version. . . . . . . . . . . . . . . . . . . 156
10.12.4.1. Version-max. . . . . . . . . . . 156
10.12.4.2. Version-min. . . . . . . . . . . 156
10.12.5. ISID . . . . . . . . . . . . . . . . . . . . 157
10.12.6. TSIH . . . . . . . . . . . . . . . . . . . . 158
10.12.7. Connection ID - CID. . . . . . . . . . . . . 158
10.12.8. CmdSN. . . . . . . . . . . . . . . . . . . . 159
10.12.9. ExpStatSN. . . . . . . . . . . . . . . . . . 159
10.12.10. Login Parameters . . . . . . . . . . . . . . 159
10.13. Login Response . . . . . . . . . . . . . . . . . . . . 160
10.13.1. Version-max. . . . . . . . . . . . . . . . . 160
10.13.2. Version-active . . . . . . . . . . . . . . . 161
10.13.3. TSIH . . . . . . . . . . . . . . . . . . . . 161
10.13.4. StatSN . . . . . . . . . . . . . . . . . . . 161
10.13.5. Status-Class and Status-Detail . . . . . . . 161
10.13.6. T (Transit) Bit. . . . . . . . . . . . . . . 164
10.13.7. C (Continue) Bit . . . . . . . . . . . . . . 164
10.13.8. Login Parameters . . . . . . . . . . . . . . 164
10.14. Logout Request . . . . . . . . . . . . . . . . . . . . 165
10.14.1. Reason Code. . . . . . . . . . . . . . . . . 167
10.14.2. TotalAHSLength and DataSegmentLength . . . . 168
10.14.3. CID. . . . . . . . . . . . . . . . . . . . . 168
10.14.4. ExpStatSN. . . . . . . . . . . . . . . . . . 168
10.14.5. Implicit termination of tasks. . . . . . . . 168
10.15. Logout Response. . . . . . . . . . . . . . . . . . . . 169
10.15.1. Response . . . . . . . . . . . . . . . . . . 170
10.15.2. TotalAHSLength and DataSegmentLength . . . . 170
10.15.3. Time2Wait. . . . . . . . . . . . . . . . . . 170
10.15.4. Time2Retain. . . . . . . . . . . . . . . . . 170
10.16. SNACK Request. . . . . . . . . . . . . . . . . . . . . 171
10.16.1. Type . . . . . . . . . . . . . . . . . . . . 172
10.16.2. Data Acknowledgement . . . . . . . . . . . . 173
10.16.3. Resegmentation . . . . . . . . . . . . . . . 173
10.16.4. Initiator Task Tag . . . . . . . . . . . . . 174
10.16.5. Target Transfer Tag or SNACK Tag . . . . . . 174
10.16.6. BegRun . . . . . . . . . . . . . . . . . . . 174
10.16.7. RunLength. . . . . . . . . . . . . . . . . . 174
10.17. Reject . . . . . . . . . . . . . . . . . . . . . . . . 175
10.17.1. Reason . . . . . . . . . . . . . . . . . . . 176
10.17.2. DataSN/R2TSN . . . . . . . . . . . . . . . . 177
10.17.3. StatSN, ExpCmdSN and MaxCmdSN. . . . . . . . 177
10.17.4. Complete Header of Bad PDU . . . . . . . . . 177
10.11.5. StatSN. . . . . . . . . . . . . . . . . . . 154 10.11.6。 テキスト応答データ. . . . . . . . . . . . . 154 10.12。 ログイン要求。 . . . . . . . . . . . . . . . . . . . . 154 10.12.1. T(トランジット)に噛み付きました。 . . . . . . . . . . . . . . 155 10.12.2. C(続けている)ビット. . . . . . . . . . . . . . 155 10.12.3。 CSGとNSG。 . . . . . . . . . . . . . . . . 156 10.12.4. バージョン。 . . . . . . . . . . . . . . . . . . 156 10.12.4.1. バージョンで最大限にしてください。 . . . . . . . . . . 156 10.12.4.2. バージョン分 . . . . . . . . . . 156 10.12.5. ISID. . . . . . . . . . . . . . . . . . . . 157 10.12.6。 TSIH. . . . . . . . . . . . . . . . . . . . 158 10.12.7。 接続ID--Cid。 . . . . . . . . . . . . 158 10.12.8. CmdSN。 . . . . . . . . . . . . . . . . . . . 159 10.12.9. ExpStatSN。 . . . . . . . . . . . . . . . . . 159 10.12.10. ログインパラメタ. . . . . . . . . . . . . . 159 10.13。 ログイン応答. . . . . . . . . . . . . . . . . . . . 160 10.13.1。 バージョンで最大限にしてください。 . . . . . . . . . . . . . . . . 160 10.13.2. バージョンアクティブな.16110.13、.3 TSIH. . . . . . . . . . . . . . . . . . . . 161 10.13.4。 StatSN. . . . . . . . . . . . . . . . . . . 161 10.13.5。 .16110.13に.6を状態で分類して、状態で詳しく述べてください。 T(トランジット)に噛み付きました。 . . . . . . . . . . . . . . 164 10.13.7. C(続けている)ビット. . . . . . . . . . . . . . 164 10.13.8。 ログインパラメタ. . . . . . . . . . . . . . 164 10.14。 ログアウトしてください。.16510.14に.1を要求してください。 コードを推論してください。 . . . . . . . . . . . . . . . . 167 10.14.2. TotalAHSLengthとDataSegmentLength. . . . 168 10.14.3。 Cid。 . . . . . . . . . . . . . . . . . . . . 168 10.14.4. ExpStatSN。 . . . . . . . . . . . . . . . . . 168 10.14.5. タスクの暗黙の終了。 . . . . . . . 168 10.15. ログアウトしてください。応答。 . . . . . . . . . . . . . . . . . . . 169 10.15.1. 応答. . . . . . . . . . . . . . . . . . 170 10.15.2。 TotalAHSLengthとDataSegmentLength. . . . 170 10.15.3。 Time2Wait。 . . . . . . . . . . . . . . . . . 170 10.15.4. Time2Retain。 . . . . . . . . . . . . . . . . 170 10.16. 軽食要求。 . . . . . . . . . . . . . . . . . . . . 171 10.16.1. タイプ. . . . . . . . . . . . . . . . . . . . 172 10.16.2。 データ承認. . . . . . . . . . . . 173 10.16.3。 Resegmentation. . . . . . . . . . . . . . . 173 10.16.4。 創始者タスクタグ. . . . . . . . . . . . . 174 10.16.5。 転送タグか軽食タグ. . . . . . 174 10.16.6を狙ってください。 BegRun. . . . . . . . . . . . . . . . . . . 174 10.16.7。 RunLength。 . . . . . . . . . . . . . . . . . 174 10.17. 廃棄物. . . . . . . . . . . . . . . . . . . . . . . . 175 10.17.1。 理由. . . . . . . . . . . . . . . . . . . 176 10.17.2。 DataSN/R2TSN. . . . . . . . . . . . . . . . 177 10.17.3。 StatSN、ExpCmdSN、およびMaxCmdSN。 . . . . . . . 177 10.17.4. 悪いPDU. . . . . . . . . 177の完全なヘッダー
Satran, et al. Standards Track [Page 7] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[7ページ]。
10.18. NOP-Out. . . . . . . . . . . . . . . . . . . . . . . . 178
10.18.1. Initiator Task Tag . . . . . . . . . . . . . 179
10.18.2. Target Transfer Tag. . . . . . . . . . . . . 179
10.18.3. Ping Data. . . . . . . . . . . . . . . . . . 179
10.19. NOP-In . . . . . . . . . . . . . . . . . . . . . . . . 180
10.19.1. Target Transfer Tag. . . . . . . . . . . . . 181
10.19.2. StatSN . . . . . . . . . . . . . . . . . . . 181
10.19.3. LUN. . . . . . . . . . . . . . . . . . . . . 181
11. iSCSI Security Text Keys and Authentication Methods . . . . . 181
11.1. AuthMethod . . . . . . . . . . . . . . . . . . . . . . 182
11.1.1. Kerberos . . . . . . . . . . . . . . . . . . 184
11.1.2. Simple Public-Key Mechanism (SPKM) . . . . . 184
11.1.3. Secure Remote Password (SRP) . . . . . . . . 185
11.1.4. Challenge Handshake Authentication Protocol
(CHAP) . . . . . . . . . . . . . . . . . . . 186
12. Login/Text Operational Text Keys. . . . . . . . . . . . . . . 187
12.1. HeaderDigest and DataDigest. . . . . . . . . . . . . . 188
12.2. MaxConnections . . . . . . . . . . . . . . . . . . . . 190
12.3. SendTargets. . . . . . . . . . . . . . . . . . . . . . 191
12.4. TargetName . . . . . . . . . . . . . . . . . . . . . . 191
12.5. InitiatorName. . . . . . . . . . . . . . . . . . . . . 192
12.6. TargetAlias. . . . . . . . . . . . . . . . . . . . . . 192
12.7. InitiatorAlias . . . . . . . . . . . . . . . . . . . . 193
12.8. TargetAddress. . . . . . . . . . . . . . . . . . . . . 193
12.9. TargetPortalGroupTag . . . . . . . . . . . . . . . . . 194
12.10. InitialR2T . . . . . . . . . . . . . . . . . . . . . . 194
12.11. ImmediateData. . . . . . . . . . . . . . . . . . . . . 195
12.12. MaxRecvDataSegmentLength . . . . . . . . . . . . . . . 196
12.13. MaxBurstLength . . . . . . . . . . . . . . . . . . . . 196
12.14. FirstBurstLength . . . . . . . . . . . . . . . . . . . 197
12.15. DefaultTime2Wait . . . . . . . . . . . . . . . . . . . 197
12.16. DefaultTime2Retain . . . . . . . . . . . . . . . . . . 198
12.17. MaxOutstandingR2T. . . . . . . . . . . . . . . . . . . 198
12.18. DataPDUInOrder . . . . . . . . . . . . . . . . . . . . 198
12.19. DataSequenceInOrder. . . . . . . . . . . . . . . . . . 199
12.20. ErrorRecoveryLevel . . . . . . . . . . . . . . . . . . 199
12.21. SessionType. . . . . . . . . . . . . . . . . . . . . . 200
12.22. The Private or Public Extension Key Format . . . . . . 200
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 201
13.1. Naming Requirements. . . . . . . . . . . . . . . . . . 203
13.2. Mechanism Specification Requirements . . . . . . . . . 203
13.3. Publication Requirements . . . . . . . . . . . . . . . 203
13.4. Security Requirements. . . . . . . . . . . . . . . . . 203
13.5. Registration Procedure . . . . . . . . . . . . . . . . 204
13.5.1. Present the iSCSI extension item to the
Community. . . . . . . . . . . . . . . . . . 204
13.5.2. iSCSI extension item review and IESG
approval . . . . . . . . . . . . . . . . . . 204
10.18. NOP-Out. . . . . . . . . . . . . . . . . . . . . . . . 178 10.18.1. Initiator Task Tag . . . . . . . . . . . . . 179 10.18.2. Target Transfer Tag. . . . . . . . . . . . . 179 10.18.3. Ping Data. . . . . . . . . . . . . . . . . . 179 10.19. NOP-In . . . . . . . . . . . . . . . . . . . . . . . . 180 10.19.1. Target Transfer Tag. . . . . . . . . . . . . 181 10.19.2. StatSN . . . . . . . . . . . . . . . . . . . 181 10.19.3. LUN. . . . . . . . . . . . . . . . . . . . . 181 11. iSCSI Security Text Keys and Authentication Methods . . . . . 181 11.1. AuthMethod . . . . . . . . . . . . . . . . . . . . . . 182 11.1.1. Kerberos . . . . . . . . . . . . . . . . . . 184 11.1.2. Simple Public-Key Mechanism (SPKM) . . . . . 184 11.1.3. Secure Remote Password (SRP) . . . . . . . . 185 11.1.4. Challenge Handshake Authentication Protocol (CHAP) . . . . . . . . . . . . . . . . . . . 186 12. Login/Text Operational Text Keys. . . . . . . . . . . . . . . 187 12.1. HeaderDigest and DataDigest. . . . . . . . . . . . . . 188 12.2. MaxConnections . . . . . . . . . . . . . . . . . . . . 190 12.3. SendTargets. . . . . . . . . . . . . . . . . . . . . . 191 12.4. TargetName . . . . . . . . . . . . . . . . . . . . . . 191 12.5. InitiatorName. . . . . . . . . . . . . . . . . . . . . 192 12.6. TargetAlias. . . . . . . . . . . . . . . . . . . . . . 192 12.7. InitiatorAlias . . . . . . . . . . . . . . . . . . . . 193 12.8. TargetAddress. . . . . . . . . . . . . . . . . . . . . 193 12.9. TargetPortalGroupTag . . . . . . . . . . . . . . . . . 194 12.10. InitialR2T . . . . . . . . . . . . . . . . . . . . . . 194 12.11. ImmediateData. . . . . . . . . . . . . . . . . . . . . 195 12.12. MaxRecvDataSegmentLength . . . . . . . . . . . . . . . 196 12.13. MaxBurstLength . . . . . . . . . . . . . . . . . . . . 196 12.14. FirstBurstLength . . . . . . . . . . . . . . . . . . . 197 12.15. DefaultTime2Wait . . . . . . . . . . . . . . . . . . . 197 12.16. DefaultTime2Retain . . . . . . . . . . . . . . . . . . 198 12.17. MaxOutstandingR2T. . . . . . . . . . . . . . . . . . . 198 12.18. DataPDUInOrder . . . . . . . . . . . . . . . . . . . . 198 12.19. DataSequenceInOrder. . . . . . . . . . . . . . . . . . 199 12.20. ErrorRecoveryLevel . . . . . . . . . . . . . . . . . . 199 12.21. SessionType. . . . . . . . . . . . . . . . . . . . . . 200 12.22. The Private or Public Extension Key Format . . . . . . 200 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 201 13.1. Naming Requirements. . . . . . . . . . . . . . . . . . 203 13.2. Mechanism Specification Requirements . . . . . . . . . 203 13.3. Publication Requirements . . . . . . . . . . . . . . . 203 13.4. Security Requirements. . . . . . . . . . . . . . . . . 203 13.5. Registration Procedure . . . . . . . . . . . . . . . . 204 13.5.1. Present the iSCSI extension item to the Community. . . . . . . . . . . . . . . . . . 204 13.5.2. iSCSI extension item review and IESG approval . . . . . . . . . . . . . . . . . . 204
Satran, et al. Standards Track [Page 8] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 8] RFC 3720 iSCSI April 2004
13.5.3. IANA Registration. . . . . . . . . . . . . . 204
13.5.4. Standard iSCSI extension item-label format . 204
13.6. IANA Procedures for Registering iSCSI extension items. 205
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Appendix A. Sync and Steering with Fixed Interval Markers . . . . 209
A.1. Markers At Fixed Intervals . . . . . . . . . . . . . . 209
A.2. Initial Marker-less Interval . . . . . . . . . . . . . 210
A.3. Negotiation. . . . . . . . . . . . . . . . . . . . . . 210
A.3.1. OFMarker, IFMarker . . . . . . . . . . . . . 210
A.3.2. OFMarkInt, IFMarkInt . . . . . . . . . . . . 211
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 212
B.1. Read Operation Example . . . . . . . . . . . . . . . . 212
B.2. Write Operation Example. . . . . . . . . . . . . . . . 213
B.3. R2TSN/DataSN Use Examples. . . . . . . . . . . . . . . 214
B.4. CRC Examples . . . . . . . . . . . . . . . . . . . . . 217
Appendix C. Login Phase Examples . . . . . . . . . . . . . . . . 219
Appendix D. SendTargets Operation. . . . . . . . . . . . . . . . 229
Appendix E. Algorithmic Presentation of Error Recovery Classes . 233
E.1. General Data Structure and Procedure Description . . . 233
E.2. Within-command Error Recovery Algorithms . . . . . . . 234
E.2.1. Procedure Descriptions . . . . . . . . . . . 234
E.2.2. Initiator Algorithms . . . . . . . . . . . . 235
E.2.3. Target Algorithms. . . . . . . . . . . . . . 237
E.3. Within-connection Recovery Algorithms. . . . . . . . . 240
E.3.1. Procedure Descriptions . . . . . . . . . . . 240
E.3.2. Initiator Algorithms . . . . . . . . . . . . 241
E.3.3. Target Algorithms. . . . . . . . . . . . . . 243
E.4. Connection Recovery Algorithms . . . . . . . . . . . . 243
E.4.1. Procedure Descriptions . . . . . . . . . . . 243
E.4.2. Initiator Algorithms . . . . . . . . . . . . 244
E.4.3. Target Algorithms. . . . . . . . . . . . . . 246
Appendix F. Clearing Effects of Various Events on Targets. . . . 249
F.1. Clearing Effects on iSCSI Objects. . . . . . . . . . . 249
F.2. Clearing Effects on SCSI Objects . . . . . . . . . . . 253
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 254
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 256
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 257
13.5.3. IANA Registration. . . . . . . . . . . . . . 204 13.5.4. Standard iSCSI extension item-label format . 204 13.6. IANA Procedures for Registering iSCSI extension items. 205 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Appendix A. Sync and Steering with Fixed Interval Markers . . . . 209 A.1. Markers At Fixed Intervals . . . . . . . . . . . . . . 209 A.2. Initial Marker-less Interval . . . . . . . . . . . . . 210 A.3. Negotiation. . . . . . . . . . . . . . . . . . . . . . 210 A.3.1. OFMarker, IFMarker . . . . . . . . . . . . . 210 A.3.2. OFMarkInt, IFMarkInt . . . . . . . . . . . . 211 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 212 B.1. Read Operation Example . . . . . . . . . . . . . . . . 212 B.2. Write Operation Example. . . . . . . . . . . . . . . . 213 B.3. R2TSN/DataSN Use Examples. . . . . . . . . . . . . . . 214 B.4. CRC Examples . . . . . . . . . . . . . . . . . . . . . 217 Appendix C. Login Phase Examples . . . . . . . . . . . . . . . . 219 Appendix D. SendTargets Operation. . . . . . . . . . . . . . . . 229 Appendix E. Algorithmic Presentation of Error Recovery Classes . 233 E.1. General Data Structure and Procedure Description . . . 233 E.2. Within-command Error Recovery Algorithms . . . . . . . 234 E.2.1. Procedure Descriptions . . . . . . . . . . . 234 E.2.2. Initiator Algorithms . . . . . . . . . . . . 235 E.2.3. Target Algorithms. . . . . . . . . . . . . . 237 E.3. Within-connection Recovery Algorithms. . . . . . . . . 240 E.3.1. Procedure Descriptions . . . . . . . . . . . 240 E.3.2. Initiator Algorithms . . . . . . . . . . . . 241 E.3.3. Target Algorithms. . . . . . . . . . . . . . 243 E.4. Connection Recovery Algorithms . . . . . . . . . . . . 243 E.4.1. Procedure Descriptions . . . . . . . . . . . 243 E.4.2. Initiator Algorithms . . . . . . . . . . . . 244 E.4.3. Target Algorithms. . . . . . . . . . . . . . 246 Appendix F. Clearing Effects of Various Events on Targets. . . . 249 F.1. Clearing Effects on iSCSI Objects. . . . . . . . . . . 249 F.2. Clearing Effects on SCSI Objects . . . . . . . . . . . 253 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 254 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 256 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 257
1. Introduction
1. Introduction
The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. SCSI is a client-server architecture. Clients of a SCSI interface are called "initiators". Initiators issue SCSI "commands" to request services from components, logical units of a server known as a "target". A "SCSI transport" maps the client-server SCSI protocol to a specific interconnect. An Initiator is one endpoint of a SCSI transport and a target is the other endpoint.
The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. SCSI is a client-server architecture. Clients of a SCSI interface are called "initiators". Initiators issue SCSI "commands" to request services from components, logical units of a server known as a "target". A "SCSI transport" maps the client-server SCSI protocol to a specific interconnect. An Initiator is one endpoint of a SCSI transport and a target is the other endpoint.
Satran, et al. Standards Track [Page 9] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 9] RFC 3720 iSCSI April 2004
The SCSI protocol has been mapped over various transports, including Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre Channel. These transports are I/O specific and have limited distance capabilities.
The SCSI protocol has been mapped over various transports, including Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre Channel. These transports are I/O specific and have limited distance capabilities.
The iSCSI protocol defined in this document describes a means of transporting SCSI packets over TCP/IP (see [RFC791], [RFC793], [RFC1035], [RFC1122]), providing for an interoperable solution which can take advantage of existing Internet infrastructure, Internet management facilities, and address distance limitations.
The iSCSI protocol defined in this document describes a means of transporting SCSI packets over TCP/IP (see [RFC791], [RFC793], [RFC1035], [RFC1122]), providing for an interoperable solution which can take advantage of existing Internet infrastructure, Internet management facilities, and address distance limitations.
2. Definitions and Acronyms
2. Definitions and Acronyms
2.1. Definitions
2.1. Definitions
- Alias: An alias string can also be associated with an iSCSI Node.
The alias allows an organization to associate a user-friendly
string with the iSCSI Name. However, the alias string is not a
substitute for the iSCSI Name.
- Alias: An alias string can also be associated with an iSCSI Node. The alias allows an organization to associate a user-friendly string with the iSCSI Name. However, the alias string is not a substitute for the iSCSI Name.
- CID (Connection ID): Connections within a session are identified by
a connection ID. It is a unique ID for this connection within the
session for the initiator. It is generated by the initiator and
presented to the target during login requests and during logouts
that close connections.
- CID (Connection ID): Connections within a session are identified by a connection ID. It is a unique ID for this connection within the session for the initiator. It is generated by the initiator and presented to the target during login requests and during logouts that close connections.
- Connection: A connection is a TCP connection. Communication
between the initiator and target occurs over one or more TCP
connections. The TCP connections carry control messages, SCSI
commands, parameters, and data within iSCSI Protocol Data Units
(iSCSI PDUs).
- Connection: A connection is a TCP connection. Communication between the initiator and target occurs over one or more TCP connections. The TCP connections carry control messages, SCSI commands, parameters, and data within iSCSI Protocol Data Units (iSCSI PDUs).
- iSCSI Device: A SCSI Device using an iSCSI service delivery
subsystem. Service Delivery Subsystem is defined by [SAM2] as a
transport mechanism for SCSI commands and responses.
- iSCSI Device: A SCSI Device using an iSCSI service delivery subsystem. Service Delivery Subsystem is defined by [SAM2] as a transport mechanism for SCSI commands and responses.
- iSCSI Initiator Name: The iSCSI Initiator Name specifies the
worldwide unique name of the initiator.
- iSCSI Initiator Name: The iSCSI Initiator Name specifies the worldwide unique name of the initiator.
- iSCSI Initiator Node: The "initiator". The word "initiator" has
been appropriately qualified as either a port or a device in the
rest of the document when the context is ambiguous. All
unqualified usages of "initiator" refer to an initiator port (or
device) depending on the context.
- iSCSI Initiator Node: The "initiator". The word "initiator" has been appropriately qualified as either a port or a device in the rest of the document when the context is ambiguous. All unqualified usages of "initiator" refer to an initiator port (or device) depending on the context.
- iSCSI Layer: This layer builds/receives iSCSI PDUs and
relays/receives them to/from one or more TCP connections that form
an initiator-target "session".
- iSCSI Layer: This layer builds/receives iSCSI PDUs and relays/receives them to/from one or more TCP connections that form an initiator-target "session".
Satran, et al. Standards Track [Page 10] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 10] RFC 3720 iSCSI April 2004
- iSCSI Name: The name of an iSCSI initiator or iSCSI target.
- iSCSI Name: The name of an iSCSI initiator or iSCSI target.
- iSCSI Node: The iSCSI Node represents a single iSCSI initiator or
iSCSI target. There are one or more iSCSI Nodes within a Network
Entity. The iSCSI Node is accessible via one or more Network
Portals. An iSCSI Node is identified by its iSCSI Name. The
separation of the iSCSI Name from the addresses used by and for the
iSCSI Node allows multiple iSCSI Nodes to use the same address, and
the same iSCSI Node to use multiple addresses.
- iSCSI Node: The iSCSI Node represents a single iSCSI initiator or iSCSI target. There are one or more iSCSI Nodes within a Network Entity. The iSCSI Node is accessible via one or more Network Portals. An iSCSI Node is identified by its iSCSI Name. The separation of the iSCSI Name from the addresses used by and for the iSCSI Node allows multiple iSCSI Nodes to use the same address, and the same iSCSI Node to use multiple addresses.
- iSCSI Target Name: The iSCSI Target Name specifies the worldwide
unique name of the target.
- iSCSI Target Name: The iSCSI Target Name specifies the worldwide unique name of the target.
- iSCSI Target Node: The "target".
- iSCSI Target Node: The "target".
- iSCSI Task: An iSCSI task is an iSCSI request for which a response
is expected.
- iSCSI Task: An iSCSI task is an iSCSI request for which a response is expected.
- iSCSI Transfer Direction: The iSCSI transfer direction is defined
with regard to the initiator. Outbound or outgoing transfers are
transfers from the initiator to the target, while inbound or
incoming transfers are from the target to the initiator.
- iSCSI Transfer Direction: The iSCSI transfer direction is defined with regard to the initiator. Outbound or outgoing transfers are transfers from the initiator to the target, while inbound or incoming transfers are from the target to the initiator.
- ISID: The initiator part of the Session Identifier. It is
explicitly specified by the initiator during Login.
- ISID: The initiator part of the Session Identifier. It is explicitly specified by the initiator during Login.
- I_T nexus: According to [SAM2], the I_T nexus is a relationship
between a SCSI Initiator Port and a SCSI Target Port. For iSCSI,
this relationship is a session, defined as a relationship between
an iSCSI Initiator's end of the session (SCSI Initiator Port) and
the iSCSI Target's Portal Group. The I_T nexus can be identified
by the conjunction of the SCSI port names; that is, the I_T nexus
identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI
Target Name + ',t,'+ Portal Group Tag).
- I_T nexus: According to [SAM2], the I_T nexus is a relationship between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship is a session, defined as a relationship between an iSCSI Initiator's end of the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag).
- Network Entity: The Network Entity represents a device or gateway
that is accessible from the IP network. A Network Entity must have
one or more Network Portals, each of which can be used to gain
access to the IP network by some iSCSI Nodes contained in that
Network Entity.
- Network Entity: The Network Entity represents a device or gateway that is accessible from the IP network. A Network Entity must have one or more Network Portals, each of which can be used to gain access to the IP network by some iSCSI Nodes contained in that Network Entity.
- Network Portal: The Network Portal is a component of a Network
Entity that has a TCP/IP network address and that may be used by an
iSCSI Node within that Network Entity for the connection(s) within
one of its iSCSI sessions. A Network Portal in an initiator is
identified by its IP address. A Network Portal in a target is
identified by its IP address and its listening TCP port.
- Network Portal: The Network Portal is a component of a Network Entity that has a TCP/IP network address and that may be used by an iSCSI Node within that Network Entity for the connection(s) within one of its iSCSI sessions. A Network Portal in an initiator is identified by its IP address. A Network Portal in a target is identified by its IP address and its listening TCP port.
Satran, et al. Standards Track [Page 11] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 11] RFC 3720 iSCSI April 2004
- Originator: In a negotiation or exchange, the party that initiates
the negotiation or exchange.
- Originator: In a negotiation or exchange, the party that initiates the negotiation or exchange.
- PDU (Protocol Data Unit): The initiator and target divide their
communications into messages. The term "iSCSI protocol data unit"
(iSCSI PDU) is used for these messages.
- PDU (Protocol Data Unit): The initiator and target divide their communications into messages. The term "iSCSI protocol data unit" (iSCSI PDU) is used for these messages.
- Portal Groups: iSCSI supports multiple connections within the same
session; some implementations will have the ability to combine
connections in a session across multiple Network Portals. A Portal
Group defines a set of Network Portals within an iSCSI Network
Entity that collectively supports the capability of coordinating a
session with connections spanning these portals. Not all Network
Portals within a Portal Group need participate in every session
connected through that Portal Group. One or more Portal Groups may
provide access to an iSCSI Node. Each Network Portal, as utilized
by a given iSCSI Node, belongs to exactly one portal group within
that node.
- Portal Groups: iSCSI supports multiple connections within the same session; some implementations will have the ability to combine connections in a session across multiple Network Portals. A Portal Group defines a set of Network Portals within an iSCSI Network Entity that collectively supports the capability of coordinating a session with connections spanning these portals. Not all Network Portals within a Portal Group need participate in every session connected through that Portal Group. One or more Portal Groups may provide access to an iSCSI Node. Each Network Portal, as utilized by a given iSCSI Node, belongs to exactly one portal group within that node.
- Portal Group Tag: This 16-bit quantity identifies a Portal Group
within an iSCSI Node. All Network Portals with the same portal
group tag in the context of a given iSCSI Node are in the same
Portal Group.
- Portal Group Tag: This 16-bit quantity identifies a Portal Group within an iSCSI Node. All Network Portals with the same portal group tag in the context of a given iSCSI Node are in the same Portal Group.
- Recovery R2T: An R2T generated by a target upon detecting the loss
of one or more Data-Out PDUs through one of the following means: a
digest error, a sequence error, or a sequence reception timeout. A
recovery R2T carries the next unused R2TSN, but requests all or
part of the data burst that an earlier R2T (with a lower R2TSN) had
already requested.
- Recovery R2T: An R2T generated by a target upon detecting the loss of one or more Data-Out PDUs through one of the following means: a digest error, a sequence error, or a sequence reception timeout. A recovery R2T carries the next unused R2TSN, but requests all or part of the data burst that an earlier R2T (with a lower R2TSN) had already requested.
- Responder: In a negotiation or exchange, the party that responds to
the originator of the negotiation or exchange.
- Responder: In a negotiation or exchange, the party that responds to the originator of the negotiation or exchange.
- SCSI Device: This is the SAM2 term for an entity that contains one
or more SCSI ports that are connected to a service delivery
subsystem and supports a SCSI application protocol. For example, a
SCSI Initiator Device contains one or more SCSI Initiator Ports and
zero or more application clients. A Target Device contains one or
more SCSI Target Ports and one or more device servers and
associated logical units. For iSCSI, the SCSI Device is the
component within an iSCSI Node that provides the SCSI
functionality. As such, there can be at most, one SCSI Device
within a given iSCSI Node. Access to the SCSI Device can only be
achieved in an iSCSI normal operational session. The SCSI Device
Name is defined to be the iSCSI Name of the node.
- SCSI Device: This is the SAM2 term for an entity that contains one or more SCSI ports that are connected to a service delivery subsystem and supports a SCSI application protocol. For example, a SCSI Initiator Device contains one or more SCSI Initiator Ports and zero or more application clients. A Target Device contains one or more SCSI Target Ports and one or more device servers and associated logical units. For iSCSI, the SCSI Device is the component within an iSCSI Node that provides the SCSI functionality. As such, there can be at most, one SCSI Device within a given iSCSI Node. Access to the SCSI Device can only be achieved in an iSCSI normal operational session. The SCSI Device Name is defined to be the iSCSI Name of the node.
Satran, et al. Standards Track [Page 12] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 12] RFC 3720 iSCSI April 2004
- SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor
Blocks) and relays/receives them with the remaining command execute
[SAM2] parameters to/from the iSCSI Layer.
- SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor Blocks) and relays/receives them with the remaining command execute [SAM2] parameters to/from the iSCSI Layer.
- Session: The group of TCP connections that link an initiator with a
target form a session (loosely equivalent to a SCSI I-T nexus).
TCP connections can be added and removed from a session. Across
all connections within a session, an initiator sees one and the
same target.
- Session: The group of TCP connections that link an initiator with a target form a session (loosely equivalent to a SCSI I-T nexus). TCP connections can be added and removed from a session. Across all connections within a session, an initiator sees one and the same target.
- SCSI Initiator Port: This maps to the endpoint of an iSCSI normal
operational session. An iSCSI normal operational session is
negotiated through the login process between an iSCSI initiator
node and an iSCSI target node. At successful completion of this
process, a SCSI Initiator Port is created within the SCSI Initiator
Device. The SCSI Initiator Port Name and SCSI Initiator Port
Identifier are both defined to be the iSCSI Initiator Name together
with (a) a label that identifies it as an initiator port
name/identifier and (b) the ISID portion of the session identifier.
- SCSI Initiator Port: This maps to the endpoint of an iSCSI normal operational session. An iSCSI normal operational session is negotiated through the login process between an iSCSI initiator node and an iSCSI target node. At successful completion of this process, a SCSI Initiator Port is created within the SCSI Initiator Device. The SCSI Initiator Port Name and SCSI Initiator Port Identifier are both defined to be the iSCSI Initiator Name together with (a) a label that identifies it as an initiator port name/identifier and (b) the ISID portion of the session identifier.
- SCSI Port: This is the SAM2 term for an entity in a SCSI Device
that provides the SCSI functionality to interface with a service
delivery subsystem. For iSCSI, the definition of the SCSI
Initiator Port and the SCSI Target Port are different.
- SCSI Port: This is the SAM2 term for an entity in a SCSI Device that provides the SCSI functionality to interface with a service delivery subsystem. For iSCSI, the definition of the SCSI Initiator Port and the SCSI Target Port are different.
- SCSI Port Name: A name made up as UTF-8 [RFC2279] characters and
includes the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag.
- SCSI Port Name: A name made up as UTF-8 [RFC2279] characters and includes the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag.
- SCSI Target Port: This maps to an iSCSI Target Portal Group.
- SCSI Target Port: This maps to an iSCSI Target Portal Group.
- SCSI Target Port Name and SCSI Target Port Identifier: These are
both defined to be the iSCSI Target Name together with (a) a label
that identifies it as a target port name/identifier and (b) the
portal group tag.
- SCSI Target Port Name and SCSI Target Port Identifier: These are both defined to be the iSCSI Target Name together with (a) a label that identifies it as a target port name/identifier and (b) the portal group tag.
- SSID (Session ID): A session between an iSCSI initiator and an
iSCSI target is defined by a session ID that is a tuple composed of
an initiator part (ISID) and a target part (Target Portal Group
Tag). The ISID is explicitly specified by the initiator at session
establishment. The Target Portal Group Tag is implied by the
initiator through the selection of the TCP endpoint at connection
establishment. The TargetPortalGroupTag key must also be returned
by the target as a confirmation during connection establishment
when TargetName is given.
- SSID (Session ID): A session between an iSCSI initiator and an iSCSI target is defined by a session ID that is a tuple composed of an initiator part (ISID) and a target part (Target Portal Group Tag). The ISID is explicitly specified by the initiator at session establishment. The Target Portal Group Tag is implied by the initiator through the selection of the TCP endpoint at connection establishment. The TargetPortalGroupTag key must also be returned by the target as a confirmation during connection establishment when TargetName is given.
- Target Portal Group Tag: A numerical identifier (16-bit) for an
iSCSI Target Portal Group.
- Target Portal Group Tag: A numerical identifier (16-bit) for an iSCSI Target Portal Group.
Satran, et al. Standards Track [Page 13] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 13] RFC 3720 iSCSI April 2004
- TSIH (Target Session Identifying Handle): A target assigned tag for
a session with a specific named initiator. The target generates it
during session establishment. Its internal format and content are
not defined by this protocol, except for the value 0 that is
reserved and used by the initiator to indicate a new session. It
is given to the target during additional connection establishment
for the same session.
- TSIH (Target Session Identifying Handle): A target assigned tag for a session with a specific named initiator. The target generates it during session establishment. Its internal format and content are not defined by this protocol, except for the value 0 that is reserved and used by the initiator to indicate a new session. It is given to the target during additional connection establishment for the same session.
2.2. Acronyms
2.2. Acronyms
Acronym Definition ------------------------------------------------------------ 3DES Triple Data Encryption Standard ACA Auto Contingent Allegiance AEN Asynchronous Event Notification AES Advanced Encryption Standard AH Additional Header (not the IPsec AH!) AHS Additional Header Segment API Application Programming Interface ASC Additional Sense Code ASCII American Standard Code for Information Interchange ASCQ Additional Sense Code Qualifier BHS Basic Header Segment CBC Cipher Block Chaining CD Compact Disk CDB Command Descriptor Block CHAP Challenge Handshake Authentication Protocol CID Connection ID CO Connection Only CRC Cyclic Redundancy Check CRL Certificate Revocation List CSG Current Stage CSM Connection State Machine DES Data Encryption Standard DNS Domain Name Server DOI Domain of Interpretation DVD Digital Versatile Disk ESP Encapsulating Security Payload EUI Extended Unique Identifier FFP Full Feature Phase FFPO Full Feature Phase Only FIM Fixed Interval Marker Gbps Gigabits per Second HBA Host Bus Adapter HMAC Hashed Message Authentication Code I_T Initiator_Target I_T_L Initiator_Target_LUN IANA Internet Assigned Numbers Authority
Acronym Definition ------------------------------------------------------------ 3DES Triple Data Encryption Standard ACA Auto Contingent Allegiance AEN Asynchronous Event Notification AES Advanced Encryption Standard AH Additional Header (not the IPsec AH!) AHS Additional Header Segment API Application Programming Interface ASC Additional Sense Code ASCII American Standard Code for Information Interchange ASCQ Additional Sense Code Qualifier BHS Basic Header Segment CBC Cipher Block Chaining CD Compact Disk CDB Command Descriptor Block CHAP Challenge Handshake Authentication Protocol CID Connection ID CO Connection Only CRC Cyclic Redundancy Check CRL Certificate Revocation List CSG Current Stage CSM Connection State Machine DES Data Encryption Standard DNS Domain Name Server DOI Domain of Interpretation DVD Digital Versatile Disk ESP Encapsulating Security Payload EUI Extended Unique Identifier FFP Full Feature Phase FFPO Full Feature Phase Only FIM Fixed Interval Marker Gbps Gigabits per Second HBA Host Bus Adapter HMAC Hashed Message Authentication Code I_T Initiator_Target I_T_L Initiator_Target_LUN IANA Internet Assigned Numbers Authority
Satran, et al. Standards Track [Page 14] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 14] RFC 3720 iSCSI April 2004
ID Identifier
IDN Internationalized Domain Name
IEEE Institute of Electrical & Electronics Engineers
IETF Internet Engineering Task Force
IKE Internet Key Exchange
I/O Input - Output
IO Initialize Only
IP Internet Protocol
IPsec Internet Protocol Security
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
IQN iSCSI Qualified Name
ISID Initiator Session ID
ITN iSCSI Target Name
ITT Initiator Task Tag
KRB5 Kerberos V5
LFL Lower Functional Layer
LTDS Logical-Text-Data-Segment
LO Leading Only
LU Logical Unit
LUN Logical Unit Number
MAC Message Authentication Codes
NA Not Applicable
NIC Network Interface Card
NOP No Operation
NSG Next Stage
OS Operating System
PDU Protocol Data Unit
PKI Public Key Infrastructure
R2T Ready To Transfer
R2TSN Ready To Transfer Sequence Number
RDMA Remote Direct Memory Access
RFC Request For Comments
SAM SCSI Architecture Model
SAM2 SCSI Architecture Model - 2
SAN Storage Area Network
SCSI Small Computer Systems Interface
SN Sequence Number
SNACK Selective Negative Acknowledgment - also
Sequence Number Acknowledgement for data
SPKM Simple Public-Key Mechanism
SRP Secure Remote Password
SSID Session ID
SW Session Wide
TCB Task Control Block
TCP Transmission Control Protocol
TPGT Target Portal Group Tag
TSIH Target Session Identifying Handle
ID Identifier IDN Internationalized Domain Name IEEE Institute of Electrical & Electronics Engineers IETF Internet Engineering Task Force IKE Internet Key Exchange I/O Input - Output IO Initialize Only IP Internet Protocol IPsec Internet Protocol Security IPv4 Internet Protocol Version 4 IPv6 Internet Protocol Version 6 IQN iSCSI Qualified Name ISID Initiator Session ID ITN iSCSI Target Name ITT Initiator Task Tag KRB5 Kerberos V5 LFL Lower Functional Layer LTDS Logical-Text-Data-Segment LO Leading Only LU Logical Unit LUN Logical Unit Number MAC Message Authentication Codes NA Not Applicable NIC Network Interface Card NOP No Operation NSG Next Stage OS Operating System PDU Protocol Data Unit PKI Public Key Infrastructure R2T Ready To Transfer R2TSN Ready To Transfer Sequence Number RDMA Remote Direct Memory Access RFC Request For Comments SAM SCSI Architecture Model SAM2 SCSI Architecture Model - 2 SAN Storage Area Network SCSI Small Computer Systems Interface SN Sequence Number SNACK Selective Negative Acknowledgment - also Sequence Number Acknowledgement for data SPKM Simple Public-Key Mechanism SRP Secure Remote Password SSID Session ID SW Session Wide TCB Task Control Block TCP Transmission Control Protocol TPGT Target Portal Group Tag TSIH Target Session Identifying Handle
Satran, et al. Standards Track [Page 15] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 15] RFC 3720 iSCSI April 2004
TTT Target Transfer Tag UFL Upper Functional Layer ULP Upper Level Protocol URN Uniform Resource Names [RFC2396] UTF Universal Transformation Format WG Working Group
TTT Target Transfer Tag UFL Upper Functional Layer ULP Upper Level Protocol URN Uniform Resource Names [RFC2396] UTF Universal Transformation Format WG Working Group
2.3. Conventions
2.3. Conventions
In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator and target respectively.
In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator and target respectively.
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 BCP 14 [RFC2119].
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 BCP 14 [RFC2119].
iSCSI messages - PDUs - are represented by diagrams as in the following example:
iSCSI messages - PDUs - are represented by diagrams as in the following example:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0| Basic Header Segment (BHS) |
+---------------+---------------+---------------+---------------+
----------
+| |
+---------------+---------------+---------------+---------------+
Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0| Basic Header Segment (BHS) | +---------------+---------------+---------------+---------------+ ---------- +| | +---------------+---------------+---------------+---------------+
The diagrams include byte and bit numbering.
The diagrams include byte and bit numbering.
The following representation and ordering rules are observed in this document:
The following representation and ordering rules are observed in this document:
- Word Rule
- Half-word Rule
- Byte Rule
- Word Rule - Half-word Rule - Byte Rule
2.3.1. Word Rule
2.3.1. Word Rule
A word holds four consecutive bytes. Whenever a word has numeric content, it is considered an unsigned number in base 2 positional representation with the lowest numbered byte (e.g., byte 0) bit 0 representing 2**31 and bit 1 representing 2**30 through lowest numbered byte + 3 (e.g., byte 3) bit 7 representing 2**0.
A word holds four consecutive bytes. Whenever a word has numeric content, it is considered an unsigned number in base 2 positional representation with the lowest numbered byte (e.g., byte 0) bit 0 representing 2**31 and bit 1 representing 2**30 through lowest numbered byte + 3 (e.g., byte 3) bit 7 representing 2**0.
Decimal and hexadecimal representation of word values map this representation to decimal or hexadecimal positional notation.
Decimal and hexadecimal representation of word values map this representation to decimal or hexadecimal positional notation.
Satran, et al. Standards Track [Page 16] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 16] RFC 3720 iSCSI April 2004
2.3.2. Half-Word Rule
2.3.2. Half-Word Rule
A half-word holds two consecutive bytes. Whenever a half-word has numeric content it is considered an unsigned number in base 2 positional representation with the lowest numbered byte (e.g., byte 0), bit 0 representing 2**15 and bit 1 representing 2**14 through lowest numbered byte + 1 (e.g., byte 1), bit 7 representing 2**0.
A half-word holds two consecutive bytes. Whenever a half-word has numeric content it is considered an unsigned number in base 2 positional representation with the lowest numbered byte (e.g., byte 0), bit 0 representing 2**15 and bit 1 representing 2**14 through lowest numbered byte + 1 (e.g., byte 1), bit 7 representing 2**0.
Decimal and hexadecimal representation of half-word values map this representation to decimal or hexadecimal positional notation.
Decimal and hexadecimal representation of half-word values map this representation to decimal or hexadecimal positional notation.
2.3.3. Byte Rule
2.3.3. Byte Rule
For every PDU, bytes are sent and received in increasing numbered order (network order).
For every PDU, bytes are sent and received in increasing numbered order (network order).
Whenever a byte has numerical content, it is considered an unsigned number in base 2 positional representation with bit 0 representing 2**7 and bit 1 representing 2**6 through bit 7 representing 2**0.
Whenever a byte has numerical content, it is considered an unsigned number in base 2 positional representation with bit 0 representing 2**7 and bit 1 representing 2**6 through bit 7 representing 2**0.
3. Overview
3. Overview
3.1. SCSI Concepts
3.1. SCSI Concepts
The SCSI Architecture Model-2 [SAM2] describes in detail the architecture of the SCSI family of I/O protocols. This section provides a brief background of the SCSI architecture and is intended to familiarize readers with its terminology.
The SCSI Architecture Model-2 [SAM2] describes in detail the architecture of the SCSI family of I/O protocols. This section provides a brief background of the SCSI architecture and is intended to familiarize readers with its terminology.
At the highest level, SCSI is a family of interfaces for requesting services from I/O devices, including hard drives, tape drives, CD and DVD drives, printers, and scanners. In SCSI terminology, an individual I/O device is called a "logical unit" (LU).
上層部によって、SCSIは入出力デバイスからサービスを要求するためのインタフェースのファミリーです、ハードドライブ、テープドライブ、CD、DVDドライブ、プリンタ、およびスキャナを含んでいて。 SCSI用語で、個々の入出力デバイスは「論理装置」(LU)と呼ばれます。
SCSI is a client-server architecture. Clients of a SCSI interface are called "initiators". Initiators issue SCSI "commands" to request services from components, logical units, of a server known as a "target". The "device server" on the logical unit accepts SCSI commands and processes them.
SCSIはクライアント/サーバアーキテクチャです。 SCSIインタフェースのクライアントは「創始者」と呼ばれます。 創始者はコンポーネント、「目標」として知られているサーバの論理装置からサービスを要求する「コマンド」をSCSIに発行します。 論理装置の「デバイスサーバ」は、SCSIコマンドを受け入れて、それらを処理します。
A "SCSI transport" maps the client-server SCSI protocol to a specific interconnect. Initiators are one endpoint of a SCSI transport. The "target" is the other endpoint. A target can contain multiple Logical Units (LUs). Each Logical Unit has an address within a target called a Logical Unit Number (LUN).
「SCSI輸送」はクライアント/サーバSCSIプロトコルを特定の内部連絡に写像します。 創始者はSCSI輸送の1つの終点です。 「目標」はもう片方の終点です。 目標は複数のLogical Units(LUs)を含むことができます。 各Logical UnitはLogical Unit Number(LUN)と呼ばれる目標の中にアドレスを持っています。
A SCSI task is a SCSI command or possibly a linked set of SCSI commands. Some LUs support multiple pending (queued) tasks, but the
SCSIコマンドかSCSIタスクはことによると繋がっているSCSIコマンドです。 しかし、未定(列に並ばせられる)の何らかのLUsサポート倍数が仕事を課します。
Satran, et al. Standards Track [Page 17] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[17ページ]。
queue of tasks is managed by the logical unit. The target uses an initiator provided "task tag" to distinguish between tasks. Only one command in a task can be outstanding at any given time.
タスクの待ち行列は論理装置によって管理されます。 目標は、タスクを見分けるのに創始者の提供された「タスクタグ」を使用します。 タスクにおける1つのコマンドだけがその時々で傑出している場合があります。
Each SCSI command results in an optional data phase and a required response phase. In the data phase, information can travel from the initiator to target (e.g., WRITE), target to initiator (e.g., READ), or in both directions. In the response phase, the target returns the final status of the operation, including any errors.
それぞれのSCSIコマンドは任意のデータフェーズと必要な応答位相をもたらします。 情報は、データフェーズでは、目標(例えば、WRITE)への創始者、創始者(例えば、READ)への目標から旅するか、または両方の方向にそうすることができます。 応答位相では、目標はどんな誤りも含む操作の最終的な状態を返します。
Command Descriptor Blocks (CDB) are the data structures used to contain the command parameters that an initiator sends to a target. The CDB content and structure is defined by [SAM2] and device-type specific SCSI standards.
コマンドDescriptor Blocks(CDB)は創始者が目標に送るコマンドパラメタを含むのに使用されるデータ構造です。 CDB内容と構造は[SAM2]と装置タイプの特定のSCSI規格によって定義されます。
3.2. iSCSI Concepts and Functional Overview
3.2. iSCSI概念と機能概要
The iSCSI protocol is a mapping of the SCSI remote procedure invocation model (see [SAM2]) over the TCP protocol. SCSI commands are carried by iSCSI requests and SCSI responses and status are carried by iSCSI responses. iSCSI also uses the request response mechanism for iSCSI protocol mechanisms.
iSCSIプロトコルはTCPプロトコルの上のSCSIのリモート手順実施のモデル([SAM2]を見る)に関するマッピングです。 SCSIコマンドはiSCSI要求で運ばれます、そして、SCSI応答と状態はiSCSI応答で運ばれます。また、iSCSIはiSCSIプロトコルメカニズムに要求反応機構を使用します。
For the remainder of this document, the terms "initiator" and "target" refer to "iSCSI initiator node" and "iSCSI target node", respectively (see Section 3.4.1 iSCSI Architecture Model) unless otherwise qualified.
このドキュメントの残りについて、用語「創始者」と「目標」はそれぞれ「iSCSI創始者ノード」と「iSCSI目標ノード」を示します(セクション3.4.1iSCSI Architecture Modelを見てください)。別の方法で資格がない場合。
In keeping with similar protocols, the initiator and target divide their communications into messages. This document uses the term "iSCSI protocol data unit" (iSCSI PDU) for these messages.
同様のプロトコルで保つ際に、創始者と目標はそれらのコミュニケーションをメッセージに分割します。 このドキュメントはこれらのメッセージに「iSCSIプロトコルデータ単位」(iSCSI PDU)という用語を使用します。
For performance reasons, iSCSI allows a "phase-collapse". A command and its associated data may be shipped together from initiator to target, and data and responses may be shipped together from targets.
性能理由で、iSCSIは「フェーズ崩壊」を許容します。 狙う創始者、およびデータからコマンドとその関連データを一緒に出荷するかもしれません、そして、目標から応答を一緒に出荷するかもしれません。
The iSCSI transfer direction is defined with respect to the initiator. Outbound or outgoing transfers are transfers from an initiator to a target, while inbound or incoming transfers are from a target to an initiator.
iSCSI転送方向は創始者に関して定義されます。 創始者から目標まで外国行き的、または、外向的な転送は転送です、目標から創始者まで本国行きの、または、入って来る転送がありますが。
An iSCSI task is an iSCSI request for which a response is expected.
iSCSIタスクは応答が予想されるiSCSI要求です。
In this document "iSCSI request", "iSCSI command", request, or (unqualified) command have the same meaning. Also, unless otherwise specified, status, response, or numbered response have the same meaning.
本書では「iSCSI要求」、「iSCSIコマンド」、要求、または(資格のない)のコマンドには、同じ意味があります。 また、別の方法で指定されない場合、状態、応答、または番号付の応答には同じ意味があります。
Satran, et al. Standards Track [Page 18] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[18ページ]。
3.2.1. Layers and Sessions
3.2.1. 層とセッション
The following conceptual layering model is used to specify initiator and target actions and the way in which they relate to transmitted and received Protocol Data Units:
以下の概念的なレイヤリングモデルが創始者を指定するのに使用されて、それらが関連する目標動作と入口は、プロトコルData Unitsを送信して、受けました:
a) the SCSI layer builds/receives SCSI CDBs (Command Descriptor
Blocks) and passes/receives them with the remaining command
execute parameters ([SAM2]) to/from
SCSI層が彼らをSCSI CDBs(コマンドDescriptor Blocks)を造るか、または受けて、通るか、または受けるa)はパラメタ([SAM2])を/に実行します残りが、命令する。
b) the iSCSI layer that builds/receives iSCSI PDUs and
relays/receives them to/from one or more TCP connections; the
group of connections form an initiator-target "session".
b) 1つ以上のTCP接続からの/に彼らをiSCSI PDUsを造るか、または受けて、リレーするか、または受けるiSCSI層。 接続のグループは創始者目標「セッション」を形成します。
Communication between the initiator and target occurs over one or more TCP connections. The TCP connections carry control messages, SCSI commands, parameters, and data within iSCSI Protocol Data Units (iSCSI PDUs). The group of TCP connections that link an initiator with a target form a session (loosely equivalent to a SCSI I_T nexus, see Section 3.4.2 SCSI Architecture Model). A session is defined by a session ID that is composed of an initiator part and a target part. TCP connections can be added and removed from a session. Each connection within a session is identified by a connection ID (CID).
創始者と目標とのコミュニケーションは1つ以上のTCP接続の上に現れます。 TCP接続はiSCSIプロトコルData Units(iSCSI PDUs)の中でコントロールメッセージ、SCSIコマンド、パラメタ、およびデータを運びます。 創始者を目標にリンクするTCP接続のグループはセッションを形成します(緩くSCSI I_T結びつきに同等です、セクション3.4.2SCSI Architecture Modelを見てください)。 セッションは創始者部分と目標部分で構成されるセッションIDによって定義されます。 セッションからTCP接続を加えて、外すことができます。 セッション以内の各接続は接続ID(CID)によって特定されます。
Across all connections within a session, an initiator sees one "target image". All target identifying elements, such as LUN, are the same. A target also sees one "initiator image" across all connections within a session. Initiator identifying elements, such as the Initiator Task Tag, are global across the session regardless of the connection on which they are sent or received.
セッション以内のすべての接続の向こう側に、創始者は1「目標イメージ」を見ます。 LUNなどのように、すべての目標特定要素が同じです。 また、目標はセッション以内にすべての接続の向こう側に1「創始者イメージ」を見ます。 Initiator Task Tagなどの創始者特定要素はそれらを送るか、または受け取る接続にかかわらずセッションの向こう側にグローバルです。
iSCSI targets and initiators MUST support at least one TCP connection and MAY support several connections in a session. For error recovery purposes, targets and initiators that support a single active connection in a session SHOULD support two connections during recovery.
iSCSI目標と創始者は、少なくとも1TCPが接続であるとサポートしなければならなくて、セッションにおけるいくつかの接続をサポートするかもしれません。 セッションにおける単独の活発な接続をサポートするエラー回復目的、目標、および創始者に関しては、SHOULDは回復の間、2つの接続をサポートします。
3.2.2. Ordering and iSCSI Numbering
3.2.2. 注文とiSCSI付番
iSCSI uses Command and Status numbering schemes and a Data sequencing scheme.
iSCSIはCommand、Statusナンバリングスキーム、およびData配列体系を使用します。
Command numbering is session-wide and is used for ordered command delivery over multiple connections. It can also be used as a mechanism for command flow control over a session.
コマンド付番は、セッション全体であり、複数の接続の上の命令されたコマンド配送に使用されます。 また、コマンドフロー制御にセッションの間、メカニズムとしてそれを使用できます。
Satran, et al. Standards Track [Page 19] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[19ページ]。
Status numbering is per connection and is used to enable missing status detection and recovery in the presence of transient or permanent communication errors.
状態付番は、接続単位であって、一時的であるか永久的な通信エラーがあるときなくなった状態検出と回復を可能にするのに使用されます。
Data sequencing is per command or part of a command (R2T triggered sequence) and is used to detect missing data and/or R2T PDUs due to header digest errors.
データ配列は、コマンド(R2Tは系列の引き金となった)のコマンドか一部単位であって、ヘッダーダイジェスト誤りのため欠測値、そして/または、R2T PDUsを検出するのに使用されます。
Typically, fields in the iSCSI PDUs communicate the Sequence Numbers between the initiator and target. During periods when traffic on a connection is unidirectional, iSCSI NOP-Out/In PDUs may be utilized to synchronize the command and status ordering counters of the target and initiator.
通常、iSCSI PDUsの分野は創始者と目標の間のSequence民数記を伝えます。 接続でのトラフィックが単方向である期間、PDUsの外のiSCSI NOP/は、目標と創始者のカウンタを注文するコマンドと状態を同時にさせるのに利用されるかもしれません。
The iSCSI session abstraction is equivalent to the SCSI I_T nexus, and the iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. For detailed design considerations that led to the iSCSI session model as it is defined here and how it relates the SCSI command ordering features defined in SCSI specifications to the iSCSI concepts see [CORD].
iSCSIセッション抽象化はSCSI I_T結びつきに同等です、そして、iSCSIセッションはSCSI創始者からSCSI目標までの命令されたコマンド配送を提供します。 詳細なデザイン問題のために、それはそれがここで定義されるようなiSCSIセッションモデルとそれがどうiSCSI概念への仕様が見るSCSIで特徴を定義するよう命令するSCSIコマンドを関係づけるかに[CORD]通じました。
3.2.2.1. Command Numbering and Acknowledging
3.2.2.1. コマンド付番と承認
iSCSI performs ordered command delivery within a session. All commands (initiator-to-target PDUs) in transit from the initiator to the target are numbered.
iSCSIはセッション以内に命令されたコマンド配送を実行します。 創始者から目標までのトランジットにおけるすべてのコマンド(創始者から目標へのPDUs)が番号付です。
iSCSI considers a task to be instantiated on the target in response to every request issued by the initiator. A set of task management operations including abort and reassign (see Section 10.5 Task Management Function Request) may be performed on any iSCSI task.
iSCSIは、タスクが目標の上に創始者によって出されたあらゆる要求に対応して例示されると考えます。 包含が中止になって、再選任する(セクション10.5 Task Management Function Requestを見ます)タスク管理操作のセットはどんなiSCSIタスクにも実行されるかもしれません。
Some iSCSI tasks are SCSI tasks, and many SCSI activities are related to a SCSI task ([SAM2]). In all cases, the task is identified by the Initiator Task Tag for the life of the task.
いくつかのiSCSIタスクがSCSIタスクです、そして、多くのSCSI活動がSCSIタスク([SAM2])に関連します。 すべての場合では、タスクはタスクの寿命のためにInitiator Task Tagによって特定されます。
The command number is carried by the iSCSI PDU as CmdSN (Command Sequence Number). The numbering is session-wide. Outgoing iSCSI PDUs carry this number. The iSCSI initiator allocates CmdSNs with a 32-bit unsigned counter (modulo 2**32). Comparisons and arithmetic on CmdSN use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
コマンド番号はCmdSN(コマンドSequence Number)としてiSCSI PDUによって運ばれます。 付番はセッション全体です。 出発しているiSCSI PDUsはこの数を運びます。 iSCSI創始者は32ビットの未署名のカウンタ(法2**32)があるCmdSNsを割り当てます。 CmdSNの上の比較と演算は[RFC1982]どこSERIAL_BITS=32に定義されるようにSerial Number Arithmeticを使用するか。
Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. CmdSN does not advance after a command marked for immediate delivery is sent.
即座の配送のために意味されたコマンドは即座の配送旗でマークされます。 また、彼らは現在のCmdSNを運ばなければなりません。 即座の配送のためにマークされたコマンドを送った後にCmdSNは進みません。
Satran, et al. Standards Track [Page 20] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[20ページ]。
Command numbering starts with the first login request on the first connection of a session (the leading login on the leading connection) and command numbers are incremented by 1 for every non-immediate command issued afterwards.
コマンド付番はセッション(主な接続の主なログイン)の最初の接続に関する最初のログイン要求から始まります、そして、コマンド番号はその後発行された各非即座のコマンドあたり1つ増加されます。
If immediate delivery is used with task management commands, these commands may reach the target before the tasks on which they are supposed to act. However their CmdSN serves as a marker of their position in the stream of commands. The initiator and target must ensure that the task management commands act as specified by [SAM2]. For example, both commands and responses appear as if delivered in order. Whenever CmdSN for an outgoing PDU is not specified by an explicit rule, CmdSN will carry the current value of the local CmdSN variable (see later in this section).
即座の配送がタスク管理コマンドと共に使用されるなら、これらのコマンドはそれらが行動するべきであるタスクの前に目標に達するかもしれません。 しかしながら、それらのCmdSNはコマンドのストリームにおけるそれらの位置のマーカーとして機能します。 創始者と目標は、[SAM2]によって指定されるようにタスク管理コマンドが行動するのを保証しなければなりません。 例えば、コマンドと応答の両方がまるで整然とした状態で提供されるかのように見えます。 出発しているPDUのためのCmdSNが明白な規則で指定されないときはいつも、CmdSNはローカルのCmdSN変数の現行価値を運ぶでしょう(後でこのセクションで見てください)。
The means by which an implementation decides to mark a PDU for immediate delivery or by which iSCSI decides by itself to mark a PDU for immediate delivery are beyond the scope of this document.
実装が即座の配送のためにPDUをマークすると決めるか、またはiSCSI自身が即座の配送のためにPDUをマークすると決める手段はこのドキュメントの範囲を超えています。
The number of commands used for immediate delivery is not limited and their delivery for execution is not acknowledged through the numbering scheme. Immediate commands MAY be rejected by the iSCSI target layer due to a lack of resources. An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI command per connection at any time.
即座の配送に使用されるコマンドの数は限られていません、そして、実行のための彼らの配送はナンバリングスキームを通して承諾されません。 即座のコマンドは財源不足のためiSCSI目標層によって拒絶されるかもしれません。 iSCSI目標はいつでも、1接続あたり少なくとも1つの即座のタスク管理コマンドと1つの即座の非タスク管理iSCSIコマンドを扱うことができなければなりません。
In this document, delivery for execution means delivery to the SCSI execution engine or an iSCSI protocol specific execution engine (e.g., for text requests with public or private extension keys involving an execution component). With the exception of the commands marked for immediate delivery, the iSCSI target layer MUST deliver the commands for execution in the order specified by CmdSN. Commands marked for immediate delivery may be delivered by the iSCSI target layer for execution as soon as detected. iSCSI may avoid delivering some commands to the SCSI target layer if required by a prior SCSI or iSCSI action (e.g., CLEAR TASK SET Task Management request received before all the commands on which it was supposed to act).
本書では、実行のための配送はSCSI実行エンジンかiSCSIのプロトコルの特定の実行エンジン(例えば、公共の、または、個人的な拡大キーが実行コンポーネントにかかわっているテキスト要求のための)に配送を意味します。 即座の配送のためにマークされたコマンドを除いて、iSCSI目標層はCmdSNによって指定されたオーダーにおける実行のためのコマンドを提供しなければなりません。 検出されるとき、即座の配送のためにマークされたコマンドは実行のためにiSCSI目標層のそばで提供されるかもしれません。iSCSIは、必要なら先のSCSIかiSCSI動作でSCSI目標層にいくつかのコマンドを提供するのを避けるかもしれません(例えばCLEAR TASK SET Task Management要求はそれが行動するべきであったすべてのコマンドの前に受信されました)。
On any connection, the iSCSI initiator MUST send the commands in increasing order of CmdSN, except for commands that are retransmitted due to digest error recovery and connection recovery.
どんな接続のときにも、iSCSI創始者はCmdSNの注文を増強する際にコマンドを送らなければなりません、ダイジェストエラー回復と接続回復のため再送されるコマンドを除いて。
For the numbering mechanism, the initiator and target maintain the following three variables for each session:
付番メカニズムのために、創始者と目標は以下の各セッションあたり3つの変数を維持します:
Satran, et al. Standards Track [Page 21] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[21ページ]。
- CmdSN - the current command Sequence Number, advanced by 1 on
each command shipped except for commands marked for immediate
delivery. CmdSN always contains the number to be assigned to
the next Command PDU.
- ExpCmdSN - the next expected command by the target. The target
acknowledges all commands up to, but not including, this
number. The initiator treats all commands with CmdSN less than
ExpCmdSN as acknowledged. The target iSCSI layer sets the
ExpCmdSN to the largest non-immediate CmdSN that it can deliver
for execution plus 1 (no holes in the CmdSN sequence).
- MaxCmdSN - the maximum number to be shipped. The queuing
capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN +
1.
- CmdSN--即座の配送のためにマークされたコマンドを除いて、出荷された各コマンドのときに1時までに進められた現在のコマンドSequence Number。 CmdSNはいつも次のCommand PDUに割り当てられる数を含んでいます。 - ExpCmdSN--目標による次の予想されたコマンド。 目標は、すべてが命令すると認めますが、包含、この数は認めません。 創始者はExpCmdSNより承認されるとしてCmdSNとのすべてのコマンドを扱うというわけではありません。 目標iSCSI層は実行と1(CmdSN系列で穴がない)のために提供できる中で最も大きい非即座のCmdSNにExpCmdSNを設定します。 - MaxCmdSN--出荷される最大数。 受信iSCSI層の列を作り容量はMaxCmdSNです--ExpCmdSN+1。
The initiator's ExpCmdSN and MaxCmdSN are derived from target-to-initiator PDU fields. Comparisons and arithmetic on ExpCmdSN and MaxCmdSN MUST use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
目標から創始者へのPDU分野から創始者のExpCmdSNとMaxCmdSNを得ます。 ExpCmdSNとMaxCmdSNの上の比較と演算は[RFC1982]どこSERIAL_BITS=32に定義されるようにSerial Number Arithmeticを使用しなければならないか。
The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1. For non-immediate commands, the CmdSN field can take any value from ExpCmdSN to MaxCmdSN inclusive. The target MUST silently ignore any non-immediate command outside of this range or non- immediate duplicates within the range. The CmdSN carried by immediate commands may lie outside the ExpCmdSN to MaxCmdSN range. For example, if the initiator has previously sent a non-immediate command carrying the CmdSN equal to MaxCmdSN, the target window is closed. For group task management commands issued as immediate commands, CmdSN indicates the scope of the group action (e.g., on ABORT TASK SET indicates which commands are aborted).
目標はExpCmdSN-1以下であるMaxCmdSNを伝えてはいけません。 非即座のコマンドのために、CmdSN分野はExpCmdSNからMaxCmdSNまで包括的にどんな値も取ることができます。 目標は静かにこの範囲か非即座の外部が範囲の中にコピーするどんな非即座のコマンドも無視しなければなりません。 ExpCmdSNの外にMaxCmdSN範囲には即座のコマンドで運ばれたCmdSNがいるかもしれません。 例えば、創始者が非即座のコマンドに以前にMaxCmdSNと等しいCmdSNを運ばせたなら、目標ウィンドウは閉じられます。 即座のコマンドとして発行されたグループタスク管理コマンドのために、CmdSNは集団行動(例えば、ABORT TASK SETでは、どのコマンドが中止されるかを示す)の範囲を示します。
MaxCmdSN and ExpCmdSN fields are processed by the initiator as follows:
MaxCmdSNとExpCmdSN分野は以下の創始者によって処理されます:
- If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial
Arithmetic Sense), they are both ignored.
- If the PDU MaxCmdSN is greater than the local MaxCmdSN (in
Serial Arithmetic Sense), it updates the local MaxCmdSN;
otherwise, it is ignored.
- If the PDU ExpCmdSN is greater than the local ExpCmdSN (in
Serial Arithmetic Sense), it updates the local ExpCmdSN;
otherwise, it is ignored.
- PDU MaxCmdSNがPDU ExpCmdSN-1以下(Serial Arithmetic Senseで)であるなら、それらはともに無視されます。 - PDU MaxCmdSNが地方のMaxCmdSN(Serial Arithmetic Senseの)より大きいなら、地方のMaxCmdSNをアップデートします。 さもなければ、それは無視されます。 - PDU ExpCmdSNが地方のExpCmdSN(Serial Arithmetic Senseの)より大きいなら、地方のExpCmdSNをアップデートします。 さもなければ、それは無視されます。
This sequence is required because updates may arrive out of order (e.g., the updates are sent on different TCP connections).
アップデートが故障していた状態で到着するかもしれないので(異なったTCP接続に例えばアップデートを送ります)、この系列が必要です。
iSCSI initiators and targets MUST support the command numbering scheme.
iSCSI創始者と目標は、コマンドがナンバリングスキームであるとサポートしなければなりません。
Satran, et al. Standards Track [Page 22] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[22ページ]。
A numbered iSCSI request will not change its allocated CmdSN, regardless of the number of times and circumstances in which it is reissued (see Section 6.2.1 Usage of Retry). At the target, CmdSN is only relevant when the command has not created any state related to its execution (execution state); afterwards, CmdSN becomes irrelevant. Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target. If no execution state is found, it is followed by ordering and delivery. If an execution state is found, it is followed by delivery.
番号付のiSCSI要求は割り当てられたCmdSNを変えないでしょう、回数とそれが再発行される事情にかかわらず(Retryのセクション6.2.1Usageを見てください)。 コマンドが実行(実行状態)に関連する少しの状態も創設していないとき、単に目標では、CmdSNは関連しています。 その後、CmdSNは無関係になります。 実行状態(Initiator Task Tagを特定しながら、表す)がないかどうかテストするのは目標でいかなる他の動作にも先行しなければなりません。 実行状態が全く見つけられないなら、注文と配送はそれのあとに続いています。 実行状態が見つけられるなら、配送はそれのあとに続いています。
If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN value is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational (i.e., it has returned to the FREE state, see Section 7.1.3 Standard Connection State Diagram for an Initiator), the connection has been reinstated (see Section 5.3.4 Connection Reinstatement), or a non-immediate command with CmdSN equal or greater than Q was issued subsequent to the command retry on the same connection and the reception of that command is acknowledged by the target (see Section 9.4 Command Retry and Cleaning Old Command Instances).
セッションCmdSN価値がQであるときに、創始者が接続でのCmdSN Rとのコマンドのためのコマンド再試行を発行するなら、**31 -1 接続がもう操作上であるなら(無料状態に戻りました、とInitiatorのためのセクション7.1.3Standard Connection州Diagramは見ます)、それはR+2を超えてCmdSNを進めてはいけません; 接続が復職したか(セクション5.3.4Connection Reinstatementを見てください)、または同じ接続のコマンド再試行とそのコマンドのレセプションへのQが発行されたより等しいかすばらしいCmdSNがその後での非即座のコマンドは目標によって承諾されます(セクション9.4 Command RetryとCleaning Old Command Instancesを見てください)。
A target MUST NOT issue a command response or Data-In PDU with status before acknowledging the command. However, the acknowledgement can be included in the response or Data-In PDU.
目標はコマンドを承諾する前の状態があるコマンド応答か中のData PDUを発行してはいけません。 しかしながら、応答か中のData PDUに承認を含むことができます。
3.2.2.2. Response/Status Numbering and Acknowledging
3.2.2.2. 応答/状態付番と承認
Responses in transit from the target to the initiator are numbered. The StatSN (Status Sequence Number) is used for this purpose. StatSN is a counter maintained per connection. ExpStatSN is used by the initiator to acknowledge status. The status sequence number space is 32-bit unsigned-integers and the arithmetic operations are the regular mod(2**32) arithmetic.
目標から創始者までのトランジットにおける応答は番号付です。 StatSN(状態Sequence Number)はこのために使用されます。 StatSNは接続単位で維持されたカウンタです。 ExpStatSNは、状態を承認するのに創始者によって使用されます。 状態一連番号スペースは32ビットの符号のない整数です、そして、四則演算はレギュラーのモッズ(2**32)演算です。
Status numbering starts with the Login response to the first Login request of the connection. The Login response includes an initial value for status numbering (any initial value is valid).
状態付番は接続の最初のLogin要求へのLogin応答から始まります。 Login応答は状態付番のための初期の値を含んでいます(どんな初期の値も有効です)。
To enable command recovery, the target MAY maintain enough state information for data and status recovery after a connection failure. A target doing so can safely discard all of the state information maintained for recovery of a command after the delivery of the status for the command (numbered StatSN) is acknowledged through ExpStatSN.
コマンド回復を可能にするために、目標は、十分が接続失敗の後にデータと状態回復のための情報を述べると主張するかもしれません。 そうする目標は安全にコマンド(StatSNに付番する)のための状態の配送がExpStatSNを通して承諾された後にコマンドの回復のために保守された州の情報のすべてを捨てることができます。
A large absolute difference between StatSN and ExpStatSN may indicate a failed connection. Initiators MUST undertake recovery actions if
StatSNとExpStatSNの大きい絶対違いは失敗した接続を示すかもしれません。 創始者は回復動作を引き受けなければなりません。
Satran, et al. Standards Track [Page 23] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[23ページ]。
the difference is greater than an implementation defined constant that MUST NOT exceed 2**31-1.
違いは実装が2**31-1を超えてはいけない定数を定義したより大きいです。
Initiators and Targets MUST support the response-numbering scheme.
創始者とTargetsは応答ナンバリングスキームをサポートしなければなりません。
3.2.2.3. Data Sequencing
3.2.2.3. データ配列
Data and R2T PDUs transferred as part of some command execution MUST be sequenced. The DataSN field is used for data sequencing. For input (read) data PDUs, DataSN starts with 0 for the first data PDU of an input command and advances by 1 for each subsequent data PDU. For output data PDUs, DataSN starts with 0 for the first data PDU of a sequence (the initial unsolicited sequence or any data PDU sequence issued to satisfy an R2T) and advances by 1 for each subsequent data PDU. R2Ts are also sequenced per command. For example, the first R2T has an R2TSN of 0 and advances by 1 for each subsequent R2T. For bidirectional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated). Unlike command and status, data PDUs and R2Ts are not acknowledged by a field in regular outgoing PDUs. Data-In PDUs can be acknowledged on demand by a special form of the SNACK PDU. Data and R2T PDUs are implicitly acknowledged by status for the command. The DataSN/R2TSN field enables the initiator to detect missing data or R2T PDUs.
データとR2T PDUsは、何らかのコマンド実行の一部を配列しなければならないので、移しました。 DataSN分野はデータ配列に使用されます。 入力(読む)データPDUsに関しては、DataSNは入力コマンドの最初のデータPDUのために0から始まって、それぞれの順次データPDUのために1時までに進みます。 出力データPDUsに関しては、DataSNは系列(R2Tを満たすために発行された初期の求められていない系列かどんなデータPDU系列も)の最初のデータPDUのために0から始まって、それぞれの順次データPDUのために1時までに進みます。 また、R2Tsはコマンド単位で配列されます。 例えば、最初のR2Tは0のR2TSNを持って、それぞれのその後のR2Tあたり1時までに進みます。 双方向のコマンドのために、目標は1つの連続した系列(非差別化した)に中の系列DataとR2T PDUsにDataSN/R2TSNを使用します。 コマンドと状態と異なって、データPDUsとR2Tsは通常の出発しているPDUsの分野によって承認されません。 SNACK PDUの特別なフォームは要求に応じて中のデータPDUsを承認できます。 データとR2T PDUsはコマンドのために状態によってそれとなく承認されます。 DataSN/R2TSN分野は、創始者が欠測値かR2T PDUsを検出するのを可能にします。
For any read or bidirectional command, a target MUST issue less than 2**32 combined R2T and Data-In PDUs. Any output data sequence MUST contain less than 2**32 Data-Out PDUs.
いずれも読むか、または双方向のコマンド、目標が2**32の結合したR2Tと中のData PDUsを発行しなければならないので。 どんな出力データ系列も2**32外のData PDUs以下を含まなければなりません。
3.2.3. iSCSI Login
3.2.3. iSCSIはログインします。
The purpose of the iSCSI login is to enable a TCP connection for iSCSI use, authentication of the parties, negotiation of the session's parameters and marking of the connection as belonging to an iSCSI session.
iSCSIログインの目的はiSCSIセッションに属するとしてiSCSI使用のためのTCP接続、パーティーの認証、セッションの接続のパラメタとマークの交渉を可能にすることです。
A session is used to identify to a target all the connections with a given initiator that belong to the same I_T nexus. (For more details on how a session relates to an I_T nexus, see Section 3.4.2 SCSI Architecture Model).
セッションは、当然のことの創始者との同じI_T結びつきに属すすべての接続を目標に特定するのに使用されます。 (セッションがどうI_T結びつきに関連するかに関するその他の詳細に関して、セクション3.4.2SCSI Architecture Modelを見てください。)
The targets listen on a well-known TCP port or other TCP port for incoming connections. The initiator begins the login process by connecting to one of these TCP ports.
目標は接続要求のためによく知られるTCPポートか他のTCPポートの上で聴かれます。 創始者は、これらのTCPポートの1つに接続することによって、ログインプロセスを開始します。
As part of the login process, the initiator and target SHOULD authenticate each other and MAY set a security association protocol for the session. This can occur in many different ways and is subject to negotiation.
ログインプロセスの一部として、創始者と目標SHOULDは互いを認証して、セッションのためにセキュリティ協会プロトコルを設定するかもしれません。 これは、多くの異なった方法で起こることができて、交渉を受けることがあります。
Satran, et al. Standards Track [Page 24] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[24ページ]。
To protect the TCP connection, an IPsec security association MAY be established before the Login request. For information on using IPsec security for iSCSI see Chapter 8 and [RFC3723].
TCP接続を保護するために、IPsecセキュリティ協会はLogin要求の前に設立されるかもしれません。 iSCSIにIPsecセキュリティを使用することの情報に関しては、第8章と[RFC3723]を参照してください。
The iSCSI Login Phase is carried through Login requests and responses. Once suitable authentication has occurred and operational parameters have been set, the session transitions to the Full Feature Phase and the initiator may start to send SCSI commands. The security policy for whether, and by what means, a target chooses to authorize an initiator is beyond the scope of this document. For a more detailed description of the Login Phase, see Chapter 5.
iSCSI Login PhaseはLogin要求と応答で運ばれます。 いったん適当な認証が起こって、操作上のパラメタが設定されると、Full Feature Phaseと創始者へのセッション変遷は、コマンドをSCSIに送り始めるかもしれません。 安全保障政策、目標が、創始者に権限を与えるのを選ぶことを意味することで、このドキュメントの範囲を超えています。 Login Phaseの、より詳細な記述に関しては、第5章を参照してください。
The login PDU includes the ISID part of the session ID (SSID). The target portal group that services the login is implied by the selection of the connection endpoint. For a new session, the TSIH is zero. As part of the response, the target generates a TSIH.
ログインPDUはセッションID(SSID)のISID部分を含んでいます。 ログインを修理する目標入り口のグループは接続終点の選択で含意されます。 新しいセッションのために、TSIHはゼロです。 応答の一部として、目標はTSIHを生成します。
During session establishment, the target identifies the SCSI initiator port (the "I" in the "I_T nexus") through the value pair (InitiatorName, ISID). We describe InitiatorName later in this section. Any persistent state (e.g., persistent reservations) on the target that is associated with a SCSI initiator port is identified based on this value pair. Any state associated with the SCSI target port (the "T" in the "I_T nexus") is identified externally by the TargetName and portal group tag (see Section 3.4.1 iSCSI Architecture Model). ISID is subject to reuse restrictions because it is used to identify a persistent state (see Section 3.4.3 Consequences of the Model).
セッション設立の間、目標は値の組(InitiatorName、ISID)を通してSCSI創始者ポート(「I_T結びつき」における「I」)を特定します。 私たちは後でこのセクションでInitiatorNameについて説明します。 SCSI創始者ポートに関連している目標のどんな永続的な状態(例えば、永続的な予約)もこの値の組に基づいて特定されます。 SCSI目標ポート(「I_T結びつき」における「T」)に関連しているどんな状態もTargetNameと入り口のグループタグによって外部的に特定されます(セクション3.4.1iSCSIアーキテクチャモデルを見てください)。 それが永続的な状態を特定するのに使用されるので(Modelのセクション3.4.3Consequencesを見てください)、ISIDは再利用制限を受けることがあります。
Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. Login requests and responses MUST be used exclusively during Login. On any connection, the login phase MUST immediately follow TCP connection establishment and a subsequent Login Phase MUST NOT occur before tearing down a connection.
Full Feature Phaseが設立される前に、Login RequestとLogin Response PDUsだけが許容されています。 排他的にLoginの間、ログイン要求と応答を使用しなければなりません。 どんな接続のときにも、ログインフェーズはすぐにTCPコネクション確立に続かなければなりません、そして、接続を取りこわす前に、その後のLogin Phaseは起こってはいけません。
A target receiving any PDU except a Login request before the Login phase is started MUST immediately terminate the connection on which the PDU was received. Once the Login phase has started, if the target receives any PDU except a Login request, it MUST send a Login reject (with Status "invalid during login") and then disconnect. If the initiator receives any PDU except a Login response, it MUST immediately terminate the connection.
Loginフェーズが始められる前にLogin要求以外のどんなPDUも受ける目標はすぐに、PDUが受け取られた接続を終えなければなりません。 目標が何かLogin要求以外のPDUを受けるなら一度、Loginフェーズが始まったことがあって、それは、Login廃棄物(「ログインの間、無効」のStatusと)を送って、次に、切断しなければなりません。 創始者が何かLogin応答以外のPDUを受け取るなら、それはすぐに、接続を終えなければなりません。
3.2.4. iSCSI Full Feature Phase
3.2.4. iSCSIの完全な特徴フェーズ
Once the initiator is authorized to do so, the iSCSI session is in the iSCSI Full Feature Phase. A session is in Full Feature Phase after successfully finishing the Login Phase on the first (leading)
創始者がそうするのにいったん権限を与えられると、iSCSIセッションがiSCSI Full Feature Phaseにあります。 1日に首尾よくLogin Phaseを終えた後に、セッションがFull Feature Phaseにあります。(先導)
Satran, et al. Standards Track [Page 25] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[25ページ]。
connection of a session. A connection is in Full Feature Phase if the session is in Full Feature Phase and the connection login has completed successfully. An iSCSI connection is not in Full Feature Phase
セッションの接続。 セッションがログインが首尾よく終了したFull Feature Phaseと接続中であるなら、接続がFull Feature Phaseにあります。 iSCSI接続がFull Feature Phaseにありません。
a) when it does not have an established transport connection,
a) それに確立した輸送接続がないとき
OR
OR
b) when it has a valid transport connection, but a successful
login was not performed or the connection is currently logged
out.
b) いつ、それには有効な輸送接続がありますが、うまくいっているログインが実行されなかったか、そして、接続が現在、ログアウトされます。
In a normal Full Feature Phase, the initiator may send SCSI commands and data to the various LUs on the target by encapsulating them in iSCSI PDUs that go over the established iSCSI session.
正常なFull Feature Phaseでは、創始者は、確立したiSCSIセッションの間に行くiSCSI PDUsで彼らをカプセル化することによって、目標の上の様々なLUsにSCSIコマンドとデータを送るかもしれません。
3.2.4.1. Command Connection Allegiance
3.2.4.1. コマンド接続忠誠
For any iSCSI request issued over a TCP connection, the corresponding response and/or other related PDU(s) MUST be sent over the same connection. We call this "connection allegiance". If the original connection fails before the command is completed, the connection allegiance of the command may be explicitly reassigned to a different transport connection as described in detail in Section 6.2 Retry and Reassign in Recovery.
TCP接続の上で出されたどんなiSCSI要求においても、対応する応答、そして/または、他の関連するPDU(s)を同じ接続の上に送らなければなりません。 私たちは、これを「接続忠誠」と呼びます。 コマンドが終了する前にオリジナルの接続が失敗するなら、コマンドの接続忠誠はセクション6.2 RecoveryのRetryとReassignで詳細に説明されるように明らかに異なった輸送接続に再選任されるかもしれません。
Thus, if an initiator issues a READ command, the target MUST send the requested data, if any, followed by the status to the initiator over the same TCP connection that was used to deliver the SCSI command. If an initiator issues a WRITE command, the initiator MUST send the data, if any, for that command over the same TCP connection that was used to deliver the SCSI command. The target MUST return Ready To Transfer (R2T), if any, and the status over the same TCP connection that was used to deliver the SCSI command. Retransmission requests (SNACK PDUs) and the data and status that they generate MUST also use the same connection.
したがって、創始者がREADコマンドを発行するなら、目標はもしあれば要求されたデータを送らなければなりません、続いて、SCSIコマンドを提供するのに使用されたのと同じTCP接続の上で状態を創始者に送ります。 創始者がWRITEコマンドを発行するなら、創始者はデータを送らなければなりません、もしあれば、SCSIコマンドを提供するのに使用された同じTCP接続の上のそのコマンドのために。 目標はSCSIコマンドを提供するのに使用されたのと同じTCP接続の上にもしあればReady To Transfer(R2T)と状態を返さなければなりません。 また、それらが生成するRetransmission要求(SNACK PDUs)、データ、および状態は同じ接続を使用しなければなりません。
However, consecutive commands that are part of a SCSI linked command-chain task (see [SAM2]) MAY use different connections. Connection allegiance is strictly per-command and not per-task. During the iSCSI Full Feature Phase, the initiator and target MAY interleave unrelated SCSI commands, their SCSI Data, and responses over the session.
しかしながら、SCSIの繋がっているコマンドチェーンタスク([SAM2]を見る)の一部である連続したコマンドは異なった接続を使用するかもしれません。 接続忠誠がタスクではなく、厳密なコマンド単位であります。 iSCSI Full Feature Phaseの間、創始者と目標はセッションの間の関係ないSCSIコマンド、それらのSCSI Data、および応答をはさみ込むかもしれません。
Satran, et al. Standards Track [Page 26] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[26ページ]。
3.2.4.2. Data Transfer Overview
3.2.4.2. データ転送概要
Outgoing SCSI data (initiator to target user data or command
parameters) is sent as either solicited data or unsolicited data.
Solicited data are sent in response to R2T PDUs. Unsolicited data
can be sent as part of an iSCSI command PDU ("immediate data") or in
separate iSCSI data PDUs.
どちらかがデータか求められていないデータに請求したので、送信するSCSIデータ(利用対象者データかコマンドパラメタへの創始者)を送ります。 R2T PDUsに対応して請求されたデータを送ります。 iSCSIコマンドPDU(「即値データ」)の一部か別々のiSCSIデータPDUsで求められていないデータを送ることができます。
Immediate data are assumed to originate at offset 0 in the initiator SCSI write-buffer (outgoing data buffer). All other Data PDUs have the buffer offset set explicitly in the PDU header.
即座のデータがオフセット0時に創始者SCSIでバッファを書いて(発信データバッファ)起因すると思われます。 他のすべてのData PDUsがPDUヘッダーに明らかにバッファオフセットをはめ込ませます。
An initiator may send unsolicited data up to FirstBurstLength as immediate (up to the negotiated maximum PDU length), in a separate PDU sequence or both. All subsequent data MUST be solicited. The maximum length of an individual data PDU or the immediate-part of the first unsolicited burst MAY be negotiated at login.
創始者は即座(交渉された最大のPDUの長さまでの)として求められていないデータをFirstBurstLengthまで送るかもしれません、別々のPDU系列か両方で。 すべての順次データに請求しなければなりません。 個々のデータPDUの最大の長さか最初の求められていない炸裂の即座の部分がログインで交渉されるかもしれません。
The maximum amount of unsolicited data that can be sent with a command is negotiated at login through the FirstBurstLength key. A target MAY separately enable immediate data (through the ImmediateData key) without enabling the more general (separate data PDUs) form of unsolicited data (through the InitialR2T key).
コマンドと共に送ることができる最大の量の求められていないデータがFirstBurstLengthキーを通したログインで交渉されます。 より一般的な(別々のデータPDUs)フォームの求められていないデータ(InitialR2Tキーを通した)を可能にしないで、目標は別々に、即値データ(ImmediateDataキーを通した)を可能にするかもしれません。
Unsolicited data on write are meant to reduce the effect of latency on throughput (no R2T is needed to start sending data). In addition, immediate data is meant to reduce the protocol overhead (both bandwidth and execution time).
書いてください。求められていないデータ、オンである、スループット(R2Tは全くデータを送り始められる必要はない)への潜在の効果を減少させることが意味されます。 さらに、即値データはプロトコルオーバーヘッド(帯域幅と実行時間の両方)を下げることになっています。
An iSCSI initiator MAY choose not to send unsolicited data, only immediate data or FirstBurstLength bytes of unsolicited data with a command. If any non-immediate unsolicited data is sent, the total unsolicited data MUST be either FirstBurstLength, or all of the data if the total amount is less than the FirstBurstLength.
iSCSI創始者は、求められていないデータ(コマンドがある即値データかFirstBurstLengthバイトの求められていないデータだけ)を送らないのを選ぶかもしれません。 何か非即座の求められていないデータを送るなら、総量がFirstBurstLength以下であるなら、総求められていないデータは、データのFirstBurstLengthかすべてのどちらかであるに違いありません。
It is considered an error for an initiator to send unsolicited data PDUs to a target that operates in R2T mode (only solicited data are allowed). It is also an error for an initiator to send more unsolicited data, whether immediate or as separate PDUs, than FirstBurstLength.
創始者がR2Tモードで作動する目標に求められていないデータPDUsを送るように、それは誤りであると考えられます(請求されたデータだけが許容されています)。 また、それは創始者が、より求められていないデータを送る誤りです、即座であるか、またはPDUsを切り離すとき、FirstBurstLengthより。
An initiator MUST honor an R2T data request for a valid outstanding command (i.e., carrying a valid Initiator Task Tag) and deliver all the requested data provided the command is supposed to deliver outgoing data and the R2T specifies data within the command bounds. The initiator action is unspecified for receiving an R2T request that specifies data, all or part, outside of the bounds of the command.
コマンドが発信データを提供するべきであり、R2Tがコマンド領域の中でデータを指定するなら、創始者は、有効な傑出しているコマンド(すなわち、有効なInitiator Task Tagを運ぶ)を求めるR2Tデータ要求を光栄に思って、すべての要求されたデータを提供しなければなりません。 データ、すべてまたは部分(コマンドの領域の外部)を指定するR2T要求を受け取るのに、創始者動きは不特定です。
Satran, et al. Standards Track [Page 27] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[27ページ]。
A target SHOULD NOT silently discard data and then request retransmission through R2T. Initiators SHOULD NOT keep track of the data transferred to or from the target (scoreboarding). SCSI targets perform residual count calculation to check how much data was actually transferred to or from the device by a command. This may differ from the amount the initiator sent and/or received for reasons such as retransmissions and errors. Read or bidirectional commands implicitly solicit the transmission of the entire amount of data covered by the command. SCSI data packets are matched to their corresponding SCSI commands by using tags specified in the protocol.
目標SHOULD NOTは静かにデータを捨てて、次に、R2Tを通して「再-トランスミッション」を要求します。 創始者SHOULD NOTは目標か目標(scoreboarding)から移されたデータの動向をおさえます。 SCSI目標は、どのくらいのデータが実際にデバイスかデバイスから移されたかをコマンドでチェックするために残りのカウント計算を実行します。 これは創始者が「再-トランスミッション」や誤りなどの理由で送る、そして/または、受けた量と異なるかもしれません。 読んでください。さもないと、双方向のコマンドはそれとなくコマンドでカバーされた全体のデータ量の送信に請求します。 SCSIデータ・パケットは、プロトコルで指定されたタグを使用することによって、彼らの対応するSCSIコマンドに合わせられています。
In addition, iSCSI initiators and targets MUST enforce some ordering rules. When unsolicited data is used, the order of the unsolicited data on each connection MUST match the order in which the commands on that connection are sent. Command and unsolicited data PDUs may be interleaved on a single connection as long as the ordering requirements of each are maintained (e.g., command N+1 MAY be sent before the unsolicited Data-Out PDUs for command N, but the unsolicited Data-Out PDUs for command N MUST precede the unsolicited Data-Out PDUs of command N+1). A target that receives data out of order MAY terminate the session.
さらに、規則を注文して、iSCSI創始者と目標はいくつかを実施しなければなりません。 求められていないデータが使用されているとき、各接続の求められていないデータの注文はその接続のコマンドが送られるオーダーに合わなければなりません。 それぞれの注文要件が維持される(コマンドNがコマンドN+1の求められていない外のData PDUsに先行しなければならないので、しかし、コマンドN、求められていない外のData PDUsのために求められていない外のData PDUsの前に例えばコマンドN+1を送るかもしれません)限り、コマンドと求められていないデータPDUsは単独結合ではさみ込まれるかもしれません。 故障していた状態でデータを受け取る目標はセッションを終えるかもしれません。
3.2.4.3. Tags and Integrity Checks
3.2.4.3. タグと保全チェック
Initiator tags for pending commands are unique initiator-wide for a session. Target tags are not strictly specified by the protocol. It is assumed that target tags are used by the target to tag (alone or in combination with the LUN) the solicited data. Target tags are generated by the target and "echoed" by the initiator. These mechanisms are designed to accomplish efficient data delivery along with a large degree of control over the data flow.
未定のコマンドのための創始者タグはセッションのために創始者全体でユニークです。 目標タグはプロトコルによって厳密に指定されません。 目標タグが目標によって使用されて、請求されたデータにタグ付けをする(単独かLUNと組み合わせて)と思われます。 目標タグは、目標によって生成されて、創始者によって「反響されます」。 これらのメカニズムは、データフローの上で大きい統制度に伴う効率的なデータ配送を実行するように設計されています。
As the Initiator Task Tag is used to identify a task during its execution, the iSCSI initiator and target MUST verify that all other fields used in task-related PDUs have values that are consistent with the values used at the task instantiation based on the Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the one used in the SCSI command PDU used to instantiate the task). Using inconsistent field values is considered a protocol error.
Initiator Task Tagが実行の間、タスクを特定するのに使用されるとき、iSCSI創始者と目標は、タスク関連のPDUsで使用される他のすべての分野がInitiator Task Tagに基づくタスク具体化に使用される値と一致した値を持っていることを確かめなければなりません(例えばものと同じくらいがSCSIコマンドPDUで使用されていたならR2T PDU MUSTで使用されるLUNは以前はよくタスクを例示していました)。 矛盾した分野値を使用するのはプロトコル誤りであると考えられます。
3.2.4.4. Task Management
3.2.4.4. タスク管理
SCSI task management assumes that individual tasks and task groups can be aborted solely based on the task tags (for individual tasks) or the timing of the task management command (for task groups), and that the task management action is executed synchronously - i.e., no message involving an aborted task will be seen by the SCSI initiator after receiving the task management response. In iSCSI initiators
SCSIタスク管理は、唯一タスクタグ(個々のタスクのための)かタスク管理コマンドのタイミング(任務群のための)に基づいて個々のタスクと任務群を中止できて、タスク管理動作が同時実行されると仮定します--タスク管理応答を受けた後に、すなわち、中止になっているタスクにかかわるメッセージが全くSCSI創始者によって見られないでしょう。 iSCSI創始者で
Satran, et al. Standards Track [Page 28] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[28ページ]。
and targets interact asynchronously over several connections. iSCSI specifies the protocol mechanism and implementation requirements needed to present a synchronous view while using an asynchronous infrastructure.
そして、目標はいくつかの接続の上に非同期に相互作用します。iSCSIは非同期なインフラストラクチャを使用している間、同期視点を提示するのに必要であるプロトコルメカニズムと実装要件を指定します。
3.2.5. iSCSI Connection Termination
3.2.5. iSCSI接続終了
An iSCSI connection may be terminated by use of a transport connection shutdown or a transport reset. Transport reset is assumed to be an exceptional event.
iSCSI接続は輸送接続閉鎖か輸送リセットの使用で終えられるかもしれません。 輸送リセットは例外的なイベントであると思われます。
Graceful TCP connection shutdowns are done by sending TCP FINs. A graceful transport connection shutdown SHOULD only be initiated by either party when the connection is not in iSCSI Full Feature Phase. A target MAY terminate a Full Feature Phase connection on internal exception events, but it SHOULD announce the fact through an Asynchronous Message PDU. Connection termination with outstanding commands may require recovery actions.
TCP FINsを送ることによって、優雅なTCP接続閉鎖をします。 接続閉鎖SHOULDを輸送してください。A優雅である、接続がiSCSI Full Feature Phaseのそうでない何れの当事者によって単に開始されてください。 目標はしかし、内部の例外イベント、それでFull Feature Phase接続を終えるかもしれません。SHOULDはAsynchronous Message PDUを通して事実を発表します。 傑出しているコマンドによる接続終了は回復動作を必要とするかもしれません。
If a connection is terminated while in Full Feature Phase, connection cleanup (see section 7) is required prior to recovery. By doing connection cleanup before starting recovery, the initiator and target will avoid receiving stale PDUs after recovery.
接続クリーンアップ(セクション7を見る)が回復の前にFull Feature Phaseで必要ですが、接続が終えられるなら。 回復を始める前に接続クリーンアップをすることによって、創始者と目標は、回復の後に聞き古したPDUsを受けるのを避けるでしょう。
3.2.6. iSCSI Names
3.2.6. iSCSI名
Both targets and initiators require names for the purpose of identification. In addition, names enable iSCSI storage resources to be managed regardless of location (address). An iSCSI node name is also the SCSI device name of an iSCSI device. The iSCSI name of a SCSI device is the principal object used in authentication of targets to initiators and initiators to targets. This name is also used to identify and manage iSCSI storage resources.
目標と創始者の両方が識別の目的のために名前を必要とします。 さらに、名前は、iSCSIストレージリソースが位置(アドレス)にかかわらず管理されるのを可能にします。 また、iSCSIノード名はiSCSIデバイスのSCSI装置名です。 SCSIデバイスのiSCSI名は目標への目標の認証に創始者と創始者に使用される主眼です。 また、この名前は、iSCSIストレージリソースを特定して、管理するのに使用されます。
iSCSI names must be unique within the operational domain of the end user. However, because the operational domain of an IP network is potentially worldwide, the iSCSI name formats are architected to be worldwide unique. To assist naming authorities in the construction of worldwide unique names, iSCSI provides two name formats for different types of naming authorities.
iSCSI名はエンドユーザの操作上のドメインの中でユニークであるに違いありません。 IPネットワークの操作上のドメインが潜在的に世界的であるので、しかしながら、iSCSI名前形式は世界中にあるようにarchitectedされます。ユニーク。 世界的なユニークな名前の構造で当局を任命するのを補助するために、iSCSIは当局を任命する異なったタイプに2つの名前形式を提供します。
iSCSI names are associated with iSCSI nodes, and not iSCSI network adapter cards, to ensure that the replacement of network adapter cards does not require reconfiguration of all SCSI and iSCSI resource allocation information.
iSCSI名は、ネットワークアダプターカードの交換がすべてのSCSIとiSCSI資源配分情報の再構成を必要としないのを保証するためにiSCSIネットワークアダプターカードではなく、iSCSIノードに関連しています。
Satran, et al. Standards Track [Page 29] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[29ページ]。
Some SCSI commands require that protocol-specific identifiers be communicated within SCSI CDBs. See Section 3.4.2 SCSI Architecture Model for the definition of the SCSI port name/identifier for iSCSI ports.
いくつかのSCSIコマンドが、プロトコル特有の識別子がSCSI CDBsの中で伝えられるのを必要とします。 iSCSIポートのためのSCSIポート名前/識別子の定義に関してセクション3.4.2SCSI Architecture Modelを見てください。
An initiator may discover the iSCSI Target Names to which it has access, along with their addresses, using the SendTargets text request, or other techniques discussed in [RFC3721].
創始者はそれがアクセスを持っているiSCSI Target Namesを発見するかもしれません、彼らのアドレスと共に、SendTargetsテキスト要求、または[RFC3721]で議論した他のテクニックを使用して。
3.2.6.1. iSCSI Name Properties
3.2.6.1. iSCSI名前の特性
Each iSCSI node, whether an initiator or target, MUST have an iSCSI name.
それぞれのiSCSIノードには、創始者か目標であることにかかわらずiSCSI名がなければなりません。
Initiators and targets MUST support the receipt of iSCSI names of up to the maximum length of 223 bytes.
創始者と目標は最大223バイトの長さのiSCSI名の領収書を支えなければなりません。
The initiator MUST present both its iSCSI Initiator Name and the iSCSI Target Name to which it wishes to connect in the first login request of a new session or connection. The only exception is if a discovery session (see Section 2.3 iSCSI Session Types) is to be established. In this case, the iSCSI Initiator Name is still required, but the iSCSI Target Name MAY be omitted.
創始者はそれが新しいセッションか接続の最初のログイン要求で接続したがっているiSCSI Initiator NameとiSCSI Target Nameの両方を寄贈しなければなりません。 唯一の例外は発見セッション(セクション2.3 iSCSI Session Typesを見る)が設立されるかどうかことであるということです。 この場合、iSCSI Initiator Nameがまだ必要ですが、iSCSI Target Nameは省略されるかもしれません。
iSCSI names have the following properties:
iSCSI名には、以下の特性があります:
a) iSCSI names are globally unique. No two initiators or targets
can have the same name.
b) iSCSI names are permanent. An iSCSI initiator node or target
node has the same name for its lifetime.
c) iSCSI names do not imply a location or address. An iSCSI
initiator or target can move, or have multiple addresses. A
change of address does not imply a change of name.
d) iSCSI names do not rely on a central name broker; the naming
authority is distributed.
e) iSCSI names support integration with existing unique naming
schemes.
f) iSCSI names rely on existing naming authorities. iSCSI does
not create any new naming authority.
a) iSCSI名はグローバルにユニークです。 どんな2人の創始者も目標も同じ名前を持つことができません。b)iSCSI名は永久的です。 iSCSI創始者ノードか目標ノードが同じ名前を生涯に持っています。c)iSCSI名は位置かアドレスを含意しません。 iSCSI創始者か目標が、複数のアドレスを動くか、または持つことができます。 住所の変更は名義変更を含意しません。d)iSCSI名は主要な名前ブローカーに頼りません。 命名権威は広げられます。e)iSCSI名は存在がユニークの体系iSCSI名が当てにする当局を任命しながら存在するf)を命名する統合をサポートします。iSCSIは少しの新しい命名権威も作成しません。
The encoding of an iSCSI name has the following properties:
iSCSI名のコード化には、以下の特性があります:
a) iSCSI names have the same encoding method regardless of the
underlying protocols.
b) iSCSI names are relatively simple to compare. The algorithm
for comparing two iSCSI names for equivalence does not rely on
an external server.
iSCSI名には、基本的なプロトコルにかかわらずメソッドをコード化する同じくらいがあります。a) b)iSCSI名は比較するのが比較的簡単です。 等価性のために2つのiSCSI名を比較するためのアルゴリズムは外部のサーバを当てにしません。
Satran, et al. Standards Track [Page 30] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[30ページ]。
c) iSCSI names are composed only of displayable characters. iSCSI
names allow the use of international character sets but are not
case sensitive. No whitespace characters are used in iSCSI
names.
d) iSCSI names may be transported using both binary and
ASCII-based protocols.
c)iSCSI名は「ディスプレイ-可能」キャラクタだけで構成されます。iSCSI名は、国際的な人物セットの使用を許しますが、大文字と小文字を区別していません。 空白キャラクタは全くiSCSI名に使用されません。d)iSCSI名は、2進の、そして、ASCIIベースの両方のプロトコルを使用することで輸送されるかもしれません。
An iSCSI name really names a logical software entity, and is not tied to a port or other hardware that can be changed. For instance, an initiator name should name the iSCSI initiator node, not a particular NIC or HBA. When multiple NICs are used, they should generally all present the same iSCSI initiator name to the targets, because they are simply paths to the same SCSI layer. In most operating systems, the named entity is the operating system image.
iSCSI名は、本当に論理的なソフトウェア実体を命名して、変えることができるポートか他のハードウェアに結ばれません。 例えば、創始者名は特定のNICかHBAではなく、iSCSI創始者ノードを命名するべきです。 複数のNICsが使用されているとき、一般に、彼らは皆、同じiSCSI創始者名を目標に提示するべきです、それらが単に同じSCSI層への経路であるので。 ほとんどのオペレーティングシステムで、命名された実体はオペレーティングシステムイメージです。
Similarly, a target name should not be tied to hardware interfaces that can be changed. A target name should identify the logical target and must be the same for the target regardless of the physical portion being addressed. This assists iSCSI initiators in determining that the two targets it has discovered are really two paths to the same target.
同様に、変えることができるハードウェア・インタフェースに目標名を結ぶべきではありません。 目標名は、論理的な目標を特定するべきであり、目標に、扱われる物理的な部分にかかわらず同じであるに違いありません。 それが発見した2個の目標が本当に同じ目標への2つの経路であることを決定するのにこれはiSCSI創始者を助けます。
The iSCSI name is designed to fulfill the functional requirements for Uniform Resource Names (URN) [RFC1737]. For example, it is required that the name have a global scope, be independent of address or location, and be persistent and globally unique. Names must be extensible and scalable with the use of naming authorities. The name encoding should be both human and machine readable. See [RFC1737] for further requirements.
iSCSI名は、Uniform Resource Names(URN)[RFC1737]のための機能条件書を実現させるように設計されています。 例えば、名前がグローバルな範囲を持って、アドレスか位置から独立していて、永続的であって、グローバルにユニークであることが必要です。 名前は、命名当局の使用で広げることができてスケーラブルであるに違いありません。 コード化という名前は、人間であって、かつマシン読み込み可能であるべきです。 さらなる要件に関して[RFC1737]を見てください。
3.2.6.2. iSCSI Name Encoding
3.2.6.2. iSCSI名前コード化
An iSCSI name MUST be a UTF-8 encoding of a string of Unicode characters with the following properties:
iSCSI名は以下の特性をもっている一連のユニコード文字に以下をコード化するUTF-8であるに違いありません。
- It is in Normalization Form C (see "Unicode Normalization
Forms" [UNICODE]).
- It only contains characters allowed by the output of the iSCSI
stringprep template (described in [RFC3722]).
- The following characters are used for formatting iSCSI names:
- それはNormalization Form Cにあります(「ユニコード正常化フォーム」[ユニコード]を見てください)。 - それはiSCSI stringprepテンプレート([RFC3722]では、説明される)の出力で許容されたキャラクタを含むだけです。 - 以下のキャラクタは形式iSCSI名に使用されます:
- dash ('-'=U+002d)
- dot ('.'=U+002e)
- colon (':'=U+003a)
- ('--'=U+002d)--ドット('. '=U+002e)--コロンを投げつけてください。(':'=U+003a)
- The UTF-8 encoding of the name is not larger than 223 bytes.
- 名前のUTF-8コード化は223バイトほど大きくはありません。
Satran, et al. Standards Track [Page 31] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[31ページ]。
The stringprep process is described in [RFC3454]; iSCSI's use of the stringprep process is described in [RFC3722]. Stringprep is a method designed by the Internationalized Domain Name (IDN) working group to translate human-typed strings into a format that can be compared as opaque strings. Strings MUST NOT include punctuation, spacing, diacritical marks, or other characters that could get in the way of readability. The stringprep process also converts strings into equivalent strings of lower-case characters.
stringprepプロセスは[RFC3454]で説明されます。 stringprepプロセスのiSCSIの使用は[RFC3722]で説明されます。 Stringprepは不透明なストリングとして比較できる形式に人間によってタイプされたストリングを翻訳するようにInternationalized Domain Name(IDN)ワーキンググループによって設計されたメソッドです。 ストリングは読み易さの邪魔をすることができた句読、スペース、読み分け記号、または他のキャラクタを含んではいけません。 また、stringprepプロセスは小文字の同等なストリングにストリングを変換します。
The stringprep process does not need to be implemented if the names are only generated using numeric and lower-case (any character set) alphabetic characters.
名前が数値の、そして、小文字(どんな文字集合も)の英字を使用することで生成されるだけであるなら、stringprepプロセスは実装される必要はありません。
Once iSCSI names encoded in UTF-8 are "normalized" they may be safely compared byte-for-byte.
UTF-8でコード化されたiSCSI名がいったん「正常にされる」と、それらはバイト安全に比較されたバイトであるかもしれません。
3.2.6.3. iSCSI Name Structure
3.2.6.3. iSCSI名前構造
An iSCSI name consists of two parts--a type designator followed by a unique name string.
iSCSI名は2つの部品から成ります--ユニークな名前ストリングが支えたタイプ指示子。
The iSCSI name does not define any new naming authorities. Instead, it supports two existing ways of designating naming authorities: an iSCSI-Qualified Name, using domain names to identify a naming authority, and the EUI format, where the IEEE Registration Authority assists in the formation of worldwide unique names (EUI-64 format).
iSCSI名はどんな新しい命名当局も定義しません。 代わりに、命名当局を任命する2つの既存の方法をサポートします: 命名権威、およびEUI形式を特定するのにドメイン名を使用するiSCSIが適切なName。(そこでは、IEEE Registration Authorityが世界的なユニークな名前(EUI-64形式)の構成を助けます)。
The type designator strings currently defined are:
現在定義されているタイプ指示子ストリングは以下の通りです。
iqn. - iSCSI Qualified name
eui. - Remainder of the string is an IEEE EUI-64
identifier, in ASCII-encoded hexadecimal.
iqn。 - iSCSI Qualifiedはeuiを命名します。 - ストリングの残りはASCIIによってコード化された16進のIEEE EUI-64識別子です。
These two naming authority designators were considered sufficient at the time of writing this document. The creation of additional naming type designators for iSCSI may be considered by the IETF and detailed in separate RFCs.
このドキュメントを書く時点で、権威を指示子と命名するこれらの2は十分であると考えられました。 iSCSIのための追加命名タイプ指示子の作成は、IETFによって考えられて別々のRFCsで詳細であるかもしれません。
3.2.6.3.1. Type "iqn." (iSCSI Qualified Name)
3.2.6.3.1. "iqn"をタイプしてください。 (iSCSIの適切な名)
This iSCSI name type can be used by any organization that owns a domain name. This naming format is useful when an end user or service provider wishes to assign iSCSI names for targets and/or initiators.
ドメイン名を所有しているどんな組織もこのiSCSI名前タイプを使用できます。 エンドユーザか目標、そして/または、創始者のために名前をiSCSIに割り当てるというサービスプロバイダー願望であるときに、この命名形式は役に立ちます。
To generate names of this type, the person or organization generating the name must own a registered domain name. This domain name does not have to be active, and does not have to resolve to an address; it
名前を生成するこのタイプ、人または組織の名前を生成するのは登録されたドメイン名を所有しなければなりません。 このドメイン名がアクティブになるように持たないで、アドレスに決議する必要はない、。 それ
Satran, et al. Standards Track [Page 32] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[32ページ]。
just needs to be reserved to prevent others from generating iSCSI names using the same domain name.
ただ、他のものが同じドメイン名を使用することでiSCSIに名前を生成するのを防ぐために予約されるのが必要です。
Since a domain name can expire, be acquired by another entity, or may be used to generate iSCSI names by both owners, the domain name must be additionally qualified by a date during which the naming authority owned the domain name. For this reason, a date code is provided as part of the "iqn." format.
ドメイン名を期限が切れることができるか、別の実体で取得するか、または両方の所有者でiSCSIに名前を生成するのに使用するかもしれないので、命名権威がドメイン名を所有していた日付までにさらに、ドメイン名に資格がなければなりません。 この理由で、"iqn"の一部として日付コードを提供します。. 形式。
The iSCSI qualified name string consists of:
ストリングというiSCSIの適切な名は以下から成ります。
- The string "iqn.", used to distinguish these names from "eui."
formatted names.
- A date code, in yyyy-mm format. This date MUST be a date
during which the naming authority owned the domain name used in
this format, and SHOULD be the first month in which the domain
name was owned by this naming authority at 00:01 GMT of the
first day of the month. This date code uses the Gregorian
calendar. All four digits in the year must be present. Both
digits of the month must be present, with January == "01" and
December == "12". The dash must be included.
- A dot "."
- The reversed domain name of the naming authority (person or
organization) creating this iSCSI name.
- An optional, colon (:) prefixed, string within the character
set and length boundaries that the owner of the domain name
deems appropriate. This may contain product types, serial
numbers, host identifiers, or software keys (e.g., it may
include colons to separate organization boundaries). With the
exception of the colon prefix, the owner of the domain name can
assign everything after the reversed domain name as desired.
It is the responsibility of the entity that is the naming
authority to ensure that the iSCSI names it assigns are
worldwide unique. For example, "Example Storage Arrays, Inc.",
might own the domain name "example.com".
- ストリングは"iqnする"です。. "eui" フォーマットされた名前とこれらの名前を区別するのにおいて、使用されています。 - yyyy-mm形式における日付コード。 ドメイン名がこの命名で所有されていた1カ月目が月の初日のグリニッジ標準時0時1分の権威であったなら、この日付は命名権威がこの形式、およびSHOULDで使用されるドメイン名を所有していた日付であるに違いありません。 この日付コードはグレゴリオ暦を使用します。 1年間のすべての4ケタが存在していなければなりません。 月の両方のケタが1月=について存在していなければならない、「1インチと12月=「12インチ。」 ダッシュを含まなければなりません。 - 「ドット」、」 - このiSCSI名を作成する命名権威(人か組織)の逆にされたドメイン名。 - 任意である、コロン、(:、)、前に置かれています、文字集合と長さの中でドメイン名の所有者が適切であると考える境界を結んでください。 これは製品タイプ、通し番号、ホスト識別子、またはソフトウェアキーを含むかもしれません(例えば、それは組織境界を切り離すためにコロンを含むかもしれません)。 コロン接頭語を除いて、ドメイン名の所有者は逆にされたドメイン名の後に望まれているようにすべてを割り当てることができます。 それが割り当てるiSCSI名が世界中にあるのを保証するのは、命名権威である実体の責任です。ユニーク。 例えば、「例のストレージはInc.を整列させること」がドメイン名"example.com"を所有するかもしれません。
The following are examples of iSCSI qualified names that might be generated by "EXAMPLE Storage Arrays, Inc."
↓これは「例のストレージはInc.を整列させること」によって生成されるかもしれないiSCSIの適切な名に関する例です。
Naming String defined by
Type Date Auth "example.com" naming authority
+--++-----+ +---------+ +--------------------------------+
| || | | | | |
権威を+と命名しながらType Date Auth"example.com"によって定義されたStringを命名します--+ +-----+ +---------+ +--------------------------------+ | || | | | | |
iqn.2001-04.com.example:storage:diskarrays-sn-a8675309
iqn.2001-04.com.example
iqn.2001-04.com.example:storage.tape1.sys1.xyz
iqn.2001-04.com.example:storage.disk2.sys1.xyz
iqn.2001-04.com.example:ストレージ:diskarrays-sn-a8675309 iqn.2001-04.com.example iqn.2001-04.com.example:storage.tape1.sys1.xyz iqn.2001-04.com.example:storage.disk2.sys1.xyz
Satran, et al. Standards Track [Page 33] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[33ページ]。
3.2.6.3.2. Type "eui." (IEEE EUI-64 format)
3.2.6.3.2. "eui"をタイプしてください。 (IEEE EUI-64形式)
The IEEE Registration Authority provides a service for assigning globally unique identifiers [EUI]. The EUI-64 format is used to build a global identifier in other network protocols. For example, Fibre Channel defines a method of encoding it into a WorldWideName. For more information on registering for EUI identifiers, see [OUI].
IEEE Registration Authorityはグローバルにユニークな識別子[EUI]を割り当てるためのサービスを提供します。 EUI-64形式は、他のネットワーク・プロトコルのグローバルな識別子を築き上げるのに使用されます。 例えば、Fibre ChannelはそれをWorldWideNameにコード化するメソッドを定義します。 EUI識別子に登録する詳しい情報に関しては、[OUI]を見てください。
The format is "eui." followed by an EUI-64 identifier (16 ASCII-encoded hexadecimal digits).
形式はEUI-64識別子によってあとに続きである(16のASCIIによってコード化された16進数字)"eui"です。
Example iSCSI name:
例のiSCSI名:
Type EUI-64 identifier (ASCII-encoded hexadecimal)
+--++--------------+
| || |
eui.02004567A425678D
タイプEUI-64識別子(ASCIIによってコード化された16進)+--+ +--------------+ | || | eui.02004567A425678D
The IEEE EUI-64 iSCSI name format might be used when a manufacturer is already registered with the IEEE Registration Authority and uses EUI-64 formatted worldwide unique names for its products.
メーカーが既にIEEE Registration Authorityに登録されるとき、形式というIEEE EUI-64 iSCSI名は使用されたかもしれません、そして、用途EUI-64は製品のために世界的なユニークな名前をフォーマットしました。
More examples of name construction are discussed in [RFC3721].
[RFC3721]で名前工事に関する、より多くの例について議論します。
3.2.7. Persistent State
3.2.7. 永続的な状態
iSCSI does not require any persistent state maintenance across sessions. However, in some cases, SCSI requires persistent identification of the SCSI initiator port name (See Section 3.4.2 SCSI Architecture Model and Section 3.4.3 Consequences of the Model).
iSCSIはセッションの向こう側に少しの永続的な州のメインテナンスも必要としません。 しかしながら、いくつかの場合、SCSIはSCSI創始者ポート名の永続的な識別を必要とします(Modelのセクション3.4.2SCSI Architecture Modelとセクション3.4.3Consequencesを見てください)。
iSCSI sessions do not persist through power cycles and boot operations.
iSCSIセッションは、パワーサイクルを通して固執していて、操作をブートしません。
All iSCSI session and connection parameters are re-initialized upon session and connection creation.
すべてのiSCSIセッションと接続パラメタはセッションと接続作成で再初期化されます。
Commands persist beyond connection termination if the session persists and command recovery within the session is supported. However, when a connection is dropped, command execution, as perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the affected task), is suspended until a new allegiance is established by the 'task reassign' task management function. (See Section 10.5 Task Management Function Request.)
セッションが持続しているなら、コマンドは接続終了を超えて持続しています、そして、セッション中のコマンド回復はサポートされます。 しかしながら、接続が下げられたら、実行を命令してください、新たな忠誠が'タスクによって確立されるまで吊されたiSCSI(すなわち、影響を受けるタスクへのiSCSIプロトコル交換にかかわる)で'タスク管理機能を再選任するように知覚するので。 (セクション10.5タスク管理機能要求を見てください。)
Satran, et al. Standards Track [Page 34] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[34ページ]。
3.2.8. Message Synchronization and Steering
3.2.8. メッセージ同期と操縦
iSCSI presents a mapping of the SCSI protocol onto TCP. This encapsulation is accomplished by sending iSCSI PDUs of varying lengths. Unfortunately, TCP does not have a built-in mechanism for signaling message boundaries at the TCP layer. iSCSI overcomes this obstacle by placing the message length in the iSCSI message header. This serves to delineate the end of the current message as well as the beginning of the next message.
iSCSIはSCSIプロトコルに関するマッピングをTCPに提示します。 このカプセル化は、異なった長さのiSCSI PDUsを送ることによって、達成されます。 残念ながら、TCPはTCP層にシグナリングメッセージ限界への内蔵のメカニズムを持っていません。iSCSIは、iSCSIメッセージヘッダーにメッセージ長を置くことによって、この障害を克服します。 これは、次のメッセージの始まりと同様に現在のメッセージの終わりを図で表わすのに役立ちます。
In situations where IP packets are delivered in order from the network, iSCSI message framing is not an issue and messages are processed one after the other. In the presence of IP packet reordering (i.e., frames being dropped), legacy TCP implementations store the "out of order" TCP segments in temporary buffers until the missing TCP segments arrive, upon which the data must be copied to the application buffers. In iSCSI, it is desirable to steer the SCSI data within these out of order TCP segments into the pre-allocated SCSI buffers rather than store them in temporary buffers. This decreases the need for dedicated reassembly buffers as well as the latency and bandwidth related to extra copies.
IPパケットがネットワークから整然とした状態で提供される状況で、iSCSIメッセージ縁どりは発行ではありません、そして、メッセージは次々と処理されます。 IPパケット再命令(すなわち、下げられるフレーム)の面前で、なくなったTCPセグメント(アプリケーションバッファにデータをコピーしなければならない)が到着するまで、レガシーTCP実装は一時的なバッファの「故障」TCPセグメントを保存します。 iSCSIでは、一時的なバッファにそれらを保存するよりこれらの不適切なTCPセグメントの中でむしろSCSIデータをあらかじめ割り当てられたSCSIバッファの中に導くのは望ましいです。 これは複本に関連する潜在と帯域幅と同様に専用再アセンブリバッファの必要性を減少させます。
Relying solely on the "message length" information from the iSCSI message header may make it impossible to find iSCSI message boundaries in subsequent TCP segments due to the loss of a TCP segment that contains the iSCSI message length. The missing TCP segment(s) must be received before any of the following segments can be steered to the correct SCSI buffers (due to the inability to determine the iSCSI message boundaries). Since these segments cannot be steered to the correct location, they must be saved in temporary buffers that must then be copied to the SCSI buffers.
iSCSIメッセージヘッダーからの唯一「メッセージ長」情報を当てにするのに、iSCSIメッセージ長を含むTCPセグメントの損失のためその後のTCPセグメントにおけるメッセージ限界をiSCSIに見つけるのは不可能になるかもしれません。 以下のセグメントのどれかを正しいSCSIバッファ(iSCSIメッセージ限界を決定できないことによる)に導くことができる前になくなったTCPセグメントを受け取らなければなりません。 これらのセグメントを正しい位置に導くことができないので、次にSCSIバッファにコピーしなければならない一時的なバッファでそれらを保存しなければなりません。
Different schemes can be used to recover synchronization. To make these schemes work, iSCSI implementations have to make sure that the appropriate protocol layers are provided with enough information to implement a synchronization and/or data steering mechanism. One of these schemes is detailed in Appendix A. - Sync and Steering with Fixed Interval Markers -.
同期を回復するのに異なった体系を使用できます。 これらの体系を働かせるように、iSCSI実装は、同期、そして/または、データが舵取り装置であると実装することができるくらいの情報が適切なプロトコル層に提供されるのを確実にしなければなりません。 これらの体系の1つがFixed Interval MarkersとAppendix A.--同期して、Steeringで詳細である、-
The Fixed Interval Markers (FIM) scheme works by inserting markers in the payload stream at fixed intervals that contain the offset for the start of the next iSCSI PDU.
Fixed Interval Markers(FIM)体系は、ペイロードストリームにマーカーを挿入することによって、次のiSCSI PDUの始まりのためのオフセットを含む固定間隔で、うまくいきます。
Under normal circumstances (no PDU loss or data reception out of order), iSCSI data steering can be accomplished by using the identifying tag and the data offset fields in the iSCSI header in addition to the TCP sequence number from the TCP header. The
通常の状況下で(PDUの損失がないかデータ受信故障している)、同定標識を使用することによって、iSCSIデータ操縦を実行できます、そして、データはTCPヘッダーからのTCP一連番号に加えてiSCSIヘッダーの分野を相殺します。 The
Satran, et al. Standards Track [Page 35] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[35ページ]。
identifying tag helps associate the PDU with a SCSI buffer address while the data offset and TCP sequence number are used to determine the offset within the buffer.
同定標識は、データオフセットとTCP一連番号がバッファの中でオフセットを決定するのに使用されている間、SCSIバッファアドレスにPDUを関連づけるのを助けます。
When the part of the TCP data stream containing an iSCSI PDU header is delayed or lost, markers may be used to minimize the damage as follows:
iSCSI PDUヘッダーを含むTCPデータ・ストリームの一部分が遅らせられるか、または失われているとき、マーカーは以下の損害を最小にするのに使用されるかもしれません:
- Markers indicate where the next iSCSI PDU starts and enable
continued processing when iSCSI headers have to be dropped due to
data errors discovered at the iSCSI level (e.g., iSCSI header CRC
errors).
- iSCSIヘッダーがiSCSIレベル(例えば、iSCSIヘッダーCRC誤り)で発見されたデータ誤りのため下げられなければならないとき、マーカーは、次のiSCSI PDUがどこから始まるかを示して、継続的な処理を可能にします。
- Markers help minimize the amount of data that has to be kept by
the TCP/iSCSI layer while waiting for a late TCP packet arrival
or recovery, because later they might help find iSCSI PDU headers
and use the information contained in those to steer data to SCSI
buffers.
- マーカーは、遅いTCPパケット到着か回復を待っている間にTCP/iSCSI層によって保たれなければならないデータ量を最小にするのを助けます、彼らが後でデータをSCSIバッファに導くのにiSCSI PDUヘッダーを見つけて、それらに含まれた情報を使用するのを助けるかもしれないので。
3.2.8.1. Sync/Steering and iSCSI PDU Length
3.2.8.1. 同時性/操縦とiSCSI PDUの長さ
When a large iSCSI message is sent, the TCP segment(s) that contain the iSCSI header may be lost. The remaining TCP segment(s), up to the next iSCSI message, must be buffered (in temporary buffers) because the iSCSI header that indicates to which SCSI buffers the data are to be steered was lost. To minimize the amount of buffering, it is recommended that the iSCSI PDU length be restricted to a small value (perhaps a few TCP segments in length). During login, each end of the iSCSI session specifies the maximum iSCSI PDU length it will accept.
大きいiSCSIメッセージを送るとき、iSCSIヘッダーを含むTCPセグメントを失うかもしれません。 データがどのSCSIバッファに導かれるかことであることを示すiSCSIヘッダーがなくされたので、残っているTCPセグメントを次のiSCSIメッセージまでバッファリングしなければなりません(一時的なバッファで)。 バッファリングの量を最小にするために、iSCSI PDUの長さが小さい値(恐らく長さにおけるいくつかのTCPセグメント)に制限されるのは、お勧めです。 ログインの間、iSCSIセッションの各端はそれが受け入れる最大のiSCSI PDUの長さを指定します。
3.3. iSCSI Session Types
3.3. iSCSIセッションタイプ
iSCSI defines two types of sessions:
iSCSIは2つのタイプのセッションを定義します:
a) Normal operational session - an unrestricted session.
b) Discovery-session - a session only opened for target
discovery. The target MUST ONLY accept text requests with the
SendTargets key and a logout request with the reason "close
the session". All other requests MUST be rejected.
a) 通常の操作上のセッション--無制限なセッション、b) 発見セッション--セッションは目標発見のために開いただけです。 目標は、SendTargetsとのテキスト要求が主要であると受け入れるだけでよいです、そして、aはログアウトします。「セッションを終えてください」理由で、要求します。 他のすべての要求を拒絶しなければなりません。
The session type is defined during login with the key=value parameter in the login command.
ログインの間、セッションタイプは主要な=値パラメタでログインコマンドで定義されます。
Satran, et al. Standards Track [Page 36] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[36ページ]。
3.4. SCSI to iSCSI Concepts Mapping Model
3.4. モデルを写像するiSCSI概念へのSCSI
The following diagram shows an example of how multiple iSCSI Nodes (targets in this case) can coexist within the same Network Entity and can share Network Portals (IP addresses and TCP ports). Other more complex configurations are also possible. For detailed descriptions of the components of these diagrams, see Section 3.4.1 iSCSI Architecture Model.
以下のダイヤグラムは複数のiSCSI Nodes(この場合、目標)がどう、同じNetwork Entityの中に共存できて、Network Portals(IPアドレスとTCPポート)を共有できるかに関する例を示しています。 また、他の、より複雑な構成も可能です。 これらのダイヤグラムの部品の詳述に関しては、セクション3.4.1iSCSI Architecture Modelを見てください。
+-----------------------------------+
| Network Entity (iSCSI Client) |
| |
| +-------------+ |
| | iSCSI Node | |
| | (Initiator) | |
| +-------------+ |
| | | |
| +--------------+ +--------------+ |
| |Network Portal| |Network Portal| |
| | 10.1.30.4 | | 10.1.40.6 | |
+-+--------------+-+--------------+-+
| |
| IP Networks |
| |
+-+--------------+-+--------------+-+
| |Network Portal| |Network Portal| |
| | 10.1.30.21 | | 10.1.40.3 | |
| | TCP Port 3260| | TCP Port 3260| |
| +--------------+ +--------------+ |
| | | |
| ----------------- |
| | | |
| +-------------+ +--------------+ |
| | iSCSI Node | | iSCSI Node | |
| | (Target) | | (Target) | |
| +-------------+ +--------------+ |
| |
| Network Entity (iSCSI Server) |
+-----------------------------------+
+-----------------------------------+ | ネットワーク実体(iSCSIクライアント)| | | | +-------------+ | | | iSCSIノード| | | | (創始者) | | | +-------------+ | | | | | | +--------------+ +--------------+ | | |ネットワーク入り口| |ネットワーク入り口| | | | 10.1.30.4 | | 10.1.40.6 | | +-+--------------+-+--------------+-+ | | | IPネットワーク| | | +-+--------------+-+--------------+-+ | |ネットワーク入り口| |ネットワーク入り口| | | | 10.1.30.21 | | 10.1.40.3 | | | | TCPは3260を移植します。| | TCPは3260を移植します。| | | +--------------+ +--------------+ | | | | | | ----------------- | | | | | | +-------------+ +--------------+ | | | iSCSIノード| | iSCSIノード| | | | (目標) | | (目標) | | | +-------------+ +--------------+ | | | | ネットワーク実体(iSCSIサーバ)| +-----------------------------------+
3.4.1. iSCSI Architecture Model
3.4.1. iSCSIアーキテクチャモデル
This section describes the part of the iSCSI architecture model that has the most bearing on the relationship between iSCSI and the SCSI Architecture Model.
このセクションはiSCSIとSCSI Architecture Modelとの関係に最も多くの関係を持っているiSCSIアーキテクチャモデルの部分について説明します。
Satran, et al. Standards Track [Page 37] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[37ページ]。
a) Network Entity - represents a device or gateway that is
accessible from the IP network. A Network Entity must have
one or more Network Portals (see item d), each of which can be
used by some iSCSI Nodes (see item (b)) contained in that
Network Entity to gain access to the IP network.
a) ネットワークEntity--IPネットワークからアクセスしやすいデバイスかゲートウェイを表します。 Network Entityには1Network Portals(項目dを見る)がなければなりません。いくつかのiSCSI Nodesがそれぞれそれを使用できます。(項目(b))がIPネットワークへのアクセスを得るためにそのNetwork Entityに含まれているのを見てください。
b) iSCSI Node - represents a single iSCSI initiator or iSCSI
target. There are one or more iSCSI Nodes within a Network
Entity. The iSCSI Node is accessible via one or more Network
Portals (see item d). An iSCSI Node is identified by its
iSCSI Name (see Section 3.2.6 iSCSI Names and Chapter 12).
The separation of the iSCSI Name from the addresses used by
and for the iSCSI node allows multiple iSCSI nodes to use the
same addresses, and the same iSCSI node to use multiple
addresses.
b)iSCSI Node--独身のiSCSI創始者かiSCSI目標の代理をします。 Network Entityの中に1iSCSI Nodesがあります。 iSCSI Nodeは1Network Portalsを通してアクセスしやすいです(項目dを見てください)。 iSCSI NodeはiSCSI Nameによって特定されます(セクション3.2.6iSCSI Namesと第12章を参照してください)。 ノードとiSCSIノードに使用されるアドレスからのiSCSI Nameの分離で、複数のiSCSIノードが、複数のアドレスを使用するのに同じアドレス、および同じiSCSIノードを使用できます。
c) An alias string may also be associated with an iSCSI Node.
The alias allows an organization to associate a user friendly
string with the iSCSI Name. However, the alias string is not
a substitute for the iSCSI Name.
c) また、別名ストリングもiSCSI Nodeに関連しているかもしれません。 別名で、組織はユーザフレンドリーなストリングをiSCSI Nameに関連づけることができます。 しかしながら、別名ストリングはiSCSI Nameの代用品ではありません。
d) Network Portal - a component of a Network Entity that has a
TCP/IP network address and that may be used by an iSCSI Node
within that Network Entity for the connection(s) within one of
its iSCSI sessions. In an initiator, it is identified by its
IP address. In a target, it is identified by its IP address
and its listening TCP port.
d) ネットワークPortal--TCP/IPネットワーク・アドレスとそれを持っているNetwork Entityの部品はiSCSIセッションの1つ中に接続にそのNetwork Entityの中でiSCSI Nodeによって使用されるかもしれません。 創始者では、それはIPアドレスによって特定されます。 目標では、それは、IPアドレスによって特定されて、それはTCPポートを聴くことです。
e) Portal Groups - iSCSI supports multiple connections within the
same session; some implementations will have the ability to
combine connections in a session across multiple Network
Portals. A Portal Group defines a set of Network Portals
within an iSCSI Node that collectively supports the capability
of coordinating a session with connections that span these
portals. Not all Network Portals within a Portal Group need
to participate in every session connected through that Portal
Group. One or more Portal Groups may provide access to an
iSCSI Node. Each Network Portal, as utilized by a given iSCSI
Node, belongs to exactly one portal group within that node.
Portal Groups are identified within an iSCSI Node by a portal
group tag, a simple unsigned-integer between 0 and 65535 (see
Section 12.3 SendTargets). All Network Portals with the same
portal group tag in the context of a given iSCSI Node are in
the same Portal Group.
e) 入り口のGroups--iSCSIは同じセッション中に複数の接続をサポートします。 いくつかの実装には、複数のNetwork Portalsの向こう側にセッションにおける接続を結合する能力があるでしょう。 Portal Groupはこれらの入り口にかかる接続とのセッションを調整する能力にまとめてサポートするiSCSI Nodeの中でNetwork Portalsの1セットを定義します。 Portal Groupの中のNetwork Portalsがあらゆるセッションのときに参加するというわけではない必要があるすべてがそのPortal Groupを通して接続しました。 1Portal GroupsがiSCSI Nodeへのアクセスを提供するかもしれません。 与えられたiSCSI Nodeによって利用される各Network Portalはまさにそのノードの中の1つの入り口のグループのものです。 入り口のグループタグ(0〜65535(セクション12.3 SendTargetsを見る)の簡単な符号のない整数)によって入り口のGroupsはiSCSI Nodeの中で特定されます。 同じ入り口のグループタグが与えられたiSCSI Nodeの文脈にあるすべてのNetwork Portalsが同じPortal Groupにあります。
Satran, et al. Standards Track [Page 38] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[38ページ]。
Both iSCSI Initiators and iSCSI Targets have portal groups,
though only the iSCSI Target Portal Groups are used directly
in the iSCSI protocol (e.g., in SendTargets). For references
to the initiator Portal Groups, see Section 9.1.1 Conservative
Reuse of ISIDs.
iSCSI InitiatorsとiSCSI Targetsの両方には、入り口のグループがあります、iSCSI Target Portal Groupsだけが直接iSCSIプロトコル(例えば、SendTargetsの)に使用されますが。 創始者Portal Groupsの参照に関しては、ISIDsのセクション9.1.1保守党員Reuseを見てください。
f) Portals within a Portal Group should support similar session
parameters, because they may participate in a common session.
f) Portal Groupの中の入り口は、一般的なセッションのときに参加するかもしれないので、同様のセッションパラメタをサポートするべきです。
The following diagram shows an example of one such configuration on a target and how a session that shares Network Portals within a Portal Group may be established.
目標とPortal Groupの中でNetwork Portalsを共有するセッションがどう確立されるかもしれないかに関して以下のダイヤグラムはそのような構成の1つに関する例を示しています。
----------------------------IP Network---------------------
| | |
+----|---------------|-----+ +----|---------+
| +---------+ +---------+ | | +---------+ |
| | Network | | Network | | | | Network | |
| | Portal | | Portal | | | | Portal | |
| +--|------+ +---------+ | | +---------+ |
| | | | | | |
| | Portal | | | | Portal |
| | Group 1 | | | | Group 2 |
+--------------------------+ +--------------+
| | |
+--------|---------------|--------------------|--------------------+
| | | | |
| +----------------------------+ +-----------------------------+ |
| | iSCSI Session (Target side)| | iSCSI Session (Target side) | |
| | | | | |
| | (TSIH = 56) | | (TSIH = 48) | |
| +----------------------------+ +-----------------------------+ |
| |
| iSCSI Target Node |
| (within Network Entity, not shown) |
+------------------------------------------------------------------+
----------------------------IPネットワーク--------------------- | | | +----|---------------|-----+ +----|---------+ | +---------+ +---------+ | | +---------+ | | | ネットワーク| | ネットワーク| | | | ネットワーク| | | | 入り口| | 入り口| | | | 入り口| | | +--|------+ +---------+ | | +---------+ | | | | | | | | | | 入り口| | | | 入り口| | | グループ1| | | | グループ2| +--------------------------+ +--------------+ | | | +--------|---------------|--------------------|--------------------+ | | | | | | +----------------------------+ +-----------------------------+ | | | iSCSI Session(目標側)| | iSCSI Session(目標側)| | | | | | | | | | (TSIH=56) | | (TSIH=48) | | | +----------------------------+ +-----------------------------+ | | | | iSCSI目標ノード| | (中、Network Entity示されないで、 | +------------------------------------------------------------------+
3.4.2. SCSI Architecture Model
3.4.2. SCSIアーキテクチャモデル
This section describes the relationship between the SCSI Architecture Model [SAM2] and the constructs of the SCSI device, SCSI port and I_T nexus, and the iSCSI constructs described in Section 3.4.1 iSCSI Architecture Model.
このセクションはSCSI Architecture Model[SAM2]と、SCSIデバイス、SCSIポート、およびI_T結びつきの構造物と、セクション3.4.1iSCSI Architecture Modelで説明されたiSCSI構造物との関係について説明します。
This relationship implies implementation requirements in order to conform to the SAM2 model and other SCSI operational functions. These requirements are detailed in Section 3.4.3 Consequences of the Model.
この関係は、SAM2モデルと他のSCSIに操作上の機能を従わせるために実装要件を含意します。 これらの要件はModelのセクション3.4.3Consequencesで詳細です。
Satran, et al. Standards Track [Page 39] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[39ページ]。
The following list outlines mappings of SCSI architectural elements to iSCSI.
以下のリストはSCSIの建築要素に関するマッピングについてiSCSIに概説します。
a) SCSI Device - the SAM2 term for an entity that contains one or
more SCSI ports that are connected to a service delivery
subsystem and supports a SCSI application protocol. For
example, a SCSI Initiator Device contains one or more SCSI
Initiator Ports and zero or more application clients. A SCSI
Target Device contains one or more SCSI Target Ports and one
or more logical units. For iSCSI, the SCSI Device is the
component within an iSCSI Node that provides the SCSI
functionality. As such, there can be one SCSI Device, at
most, within an iSCSI Node. Access to the SCSI Device can
only be achieved in an iSCSI normal operational session (see
Section 3.3 iSCSI Session Types). The SCSI Device Name is
defined to be the iSCSI Name of the node and MUST be used in
the iSCSI protocol.
a) SCSI Device--1SCSIを含む実体がそれを移植するので、SAM2用語は、サービス配送サブシステムに関連づけられて、SCSIがアプリケーション・プロトコルであるとサポートします。 例えば、SCSI Initiator Deviceは1SCSI Initiator Portsとゼロか、より多くのアプリケーションクライアントを含みます。 SCSI Target Deviceは1SCSI Target Portsと1個以上の論理装置を含んでいます。 iSCSIに関しては、SCSI DeviceはSCSIの機能性を提供するiSCSI Nodeの中のコンポーネントです。 そういうものとして、iSCSI Nodeの中に1SCSI Deviceが大部分にあることができます。 iSCSIの通常の操作上のセッションのときにSCSI Deviceへのアクセスを達成できるだけです(セクション3.3 iSCSI Session Typesを見てください)。 SCSI Device NameをノードのiSCSI Nameになるように定義されて、iSCSIプロトコルに使用しなければなりません。
b) SCSI Port - the SAM2 term for an entity in a SCSI Device that
provides the SCSI functionality to interface with a service
delivery subsystem or transport. For iSCSI, the definition of
SCSI Initiator Port and SCSI Target Port are different.
b) SCSI Port--サービス配送サブシステムか輸送を連結するSCSIの機能性に提供するSCSI Deviceの実体のためのSAM2用語。 iSCSI、SCSI Initiator PortとSCSI Target Portの定義が異なっているので。
SCSI Initiator Port: This maps to one endpoint of an iSCSI
normal operational session (see Section 3.3 iSCSI Session
Types). An iSCSI normal operational session is negotiated
through the login process between an iSCSI initiator node and
an iSCSI target node. At successful completion of this
process, a SCSI Initiator Port is created within the SCSI
Initiator Device. The SCSI Initiator Port Name and SCSI
Initiator Port Identifier are both defined to be the iSCSI
Initiator Name together with (a) a label that identifies it as
an initiator port name/identifier and (b) the ISID portion of
the session identifier.
SCSI創始者ポート: これは通常の操作上のセッションをiSCSIの1つの終点に写像します(セクション3.3 iSCSI Session Typesを見てください)。 iSCSIの通常の操作上のセッションはiSCSI創始者ノードとiSCSI目標ノードの間のログインプロセスを通して交渉されます。 このプロセスの無事終了では、SCSI Initiator PortはSCSI Initiator Deviceの中で作成されます。 SCSI Initiator Port NameとSCSI Initiator Port Identifierは、(a) それが創始者ポート名前/識別子であると認識するラベルと(b) セッション識別子のISID部分に伴うiSCSI Initiator Nameになるようにともに定義されます。
SCSI Target Port: This maps to an iSCSI Target Portal Group.
The SCSI Target Port Name and the SCSI Target Port Identifier
are both defined to be the iSCSI Target Name together with (a)
a label that identifies it as a target port name/identifier
and (b) the portal group tag.
SCSIはポートを狙います: iSCSI Target Portal Groupへのこの地図。 SCSI Target Port NameとSCSI Target Port Identifierは、(a) それが目標ポート名前/識別子であると認識するラベルと(b) 入り口のグループタグに伴うiSCSI Target Nameになるようにともに定義されます。
The SCSI Port Name MUST be used in iSCSI. When used in SCSI
parameter data, the SCSI port name MUST be encoded as:
- The iSCSI Name in UTF-8 format, followed by
- a comma separator (1 byte), followed by
- the ASCII character 'i' (for SCSI Initiator Port) or the
ASCII character 't' (for SCSI Target Port) (1 byte),
followed by
iSCSIでSCSI Port Nameを使用しなければなりません。 SCSIパラメタデータで使用されると、以下としてSCSIポート名をコード化しなければなりません。 - ''i'(SCSI Initiator Portのための)かASCII文字ごとに、'(SCSI Target Portのための)(1バイト)でないUTF-8形式におけるiSCSI Nameが続いたのを後をつけました。
Satran, et al. Standards Track [Page 40] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[40ページ]。
- a comma separator (1 byte), followed by
- a text encoding as a hex-constant (see Section 5.1 Text
Format) of the ISID (for SCSI initiator port) or the portal
group tag (for SCSI target port) including the initial 0X
or 0x and the terminating null (15 bytes).
- 初期の0Xか0xを含んでいて、テキストがISID(SCSI創始者ポートへの)か入り口のグループタグ(SCSI目標ポートへの)の十六進法定数(セクション5.1 Text Formatを見る)としてコード化されて、従われたコンマ分離符(1バイト)と終わりヌル(15バイト)。
The ASCII character 'i' or 't' is the label that identifies
this port as either a SCSI Initiator Port or a SCSI Target
Port.
'ASCII文字'i'です'、このポートがどちらかであると認識するラベルは、SCSI Initiator PortかそれともSCSI Target Portですか?
c) I_T nexus - a relationship between a SCSI Initiator Port and a
SCSI Target Port, according to [SAM2]. For iSCSI, this
relationship is a session, defined as a relationship between
an iSCSI Initiator's end of the session (SCSI Initiator Port)
and the iSCSI Target's Portal Group. The I_T nexus can be
identified by the conjunction of the SCSI port names or by the
iSCSI session identifier SSID. iSCSI defines the I_T nexus
identifier to be the tuple (iSCSI Initiator Name + 'i' + ISID,
iSCSI Target Name + 't' + Portal Group Tag).
c) I_T結びつき--[SAM2]に従ったSCSI Initiator PortとSCSI Target Portとの関係。 iSCSIに関しては、この関係はiSCSI Initiatorのセッション(SCSI Initiator Port)の終わりとiSCSI TargetのPortal Groupとの関係と定義されたセッションです。 'I_T結びつきは、SCSIポート名の接続詞で特定できるか、またはtuple('+ + iSCSI Initiator Name+'i'ISID、iSCSI Target Name+入り口Group Tagでない)になるようにiSCSIセッション識別子SSID. iSCSIでI_T結びつき識別子を定義します。
NOTE: The I_T nexus identifier is not equal to the session
identifier (SSID).
以下に注意してください。 I_T結びつき識別子はセッション識別子(SSID)と等しくはありません。
3.4.3. Consequences of the Model
3.4.3. モデルの結果
This section describes implementation and behavioral requirements that result from the mapping of SCSI constructs to the iSCSI constructs defined above. Between a given SCSI initiator port and a given SCSI target port, only one I_T nexus (session) can exist. No more than one nexus relationship (parallel nexus) is allowed by [SAM2]. Therefore, at any given time, only one session can exist between a given iSCSI initiator node and an iSCSI target node, with the same session identifier (SSID).
このセクションはSCSI構造物に関するマッピングからiSCSI構造物までの結果が上で定義した実装と行動の要件について説明します。 当然のことのSCSI創始者ポートと当然のことのSCSI目標ポート、1つだけの間では、I_T結びつき(セッション)は存在できます。 1つ未満の結びつきの関係(平行な結びつき)は[SAM2]によって許容されています。 したがって、その時々で、1つのセッションしか与えられたiSCSI創始者ノードとiSCSI目標ノードの間に存在できません、同じセッション識別子(SSID)で。
These assumptions lead to the following conclusions and requirements:
これらの仮定は以下の結論と要件につながります:
ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal Group (SCSI target port), there can only be one session with a given value for ISID that identifies the SCSI initiator port. See Section 10.12.5 ISID.
ISIDは統治します: 与えられたiSCSI InitiatorとiSCSI Target Portal Group(SCSI目標ポート)の間に、SCSI創始者ポートを特定するISIDのための与えられた値との1つのセッションしかあることができません。 セクション10.12.5ISIDを見てください。
The structure of the ISID that contains a naming authority component (see Section 10.12.5 ISID and [RFC3721]) provides a mechanism to facilitate compliance with the ISID rule. (See Section 9.1.1 Conservative Reuse of ISIDs.)
命名権威コンポーネント(セクション10.12.5ISIDと[RFC3721]を見る)を含むISIDの構造は、ISID規則へのコンプライアンスを容易にするためにメカニズムを提供します。 (ISIDsのセクション9.1.1の保守的な再利用を見てください。)
Satran, et al. Standards Track [Page 41] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[41ページ]。
The iSCSI Initiator Node should manage the assignment of ISIDs prior to session initiation. The "ISID RULE" does not preclude the use of the same ISID from the same iSCSI Initiator with different Target Portal Groups on the same iSCSI target or on other iSCSI targets (see Section 9.1.1 Conservative Reuse of ISIDs). Allowing this would be analogous to a single SCSI Initiator Port having relationships (nexus) with multiple SCSI target ports on the same SCSI target device or SCSI target ports on other SCSI target devices. It is also possible to have multiple sessions with different ISIDs to the same Target Portal Group. Each such session would be considered to be with a different initiator even when the sessions originate from the same initiator device. The same ISID may be used by a different iSCSI initiator because it is the iSCSI Name together with the ISID that identifies the SCSI Initiator Port.
iSCSI Initiator Nodeはセッション開始の前にISIDsの課題を管理するはずです。 「ISID規則」は同じiSCSI目標か他のiSCSI目標に関する同じiSCSI創始者と異なった目標入り口のグループ(ISIDsのセクション9.1.1の保守的な再利用を見る)と共に同じISIDの使用を排除しません。 これを許容するのは同じSCSI対象装置の上の複数のSCSI目標ポートか他のSCSI対象装置の上のSCSI目標ポートとの関係(結びつき)を持っている独身のSCSI Initiator Portに類似しているでしょう。 また、異なったISIDsとの複数のセッションを同じTarget Portal Groupに持っているのも可能です。 セッションが同じ創始者デバイスから発するときさえ、そのような各セッションが異なった創始者と共にいると考えられるでしょう。 ISIDと共にSCSI Initiator Portを特定するのが、iSCSI Nameであるので、同じISIDは異なったiSCSI創始者によって使用されるかもしれません。
NOTE: A consequence of the ISID RULE and the specification for the I_T nexus identifier is that two nexus with the same identifier should never exist at the same time.
以下に注意してください。 ISID RULEの結果とI_T結びつき識別子のための仕様は同じ識別子がある2結びつきが同時に決して存在するべきでないということです。
TSIH RULE: The iSCSI Target selects a non-zero value for the TSIH at session creation (when an initiator presents a 0 value at Login). After being selected, the same TSIH value MUST be used whenever the initiator or target refers to the session and a TSIH is required.
TSIHは統治します: iSCSI TargetはTSIHのためにセッション作成で非ゼロ値を選択します(創始者がLoginに0値を提示すると)。 選択された後に、創始者か目標がセッションを参照するときはいつも、同じTSIH値を使用しなければなりません、そして、TSIHが必要です。
3.4.3.1. I_T Nexus State
3.4.3.1. I_T結びつき状態
Certain nexus relationships contain an explicit state (e.g., initiator-specific mode pages) that may need to be preserved by the device server [SAM2] in a logical unit through changes or failures in the iSCSI layer (e.g., session failures). In order for that state to be restored, the iSCSI initiator should reestablish its session (re-login) to the same Target Portal Group using the previous ISID. That is, it should perform session recovery as described in Chapter 6. This is because the SCSI initiator port identifier and the SCSI target port identifier (or relative target port) form the datum that the SCSI logical unit device server uses to identify the I_T nexus.
ある結びつき関係はデバイスサーバ[SAM2]によってiSCSI層(例えば、セッション失敗)の中に変化か失敗を通して論理装置に保存される必要があるかもしれない明白な州(例えば、創始者特定のモードページ)を含んでいます。 その状態が回復するように、iSCSI創始者はセッション(再ログインする)を同じTarget Portal Groupに前のISIDを使用することで回復させるべきです。 すなわち、それは第6章で説明されるようにセッション回復を実行するべきです。 これはSCSI創始者ポート識別子とSCSI目標ポート識別子(または、相対的な目標ポート)がSCSI論理装置デバイスサーバがI_T結びつきを特定するのに使用するデータを形成するからです。
3.5. Request/Response Summary
3.5. 要求/応答概要
This section lists and briefly describes all the iSCSI PDU types (request and responses).
このセクションは、記載して、簡潔に、すべてのiSCSI PDUタイプ(要求と応答)について説明します。
All iSCSI PDUs are built as a set of one or more header segments (basic and auxiliary) and zero or one data segments. The header group and the data segment may each be followed by a CRC (digest).
すべてのiSCSI PDUsが1つ以上のヘッダー・セグメント(基本的で補助の)とゼロか1つのデータ・セグメントのセットとして造られます。 ヘッダーグループとデータ・セグメントはCRCによってそれぞれ従われるかもしれません(読みこなしてください)。
The basic header segment has a fixed length of 48 bytes.
基本的なヘッダー・セグメントには、48バイトの固定長があります。
Satran, et al. Standards Track [Page 42] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[42ページ]。
3.5.1. Request/Response Types Carrying SCSI Payload
3.5.1. SCSI有効搭載量を運ぶ要求/応答タイプ
3.5.1.1. SCSI-Command
3.5.1.1. SCSI-コマンド
This request carries the SCSI CDB and all the other SCSI execute command procedure call (see [SAM2]) IN arguments such as task attributes, Expected Data Transfer Length for one or both transfer directions (the latter for bidirectional commands), and Task Tag (as part of the I_T_L_x nexus). The I_T_L nexus is derived by the initiator and target from the LUN field in the request and the I_T nexus is implicit in the session identification.
この要求はSCSI CDBを運びます、そして、もう片方のすべてのSCSIがタスク属性などのコマンドプロシジャ要求([SAM2]を見る)IN議論を実行します、そして、Expected Data Transfer Lengthは個人的にはかともに、方向(双方向のコマンドのための後者)、およびTask Tag(I_T_L_x結びつきの一部としての)を移します。 I_T_L結びつきは創始者と目標によって要求におけるLUN分野から引き出されます、そして、I_T結びつきはセッション識別で暗黙です。
In addition, the SCSI-command PDU carries information required for the proper operation of the iSCSI protocol - the command sequence number (CmdSN) for the session and the expected status number (ExpStatSN) for the connection.
さらに、SCSI-コマンドPDUはiSCSIプロトコルの適切な操作に必要である情報を運びます--セッションのコマンド・シーケンス数の(CmdSN)と接続の予想された状態番号(ExpStatSN)。
All or part of the SCSI output (write) data associated with the SCSI command may be sent as part of the SCSI-Command PDU as a data segment.
データ・セグメントとしてのSCSI-コマンドPDUの一部としてSCSIコマンドに関連しているSCSI出力(書く)データのすべてか一部を送るかもしれません。
3.5.1.2. SCSI-Response
3.5.1.2. SCSI-応答
The SCSI-Response carries all the SCSI execute-command procedure call (see [SAM2]) OUT arguments and the SCSI execute-command procedure call return value.
SCSI-応答はすべてのSCSIコマンドプロシジャを作成している要求([SAM2]を見る)OUT議論とコマンドプロシジャを作成しているSCSI呼び出しリターン価値を運びます。
The SCSI-Response contains the residual counts from the operation, if any, an indication of whether the counts represent an overflow or an underflow, and the SCSI status if the status is valid or a response code (a non-zero return value for the execute-command procedure call) if the status is not valid.
SCSI-応答は操作からの残りのカウントを含んでいます、状態が有効でないならいずれ、状態が有効であるならカウントがオーバーフローかアンダーフローと、SCSI状態を表すかどうかしるしまたは応答が(コマンドプロシジャを作成している呼び出しのための非原点復帰値)をコード化するなら。
For a valid status that indicates that the command has been processed, but resulted in an exception (e.g., a SCSI CHECK CONDITION), the PDU data segment contains the associated sense data. The use of Autosense ([SAM2]) is REQUIRED by iSCSI.
コマンドが処理されますが、例外(例えば、SCSI CHECK CONDITION)となっているのを示す有効な状態に、PDUデータ・セグメントは関連センス・データを含んでいます。 Autosense([SAM2])の使用はiSCSIによるREQUIREDです。
Some data segment content may also be associated (in the data segment) with a non-zero response code.
また、何らかのデータ・セグメント内容も非ゼロ応答コードに関連しているかもしれません(データ・セグメントの)。
In addition, the SCSI-Response PDU carries information required for the proper operation of the iSCSI protocol:
さらに、SCSI-応答PDUはiSCSIプロトコルの適切な操作に必要である情報を運びます:
- The number of Data-In PDUs that a target has sent (to enable
the initiator to check that all have arrived).
- StatSN - the Status Sequence Number on this connection.
- 目標が送った(創始者が、すべてが到着したのをチェックするのを可能にする)中のData PDUsの数。 - StatSN--この接続でのStatus Sequence Number。
Satran, et al. Standards Track [Page 43] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[43ページ]。
- ExpCmdSN - the next Expected Command Sequence Number at the
target.
- MaxCmdSN - the maximum CmdSN acceptable at the target from
this initiator.
- ExpCmdSN--目標の次のExpected Command Sequence Number。 - MaxCmdSN--目標でこの創始者から許容できる最大のCmdSN。
3.5.1.3 Task Management Function Request
3.5.1.3 タスク管理機能要求
The Task Management function request provides an initiator with a way to explicitly control the execution of one or more SCSI Tasks or iSCSI functions. The PDU carries a function identifier (which task management function to perform) and enough information to unequivocally identify the task or task-set on which to perform the action, even if the task(s) to act upon has not yet arrived or has been discarded due to an error.
Task Management機能要求は明らかに1SCSI TasksかiSCSI機能の実行を制御する方法を創始者に提供します。 PDUは機能識別子(働くどのタスク管理機能)と明確に、動作を実行するタスクかタスクセットを特定できるくらいの情報を運ぶか、作用するタスクがまだ到着していない、または誤りのため捨てられたとしても。
The referenced tag identifies an individual task if the function refers to an individual task.
機能が個々のタスクを示すなら、参照をつけられたタグは個々のタスクを特定します。
The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is identified by the LUN and the session identification (the session identifies an I_T nexus).
I_T_L結びつきはタスクセットを特定します。 iSCSIでは、I_T_L結びつきはLUNとセッション識別で特定されます(セッションはI_T結びつきを特定します)。
For task sets, the CmdSN of the Task Management function request helps identify the tasks upon which to act, namely all tasks associated with a LUN and having a CmdSN preceding the Task Management function request CmdSN.
タスクセットのために、Task Management機能要求のCmdSNは、行動するタスクを特定するのを助けます、すなわち、LUNに関連しているすべてのタスクとCmdSNをTask Management機能が先行する持っているのはCmdSNを要求します。
For a Task Management function, the coordination between responses to the tasks affected and the Task Management function response is done by the target.
Task Management機能において、目標は影響を受けるタスクへの応答の間のコーディネートとTask Management機能応答をします。
3.5.1.4. Task Management Function Response
3.5.1.4. タスク管理機能応答
The Task Management function response carries an indication of function completion for a Task Management function request including how it was completed (response and qualifier) and additional information for failure responses.
Task Management機能応答はどう完成したかを(応答と資格を与える人)含むTask Management機能要求のための機能完成と失敗応答のための追加情報のしるしを運びます。
After the Task Management response indicates Task Management function completion, the initiator will not receive any additional responses from the affected tasks.
Task Management応答がTask Management機能完成を示した後に、創始者は影響を受けるタスクから少しの追加応答も受けないでしょう。
3.5.1.5. SCSI Data-Out and SCSI Data-In
3.5.1.5. 外のSCSIデータと中のSCSIデータ
SCSI Data-Out and SCSI Data-In are the main vehicles by which SCSI data payload is carried between initiator and target. Data payload is associated with a specific SCSI command through the Initiator Task Tag. For target convenience, outgoing solicited data also carries a
外のSCSI Dataと中のSCSI DataはSCSIデータペイロードが創始者と目標の間まで運ばれるメイン乗り物です。 データペイロードはInitiator Task Tagを通した特定のSCSIコマンドに関連しています。 また、目標便宜のために、送信する請求されたデータはaを運びます。
Satran, et al. Standards Track [Page 44] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[44ページ]。
Target Transfer Tag (copied from R2T) and the LUN. Each PDU contains the payload length and the data offset relative to the buffer address contained in the SCSI execute command procedure call.
転送タグ(R2Tから、コピーされる)とLUNを狙ってください。 各PDUはペイロード長を含んでいます、そして、SCSIに含まれたバッファアドレスに比例して相殺されたデータはコマンドプロシジャ呼び出しを実行します。
In each direction, the data transfer is split into "sequences". An end-of-sequence is indicated by the F bit.
各方向では、データ転送が「系列」に分けられます。 系列の終わりはFビットによって示されます。
An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in response to an R2T.
外向的な系列は、求められていないか(最初の系列だけが求められていない場合があります)、またはR2Tに対応して送られたすべての外のData PDUsから成ります。
Input sequences are built to enable the direction switching for bidirectional commands.
入力系列は、双方向のコマンドのために切り替わる方向を可能にするために築き上げられます。
For input, the target may request positive acknowledgement of input data. This is limited to sessions that support error recovery and is implemented through the A bit in the SCSI Data-In PDU header.
入力のために、目標は入力データの積極的な承認を要求するかもしれません。 これは、エラー回復をサポートするセッションまで制限されて、中のSCSI Data PDUヘッダーのAビットを通して実装されます。
Data-In and Data-Out PDUs also carry the DataSN to enable the initiator and target to detect missing PDUs (discarded due to an error).
また、中のデータと外のData PDUsは、なくなったPDUs(誤りのため捨てられる)を検出するために創始者と目標を可能にするDataSNを運びます。
In addition, StatSN is carried by the Data-In PDUs.
さらに、StatSNは中のData PDUsによって運ばれます。
To enable a SCSI command to be processed while involving a minimum number of messages, the last SCSI Data-In PDU passed for a command may also contain the status if the status indicates termination with no exceptions (no sense or response involved).
また、最小の数のメッセージにかかわっている間に処理されるべきSCSIコマンドを可能にするために、状態が例外(かかわった感覚でない応答がない)なしで終了を示すなら、コマンドのために渡された最後の中のSCSI Data PDUは状態を含むかもしれません。
3.5.1.6. Ready To Transfer (R2T)
3.5.1.6. 移す準備ができています。(R2T)
R2T is the mechanism by which the SCSI target "requests" the initiator for output data. R2T specifies to the initiator the offset of the requested data relative to the buffer address from the execute command procedure call and the length of the solicited data.
R2TはSCSI目標が出力データのために創始者を「要求する」メカニズムです。 R2Tがバッファに比例した要求されたデータのオフセットが演説する創始者に指定する、請求されたデータのコマンドプロシジャ呼び出しと長さを実行してください。
To help the SCSI target associate the resulting Data-Out with an R2T, the R2T carries a Target Transfer Tag that will be copied by the initiator in the solicited SCSI Data-Out PDUs. There are no protocol specific requirements with regard to the value of these tags, but it is assumed that together with the LUN, they will enable the target to associate data with an R2T.
SCSI目標が外の結果として起こるDataをR2Tに関連づけるのを助けるために、R2Tは請求された外のSCSI Data PDUsの創始者によってコピーされるTarget Transfer Tagを運びます。 これらのタグの値に関してプロトコル決められた一定の要求が全くありませんが、LUNと共に、彼らが、目標がデータをR2Tに関連づけるのを可能にすると思われます。
Satran, et al. Standards Track [Page 45] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[45ページ]。
R2T also carries information required for proper operation of the iSCSI protocol, such as:
また、R2TはiSCSIプロトコルの適切な操作に必要である以下の情報を運びます。
- R2TSN (to enable an initiator to detect a missing R2T)
- StatSN
- ExpCmdSN
- MaxCmdSN
- R2TSN(創始者がなくなったR2Tを検出するのを可能にする)--StatSN--ExpCmdSN--MaxCmdSN
3.5.2. Requests/Responses carrying SCSI and iSCSI Payload
3.5.2. SCSIとiSCSI有効搭載量を運ぶ要求/応答
3.5.2.1. Asynchronous Message
3.5.2.1. 非同期なメッセージ
Asynchronous Messages are used to carry SCSI asynchronous events (AEN) and iSCSI asynchronous messages.
非同期なMessagesは、SCSI非同期的なイベント(AEN)とiSCSIの非同期なメッセージを伝えるのに使用されます。
When carrying an AEN, the event details are reported as sense data in the data segment.
AENを運ぶとき、イベントの詳細はセンス・データとしてデータ・セグメントで報告されます。
3.5.3. Requests/Responses Carrying iSCSI Only Payload
3.5.3. iSCSIだけを運ぶ要求/応答、有効搭載量
3.5.3.1. Text Request and Text Response
3.5.3.1. テキスト要求とテキスト応答
Text requests and responses are designed as a parameter negotiation vehicle and as a vehicle for future extension.
テキスト要求と応答はパラメタ交渉手段として今後の拡大のための手段として設計されています。
In the data segment, Text Requests/Responses carry text information using a simple "key=value" syntax.
データ・セグメントでは、Text Requests/応答は、簡単な「主要な=値」構文を使用することでテキスト情報を運びます。
Text Request/Responses may form extended sequences using the same Initiator Task Tag. The initiator uses the F (Final) flag bit in the text request header to indicate its readiness to terminate a sequence. The target uses the F (Final) flag bit in the text response header to indicate its consent to sequence termination.
テキストRequest/応答は、同じInitiator Task Tagを使用することで拡張配列を形成するかもしれません。 創始者は、系列を終える準備を示すのにテキスト要求ヘッダーでF(最終的)のフラグビットを使用します。 目標は、系列終了に同意について簡単に述べるのにテキスト応答ヘッダでF(最終的)のフラグビットを使用します。
Text Request and Responses also use the Target Transfer Tag to indicate continuation of an operation or a new beginning. A target that wishes to continue an operation will set the Target Transfer Tag in a Text Response to a value different from the default 0xffffffff. An initiator willing to continue will copy this value into the Target Transfer Tag of the next Text Request. If the initiator wants to restart the current target negotiation (start fresh) will set the Target Transfer Tag to 0xffffffff.
また、テキストRequestとResponsesは、操作か新しい始めの継続を示すのにTarget Transfer Tagを使用します。 それが操作を続けたがっている目標はデフォルト0xffffffffと異なった値へのText ResponseにTarget Transfer Tagをはめ込むでしょう。 続いても構わないと思っている創始者は次のText RequestのTarget Transfer Tagにこの値をコピーするでしょう。 創始者が再開したいなら、現在の目標交渉(新たに、始める)は0xffffffffにTarget Transfer Tagを設定するでしょう。
Although a complete exchange is always started by the initiator, specific parameter negotiations may be initiated by the initiator or target.
完全交換はいつも創始者によって始められますが、特定のパラメタ交渉は創始者か目標によって開始されるかもしれません。
Satran, et al. Standards Track [Page 46] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[46ページ]。
3.5.3.2. Login Request and Login Response
3.5.3.2. ログイン要求とログイン応答
Login Requests and Responses are used exclusively during the Login Phase of each connection to set up the session and connection parameters. (The Login Phase consists of a sequence of login requests and responses carrying the same Initiator Task Tag.)
Login Requests and Responses are used exclusively during the Login Phase of each connection to set up the session and connection parameters. (The Login Phase consists of a sequence of login requests and responses carrying the same Initiator Task Tag.)
A connection is identified by an arbitrarily selected connection-ID (CID) that is unique within a session.
A connection is identified by an arbitrarily selected connection-ID (CID) that is unique within a session.
Similar to the Text Requests and Responses, Login Requests/Responses carry key=value text information with a simple syntax in the data segment.
Similar to the Text Requests and Responses, Login Requests/Responses carry key=value text information with a simple syntax in the data segment.
The Login Phase proceeds through several stages (security negotiation, operational parameter negotiation) that are selected with two binary coded fields in the header -- the "current stage" (CSG) and the "next stage" (NSG) with the appearance of the latter being signaled by the "transit" flag (T).
The Login Phase proceeds through several stages (security negotiation, operational parameter negotiation) that are selected with two binary coded fields in the header -- the "current stage" (CSG) and the "next stage" (NSG) with the appearance of the latter being signaled by the "transit" flag (T).
The first Login Phase of a session plays a special role, called the leading login, which determines some header fields (e.g., the version number, the maximum number of connections, and the session identification).
The first Login Phase of a session plays a special role, called the leading login, which determines some header fields (e.g., the version number, the maximum number of connections, and the session identification).
The CmdSN initial value is also set by the leading login.
The CmdSN initial value is also set by the leading login.
StatSN for each connection is initiated by the connection login.
StatSN for each connection is initiated by the connection login.
A login request may indicate an implied logout (cleanup) of the connection to be logged in (a connection restart) by using the same Connection ID (CID) as an existing connection, as well as the same session identifying elements of the session to which the old connection was associated.
A login request may indicate an implied logout (cleanup) of the connection to be logged in (a connection restart) by using the same Connection ID (CID) as an existing connection, as well as the same session identifying elements of the session to which the old connection was associated.
3.5.3.3. Logout Request and Response
3.5.3.3. Logout Request and Response
Logout Requests and Responses are used for the orderly closing of connections for recovery or maintenance. The logout request may be issued following a target prompt (through an asynchronous message) or at an initiators initiative. When issued on the connection to be logged out, no other request may follow it.
Logout Requests and Responses are used for the orderly closing of connections for recovery or maintenance. The logout request may be issued following a target prompt (through an asynchronous message) or at an initiators initiative. When issued on the connection to be logged out, no other request may follow it.
The Logout Response indicates that the connection or session cleanup is completed and no other responses will arrive on the connection (if received on the logging out connection). In addition, the Logout Response indicates how long the target will continue to hold resources for recovery (e.g., command execution that continues on a
The Logout Response indicates that the connection or session cleanup is completed and no other responses will arrive on the connection (if received on the logging out connection). In addition, the Logout Response indicates how long the target will continue to hold resources for recovery (e.g., command execution that continues on a
Satran, et al. Standards Track [Page 47] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 47] RFC 3720 iSCSI April 2004
new connection) in the text key Time2Retain and how long the initiator must wait before proceeding with recovery in the text key Time2Wait.
new connection) in the text key Time2Retain and how long the initiator must wait before proceeding with recovery in the text key Time2Wait.
3.5.3.4. SNACK Request
3.5.3.4. SNACK Request
With the SNACK Request, the initiator requests retransmission of numbered-responses or data from the target. A single SNACK request covers a contiguous set of missing items, called a run, of a given type of items. The type is indicated in a type field in the PDU header. The run is composed of an initial item (StatSN, DataSN, R2TSN) and the number of missed Status, Data, or R2T PDUs. For long Data-In sequences, the target may request (at predefined minimum intervals) a positive acknowledgement for the data sent. A SNACK request with a type field that indicates ACK and the number of Data-In PDUs acknowledged conveys this positive acknowledgement.
With the SNACK Request, the initiator requests retransmission of numbered-responses or data from the target. A single SNACK request covers a contiguous set of missing items, called a run, of a given type of items. The type is indicated in a type field in the PDU header. The run is composed of an initial item (StatSN, DataSN, R2TSN) and the number of missed Status, Data, or R2T PDUs. For long Data-In sequences, the target may request (at predefined minimum intervals) a positive acknowledgement for the data sent. A SNACK request with a type field that indicates ACK and the number of Data-In PDUs acknowledged conveys this positive acknowledgement.
3.5.3.5. Reject
3.5.3.5. Reject
Reject enables the target to report an iSCSI error condition (e.g., protocol, unsupported option) that uses a Reason field in the PDU header and includes the complete header of the bad PDU in the Reject PDU data segment.
Reject enables the target to report an iSCSI error condition (e.g., protocol, unsupported option) that uses a Reason field in the PDU header and includes the complete header of the bad PDU in the Reject PDU data segment.
3.5.3.6. NOP-Out Request and NOP-In Response
3.5.3.6. NOP-Out Request and NOP-In Response
This request/response pair may be used by an initiator and target as a "ping" mechanism to verify that a connection/session is still active and all of its components are operational. Such a ping may be triggered by the initiator or target. The triggering party indicates that it wants a reply by setting a value different from the default 0xffffffff in the corresponding Initiator/Target Transfer Tag.
This request/response pair may be used by an initiator and target as a "ping" mechanism to verify that a connection/session is still active and all of its components are operational. Such a ping may be triggered by the initiator or target. The triggering party indicates that it wants a reply by setting a value different from the default 0xffffffff in the corresponding Initiator/Target Transfer Tag.
NOP-In/NOP-Out may also be used "unidirectional" to convey to the initiator/target command, status or data counter values when there is no other "carrier" and there is a need to update the initiator/ target.
NOP-In/NOP-Out may also be used "unidirectional" to convey to the initiator/target command, status or data counter values when there is no other "carrier" and there is a need to update the initiator/ target.
4. SCSI Mode Parameters for iSCSI
4. SCSI Mode Parameters for iSCSI
There are no iSCSI specific mode pages.
There are no iSCSI specific mode pages.
5. Login and Full Feature Phase Negotiation
5. Login and Full Feature Phase Negotiation
iSCSI parameters are negotiated at session or connection establishment by using Login Requests and Responses (see Section 3.2.3 iSCSI Login) and during the Full Feature Phase (Section 3.2.4 iSCSI Full Feature Phase) by using Text Requests and Responses. In
iSCSI parameters are negotiated at session or connection establishment by using Login Requests and Responses (see Section 3.2.3 iSCSI Login) and during the Full Feature Phase (Section 3.2.4 iSCSI Full Feature Phase) by using Text Requests and Responses. In
Satran, et al. Standards Track [Page 48] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 48] RFC 3720 iSCSI April 2004
both cases the mechanism used is an exchange of iSCSI-text-key=value pairs. For brevity iSCSI-text-keys are called just keys in the rest of this document.
both cases the mechanism used is an exchange of iSCSI-text-key=value pairs. For brevity iSCSI-text-keys are called just keys in the rest of this document.
Keys are either declarative or require negotiation and the key description indicates if the key is declarative or requires negotiation.
Keys are either declarative or require negotiation and the key description indicates if the key is declarative or requires negotiation.
For the declarative keys, the declaring party sets a value for the key. The key specification indicates if the key can be declared by the initiator, target or both.
For the declarative keys, the declaring party sets a value for the key. The key specification indicates if the key can be declared by the initiator, target or both.
For the keys that require negotiation one of the parties (the proposing party) proposes a value or set of values by including the key=value in the data part of a Login or Text Request or Response PDUs. The other party (the accepting party) makes a selection based on the value or list of values proposed and includes the selected value in a key=value in the data part of one of the following Login or Text Response or Request PDUs. For most of the keys both the initiator and target can be proposing parties.
For the keys that require negotiation one of the parties (the proposing party) proposes a value or set of values by including the key=value in the data part of a Login or Text Request or Response PDUs. The other party (the accepting party) makes a selection based on the value or list of values proposed and includes the selected value in a key=value in the data part of one of the following Login or Text Response or Request PDUs. For most of the keys both the initiator and target can be proposing parties.
The login process proceeds in two stages - the security negotiation stage and the operational parameter negotiation stage. Both stages are optional but at least one of them has to be present to enable the setting of some mandatory parameters.
The login process proceeds in two stages - the security negotiation stage and the operational parameter negotiation stage. Both stages are optional but at least one of them has to be present to enable the setting of some mandatory parameters.
If present, the security negotiation stage precedes the operational parameter negotiation stage.
If present, the security negotiation stage precedes the operational parameter negotiation stage.
Progression from stage to stage is controlled by the T (Transition) bit in the Login Request/Response PDU header. Through the T bit set to 1, the initiator indicates that it would like to transition. The target agrees to the transition (and selects the next stage) when ready. A field in the Login PDU header indicates the current stage (CSG) and during transition, another field indicates the next stage (NSG) proposed (initiator) and selected (target).
Progression from stage to stage is controlled by the T (Transition) bit in the Login Request/Response PDU header. Through the T bit set to 1, the initiator indicates that it would like to transition. The target agrees to the transition (and selects the next stage) when ready. A field in the Login PDU header indicates the current stage (CSG) and during transition, another field indicates the next stage (NSG) proposed (initiator) and selected (target).
The text negotiation process is used to negotiate or declare operational parameters. The negotiation process is controlled by the F (final) bit in the PDU header. During text negotiations, the F bit is used by the initiator to indicate that it is ready to finish the negotiation and by the Target to acquiesce the end of negotiation.
The text negotiation process is used to negotiate or declare operational parameters. The negotiation process is controlled by the F (final) bit in the PDU header. During text negotiations, the F bit is used by the initiator to indicate that it is ready to finish the negotiation and by the Target to acquiesce the end of negotiation.
Since some key=value pairs may not fit entirely in a single PDU, the C (continuation) bit is used (both in Login and Text) to indicate that "more follows".
Since some key=value pairs may not fit entirely in a single PDU, the C (continuation) bit is used (both in Login and Text) to indicate that "more follows".
Satran, et al. Standards Track [Page 49] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 49] RFC 3720 iSCSI April 2004
The text negotiation uses an additional mechanism by which a target may deliver larger amounts of data to an enquiring initiator. The target sets a Target Task Tag to be used as a bookmark that when returned by the initiator, means "go on". If reset to a "neutral value", it means "forget about the rest".
The text negotiation uses an additional mechanism by which a target may deliver larger amounts of data to an enquiring initiator. The target sets a Target Task Tag to be used as a bookmark that when returned by the initiator, means "go on". If reset to a "neutral value", it means "forget about the rest".
This chapter details types of keys and values used, the syntax rules for parameter formation, and the negotiation schemes to be used with different types of parameters.
This chapter details types of keys and values used, the syntax rules for parameter formation, and the negotiation schemes to be used with different types of parameters.
5.1. Text Format
5.1. Text Format
The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case in which they appear in this document. They are case sensitive.
The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case in which they appear in this document. They are case sensitive.
The following character symbols are used in this document for text items (the hexadecimal values represent Unicode code points):
The following character symbols are used in this document for text items (the hexadecimal values represent Unicode code points):
(a-z, A-Z) - letters (0-9) - digits " " (0x20) - space "." (0x2e) - dot "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore "=" (0x3d) - equal ":" (0x3a) - colon "/" (0x2f) - solidus or slash "[" (0x5b) - left bracket "]" (0x5d) - right bracket null (0x00) - null separator "," (0x2c) - comma "~" (0x7e) - tilde
(a-z, A-Z) - letters (0-9) - digits " " (0x20) - space "." (0x2e) - dot "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore "=" (0x3d) - equal ":" (0x3a) - colon "/" (0x2f) - solidus or slash "[" (0x5b) - left bracket "]" (0x5d) - right bracket null (0x00) - null separator "," (0x2c) - comma "~" (0x7e) - tilde
Key=value pairs may span PDU boundaries. An initiator or target that sends partial key=value text within a PDU indicates that more text follows by setting the C bit in the Text or Login Request or Text or Login Response to 1. Data segments in a series of PDUs that have the C bit set to 1 and end with a PDU that have the C bit set to 0, or include a single PDU that has the C bit set to 0, have to be considered as forming a single logical-text-data-segment (LTDS).
Key=value pairs may span PDU boundaries. An initiator or target that sends partial key=value text within a PDU indicates that more text follows by setting the C bit in the Text or Login Request or Text or Login Response to 1. Data segments in a series of PDUs that have the C bit set to 1 and end with a PDU that have the C bit set to 0, or include a single PDU that has the C bit set to 0, have to be considered as forming a single logical-text-data-segment (LTDS).
Every key=value pair, including the last or only pair in a LTDS, MUST be followed by one null (0x00) delimiter.
Every key=value pair, including the last or only pair in a LTDS, MUST be followed by one null (0x00) delimiter.
Satran, et al. Standards Track [Page 50] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 50] RFC 3720 iSCSI April 2004
A key-name is whatever precedes the first "=" in the key=value pair. The term key is used frequently in this document in place of key-name.
A key-name is whatever precedes the first "=" in the key=value pair. The term key is used frequently in this document in place of key-name.
A value is whatever follows the first "=" in the key=value pair up to the end of the key=value pair, but not including the null delimiter.
A value is whatever follows the first "=" in the key=value pair up to the end of the key=value pair, but not including the null delimiter.
The following definitions will be used in the rest of this document:
The following definitions will be used in the rest of this document:
standard-label: A string of one or more characters that consist of
letters, digits, dot, minus, plus, commercial at, or underscore.
A standard-label MUST begin with a capital letter and must not
exceed 63 characters.
standard-label: A string of one or more characters that consist of letters, digits, dot, minus, plus, commercial at, or underscore. A standard-label MUST begin with a capital letter and must not exceed 63 characters.
key-name: A standard-label.
key-name: A standard-label.
text-value: A string of zero or more characters that consist of
letters, digits, dot, minus, plus, commercial at, underscore,
slash, left bracket, right bracket, or colon.
text-value: A string of zero or more characters that consist of letters, digits, dot, minus, plus, commercial at, underscore, slash, left bracket, right bracket, or colon.
iSCSI-name-value: A string of one or more characters that consist
of minus, dot, colon, or any character allowed by the output of
the iSCSI string-prep template as specified in [RFC3722] (see
also Section 3.2.6.2 iSCSI Name Encoding).
iSCSI-name-value: A string of one or more characters that consist of minus, dot, colon, or any character allowed by the output of the iSCSI string-prep template as specified in [RFC3722] (see also Section 3.2.6.2 iSCSI Name Encoding).
iSCSI-local-name-value: A UTF-8 string; no null characters are
allowed in the string. This encoding is to be used for localized
(internationalized) aliases.
iSCSI-local-name-value: A UTF-8 string; no null characters are allowed in the string. This encoding is to be used for localized (internationalized) aliases.
boolean-value: The string "Yes" or "No".
boolean-value: The string "Yes" or "No".
hex-constant: A hexadecimal constant encoded as a string that
starts with "0x" or "0X" followed by one or more digits or the
letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex-constants are
used to encode numerical values or binary strings. When used to
encode numerical values, the excessive use of leading 0 digits is
discouraged. The string following 0X (or 0x) represents a base16
number that starts with the most significant base16 digit,
followed by all other digits in decreasing order of significance
and ending with the least-significant base16 digit. When used to
encode binary strings, hexadecimal constants have an implicit
byte-length that includes four bits for every hexadecimal digit
of the constant, including leading zeroes. For example, a
hex-constant of n hexadecimal digits has a byte-length of (the
integer part of) (n+1)/2.
hex-constant: A hexadecimal constant encoded as a string that starts with "0x" or "0X" followed by one or more digits or the letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex-constants are used to encode numerical values or binary strings. When used to encode numerical values, the excessive use of leading 0 digits is discouraged. The string following 0X (or 0x) represents a base16 number that starts with the most significant base16 digit, followed by all other digits in decreasing order of significance and ending with the least-significant base16 digit. When used to encode binary strings, hexadecimal constants have an implicit byte-length that includes four bits for every hexadecimal digit of the constant, including leading zeroes. For example, a hex-constant of n hexadecimal digits has a byte-length of (the integer part of) (n+1)/2.
Satran, et al. Standards Track [Page 51] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 51] RFC 3720 iSCSI April 2004
decimal-constant: An unsigned decimal number with the digit 0 or a
string of one or more digits that start with a non-zero digit.
Decimal-constants are used to encode numerical values or binary
strings. Decimal constants can only be used to encode binary
strings if the string length is explicitly specified. There is
no implicit length for decimal strings. Decimal-constant MUST
NOT be used for parameter values if the values can be equal or
greater than 2**64 (numerical) or for binary strings that can be
longer than 64 bits.
decimal-constant: An unsigned decimal number with the digit 0 or a string of one or more digits that start with a non-zero digit. Decimal-constants are used to encode numerical values or binary strings. Decimal constants can only be used to encode binary strings if the string length is explicitly specified. There is no implicit length for decimal strings. Decimal-constant MUST NOT be used for parameter values if the values can be equal or greater than 2**64 (numerical) or for binary strings that can be longer than 64 bits.
base64-constant: base64 constant encoded as a string that starts
with "0b" or "0B" followed by 1 or more digits or letters or plus
or slash or equal. The encoding is done according to [RFC2045]
and each character, except equal, represents a base64 digit or a
6-bit binary string. Base64-constants are used to encode
numerical-values or binary strings. When used to encode
numerical values, the excessive use of leading 0 digits (encoded
as A) is discouraged. The string following 0B (or 0b) represents
a base64 number that starts with the most significant base64
digit, followed by all other digits in decreasing order of
significance and ending with the least-significant base64 digit;
the least significant base64 digit may be optionally followed by
pad digits (encoded as equal) that are not considered as part of
the number. When used to encode binary strings, base64-constants
have an implicit
byte-length that includes six bits for every character of the
constant, excluding trailing equals (i.e., a base64-constant of n
base64 characters excluding the trailing equals has a byte-length
of ((the integer part of) (n*3/4)). Correctly encoded base64
strings cannot have n values of 1, 5 ... k*4+1.
base64-constant: base64 constant encoded as a string that starts with "0b" or "0B" followed by 1 or more digits or letters or plus or slash or equal. The encoding is done according to [RFC2045] and each character, except equal, represents a base64 digit or a 6-bit binary string. Base64-constants are used to encode numerical-values or binary strings. When used to encode numerical values, the excessive use of leading 0 digits (encoded as A) is discouraged. The string following 0B (or 0b) represents a base64 number that starts with the most significant base64 digit, followed by all other digits in decreasing order of significance and ending with the least-significant base64 digit; the least significant base64 digit may be optionally followed by pad digits (encoded as equal) that are not considered as part of the number. When used to encode binary strings, base64-constants have an implicit byte-length that includes six bits for every character of the constant, excluding trailing equals (i.e., a base64-constant of n base64 characters excluding the trailing equals has a byte-length of ((the integer part of) (n*3/4)). Correctly encoded base64 strings cannot have n values of 1, 5 ... k*4+1.
numerical-value: An unsigned integer always less than 2**64 encoded
as a decimal-constant or a hex-constant. Unsigned integer
arithmetic applies to numerical-values.
numerical-value: An unsigned integer always less than 2**64 encoded as a decimal-constant or a hex-constant. Unsigned integer arithmetic applies to numerical-values.
large-numerical-value: An unsigned integer that can be larger than
or equal to 2**64 encoded as a hex constant, or
base64-constant. Unsigned integer arithmetic applies to
large-numeric-values.
large-numerical-value: An unsigned integer that can be larger than or equal to 2**64 encoded as a hex constant, or base64-constant. Unsigned integer arithmetic applies to large-numeric-values.
numeric-range: Two numerical-values separated by a tilde where the
value to the right of tilde must not be lower than the value to
the left.
numeric-range: Two numerical-values separated by a tilde where the value to the right of tilde must not be lower than the value to the left.
regular-binary-value: A binary string not longer than 64 bits
encoded as a decimal constant, hex constant, or base64-constant.
The length of the string is either specified by the key
definition or is the implicit byte-length of the encoded string.
regular-binary-value: A binary string not longer than 64 bits encoded as a decimal constant, hex constant, or base64-constant. The length of the string is either specified by the key definition or is the implicit byte-length of the encoded string.
Satran, et al. Standards Track [Page 52] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 52] RFC 3720 iSCSI April 2004
large-binary-value: A binary string longer than 64 bits encoded as
a hex-constant or base64-constant. The length of the string is
either specified by the key definition or is the implicit
byte-length of the encoded string.
large-binary-value: A binary string longer than 64 bits encoded as a hex-constant or base64-constant. The length of the string is either specified by the key definition or is the implicit byte-length of the encoded string.
binary-value: A regular-binary-value or a large-binary-value.
Operations on binary values are key specific.
binary-value: A regular-binary-value or a large-binary-value. Operations on binary values are key specific.
simple-value: Text-value, iSCSI-name-value, boolean-value,
numeric-value, a numeric-range, or a binary-value.
simple-value: Text-value, iSCSI-name-value, boolean-value, numeric-value, a numeric-range, or a binary-value.
list-of-values: A sequence of text-values separated by a comma.
list-of-values: A sequence of text-values separated by a comma.
If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes, not including the delimiter (comma or zero byte).
If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes, not including the delimiter (comma or zero byte).
Any iSCSI target or initiator MUST support receiving at least 8192 bytes of key=value data in a negotiation sequence. When proposing or accepting authentication methods that explicitly require support for very long authentication items, the initiator and target MUST support receiving of at least 64 kilobytes of key=value data (see Appendix 11.1.2 - Simple Public-Key Mechanism (SPKM) - that require support for public key certificates).
Any iSCSI target or initiator MUST support receiving at least 8192 bytes of key=value data in a negotiation sequence. When proposing or accepting authentication methods that explicitly require support for very long authentication items, the initiator and target MUST support receiving of at least 64 kilobytes of key=value data (see Appendix 11.1.2 - Simple Public-Key Mechanism (SPKM) - that require support for public key certificates).
5.2. Text Mode Negotiation
5.2. Text Mode Negotiation
During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information.
During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information.
The initiator starts the negotiation and/or declaration through a Text or Login Request and indicates when it is ready for completion (by setting the F bit to 1 and keeping it to 1 in a Text Request or the T bit in the Login Request). As negotiation text may span PDU boundaries, a Text or Login Request or Text or Login Response PDU that has the C bit set to 1 MUST NOT have the F/T bit set to 1.
The initiator starts the negotiation and/or declaration through a Text or Login Request and indicates when it is ready for completion (by setting the F bit to 1 and keeping it to 1 in a Text Request or the T bit in the Login Request). As negotiation text may span PDU boundaries, a Text or Login Request or Text or Login Response PDU that has the C bit set to 1 MUST NOT have the F/T bit set to 1.
A target receiving a Text or Login Request with the C bit set to 1 MUST answer with a Text or Login Response with no data segment (DataSegmentLength 0). An initiator receiving a Text or Login Response with the C bit set to 1 MUST answer with a Text or Login Request with no data segment (DataSegmentLength 0).
A target receiving a Text or Login Request with the C bit set to 1 MUST answer with a Text or Login Response with no data segment (DataSegmentLength 0). An initiator receiving a Text or Login Response with the C bit set to 1 MUST answer with a Text or Login Request with no data segment (DataSegmentLength 0).
A target or initiator SHOULD NOT use a Text or Login Response or Text or Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule.
A target or initiator SHOULD NOT use a Text or Login Response or Text or Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule.
Satran, et al. Standards Track [Page 53] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 53] RFC 3720 iSCSI April 2004
The format of a declaration is:
The format of a declaration is:
Declarer-> <key>=<valuex>
Declarer-> <key>=<valuex>
The general format of text negotiation is:
The general format of text negotiation is:
Proposer-> <key>=<valuex>
Acceptor-> <key>={<valuey>|NotUnderstood|Irrelevant|Reject}
Proposer-> <key>=<valuex> Acceptor-> <key>={<valuey>|NotUnderstood|Irrelevant|Reject}
Thus a declaration is a one-way textual exchange while a negotiation is a two-way exchange.
Thus a declaration is a one-way textual exchange while a negotiation is a two-way exchange.
The proposer or declarer can either be the initiator or the target, and the acceptor can either be the target or initiator, respectively. Targets are not limited to respond to key=value pairs as proposed by the initiator. The target may propose key=value pairs of its own.
The proposer or declarer can either be the initiator or the target, and the acceptor can either be the target or initiator, respectively. Targets are not limited to respond to key=value pairs as proposed by the initiator. The target may propose key=value pairs of its own.
All negotiations are explicit (i.e., the result MUST only be based on newly exchanged or declared values). There are no implicit proposals. If a proposal is not made, then a reply cannot be expected. Conservative design also requires that default values should not be relied upon when use of some other value has serious consequences.
All negotiations are explicit (i.e., the result MUST only be based on newly exchanged or declared values). There are no implicit proposals. If a proposal is not made, then a reply cannot be expected. Conservative design also requires that default values should not be relied upon when use of some other value has serious consequences.
The value proposed or declared can be a numerical-value, a numerical-range defined by lower and upper values with both integers separated by a tilde, a binary value, a text-value, an iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes or No), or a list of comma separated text-values. A range, a large-numerical-value, an iSCSI-name-value and an iSCSI-local-name-value MAY ONLY be used if it is explicitly allowed. An accepted value can be a numerical-value, a large-numerical-value, a text-value, or a boolean-value.
The value proposed or declared can be a numerical-value, a numerical-range defined by lower and upper values with both integers separated by a tilde, a binary value, a text-value, an iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes or No), or a list of comma separated text-values. A range, a large-numerical-value, an iSCSI-name-value and an iSCSI-local-name-value MAY ONLY be used if it is explicitly allowed. An accepted value can be a numerical-value, a large-numerical-value, a text-value, or a boolean-value.
If a specific key is not relevant for the current negotiation, the acceptor may answer with the constant "Irrelevant" for all types of negotiation. However the negotiation is not considered as failed if the answer is "Irrelevant". The "Irrelevant" answer is meant for those cases in which several keys are presented by a proposing party but the selection made by the acceptor for one of the keys makes other keys irrelevant. The following example illustrates the use of "Irrelevant":
If a specific key is not relevant for the current negotiation, the acceptor may answer with the constant "Irrelevant" for all types of negotiation. However the negotiation is not considered as failed if the answer is "Irrelevant". The "Irrelevant" answer is meant for those cases in which several keys are presented by a proposing party but the selection made by the acceptor for one of the keys makes other keys irrelevant. The following example illustrates the use of "Irrelevant":
I->T OFMarker=Yes,OFMarkInt=2048~8192 T->I OFMarker=No,OFMarkInt=Irrelevant
I->T OFMarker=Yes,OFMarkInt=2048~8192 T->I OFMarker=No,OFMarkInt=Irrelevant
I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb) T->I X#vkey1=None,X#vkey2=Irrelevant
I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb) T->I X#vkey1=None,X#vkey2=Irrelevant
Satran, et al. Standards Track [Page 54] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 54] RFC 3720 iSCSI April 2004
Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, the answer for a key not understood MUST be key=NotUnderstood.
Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, the answer for a key not understood MUST be key=NotUnderstood.
The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrelevant", and "NotUnderstood" as proposed values).
The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrelevant", and "NotUnderstood" as proposed values).
Reject or Irrelevant are legitimate negotiation options where allowed but their excessive use is discouraged. A negotiation is considered complete when the acceptor has sent the key value pair even if the value is "Reject", "Irrelevant", or "NotUnderstood. Sending the key again would be a re-negotiation and is forbidden for many keys.
Reject or Irrelevant are legitimate negotiation options where allowed but their excessive use is discouraged. A negotiation is considered complete when the acceptor has sent the key value pair even if the value is "Reject", "Irrelevant", or "NotUnderstood. Sending the key again would be a re-negotiation and is forbidden for many keys.
If the acceptor sends "Reject" as an answer the negotiated key is left at its current value (or default if no value was set). If the current value is not acceptable to the proposer on the connection or to the session it is sent, the proposer MAY choose to terminate the connection or session.
If the acceptor sends "Reject" as an answer the negotiated key is left at its current value (or default if no value was set). If the current value is not acceptable to the proposer on the connection or to the session it is sent, the proposer MAY choose to terminate the connection or session.
All keys in this document, except for the X extension formats, MUST be supported by iSCSI initiators and targets when used as specified here. If used as specified, these keys MUST NOT be answered with NotUnderstood.
All keys in this document, except for the X extension formats, MUST be supported by iSCSI initiators and targets when used as specified here. If used as specified, these keys MUST NOT be answered with NotUnderstood.
Implementers may introduce new keys by prefixing them with "X-", followed by their (reversed) domain name, or with new keys registered with IANA prefixing them with X#. For example, the entity owning the domain example.com can issue:
Implementers may introduce new keys by prefixing them with "X-", followed by their (reversed) domain name, or with new keys registered with IANA prefixing them with X#. For example, the entity owning the domain example.com can issue:
X-com.example.bar.foo.do_something=3
X-com.example.bar.foo.do_something=3
or a new registered key may be used as in:
or a new registered key may be used as in:
X#SuperCalyPhraGilistic=Yes
X#SuperCalyPhraGilistic=Yes
Implementers MAY also introduce new values, but ONLY for new keys or authentication methods (see Section 11 iSCSI Security Text Keys and Authentication Methods), or digests (see Section 12.1 HeaderDigest and DataDigest).
Implementers MAY also introduce new values, but ONLY for new keys or authentication methods (see Section 11 iSCSI Security Text Keys and Authentication Methods), or digests (see Section 12.1 HeaderDigest and DataDigest).
Whenever parameter action or acceptance is dependent on other parameters, the dependency rules and parameter sequence must be specified with the parameters.
Whenever parameter action or acceptance is dependent on other parameters, the dependency rules and parameter sequence must be specified with the parameters.
Satran, et al. Standards Track [Page 55] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 55] RFC 3720 iSCSI April 2004
In the Login Phase (see Section 5.3 Login Phase), every stage is a separate negotiation. In the FullFeaturePhase, a Text Request Response sequence is a negotiation. Negotiations MUST be handled as atomic operations. For example, all negotiated values go into effect after the negotiation concludes in agreement or are ignored if the negotiation fails.
In the Login Phase (see Section 5.3 Login Phase), every stage is a separate negotiation. In the FullFeaturePhase, a Text Request Response sequence is a negotiation. Negotiations MUST be handled as atomic operations. For example, all negotiated values go into effect after the negotiation concludes in agreement or are ignored if the negotiation fails.
Some parameters may be subject to integrity rules (e.g., parameter-x must not exceed parameter-y or parameter-u not 1 implies parameter-v be Yes). Whenever required, integrity rules are specified with the keys. Checking for compliance with the integrity rule must only be performed after all the parameters are available (the existent and the newly negotiated). An iSCSI target MUST perform integrity checking before the new parameters take effect. An initiator MAY perform integrity checking.
Some parameters may be subject to integrity rules (e.g., parameter-x must not exceed parameter-y or parameter-u not 1 implies parameter-v be Yes). Whenever required, integrity rules are specified with the keys. Checking for compliance with the integrity rule must only be performed after all the parameters are available (the existent and the newly negotiated). An iSCSI target MUST perform integrity checking before the new parameters take effect. An initiator MAY perform integrity checking.
An iSCSI initiator or target MAY terminate a negotiation that does not end within a reasonable time or number of exchanges.
An iSCSI initiator or target MAY terminate a negotiation that does not end within a reasonable time or number of exchanges.
5.2.1. List negotiations
5.2.1. List negotiations
In list negotiation, the originator sends a list of values (which may include "None") in its order of preference.
In list negotiation, the originator sends a list of values (which may include "None") in its order of preference.
The responding party MUST respond with the same key and the first value that it supports (and is allowed to use for the specific originator) selected from the originator list.
The responding party MUST respond with the same key and the first value that it supports (and is allowed to use for the specific originator) selected from the originator list.
The constant "None" MUST always be used to indicate a missing function. However, "None" is only a valid selection if it is explicitly proposed.
The constant "None" MUST always be used to indicate a missing function. However, "None" is only a valid selection if it is explicitly proposed.
If an acceptor does not understand any particular value in a list, it MUST ignore it. If an acceptor does not support, does not understand, or is not allowed to use any of the proposed options with a specific originator, it may use the constant "Reject" or terminate the negotiation. The selection of a value not proposed MUST be handled as a protocol error.
If an acceptor does not understand any particular value in a list, it MUST ignore it. If an acceptor does not support, does not understand, or is not allowed to use any of the proposed options with a specific originator, it may use the constant "Reject" or terminate the negotiation. The selection of a value not proposed MUST be handled as a protocol error.
5.2.2. Simple-value Negotiations
5.2.2. Simple-value Negotiations
For simple-value negotiations, the accepting party MUST answer with the same key. The value it selects becomes the negotiation result.
For simple-value negotiations, the accepting party MUST answer with the same key. The value it selects becomes the negotiation result.
Proposing a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject" or the acceptor MAY select an admissible value.
Proposing a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject" or the acceptor MAY select an admissible value.
Satran, et al. Standards Track [Page 56] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 56] RFC 3720 iSCSI April 2004
The selection by the acceptor, of a value not admissible under the selection rules is considered a protocol error. The selection rules are key-specific.
アクセプタによる選択であり、容認できない選択で価値では、規則はプロトコル誤りであると考えられます。 選択規則は主要に特定です。
For a numerical range, the value selected must be an integer within the proposed range or "Reject" (if the range is unacceptable).
数字の範囲に、選択された値は提案された範囲か「廃棄物」の中の整数でなければなりません(範囲が容認できないなら)。
In Boolean negotiations (i.e., those that result in keys taking the values Yes or No), the accepting party MUST answer with the same key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value to answer with are expressed as Boolean functions of the value received, and the value that the accepting party would have selected if given a choice.
ブール交渉、(すなわち、値を取るキーをもたらすもの、はいかいいえ、)、受諾パーティーは同じキーによる答えと容認された値自体がその結果を決定しないときの交渉の結果がそうしなければなりません。 伝えられた最終値は交渉結果になります。 答える値を選択するための規則は対価領収のブール関数、および選択を与えるなら受諾パーティーが選択させる値として表されます。
Specifically, the two cases in which answers are OPTIONAL are:
明確に、答えがOPTIONALである2つの場合は以下の通りです。
- The Boolean function is "AND" and the value "No" is received.
The outcome of the negotiation is "No".
- The Boolean function is "OR" and the value "Yes" is received.
The outcome of the negotiation is "Yes".
- ブール関数は“AND"です、そして、値の「いいえ」は受け取られています。 交渉の結果は「いいえ」です。 - ブール関数は「OR」です、そして、値の「はい」は受け取られています。 交渉の結果は「はい」です。
Responses are REQUIRED in all other cases, and the value chosen and sent by the acceptor becomes the outcome of the negotiation.
応答は他のすべての場合でREQUIREDです、そして、アクセプタによって選ばれていて、送られた値は交渉の結果になります。
5.3. Login Phase
5.3. ログインフェーズ
The Login Phase establishes an iSCSI connection between an initiator and a target; it also creates a new session or associates the connection to an existing session. The Login Phase sets the iSCSI protocol parameters, security parameters, and authenticates the initiator and target to each other.
Login Phaseは創始者と目標とのiSCSI接続を確立します。 それは、また、新しいセッションを作成するか、または既存のセッションまで接続を関連づけます。 Login PhaseはiSCSIプロトコルパラメタ、セキュリティパラメタを設定して、創始者と目標を互いに認証します。
The Login Phase is only implemented via Login Request and Responses. The whole Login Phase is considered as a single task and has a single Initiator Task Tag (similar to the linked SCSI commands).
Login PhaseはLogin RequestとResponsesを通して実行されるだけです。 全体のLogin Phaseはシングルタスクであるとみなされて、独身のInitiator Task Tagを持っています(繋がっているSCSIコマンドと同様の)。
The default MaxRecvDataSegmentLength is used during Login.
デフォルトMaxRecvDataSegmentLengthはLoginの間、使用されます。
The Login Phase sequence of requests and responses proceeds as follows:
要求と応答のLogin Phase系列は以下の通り続きます:
- Login initial request
- Login partial response (optional)
- More Login Requests and Responses (optional)
- Login Final-Response (mandatory)
- ログインの初期の要求--ログイン部分応答(任意の)(より多くのLogin RequestsとResponses(任意の))ログインFinal-応答(義務的)です。
Satran, et al. Standards Track [Page 57] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[57ページ]。
The initial Login Request of any connection MUST include the InitiatorName key=value pair. The initial Login Request of the first connection of a session MAY also include the SessionType key=value pair. For any connection within a session whose type is not "Discovery", the first Login Request MUST also include the TargetName key=value pair.
どんな接続の初期のLogin RequestもInitiatorName主要な=値組を含まなければなりません。 また、セッションの最初の接続の初期のLogin RequestはSessionType主要な=値組を含むかもしれません。 また、タイプが「発見」でないセッション以内のどんな接続のためにも、最初のLogin RequestはTargetName主要な=値組を含まなければなりません。
The Login Final-response accepts or rejects the Login Request.
Login Final-応答は、Login Requestを受け入れるか、または拒絶します。
The Login Phase MAY include a SecurityNegotiation stage and a LoginOperationalNegotiation stage or both, but MUST include at least one of them. The included stage MAY be empty except for the mandatory names.
Login PhaseはSecurityNegotiationステージとLoginOperationalNegotiationステージか両方を含むかもしれませんが、少なくともそれらの1つを含まなければなりません。 義務的な名前を除いて、含まれているステージは人影がないかもしれません。
The Login Requests and Responses contain a field (CSG) that indicates the current negotiation stage (SecurityNegotiation or LoginOperationalNegotiation). If both stages are used, the SecurityNegotiation MUST precede the LoginOperationalNegotiation.
Login RequestsとResponsesは現在の交渉ステージ(SecurityNegotiationかLoginOperationalNegotiation)を示す分野(CSG)を含んでいます。 両方のステージが使用されているなら、SecurityNegotiationはLoginOperationalNegotiationに先行しなければなりません。
Some operational parameters can be negotiated outside the login through Text Requests and Responses.
Text RequestsとResponsesを通したログインの外でいくつかの操作上のパラメタを交渉できます。
Security MUST be completely negotiated within the Login Phase. The use of underlying IPsec security is specified in Chapter 8 and in [RFC3723]. iSCSI support for security within the protocol only consists of authentication in the Login Phase.
Login Phaseの中でセキュリティを完全に交渉しなければなりません。 基本的なIPsecセキュリティの使用は第8章と[RFC3723]で指定されます。プロトコルの中のセキュリティのiSCSIサポートはLogin Phaseで認証から成るだけです。
In some environments, a target or an initiator is not interested in authenticating its counterpart. It is possible to bypass authentication through the Login Request and Response.
いくつかの環境で、目標か創始者が対応者を認証したがっていません。 Login RequestとResponseを通した認証を迂回させるのは可能です。
The initiator and target MAY want to negotiate iSCSI authentication parameters. Once this negotiation is completed, the channel is considered secure.
創始者と目標はiSCSI認証パラメタを交渉したがっているかもしれません。 この交渉がいったん終了されていると、チャンネルは安全であると考えられます。
Most of the negotiation keys are only allowed in a specific stage. The SecurityNegotiation keys appear in Chapter 11 and the LoginOperationalNegotiation keys appear in Chapter 12. Only a limited set of keys (marked as Any-Stage in Chapter 12) may be used in any of the two stages.
交渉キーの大部分は特定の段階に許容されているだけです。 SecurityNegotiationキーは連邦破産法11条に現れます、そして、LoginOperationalNegotiationキーは第12章に現れます。 2つのステージのいずれでも限られたセットのキー(Any-ステージとして、第12章では、マークされる)だけを使用してもよいです。
Any given Login Request or Response belongs to a specific stage; this determines the negotiation keys allowed with the request or response. It is considered to be a protocol error to send a key that is not allowed in the current stage.
どんな与えられたLogin RequestやResponseも特定のステージに属します。 これは要求か応答で許容された交渉キーを決定します。 それは、現在の段階に許容されていないキーを送るためにプロトコル誤りであると考えられます。
Satran, et al. Standards Track [Page 58] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[58ページ]。
Stage transition is performed through a command exchange (request/ response) that carries the T bit and the same CSG code. During this exchange, the next stage is selected by the target through the "next stage" code (NSG). The selected NSG MUST NOT exceed the value stated by the initiator. The initiator can request a transition whenever it is ready, but a target can only respond with a transition after one is proposed by the initiator.
Tビットと同じCSGコードを運ぶコマンド交換(要求/応答)を通してステージ変化をします。 この交換の間、次のステージは「次のステージ」コード(NSG)を通して目標によって選択されます。 選択されたNSG MUST NOTは創始者によって述べられた値を超えています。 それが準備ができているときはいつも、創始者は変遷を要求できますが、1つが創始者によって提案された後に目標は変遷で応じることができるだけです。
In a negotiation sequence, the T bit settings in one pair of Login Request-Responses have no bearing on the T bit settings of the next pair. An initiator that has a T bit set to 1 in one pair and is answered with a T bit setting of 0, may issue the next request with the T bit set to 0.
交渉系列では、Login Request-応答の1組のT噛み付いている設定は次の組のT噛み付いている設定の上に堪えることを持っていません。 1組でTビットを1に設定させて、Tビットがセットしている状態で答えられる、0歳の創始者、0に設定されたTビットによる次の要求を出すかもしれません。
When a transition is requested by the initiator and acknowledged by the target, both the initiator and target switch to the selected stage.
変遷が創始者によって要求されていて、目標によって承諾されるとき、創始者と目標の両方が選択されたステージに切り替わります。
Targets MUST NOT submit parameters that require an additional initiator Login Request in a Login Response with the T bit set to 1.
目標はLogin Responseで1に設定されたTビットで追加創始者Login Requestを必要とするパラメタを提出してはいけません。
Stage transitions during login (including entering and exit) are only possible as outlined in the following table:
ログイン(入るのと出口を含んでいる)の間のステージ変遷は単に以下のテーブルに概説されているように可能です:
+-----------------------------------------------------------+ |From To -> | Security | Operational | FullFeature | | | | | | | | V | | | | +-----------------------------------------------------------+ | (start) | yes | yes | no | +-----------------------------------------------------------+ | Security | no | yes | yes | +-----------------------------------------------------------+ | Operational | no | no | yes | +-----------------------------------------------------------+
+-----------------------------------------------------------+ |->。| セキュリティ| 操作上| FullFeature| | | | | | | | V| | | | +-----------------------------------------------------------+ | (始め) | はい| はい| いいえ| +-----------------------------------------------------------+ | セキュリティ| いいえ| はい| はい| +-----------------------------------------------------------+ | 操作上| いいえ| いいえ| はい| +-----------------------------------------------------------+
The Login Final-Response that accepts a Login Request can only come as a response to a Login Request with the T bit set to 1, and both the request and response MUST indicate FullFeaturePhase as the next phase via the NSG field.
TビットがあるLogin Requestへの応答が1にセットしたとき、Login Requestを受け入れるLogin Final-応答は来ることができるだけです、そして、要求と応答の両方が次のフェーズとしてNSG分野を通ってFullFeaturePhaseを示さなければなりません。
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g., TargetAddress). An attempt to renegotiate/redeclare parameters not specifically allowed MUST be detected by the initiator and target. If such an attempt is detected
創始者も目標も、明らかに、繰り返された主要な宣言(例えば、TargetAddress)を許容する特定のキーへの応答以外のログインの間の一度より多くのパラメタを宣言するか、または交渉するのを試みるはずがありません。 創始者と目標で明確に許容されなかった/redeclareパラメタを再交渉する試みを検出しなければなりません。 そのような試みが検出されるなら
Satran, et al. Standards Track [Page 59] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[59ページ]。
by the target, the target MUST respond with Login reject (initiator error); if detected by the initiator, the initiator MUST drop the connection.
目標で、目標はLoginと共に廃棄物(創始者誤り)を反応させなければなりません。 創始者によって検出されるなら、創始者は接続を落とさなければなりません。
5.3.1. Login Phase Start
5.3.1. ログインフェーズ始め
The Login Phase starts with a Login Request from the initiator to the target. The initial Login Request includes:
Login Phaseは創始者から目標までLogin Requestから始まります。 初期のLogin Requestは:
- Protocol version supported by the initiator.
- iSCSI Initiator Name and iSCSI Target Name
- ISID, TSIH, and connection Ids
- Negotiation stage that the initiator is ready to enter.
- 創始者によって支持されたバージョンについて議定書の中で述べてください。 - iSCSI Initiator NameとiSCSI Target Name--ISID、TSIH、および接続Ids--創始者が登場する準備ができている交渉ステージ。
A login may create a new session or it may add a connection to an existing session. Between a given iSCSI Initiator Node (selected only by an InitiatorName) and a given iSCSI target defined by an iSCSI TargetName and a Target Portal Group Tag, the login results are defined by the following table:
ログインが新しいセッションを作成するかもしれませんか、またはそれは既存のセッションに接続を加えるかもしれません。 与えられたiSCSI Initiator Node(単にInitiatorNameによって選択される)とiSCSI TargetNameとTarget Portal Group Tagによって定義された与えられたiSCSI目標の間では、ログイン結果は以下のテーブルによって定義されます:
+------------------------------------------------------------------+
|ISID | TSIH | CID | Target action |
+------------------------------------------------------------------+
|new | non-zero | any | fail the login |
| | | | ("session does not exist") |
+------------------------------------------------------------------+
|new | zero | any | instantiate a new session |
+------------------------------------------------------------------+
|existing | zero | any | do session reinstatement |
| | | | (see section 5.3.5) |
+------------------------------------------------------------------+
|existing | non-zero | new | add a new connection to |
| | existing | | the session |
+------------------------------------------------------------------+
|existing | non-zero |existing| do connection reinstatement|
| | existing | | (see section 5.3.4) |
+------------------------------------------------------------------+
|existing | non-zero | any | fail the login |
| | new | | ("session does not exist") |
+------------------------------------------------------------------+
+------------------------------------------------------------------+ |ISID| TSIH| Cid| 目標動作| +------------------------------------------------------------------+ |新しい| 非ゼロ| いくらか| ログインに失敗してください。| | | | | (「セッションは存在していません」) | +------------------------------------------------------------------+ |新しい| ゼロ| いくらか| 新しいセッションを例示してください。| +------------------------------------------------------------------+ |存在しています。| ゼロ| いくらか| セッション復職をしてください。| | | | | (セクション5.3.5を見ます) | +------------------------------------------------------------------+ |存在しています。| 非ゼロ| 新しい| 新しい接続を加えます。| | | 存在しています。| | セッション| +------------------------------------------------------------------+ |存在しています。| 非ゼロ|存在しています。| 接続に復職してください。| | | 存在しています。| | (セクション5.3.4を見ます) | +------------------------------------------------------------------+ |存在しています。| 非ゼロ| いくらか| ログインに失敗してください。| | | 新しい| | (「セッションは存在していません」) | +------------------------------------------------------------------+
Determination of "existing" or "new" are made by the target.
目標は「既存である」か「新しいこと」の決断をします。
Satran, et al. Standards Track [Page 60] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[60ページ]。
Optionally, the Login Request may include:
任意に、Login Requestは以下を含むかもしれません。
- Security parameters
OR
- iSCSI operational parameters
AND/OR
- The next negotiation stage that the initiator is ready to
enter.
- セキュリティパラメタOR--iSCSIの操作上のパラメタAND/OR--創始者が登場する準備ができている次の交渉ステージ。
The target can answer the login in the following ways:
目標は以下の方法でログインに答えることができます:
- Login Response with Login reject. This is an immediate rejection
from the target that causes the connection to terminate and the
session to terminate if this is the first (or only) connection of
a new session. The T bit and the CSG and NSG fields are
reserved.
- Login Response with Login Accept as a final response (T bit set
to 1 and the NSG in both request and response are set to
FullFeaturePhase). The response includes the protocol version
supported by the target and the session ID, and may include iSCSI
operational or security parameters (that depend on the current
stage).
- Login Response with Login Accept as a partial response (NSG not
set to FullFeaturePhase in both request and response) that
indicates the start of a negotiation sequence. The response
includes the protocol version supported by the target and either
security or iSCSI parameters (when no security mechanism is
chosen) supported by the target.
- Login廃棄物があるログインResponse。 これは終える接続とセッションがこれが新しいセッションの最初(単に)の接続であるなら終わる目標からの即座の拒絶です。 Tビット、CSG、およびNSG分野は予約されています。 - 最終的な応答(Tビットは1にセットしました、そして、要求と応答の両方のNSGはFullFeaturePhaseに用意ができている)としてのLogin AcceptとログインResponse。 応答は、目標とセッションIDによって支持されたプロトコルバージョンを含んでいて、iSCSI操作上かセキュリティパラメタを含むかもしれません(それを現在のステージに依存します)。 - 交渉系列の始まりを示す部分応答(NSGは要求と応答の両方にFullFeaturePhaseにセットしなかった)としてのLogin AcceptとログインResponse。 応答は目標によって支えられた目標とセキュリティかiSCSIパラメタ(セキュリティー対策が全く選ばれていないと)のどちらかによって支持されたプロトコルバージョンを含んでいます。
If the initiator decides to forego the SecurityNegotiation stage, it issues the Login with the CSG set to LoginOperationalNegotiation and the target may reply with a Login Response that indicates that it is unwilling to accept the connection (see Section 10.13 Login Response) without SecurityNegotiation and will terminate the connection with a response of Authentication failure (see Section 10.13.5 Status-Class and Status-Detail).
創始者が、SecurityNegotiationステージに先立つと決めるなら、CSGセットでLoginOperationalNegotiationにLoginを発行します、そして、目標はSecurityNegotiationなしで接続(セクション10.13 Login Responseを見る)を受け入れるのが不本意であることを示して、Authenticationの故障の応答との関係を終えるLogin Responseと共に返答するかもしれません(セクション10.13.5のStatus-クラスとStatus-詳細を見てください)。
If the initiator is willing to negotiate iSCSI security, but is unwilling to make the initial parameter proposal and may accept a connection without iSCSI security, it issues the Login with the T bit set to 1, the CSG set to SecurityNegotiation, and the NSG set to LoginOperationalNegotiation. If the target is also ready to skip security, the Login Response only contains the TargetPortalGroupTag key (see Section 12.9 TargetPortalGroupTag), the T bit set to 1, the CSG set to SecurityNegotiation, and the NSG set to LoginOperationalNegotiation.
創始者がiSCSIセキュリティを交渉することを望みますが、初期値パラメタ提案をするように不本意であり、iSCSIセキュリティなしで接続を受け入れるかもしれないなら、それは1に設定されたTビットでLoginを発行します、そして、CSGはSecurityNegotiationにセットしました、そして、NSGはLoginOperationalNegotiationにセットしました。 また、目標もセキュリティをスキップする準備ができているなら、Login ResponseはTargetPortalGroupTagキーを含むだけです、そして、(セクション12.9 TargetPortalGroupTagを見てください)Tビットは1にセットしました、そして、CSGはSecurityNegotiationにセットしました、そして、NSGはLoginOperationalNegotiationにセットしました。
Satran, et al. Standards Track [Page 61] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[61ページ]。
An initiator that chooses to operate without iSCSI security, with all the operational parameters taking the default values, issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation, and the NSG set to FullFeaturePhase. If the target is also ready to forego security and can finish its LoginOperationalNegotiation, the Login Response has T bit set to 1, the CSG set to LoginOperationalNegotiation, and the NSG set to FullFeaturePhase in the next stage.
すべての操作上のパラメタがデフォルト値を取っていてiSCSIセキュリティなしで作動するのを選ぶ創始者は1に設定されたTビットでLoginを発行します、そして、CSGはLoginOperationalNegotiationにセットしました、そして、NSGはFullFeaturePhaseにセットしました。 目標がまた、セキュリティに先立つ準備ができていて、LoginOperationalNegotiationを終えることができるなら、Login ResponseはTビットを1に設定させます、そして、CSGはLoginOperationalNegotiationにセットしました、そして、NSGは次の段階にFullFeaturePhaseにセットしました。
During the Login Phase the iSCSI target MUST return the TargetPortalGroupTag key with the first Login Response PDU with which it is allowed to do so (i.e., the first Login Response issued after the first Login Request with the C bit set to 0) for all session types when TargetName is given and the response is not a redirection. The TargetPortalGroupTag key value indicates the iSCSI portal group servicing the Login Request PDU. If the reconfiguration of iSCSI portal groups is a concern in a given environment, the iSCSI initiator should use this key to ascertain that it had indeed initiated the Login Phase with the intended target portal group.
TargetNameを与えて、応答がリダイレクションでないときに、iSCSI目標が返さなければならないLogin Phaseの間、すべてのセッションのためにそうそれと(すなわち、Cビットがある最初のLogin Requestが0にセットした後に発行された最初のLogin Response)をできる最初のLogin Response PDUによって主要なTargetPortalGroupTagはタイプします。 TargetPortalGroupTagキー値はLogin Request PDUを調整するiSCSI入り口のグループを示します。 iSCSI入り口のグループの再構成が与えられた環境で関心であるなら、iSCSI創始者は、本当に、意図している目標入り口のグループと共にLogin Phaseを開始したのを確かめるのにこのキーを使用するべきです。
5.3.2. iSCSI Security Negotiation
5.3.2. iSCSIセキュリティ交渉
The security exchange sets the security mechanism and authenticates the initiator user and the target to each other. The exchange proceeds according to the authentication method chosen in the negotiation phase and is conducted using the Login Requests' and responses' key=value parameters.
セキュリティ交換は、互いにセキュリティー対策を設定して、創始者ユーザと目標を認証します。 '交換が、交渉フェーズで選ばれた認証方法によって続いて、Login Requestsと応答を使用することで行われ'キーは値のパラメタと等しいです。
An initiator directed negotiation proceeds as follows:
創始者の指示された交渉は以下の通り続きます:
- The initiator sends a Login Request with an ordered list of the
options it supports (authentication algorithm). The options are
listed in the initiator's order of preference. The initiator MAY
also send private or public extension options.
- 創始者はそれがサポートするオプション(認証アルゴリズム)の規則正しいリストがあるLogin Requestを送ります。 オプションは創始者のよく使われる順に記載されています。 また、創始者は個人的であるか公共の拡大オプションを送るかもしれません。
- The target MUST reply with the first option in the list it
supports and is allowed to use for the specific initiator unless
it does not support any, in which case it MUST answer with
"Reject" (see Section 5.2 Text Mode Negotiation). The parameters
are encoded in UTF8 as key=value. For security parameters, see
Chapter 11.
- いずれかも支持するなら、目標はそれが支持して、特定の創始者に使用できるリストにおける第1の選択で返答しなければなりません、その場合、それに「廃棄物」で答えなければなりません(セクション5.2 Text Mode Negotiationを見てください)。 パラメタは主要な=値としてUTF8でコード化されます。 セキュリティパラメタに関しては、連邦破産法11条を見てください。
- When the initiator considers that it is ready to conclude the
SecurityNegotiation stage, it sets the T bit to 1 and the NSG to
what it would like the next stage to be. The target will then
set the T bit to 1 and set the NSG to the next stage in the Login
Response when it finishes sending its security keys. The next
- 創始者が、それがSecurityNegotiationステージを結論づける準備ができていると考えるとき、それは次のステージに何を設定したがっているように1とNSGにTビットを設定するか。 それが、セキュリティキーを送り終えると、目標は、次に、Tビットを1に設定して、Login Responseの次のステージにNSGを設定するでしょう。 次
Satran, et al. Standards Track [Page 62] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[62ページ]。
stage selected will be the one the target selected. If the next
stage is FullFeaturePhase, the target MUST respond with a Login
Response with the TSIH value.
選択されたステージは目標が選択したものになるでしょう。 次のステージがFullFeaturePhaseであるなら、目標はLogin Responseと共にTSIH値で応じなければなりません。
If the security negotiation fails at the target, then the target MUST send the appropriate Login Response PDU. If the security negotiation fails at the initiator, the initiator SHOULD close the connection.
セキュリティ交渉が目標で失敗するなら、目標は適切なLogin Response PDUを送らなければなりません。 セキュリティ交渉が創始者で失敗するなら、創始者SHOULDは接続を終えます。
It should be noted that the negotiation might also be directed by the target if the initiator does support security, but is not ready to direct the negotiation (propose options).
交渉がまた、創始者がセキュリティを支持するなら目標によって指示されるかもしれませんが、交渉は指示する準備ができていないことに(オプションを提案してください)注意されるべきです。
5.3.3. Operational Parameter Negotiation During the Login Phase
5.3.3. ログイン段階の間の操作上のパラメタ交渉
Operational parameter negotiation during the login MAY be done:
ログインの間の操作上のパラメタ交渉は完了しているかもしれません:
- Starting with the first Login Request if the initiator does not
propose any security/integrity option.
- 創始者が少しのセキュリティ/保全オプションも提案しないなら、最初のLogin Requestから始まります。
- Starting immediately after the security negotiation if the
initiator and target perform such a negotiation.
- セキュリティ交渉直後、創始者と目標がそのような交渉を実行するなら、始まります。
Operational parameter negotiation MAY involve several Login Request-Response exchanges started and terminated by the initiator. The initiator MUST indicate its intent to terminate the negotiation by setting the T bit to 1; the target sets the T bit to 1 on the last response.
操作上のパラメタ交渉は創始者によって始められて、終えられた数回のLogin Request-応答交換にかかわるかもしれません。 創始者はTビットを1に設定することによって交渉を終える意図を示さなければなりません。 目標は最後の応答のときにTビットを1に設定します。
If the target responds to a Login Request that has the T bit set to 1 with a Login Response that has the T bit set to 0, the initiator should keep sending the Login Request (even empty) with the T bit set to 1, while it still wants to switch stage, until it receives the Login Response that has the T bit set to 1 or it receives a key that requires it to set the T bit to 0.
目標がTビットを0に設定させるLogin Responseと共にTビットを1に設定させるLogin Requestに応じるなら、創始者は1に設定されたTビットでLogin Request(空のさえ)を送り続けるべきです、まだステージを切り換えていたがっていますが、Tビットを1に設定させるLogin Responseを受けるか、またはTビットを0に設定するためにそれを必要とするキーを受けるまで。
Some session specific parameters can only be specified during the Login Phase of the first connection of a session (i.e., begun by a Login Request that contains a zero-valued TSIH) - the leading Login Phase (e.g., the maximum number of connections that can be used for this session).
セッション(すなわち、無評価されたTSIHを含むLogin Requestが始められる)の最初の接続のLogin Phaseの間、いくつかのセッションの特定のパラメタを指定できるだけです--主なLogin Phase(例えば、このセッションに使用できる接続の最大数)。
A session is operational once it has at least one connection in FullFeaturePhase. New or replacement connections can only be added to a session after the session is operational.
それに少なくとも1つの接続がFullFeaturePhaseにいったんあると、セッションは操作上です。 セッションが操作上になった後に新しいか交換接続をセッションに加えることができるだけです。
For operational parameters, see Chapter 12.
操作上のパラメタに関しては、第12章を参照してください。
Satran, et al. Standards Track [Page 63] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[63ページ]。
5.3.4. Connection Reinstatement
5.3.4. 接続復職
Connection reinstatement is the process of an initiator logging in with an ISID-TSIH-CID combination that is possibly active from the target's perspective, which causes the implicit logging out of the connection corresponding to the CID, and reinstating a new Full Feature Phase iSCSI connection in its place (with the same CID). Thus, the TSIH in the Login PDU MUST be non-zero and the CID does not change during a connection reinstatement. The Login Request performs the logout function of the old connection if an explicit logout was not performed earlier. In sessions with a single connection, this may imply the opening of a second connection with the sole purpose of cleaning up the first. Targets MUST support opening a second connection even when they do not support multiple connections in Full Feature Phase if ErrorRecoveryLevel is 2 and SHOULD support opening a second connection if ErrorRecoveryLevel is less than 2.
接続復職は創始者がことによるとCIDに対応する接続から暗黙の伐採を引き起こす目標の見解から活発なISID-TSIH-CID組み合わせでログインして、場所(同じCIDと)で新しいFull Feature Phase iSCSI接続を復職させる過程です。 したがって、Login PDUのTSIHは非ゼロであるに違いありません、そして、CIDは接続復職の間、変化しません。 ログアウトしてください。Login Requestが働く、ログアウト、年取った接続の機能、明白である、 より早く実行されませんでした。 単独結合とのセッションのときに、これは1番目をきれいにする唯一の目的との2番目の関係の始まりを含意するかもしれません。 目標は、ErrorRecoveryLevelが2とSHOULDサポートであるならErrorRecoveryLevelが2歳未満であるなら2番目の接続を開きながらFull Feature Phaseでの複数の接続を支持しないと2番目の接続を開くのを支持しなければなりません。
If the operational ErrorRecoveryLevel is 2, connection reinstatement enables future task reassignment. If the operational ErrorRecoveryLevel is less than 2, connection reinstatement is the replacement of the old CID without enabling task reassignment. In this case, all the tasks that were active on the old CID must be immediately terminated without further notice to the initiator.
操作上のErrorRecoveryLevelが2歳であるなら、接続復職は今後のタスク再割当てを可能にします。 操作上のErrorRecoveryLevelが2歳未満であるなら、接続復職はタスク再割当てを可能にすることのない古いCIDの交換です。 この場合、すぐに、創始者へのさらなる予告なしですべての古いCIDでアクティブであったタスクを終えなければなりません。
The initiator connection state MUST be CLEANUP_WAIT (section 7.1.3) when the initiator attempts a connection reinstatement.
創始者が接続復職を試みるとき、創始者接続状態はCLEANUP_WAITであるに違いありません(セクション7.1.3)。
In practical terms, in addition to the implicit logout of the old connection, reinstatement is equivalent to a new connection login.
実際的な言い方をするなら、暗黙に加えて年取った接続にログアウトしてください、そして、復職は新しい接続ログインに同等です。
5.3.5. Session Reinstatement, Closure, and Timeout
5.3.5. セッション復職、閉鎖、およびタイムアウト
Session reinstatement is the process of the initiator logging in with an ISID that is possibly active from the target's perspective. Thus implicitly logging out the session that corresponds to the ISID and reinstating a new iSCSI session in its place (with the same ISID). Therefore, the TSIH in the Login PDU MUST be zero to signal session reinstatement. Session reinstatement causes all the tasks that were active on the old session to be immediately terminated by the target without further notice to the initiator.
セッション復職は創始者がことによると目標の見解からアクティブなISIDと共にログインする過程です。 その結果、それとなくISIDに対応するセッションをログアウトして、場所(同じISIDと)で新しいiSCSIセッションを復職させます。 したがって、Login PDUのTSIHは、セッション復職に合図するためにはゼロでなければなりません。 セッション復職で、この上通告せずに創始者への目標はすぐに、すべての古いセッションのときにアクティブであったタスクを終えます。
The initiator session state MUST be FAILED (Section 7.3 Session State Diagrams) when the initiator attempts a session reinstatement.
創始者がセッション復職を試みるとき、創始者セッション状態はFAILEDであるに違いありません(セクション7.3 Session州Diagrams)。
Satran, et al. Standards Track [Page 64] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[64ページ]。
Session closure is an event defined to be one of the following:
セッション閉鎖は以下の1つになるように定義された出来事です:
- A successful "session close" logout.
- A successful "connection close" logout for the last Full Feature
Phase connection when no other connection in the session is
waiting for cleanup (Section 7.2 Connection Cleanup State Diagram
for Initiators and Targets) and no tasks in the session are
waiting for reassignment.
- うまくいっている「セッション閉鎖」はログアウトします。 - セッションにおける他のどんな接続もクリーンアップ(セクション7.2 InitiatorsとTargetsのためのConnection Cleanup州Diagram)を待っていないとき、うまくいっている「接続閉鎖」は最後のFull Feature Phase接続のためにログアウトします、そして、セッションにおけるどんなタスクも再割当てを待たないことです。
Session timeout is an event defined to occur when the last connection state timeout expires and no tasks are waiting for reassignment. This takes the session to the FREE state (N6 transition in the session state diagram).
セッションタイムアウトはタイムアウトが吐き出す最後の接続状態にもかかわらず、どんなタスクも再割当てを待たないことであるとき、起こるように定義された出来事です。 これは無料状態(セッション州のダイヤグラムにおけるN6変遷)にセッションを取ります。
5.3.5.1. Loss of Nexus Notification
5.3.5.1. 結びつき通知の損失
The iSCSI layer provides the SCSI layer with the "I_T nexus loss" notification when any one of the following events happens:
以下の出来事のどれかが起こると、iSCSI層は「I_T結びつきの損失」通知をSCSI層に提供します:
a) Successful completion of session reinstatement.
b) Session closure event.
c) Session timeout event.
a) セッション復職b)の無事終了 セッション閉鎖出来事c) セッションタイムアウト出来事。
Certain SCSI object clearing actions may result due to the notification in the SCSI end nodes, as documented in Appendix F. - Clearing Effects of Various Events on Targets -.
あるSCSI物の開拓地動作は通知のためSCSIエンドノードに結果として生じるかもしれません、Targetsの上のVarious EventsをEffectsから取り除いて、Appendix F.に記録されるように-
5.3.6. Session Continuation and Failure
5.3.6. セッション継続と失敗
Session continuation is the process by which the state of a preexisting session continues to be used by connection reinstatement (Section 5.3.4 Connection Reinstatement), or by adding a connection with a new CID. Either of these actions associates the new transport connection with the session state.
セッション継続は先在のセッションの州が接続復職(セクション5.3.4Connection Reinstatement)、または新しいCIDとの接続を加えることによって使用され続けている過程です。 これらの動作のどちらかがセッション状態との新しい輸送接続を関連づけます。
Session failure is an event where the last Full Feature Phase connection reaches the CLEANUP_WAIT state (Section 7.2 Connection Cleanup State Diagram for Initiators and Targets), or completes a successful recovery logout, thus causing all active tasks (that are formerly allegiant to the connection) to start waiting for task reassignment.
セッション失敗は最後のFull Feature Phase接続がCLEANUP_WAIT状態(セクション7.2 InitiatorsとTargetsのためのConnection Cleanup州Diagram)に着くか、またはタスク再割当てを待ち始めるためにログアウトして、その結果すべてのアクティブ・タスクを引き起こすうまくいっている回復(以前、それは接続へのallegiantである)を終了するところの出来事です。
Satran, et al. Standards Track [Page 65] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[65ページ]。
5.4. Operational Parameter Negotiation Outside the Login Phase
5.4. ログインフェーズの外における操作上のパラメタ交渉
Some operational parameters MAY be negotiated outside (after) the Login Phase.
いくつかの操作上のパラメタは交渉された外の(after)がLogin Phaseであったならそうするかもしれません。
Parameter negotiation in Full Feature Phase is done through Text requests and responses. Operational parameter negotiation MAY involve several Text request-response exchanges, which the initiator always starts and terminates using the same Initiator Task Tag. The initiator MUST indicate its intent to terminate the negotiation by setting the F bit to 1; the target sets the F bit to 1 on the last response.
Text要求と応答でFull Feature Phaseでのパラメタ交渉をします。 操作上のパラメタ交渉は、数回のText要求応答交換にかかわるかもしれなくて、同じInitiator Task Tagを使用することで終わります。(創始者はいつも交換を始めます)。 創始者はFビットを1に設定することによって交渉を終える意図を示さなければなりません。 目標は最後の応答のときにFビットを1に設定します。
If the target responds to a Text request with the F bit set to 1 and with a Text response with the F bit set to 0, the initiator should keep sending the Text request (even empty) with the F bit set to 1, while it still wants to finish the negotiation, until it receives the Text response with the F bit set to 1. Responding to a Text request with the F bit set to 1 with an empty (no key=value pairs) response with the F bit set to 0 is discouraged.
目標が1に設定されたFビットとText応答で0に設定されたFビットでText要求に応じるなら、創始者は1に設定されたFビットでText要求(空のさえ)を送り続けるべきです、まだ交渉を終えていたがっていますが、1に設定されたFビットでText応答を受けるまで。 0に設定されたFビットで空(主要な=値組がない)の応答で1に設定されたFビットでText要求に応じるのはお勧めできないです。
Targets MUST NOT submit parameters that require an additional initiator Text request in a Text response with the F bit set to 1.
目標は1に設定されたFビットでTextがText応答で要求する追加創始者を必要とするパラメタを提出してはいけません。
In a negotiation sequence, the F bit settings in one pair of Text request-responses have no bearing on the F bit settings of the next pair. An initiator that has the F bit set to 1 in a request and is being answered with an F bit setting of 0 may issue the next request with the F bit set to 0.
交渉系列では、Fを圧迫しないText要求応答の1組の噛み付いている設定にはあるFは次の組の設定に噛み付きました。 要求にFビットを1に設定させて、Fビットがセットしている状態で答えられている0歳の創始者は0に設定されたFビットによる次の要求を出すかもしれません。
Whenever the target responds with the F bit set to 0, it MUST set the Target Transfer Tag to a value other than the default 0xffffffff.
目標が0に設定されたFビットで応じるときはいつも、それはデフォルト0xffffffff以外の値にTarget Transfer Tagを設定しなければなりません。
An initiator MAY reset an operational parameter negotiation by issuing a Text request with the Target Transfer Tag set to the value 0xffffffff after receiving a response with the Target Transfer Tag set to a value other than 0xffffffff. A target may reset an operational parameter negotiation by answering a Text request with a Reject PDU.
Target Transfer Tagセットによる応答を0xffffffff以外の値に受けた後に値の0xffffffffに設定されて、創始者は、Target Transfer TagとのText要求を出すことによって、操作上のパラメタ交渉をリセットするかもしれません。 目標は、Reject PDUとのText要求に答えることによって、操作上のパラメタ交渉をリセットするかもしれません。
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). If detected by the target, this MUST result in a Reject PDU with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
創始者も目標も、介入している操作上のパラメタ交渉リセットなしでどんな交渉系列の間の一度より多くのパラメタも宣言するか、または交渉するのを試みるはずがありません、明らかに、繰り返された主要な宣言(例えば、TargetAddress)を許容する特定のキーへの応答を除いて。 目標によって検出されるなら、これは「プロトコル誤り」の理由でReject PDUをもたらさなければなりません。 創始者は上に概説されているように交渉をリセットしなければなりません。
Satran, et al. Standards Track [Page 66] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[66ページ]。
Parameters negotiated by a text exchange negotiation sequence only become effective after the negotiation sequence is completed.
交渉系列が完了した後にテキスト交換交渉系列によって交渉されたパラメタは有効になるだけです。
6. iSCSI Error Handling and Recovery
6. iSCSIエラー処理と回復
6.1. Overview
6.1. 概観
6.1.1. Background
6.1.1. バックグラウンド
The following two considerations prompted the design of much of the error recovery functionality in iSCSI:
以下の2つの問題がiSCSIのエラー回復の機能性の多くのデザインをうながしました:
i) An iSCSI PDU may fail the digest check and be dropped, despite
being received by the TCP layer. The iSCSI layer must
optionally be allowed to recover such dropped PDUs.
ii) A TCP connection may fail at any time during the data
transfer. All the active tasks must optionally be allowed to
continue on a different TCP connection within the same
session.
i) iSCSI PDUにダイジェストチェックに失敗して、TCP層のそばに受け取りますが、下げるかもしれません。 iSCSI層に下げられたPDUsそのようなii)を任意に回復させなければなりません。 TCP接続はいつでも、データ転送の間、失敗するかもしれません。 すべてのアクティブ・タスクに同じセッション中に異なったTCP接続に任意に続かせなければなりません。
Implementations have considerable flexibility in deciding what degree of error recovery to support, when to use it and by which mechanisms to achieve the required behavior. Only the externally visible actions of the error recovery mechanisms must be standardized to ensure interoperability.
実装は必要な振舞いを達成するためにそれを使用して、どのメカニズムでどの度合いのサポートへのエラー回復、いつかを決めるかにかなりの柔軟性を持っています。 相互運用性を確実にするためにエラー回復メカニズムの外部的に目に見える運動だけを標準化しなければなりません。
This chapter describes a general model for recovery in support of interoperability. See Appendix E. - Algorithmic Presentation of Error Recovery Classes - for further detail on how the described model may be implemented. Compliant implementations do not have to match the implementation details of this model as presented, but the external behavior of such implementations must correspond to the externally observable characteristics of the presented model.
本章は回復のために相互運用性を支持して一般的なモデルについて説明します。 説明されたモデルがどう実装されるかもしれないかに関する詳細に関してAppendix E.(Error Recovery ClassesのアルゴリズムのPresentation)を見てください。 対応する実装は提示されるようにこのモデルの実装細部に合う必要はありませんが、そのような実装の外部の振舞いは提示されたモデルの外部的に観察可能な特性に対応しなければなりません。
6.1.2. Goals
6.1.2. 目標
The major design goals of the iSCSI error recovery scheme are as follows:
iSCSIエラー回復体系の主要なデザイン目標は以下の通りです:
a) Allow iSCSI implementations to meet different requirements by
defining a collection of error recovery mechanisms that
implementations may choose from.
b) Ensure interoperability between any two implementations
supporting different sets of error recovery capabilities.
c) Define the error recovery mechanisms to ensure command
ordering even in the face of errors, for initiators that
demand ordering.
a) iSCSI実装に実装が. b)から選ぶかもしれないエラー回復メカニズムの収集を定義することによって、異なった必要条件を満たさせてください。 エラー回復能力異なったセットのc)をサポートして、どんな2つの実装の間でも相互運用性を確実にしてください。 エラー回復メカニズムを定義して、誤りに直面してさえ注文を要求する創始者のために注文されるコマンドを確実にしてください。
Satran, et al. Standards Track [Page 67] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[67ページ]。
d) Do not make additions in the fast path, but allow moderate
complexity in the error recovery path.
e) Prevent both the initiator and target from attempting to
recover the same set of PDUs at the same time. For example,
there must be a clear "error recovery functionality
distribution" between the initiator and target.
d) 高速経路で追加を作るな、ただし、エラー回復における適度の複雑さに経路e)を許容してください。 創始者と目標の両方が、同時にPDUsの同じセットを回収するのを試みるのを防いでください。 例えば、創始者と目標の間には、明確な「エラー回復機能性分配」があるに違いありません。
6.1.3. Protocol Features and State Expectations
6.1.3. プロトコル機能と州の期待
The initiator mechanisms defined in connection with error recovery are:
エラー回復に関して定義された創始者メカニズムは以下の通りです。
a) NOP-OUT to probe sequence numbers of the target (section
10.18)
b) Command retry (section 6.2.1)
c) Recovery R2T support (section 6.7)
d) Requesting retransmission of status/data/R2T using the SNACK
facility (section 10.16)
e) Acknowledging the receipt of the data (section 10.16)
f) Reassigning the connection allegiance of a task to a different
TCP connection (section 6.2.2)
g) Terminating the entire iSCSI session to start afresh (section
6.1.4.4)
a) 目標(セクション10.18)b)のプローブ配列番号へのNOP-OUT コマンド再試行(セクション6.2.1)c) 回復R2Tは、(セクション6.7)がd)であるとサポートします。 SNACK施設(セクション10.16)e)を使用することで状態/データ/R2Tの「再-トランスミッション」を要求します。 データ(セクション10.16)f)の領収書を受け取ったことを知らせます。 異なったTCP接続(セクション6.2.2)g)にタスクの接続忠誠を再選任します。 最初からやり直すために全体のiSCSIセッションを終えます。(セクション6.1.4、.4)
The target mechanisms defined in connection with error recovery are:
エラー回復に関して定義された目標メカニズムは以下の通りです。
a) NOP-IN to probe sequence numbers of the initiator (section
10.19)
b) Requesting retransmission of data using the recovery R2T
feature (section 6.7)
c) SNACK support (section 10.16) d) Requesting that parts of
read data be acknowledged (section 10.7.2)
e) Allegiance reassignment support (section 6.2.2)
f) Terminating the entire iSCSI session to force the initiator to
start over (section 6.1.4.4)
a) 創始者(セクション10.19)b)のプローブ配列番号へのNOP-IN 回復R2T機能(セクション6.7)c)を使用することでデータの再伝送を要求します。 SNACKは、(セクション10.16)がd)であるとサポートします。 読書データの部分が承認されるよう(セクション10.7.2)要求する、e) 忠誠再割当てサポート(セクション6.2.2)f) 創始者にやり直させる全体のiSCSIセッションを終えます。(セクション6.1.4、.4)
For any outstanding SCSI command, it is assumed that iSCSI, in conjunction with SCSI at the initiator, is able to keep enough information to be able to rebuild the command PDU, and that outgoing data is available (in host memory) for retransmission while the command is outstanding. It is also assumed that at the target, incoming data (read data) MAY be kept for recovery or it can be reread from a device server.
保つことができるそれが創始者のSCSIに関連したそのiSCSIであるとコマンドが思われるどんな傑出しているSCSIにおいても、コマンドは傑出していますが、コマンドPDU、およびその発信データを再建できるためには十分な情報が「再-トランスミッション」に利用可能です(ホストメモリの)。 また、目標では、回復のために受信データ(データを読む)を保つかもしれないか、またはデバイスサーバからそれを再読できると思われます。
It is further assumed that a target will keep the "status & sense" for a command it has executed if it supports status retransmission. A target that agrees to support data retransmission is expected to be prepared to retransmit the outgoing data (i.e., Data-In) on request
それが、状態が「再-トランスミッション」であるとサポートすると目標がそれが実行したコマンドのために「状態と感覚」を保つとさらに思われます。 要求に応じて発信データ(すなわち、中のData)を再送するようにデータが「再-トランスミッション」であるとサポートするのに同意する目標が準備されると予想されます。
Satran, et al. Standards Track [Page 68] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[68ページ]。
until either the status for the completed command is acknowledged, or the data in question has been separately acknowledged.
どちらかまで、完成したコマンドのための状態が承認されるか、または問題のデータは別々に承認されました。
6.1.4. Recovery Classes
6.1.4. 回復のクラス
iSCSI enables the following classes of recovery (in the order of increasing scope of affected iSCSI tasks):
iSCSIは以下のクラスの回復(影響を受けるiSCSIタスクの増加する範囲の注文における)を可能にします:
- Within a command (i.e., without requiring command restart).
- Within a connection (i.e., without requiring the connection to
be rebuilt, but perhaps requiring command restart).
- Connection recovery (i.e., perhaps requiring connections to be
rebuilt and commands to be reissued).
- Session recovery.
- コマンド(すなわち、コマンド再開を必要とすることのない)の中で。 - 接続(すなわち、接続が再建されますが、恐らくコマンド再開を必要とするのが必要であることのない)の中で。 - 接続回復(すなわち、恐らく、再建されるべき接続と再発行されるべきコマンドを必要とします)。 - セッション回復。
The recovery scenarios detailed in the rest of this section are representative rather than exclusive. In every case, they detail the lowest class recovery that MAY be attempted. The implementer is left to decide under which circumstances to escalate to the next recovery class and/or what recovery classes to implement. Both the iSCSI target and initiator MAY escalate the error handling to an error recovery class, which impacts a larger number of iSCSI tasks in any of the cases identified in the following discussion.
排他的であるというよりむしろこのセクションの残りで詳細な回復シナリオは代表しています。 あらゆる場合に、彼らは試みられるかもしれない中で最も低いクラス回復を詳しく述べます。 implementerが、次の回復のクラス、そして/または、回復が実装するために属させることに徐々に拡大するとどの状況で決めるかが残されます。 ともに、iSCSI目標と創始者はエラー回復のクラスにエラー処理を徐々に拡大するかもしれません。(それは、以下の議論で特定されたケースのどれかの、より多くのiSCSIタスクに影響を与えます)。
In all classes, the implementer has the choice of deferring errors to the SCSI initiator (with an appropriate response code), in which case the task, if any, has to be removed from the target and all the side effects, such as ACA, must be considered.
すべてのクラスでは、implementerはSCSI創始者(適切な応答コードがある)に誤りを延期することの選択を持っています、そして、その場合、もしあればタスクは目標から取り除かれなければなりません、そして、ACAなどのすべての副作用を考えなければなりません。
Use of within-connection and within-command recovery classes MUST NOT be attempted before the connection is in Full Feature Phase.
接続がFull Feature Phaseにある前に接続とコマンドの中の回復のクラスの使用を試みてはいけません。
In the detailed description of the recovery classes, the mandating terms (MUST, SHOULD, MAY, etc.) indicate normative actions to be executed if the recovery class is supported and used.
回復のクラスの詳述、強制用語、(SHOULD、5月など) 回復のクラスがサポートされて、使用されるなら標準の動作を示さなければならなくて、実行されてください。
6.1.4.1. Recovery Within-command
6.1.4.1. 回復は中で命令します。
At the target, the following cases lend themselves to within-command recovery:
目標では、以下のケースはコマンドの中の回復に自分たちを与えます:
- Lost data PDU - realized through one of the following:
- ロストデータPDU--以下の1つを通して実感される:
a) Data digest error - dealt with as specified in Section 6.7
Digest Errors, using the option of a recovery R2T.
a) データは誤りを読みこなします--セクション6.7 Digest Errorsで指定されるように、回復R2Tのオプションを使用して、対処されています。
Satran, et al. Standards Track [Page 69] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[69ページ]。
b) Sequence reception timeout (no data or
partial-data-and-no-F-bit) - considered an implicit sequence
error and dealt with as specified in Section 6.8 Sequence
Errors, using the option of a recovery R2T.
c) Header digest error, which manifests as a sequence reception
timeout or a sequence error - dealt with as specified in
Section 6.8 Sequence Errors, using the option of a recovery
R2T.
b) 系列レセプションタイムアウト(データがない部分的なデータにもかかわらず、Fビットがありません) - 回復R2T.c)のオプションを使用して、暗黙の系列誤りであると考えられて、セクション6.8 Sequence Errorsで指定されるように対処されています。 系列レセプションタイムアウトか系列誤りとしてのどの顕現--ヘッダーダイジェスト誤り、セクション6.8 Sequence Errorsで指定されるように、回復R2Tのオプションを使用して、対処されているか。
At the initiator, the following cases lend themselves to within-command recovery:
創始者では、以下のケースはコマンドの中の回復に自分たちを与えます:
Lost data PDU or lost R2T - realized through one of the
following:
ロストデータPDUか無くなっているR2T--以下の1つを通して実感される:
a) Data digest error - dealt with as specified in Section 6.7
Digest Errors, using the option of a SNACK.
b) Sequence reception timeout (no status) or response reception
timeout - dealt with as specified in Section 6.8 Sequence
Errors, using the option of a SNACK.
c) Header digest error, which manifests as a sequence reception
timeout or a sequence error - dealt with as specified in
Section 6.8 Sequence Errors, using the option of a SNACK.
a) データダイジェスト誤り--セクション6.7 Digest Errorsで指定されるように、SNACK. bのオプションを使用して、対処されています。 系列レセプションタイムアウト(状態がない)か応答レセプションタイムアウト--セクション6.8 Sequence Errorsで指定されるように、SNACK. cのオプションを使用して、対処されています。 系列レセプションタイムアウトか系列誤りとしてのどの顕現--ヘッダーダイジェスト誤り、セクション6.8 Sequence Errorsで指定されるように、SNACKのオプションを使用して、対処されているか。
To avoid a race with the target, which may already have a recovery R2T or a termination response on its way, an initiator SHOULD NOT originate a SNACK for an R2T based on its internal timeouts (if any). Recovery in this case is better left to the target.
途中に既に回復R2Tか終了応答を持っているかもしれない目標によるレースを避けるために、創始者SHOULD NOTは内部のタイムアウト(もしあれば)に基づくR2TのためにSNACKを溯源します。 この場合、回復は目標に残されるほうがよいです。
The timeout values used by the initiator and target are outside the scope of this document. Sequence reception timeout is generally a large enough value to allow the data sequence transfer to be complete.
このドキュメントの範囲の外に創始者と目標によって使用されるタイムアウト値があります。 一般に、系列レセプションタイムアウトはデータ系列転送が完全であることを許容する十分大きい値です。
6.1.4.2. Recovery Within-connection
6.1.4.2. 回復、接続
At the initiator, the following cases lend themselves to within-connection recovery:
創始者では、以下のケースは接続の中の回復に自分たちを与えます:
- Requests not acknowledged for a long time. Requests are
acknowledged explicitly through ExpCmdSN or implicitly by
receiving data and/or status. The initiator MAY retry
non-acknowledged commands as specified in Section 6.2 Retry and
Reassign in Recovery.
- 長い間承諾されなかった要求。 要求は受信データ、そして/または、状態によって明らかにExpCmdSNかそれとなく承諾されます。 創始者はRecoveryでセクション6.2 RetryとReassignの指定されるとしての非承認されたコマンドを再試行するかもしれません。
Satran, et al. Standards Track [Page 70] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[70ページ]。
- Lost iSCSI numbered Response. It is recognized by either
identifying a data digest error on a Response PDU or a Data-In
PDU carrying the status, or by receiving a Response PDU with a
higher StatSN than expected. In the first case, digest error
handling is done as specified in Section 6.7 Digest Errors using
the option of a SNACK. In the second case, sequence error
handling is done as specified in Section 6.8 Sequence Errors,
using the option of a SNACK.
- 無くなっているiSCSIはResponseに付番しました。 それは、状態を運ぶResponse PDUでデータダイジェスト誤りを特定するか、中のData PDUのどちらか、または予想より高いStatSNと共にResponse PDUを受けることによって、認識されます。 前者の場合、セクション6.7 Digest ErrorsでSNACKのオプションを使用することで指定されるようにダイジェストエラー処理をします。 2番目の場合では、セクション6.8 Sequence Errorsで指定されるように系列エラー処理をします、SNACKのオプションを使用して。
At the target, the following cases lend themselves to within-connection recovery:
目標では、以下のケースは接続の中の回復に自分たちを与えます:
- Status/Response not acknowledged for a long time. The target MAY
issue a NOP-IN (with a valid Target Transfer Tag or otherwise)
that carries the next status sequence number it is going to use
in the StatSN field. This helps the initiator detect any missing
StatSN(s) and issue a SNACK for the status.
- 長い間承諾されなかった状態/応答。 目標はそれがStatSN分野で使用する次の状態一連番号を運ぶNOP-IN(有効なTarget Transfer Tagかそうでないのがある)を発行するかもしれません。 これは、創始者がどんななくなったStatSN(s)も検出して、状態にSNACKを発行するのを助けます。
The timeout values used by the initiator and the target are outside the scope of this document.
このドキュメントの範囲の外に創始者と目標によって使用されるタイムアウト値があります。
6.1.4.3. Connection Recovery
6.1.4.3. 接続回復
At an iSCSI initiator, the following cases lend themselves to connection recovery:
iSCSI創始者では、以下のケースは接続回復に自分たちを与えます:
- TCP connection failure: The initiator MUST close the connection.
It then MUST either implicitly or explicitly logout the failed
connection with the reason code "remove the connection for
recovery" and reassign connection allegiance for all commands
still in progress associated with the failed connection on one or
more connections (some or all of which MAY be newly established
connections) using the "Task reassign" task management function
(see Section 10.5.1 Function). For an initiator, a command is in
progress as long as it has not received a response or a Data-In
PDU including status.
- TCP接続の故障: 創始者は接続を終えなければなりません。 次に、それとなくか明らかにログアウトしなければならない、コードが「回復のために接続を外し」て、すべてのために接続忠誠を再選任する理由との失敗した関係がまだ1つ以上の接続(それのいくつかかすべてが新設された接続であるかもしれない)の失敗した接続に関連している進行中で使用を命令する、「タスクは」 タスク管理機能を再選任します(セクション10.5.1Functionを見てください)。 創始者にとって、応答か状態を含む中のData PDUを受けていない限り、コマンドは進行しています。
Note: The logout function is mandatory. However, a new connection
establishment is only mandatory if the failed connection was the
last or only connection in the session.
以下に注意してください。 ログアウトしてください。機能は義務的です。 しかしながら、新しいコネクション確立は失敗した接続がセッションで最終か唯一の接続であった場合にだけ義務的です。
- Receiving an Asynchronous Message that indicates one or all
connections in a session has been dropped. The initiator MUST
handle it as a TCP connection failure for the connection(s)
referred to in the Message.
- 1を示すAsynchronous Messageかセッションにおけるすべての接続を受けるのは下げられました。 創始者はMessageで言及された接続のためのTCP接続の故障としてそれを扱わなければなりません。
Satran, et al. Standards Track [Page 71] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[71ページ]。
At an iSCSI target, the following cases lend themselves to connection recovery:
iSCSI目標では、以下のケースは接続回復に自分たちを与えます:
- TCP connection failure. The target MUST close the connection and,
if more than one connection is available, the target SHOULD send
an Asynchronous Message that indicates it has dropped the
connection. Then, the target will wait for the initiator to
continue recovery.
- TCP接続の故障。 目標は接続を終えなければなりません、そして、1つ以上の接続が手があくなら、目標SHOULDはそれが低下したのを示すAsynchronous Messageに接続を送ります。 そして、目標は、創始者が回復を続けているのを待つでしょう。
6.1.4.4. Session Recovery
6.1.4.4. セッション回復
Session recovery should be performed when all other recovery attempts have failed. Very simple initiators and targets MAY perform session recovery on all iSCSI errors and rely on recovery on the SCSI layer and above.
他のすべての回復試みが失敗したとき、セッション回復は実行されるべきです。 非常に純真な創始者と目標は、すべてのiSCSI誤りにセッション回復を実行して、SCSI層における回復の上と上で当てにされるかもしれません。
Session recovery implies the closing of all TCP connections, internally aborting all executing and queued tasks for the given initiator at the target, terminating all outstanding SCSI commands with an appropriate SCSI service response at the initiator, and restarting a session on a new set of connection(s) (TCP connection establishment and login on all new connections).
すべてのTCP接続の閉鎖はセッション回復は含意されて、内部的に実行して、列に並ばせられたすべてを中止すると、目標、適切なSCSIサービス応答が創始者にあるすべての傑出しているSCSIコマンドを終えて、および再開における、新しい接続(すべての新しい接続のTCPコネクション確立とログイン)のセッションは与えられた創始者のために仕事を課されます。
For possible clearing effects of session recovery on SCSI and iSCSI objects, refer to Appendix F. - Clearing Effects of Various Events on Targets -.
Targetsの上のVarious EventsをEffectsから取り除いて、SCSIとiSCSIオブジェクトへのセッション回復の可能な開拓地効果について、Appendix F.を参照してください、-
6.1.5. Error Recovery Hierarchy
6.1.5. エラー回復階層構造
The error recovery classes described so far are organized into a hierarchy for ease in understanding and to limit the implementation complexity. With few and well defined recovery levels interoperability is easier to achieve. The attributes of this hierarchy are as follows:
今までのところ説明されているエラー回復のクラスは理解における容易さ、実装の複雑さを制限する階層構造に組織化されます。 わずかでよく定義された回復レベルでは、相互運用性はより達成しやすいです。 この階層構造の属性は以下の通りです:
a) Each level is a superset of the capabilities of the previous
level. For example, Level 1 support implies supporting all
capabilities of Level 0 and more.
b) As a corollary, supporting a higher error recovery level means
increased sophistication and possibly an increase in resource
requirements.
c) Supporting error recovery level "n" is advertised and
negotiated by each iSCSI entity by exchanging the text key
"ErrorRecoveryLevel=n". The lower of the two exchanged values
is the operational ErrorRecoveryLevel for the session.
a) 各レベルは前のレベルの能力のスーパーセットです。 例えば、Level1サポートはサポートしているLevel0のすべての能力とその他b)を含意します。 推論、平らな手段が増強したより高いエラー回復に洗練をサポートして、およびことによるとリソース要件c)の増加として エラー回復レベル「n」をサポートするのは、それぞれのiSCSI実体によってテキストキー"ErrorRecoveryLevel=n"を交換することによって、広告を出して、交渉されます。 2つの交換された値では、セッションのための操作上のErrorRecoveryLevelは、より低いです。
Satran, et al. Standards Track [Page 72] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[72ページ]。
The following diagram represents the error recovery hierarchy.
以下のダイヤグラムはエラー回復階層構造を表します。
+
/
/ 2 \ <-- Connection recovery
+-----+
/ 1 \ <-- Digest failure recovery
+---------+
/ 0 \ <-- Session failure recovery
+-------------+
+ //2円の<--接続回復+-----+/1円の<--ダイジェスト失敗回復+---------+/0円の<--セッション失敗回復+-------------+
The following table lists the error recovery capabilities expected from the implementations that support each error recovery level.
以下のテーブルは各エラー回復がレベルであるとサポートする実装から予想されたエラー回復能力を記載します。
+-------------------+--------------------------------------------+ |ErrorRecoveryLevel | Associated Error recovery capabilities | +-------------------+--------------------------------------------+ | 0 | Session recovery class | | | (Section 6.1.4.4 Session Recovery) | +-------------------+--------------------------------------------+ | 1 | Digest failure recovery (See Note below.) | | | plus the capabilities of ER Level 0 | +-------------------+--------------------------------------------+ | 2 | Connection recovery class | | | (Section 6.1.4.3 Connection Recovery) | | | plus the capabilities of ER Level 1 | +-------------------+--------------------------------------------+
+-------------------+--------------------------------------------+ |ErrorRecoveryLevel| 関連Error回復能力| +-------------------+--------------------------------------------+ | 0 | セッション回復のクラス| | | (セクション6.1.4.4セッション回復) | +-------------------+--------------------------------------------+ | 1 | 失敗回復を読みこなしてください(以下のNoteを見てください。)。 | | | プラスはER Level0の能力です。| +-------------------+--------------------------------------------+ | 2 | 接続回復のクラス| | | (セクション6.1.4.3接続回復) | | | プラスはER Level1の能力です。| +-------------------+--------------------------------------------+
Note: Digest failure recovery is comprised of two recovery classes: Within-Connection recovery class (Section 6.1.4.2 Recovery Within- connection) and Within-Command recovery class (Section 6.1.4.1 Recovery Within-command).
以下に注意してください。 ダイジェスト失敗回復は2つの回復のクラスから成ります: 接続の中の回復のクラス、(セクション6.1 .4 .2 Recovery Within接続) そして、Within-コマンド回復のクラス(セクション6.1.4.1Recovery Within-コマンド)。
When a defined value of ErrorRecoveryLevel is proposed by an originator in a text negotiation, the originator MUST support the functionality defined for the proposed value and additionally, the functionality corresponding to any defined value numerically less than the proposed. When a defined value of ErrorRecoveryLevel is returned by a responder in a text negotiation, the responder MUST support the functionality corresponding to the ErrorRecoveryLevel it is accepting.
ErrorRecoveryLevelの定義された値がテキスト交渉で創始者によって提案されるとき、創始者が提案された値のために定義された機能性をサポートしなければならなくて、さらに、いずれにも対応する機能性は提案より数の上で値を定義しませんでした。 ErrorRecoveryLevelの定義された値がテキスト交渉で応答者によって返されるとき、応答者はそれが受け入れているErrorRecoveryLevelに対応する機能性をサポートしなければなりません。
When either party attempts to use error recovery functionality beyond what is negotiated, the recovery attempts MAY fail unless an a priori agreement outside the scope of this document exists between the two parties to provide such support.
何れの当事者が、交渉されることを超えてエラー回復の機能性を使用するのを試みるとき、このドキュメントの範囲の外での先験的な協定がそのようなサポートを提供するために2回のパーティーの間に存在していない場合、回復試みは失敗するかもしれません。
Satran, et al. Standards Track [Page 73] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[73ページ]。
Implementations MUST support error recovery level "0", while the rest are OPTIONAL to implement. In implementation terms, the above striation means that the following incremental sophistication with each level is required.
実装がエラー回復レベルをサポートしなければならない、「残りが実装するために任意である間の0インチ 実装用語で、上の筋は、各レベルがある以下の増加の洗練が必要であることを意味します。
+-------------------+---------------------------------------------+ |Level transition | Incremental requirement | +-------------------+---------------------------------------------+ | 0->1 | PDU retransmissions on the same connection | +-------------------+---------------------------------------------+ | 1->2 | Retransmission across connections and | | | allegiance reassignment | +-------------------+---------------------------------------------+
+-------------------+---------------------------------------------+ |変遷を平らにしてください。| 増加の要件| +-------------------+---------------------------------------------+ | 0>1| 同じ接続でのPDU retransmissions| +-------------------+---------------------------------------------+ | 1>2| そして接続の向こう側のRetransmission。| | | 忠誠再割当て| +-------------------+---------------------------------------------+
6.2. Retry and Reassign in Recovery
6.2. 中で回復を再試行して、再選任してください。
This section summarizes two important and somewhat related iSCSI protocol features used in error recovery.
このセクションは誤り回復に使用される2つの重要でいくらか関連するiSCSIプロトコル機能をまとめます。
6.2.1. Usage of Retry
6.2.1. 再試行の用法
By resending the same iSCSI command PDU ("retry") in the absence of a
command acknowledgement (by way of an ExpCmdSN update) or a response,
an initiator attempts to "plug" (what it thinks are) the
discontinuities in CmdSN ordering on the target end. Discarded
command PDUs, due to digest errors, may have created these
discontinuities.
コマンド承認(ExpCmdSNアップデートを通した)か応答がないとき同じiSCSIコマンドPDU(「再試行」)を再送することによって、創始者は、目標エンドで注文するCmdSNで不連続を「ふさぐこと」を(あるそれが考えること)試みます。 誤りを読みこなすことになっている捨てられたコマンドPDUsはこれらの不連続を作成したかもしれません。
Retry MUST NOT be used for reasons other than plugging command sequence gaps, and in particular, cannot be used for requesting PDU retransmissions from a target. Any such PDU retransmission requests for a currently allegiant command in progress may be made using the SNACK mechanism described in section 10.16, although the usage of SNACK is OPTIONAL.
コマンド・シーケンス赤字を埋めた以外の理由に再試行を使用してはいけません、そして、特に、目標からPDU retransmissionsを要求するのに使用できません。 セクション10.16で説明されたSNACKメカニズムを使用することで進行中の現在allegiantなコマンドを求めるどんなそのようなPDU retransmission要求もするかもしれません、SNACKの使用法はOPTIONALですが。
If initiators, as part of plugging command sequence gaps as described above, inadvertently issue retries for allegiant commands already in progress (i.e., targets did not see the discontinuities in CmdSN ordering), the duplicate commands are silently ignored by targets as specified in section 3.2.2.1.
創始者であるなら、説明されるとしてのコマンド・シーケンスギャップが上に、うっかり発行する働きの一部が既に進行中のallegiantコマンドのために再試行されるとき(すなわち、目標は、CmdSNの不連続が注文されているのを見ませんでした)、セクション3.2.2で.1を指定するとき、コピーコマンドは目標によって静かに無視されます。
When an iSCSI command is retried, the command PDU MUST carry the original Initiator Task Tag and the original operational attributes (e.g., flags, function names, LUN, CDB etc.) as well as the original CmdSN. The command being retried MUST be sent on the same connection as the original command unless the original connection was already successfully logged out.
iSCSIコマンドが再試行されるとき、コマンドPDU MUSTはオリジナルのCmdSNと同様にオリジナルのInitiator Task Tagと元の操作上の属性(例えば、旗、機能名、CDB LUNなど)を運びます。 既に首尾よくオリジナルの接続をログアウトしなかったなら、オリジナルのコマンドと同じ接続に再試行されるコマンドを送らなければなりません。
Satran, et al. Standards Track [Page 74] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[74ページ]。
6.2.2. Allegiance Reassignment
6.2.2. 忠誠再割当て
By issuing a "task reassign" task management request (Section 10.5.1 Function), the initiator signals its intent to continue an already active command (but with no current connection allegiance) as part of connection recovery. This means that a new connection allegiance is requested for the command, which seeks to associate it to the connection on which the task management request is being issued. Before the allegiance reassignment is attempted for a task, an implicit or explicit Logout with the reason code "remove the connection for recovery" ( see section 10.14) MUST be successfully completed for the previous connection to which the task was allegiant.
aを発行する、「タスクは」 タスク管理要求(セクション10.5.1Function)を再選任します、と創始者が接続回復の一部として既に活発なコマンド(しかし現在の接続忠誠なしで)を続ける意図に合図します。 これは、新たな接続忠誠がコマンドのために要求されていることを意味します。(コマンドはタスク管理要求が出される予定である接続にそれを関連づけようとします)。 忠誠再割当てが試みられる前に、タスク、「回復のための接続を外す」(セクション10.14を見る)がそうしなければならない理由コードがある暗黙の、または、明白なLogoutに関して、タスクがallegiantであった前の接続のために首尾よく完成してください。
In reassigning connection allegiance for a command, the targets SHOULD continue the command from its current state. For example, when reassigning read commands, the target SHOULD take advantage of the ExpDataSN field provided by the Task Management function request (which must be set to zero if there was no data transfer) and bring the read command to completion by sending the remaining data and sending (or resending) the status. ExpDataSN acknowledges all data sent up to, but not including, the Data-In PDU and or R2T with DataSN (or R2TSN) equal to ExpDataSN. However, targets may choose to send/receive all unacknowledged data or all of the data on a reassignment of connection allegiance if unable to recover or maintain an accurate state. Initiators MUST not subsequently request data retransmission through Data SNACK for PDUs numbered less than ExpDataSN (i.e., prior to the acknowledged sequence number). For all types of commands, a reassignment request implies that the task is still considered in progress by the initiator and the target must conclude the task appropriately if the target returns the "Function Complete" response to the reassignment request. This might possibly involve retransmission of data/R2T/status PDUs as necessary, but MUST involve the (re)transmission of the status PDU.
現状からのコマンド、SHOULDが続けている目標に関する接続忠誠を再選任することにおけるコマンド。 例えば、読みコマンドを再選任するとき、目標SHOULDは、Task Management機能要求(データ転送が全くなかったなら、ゼロに設定しなければならない)で提供されたExpDataSN野原を利用して、残っているデータを送って、状態を送ることによって(または、再送)、読みコマンドを完成にもたらします。 そして、ExpDataSNは包含ではなく、データが発信したすべてを承認します、中のData PDU、または、ExpDataSNと等しいDataSN(または、R2TSN)とR2T。 しかしながら、正確な状態を回復するか、または維持できないなら、目標は、接続忠誠の再割当てに関するデータのすべての不承認のデータかすべてを送るか、または受け取るのを選ぶかもしれません。 創始者は、次に、PDUsのためのData SNACKを通したデータ再送がExpDataSN(すなわち、承認された一連番号の前の)以下に付番したよう要求してはいけません。 すべてのタイプのコマンドのために、再割当て要求は、タスクが創始者によって進行中であるとまだ考えられているのを含意します、そして、目標が再割当て要求への「機能完全な」応答を返すなら、目標は適切にタスクを結論づけなければなりません。 これは、ことによると必要に応じてデータの再伝送/R2T/状態PDUsにかかわるかもしれませんが、状態PDUの(re)トランスミッションにかかわらなければなりません。
It is OPTIONAL for targets to support the allegiance reassignment. This capability is negotiated via the ErrorRecoveryLevel text key during the login time. When a target does not support allegiance reassignment, it MUST respond with a Task Management response code of "Allegiance reassignment not supported". If allegiance reassignment is supported by the target, but the task is still allegiant to a different connection, or a successful recovery Logout of the previously allegiant connection was not performed, the target MUST respond with a Task Management response code of "Task still allegiant".
それは目標が忠誠再割当てをサポートするOPTIONALです。 この能力はログイン時間主要なErrorRecoveryLevelテキストで交渉されます。 目標が、忠誠が再割当てであるとサポートしないと、それは「サポートされなかった忠誠再割当て」のTask Management応答コードで応じなければなりません。 忠誠再割当てが目標で後押しされていますが、それでも、タスクが異なった接続へのallegiantであるか以前にallegiantな接続のaうまくいっている回復Logoutが実行されなかったなら、目標は「それでも、タスクallegiant」のTask Management応答コードで応じなければなりません。
Satran, et al. Standards Track [Page 75] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[75ページ]。
If allegiance reassignment is supported by the target, the Task Management response to the reassignment request MUST be issued before the reassignment becomes effective.
忠誠再割当てが目標で後押しされているなら、再割当てが有効になる前に再割当て要求へのTask Management応答を発行しなければなりません。
If a SCSI Command that involves data input is reassigned, any SNACK Tag it holds for a final response from the original connection is deleted and the default value of 0 MUST be used instead.
入力はデータにかかわるSCSI Commandであるなら再選任されて、どんなSNACK Tagもそれです。オリジナルの接続からの最終的な応答のための船倉は削除されます、そして、代わりに0のデフォルト値を使用しなければなりません。
6.3. Usage Of Reject PDU in Recovery
6.3. 回復における廃棄物PDUの使用法
Targets MUST NOT implicitly terminate an active task by sending a Reject PDU for any PDU exchanged during the life of the task. If the target decides to terminate the task, a Response PDU (SCSI, Text, Task, etc.) must be returned by the target to conclude the task. If the task had never been active before the Reject (i.e., the Reject is on the command PDU), targets should not send any further responses because the command itself is being discarded.
目標は、タスクの寿命の間に交換されたどんなPDUのためにもReject PDUを送ることによって、それとなくアクティブ・タスクを終えてはいけません。 目標が、タスクを終えると決めるなら、目標で、Response PDU(SCSI、Text、Taskなど)を返して、タスクを結論づけなければなりません。 タスクがRejectの前で一度もアクティブであったことがなかったなら(コマンドPDUにはすなわち、Rejectがあります)、コマンド自体が捨てられているので、目標は少しのさらなる応答も送るはずがありません。
The above rule means that the initiator can eventually expect a response on receiving Rejects, if the received Reject is for a PDU other than the command PDU itself. The non-command Rejects only have diagnostic value in logging the errors, and they can be used for retransmission decisions by the initiators.
上の規則は、創始者が結局Rejectsを受けるときの応答を予想できることを意味します、容認されたRejectがコマンドPDU自身以外のPDUのためのものであるなら。 非コマンドRejectsは誤りを登録する際に診断値を持っているだけです、そして、創始者による「再-トランスミッション」決定にそれらは使用できます。
The CmdSN of the rejected command PDU (if it is a non-immediate command) MUST NOT be considered received by the target (i.e., a command sequence gap must be assumed for the CmdSN), even though the CmdSN of the rejected command PDU may be reliably ascertained. Upon receiving the Reject, the initiator MUST plug the CmdSN gap in order to continue to use the session. The gap may be plugged either by transmitting a command PDU with the same CmdSN, or by aborting the task (see section 6.9 on how an abort may plug a CmdSN gap).
拒絶されたコマンドのCmdSNは目標のそばで受信しました(CmdSNのためにすなわち、コマンド・シーケンスギャップを想定しなければなりません)PDU(それが非即座のコマンドであるなら)を考えてはいけない、拒絶されたコマンドPDUのCmdSNは確かに確かめられるかもしれませんが。 Rejectを受けると、創始者は、セッションを使用し続けるためにCmdSN赤字を埋めなければなりませんでした。 赤字は、同じCmdSNと共にコマンドPDUを伝えるか、またはタスクを中止することによって、埋められたかもしれません(アボートがどうCmdSN赤字を埋めたかもしれないかに関するセクション6.9を見てください)。
When a data PDU is rejected and its DataSN can be ascertained, a target MUST advance ExpDataSN for the current data burst if a recovery R2T is being generated. The target MAY advance its ExpDataSN if it does not attempt to recover the lost data PDU.
データPDUを拒絶して、DataSNを確かめることができるとき、目標は回復R2Tが生成されているなら押し破かれた現在のデータのためにExpDataSNを進めなければなりません。 ロストデータPDUを回収するのを試みないなら、目標はExpDataSNを進めるかもしれません。
6.4. Connection Timeout Management
6.4. 接続タイムアウト管理
iSCSI defines two session-global timeout values (in seconds) - Time2Wait and Time2Retain - that are applicable when an iSCSI Full Feature Phase connection is taken out of service either intentionally or by an exception. Time2Wait is the initial "respite time" before attempting an explicit/implicit Logout for the CID in question or task reassignment for the affected tasks (if any). Time2Retain is the maximum time after the initial respite interval that the task and/or connection state(s) is/are guaranteed to be maintained on the
iSCSIは故意にか例外で使われなくなっている2つのiSCSI Full Feature Phase接続を取るとき適切なセッショングローバルなタイムアウト値(秒の)(Time2WaitとTime2Retain)を定義します。 Time2Waitは問題のCIDのための明白であるか内在しているLogoutを試みる前の初期の「一時延期時間」か(もしあれば)の影響を受けるタスクのためのタスク再割当てです。 Time2Retainはタスク、そして/または、接続状態が/であることが保証されている初期の一時延期間隔の後の最大の時にオンに維持されます。
Satran, et al. Standards Track [Page 76] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[76ページ]。
target to cater to a possible recovery attempt. Recovery attempts for the connection and/or task(s) SHOULD NOT be made before Time2Wait seconds, but MUST be completed within Time2Retain seconds after that initial Time2Wait waiting period.
可能な回復試みに満たすために、狙います。 接続、そして/または、タスクSHOULD NOTのための回復試みをTime2Wait秒以前作られますが、その初期のTime2Wait待ちの期間の秒後にTime2Retainの中で終了しなければなりません。
6.4.1. Timeouts on Transport Exception Events
6.4.1. 輸送例外出来事におけるタイムアウト
A transport connection shutdown or a transport reset without any preceding iSCSI protocol interactions informing the end-points of the fact causes a Full Feature Phase iSCSI connection to be abruptly terminated. The timeout values to be used in this case are the negotiated values of defaultTime2Wait (Section 12.15 DefaultTime2Wait) and DefaultTime2Retain (Section 12.16 DefaultTime2Retain) text keys for the session.
事実のエンドポイントを知らせる少しも前のiSCSIプロトコル相互作用なしでリセットされた輸送接続閉鎖か輸送で、突然にFull Feature Phase iSCSI接続を終えます。 この場合使用されるべきタイムアウト値はセッションのためのdefaultTime2Wait(セクション12.15 DefaultTime2Wait)とDefaultTime2Retain(セクション12.16 DefaultTime2Retain)テキストキーの交渉された値です。
6.4.2. Timeouts on Planned Decommissioning
6.4.2. 計画された廃炉におけるタイムアウト
Any planned decommissioning of a Full Feature Phase iSCSI connection is preceded by either a Logout Response PDU, or an Async Message PDU. The Time2Wait and Time2Retain field values (section 10.15) in a Logout Response PDU, and the Parameter2 and Parameter3 fields of an Async Message (AsyncEvent types "drop the connection" or "drop all the connections"; section 10.9.1) specify the timeout values to be used in each of these cases.
Full Feature Phase iSCSI接続をどんな計画された解任することがLogout Response PDUかAsync Message PDUのどちらかによって先行されています。 Time2WaitとTime2RetainはLogout Response PDUで値(セクション10.15)をさばきます、そして、Async Message(AsyncEventタイプは、「接続を落とす」か、または「すべての接続を落とす」; 10.9に.1を区分する)のParameter2とParameter3分野はそれぞれのこれらの場合に使用されるためにタイムアウト値を指定します。
These timeout values are only applicable for the affected connection, and the tasks active on that connection. These timeout values have no bearing on initiator timers (if any) that are already running on connections or tasks associated with that session.
影響を受ける接続、およびその接続のときにアクティブなタスクだけに、これらのタイムアウト値は適切です。 これらのタイムアウト値は(もしあれば)の既にそのセッションに関連している接続かタスクで動いている創始者タイマの上に堪えることを持っていません。
6.5. Implicit Termination of Tasks
6.5. タスクの暗黙の終了
A target implicitly terminates the active tasks due to iSCSI protocol dynamics in the following cases:
目標は以下の場合におけるiSCSIプロトコル力学のためそれとなくアクティブ・タスクを終えます:
a) When a connection is implicitly or explicitly logged out with
the reason code of "Close the connection" and there are active
tasks allegiant to that connection.
a) 接続が理由コードでそれとなくか明らかにいつでログアウトされるかが「接続を終えます」、そして、その接続へのアクティブ・タスクallegiantがあります。
b) When a connection fails and the connection state eventually
times out (state transition M1 in Section 7.2.2 State
Transition Descriptions for Initiators and Targets) and there
are active tasks allegiant to that connection.
b) 接続がいつ、失敗するか、そして、接続は結局(InitiatorsとTargetsのためのセクション7.2.2の州Transition記述における状態遷移M1)より回を述べます、そして、その接続へのアクティブ・タスクallegiantがあります。
c) When a successful Logout with the reason code of "remove the
connection for recovery" is performed while there are active
tasks allegiant to that connection, and those tasks eventually
c) 結局、その接続と、それらのタスクへのアクティブ・タスクallegiantがある間「回復のための接続を外してください」の理由コードがあるうまくいっているLogoutが実行されるとき
Satran, et al. Standards Track [Page 77] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[77ページ]。
time out after the Time2Wait and Time2Retain periods without
allegiance reassignment.
Time2Waitの後のタイムアウトと忠誠再割当てのないTime2Retainの期間。
d) When a connection is implicitly or explicitly logged out with
the reason code of "Close the session" and there are active
tasks in that session.
d) 接続が理由コードでそれとなくか明らかにいつでログアウトされるかが「セッションを終えます」、そして、そのセッションにはアクティブ・タスクがあります。
If the tasks terminated in the above cases a), b, c) and d)are SCSI tasks, they must be internally terminated as if with CHECK CONDITION status. This status is only meaningful for appropriately handling the internal SCSI state and SCSI side effects with respect to ordering because this status is never communicated back as a terminating status to the initiator. However additional actions may have to be taken at SCSI level depending on the SCSI context as defined by the SCSI standards (e.g., queued commands and ACA, in cases a), b), and c), after the tasks are terminated, the target MUST report a Unit Attention condition on the next command processed on any connection for each affected I_T_L nexus with the status of CHECK CONDITION, and the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT" , etc. - see [SAM2] and [SPC3]).
上の場合a)、b、c)、およびd)で終えられたタスクがSCSIタスクであるなら、まるでCHECK CONDITION状態で終えるかのように内部的にそれらを終えなければなりません。 この状態が決して伝え返されないので注文することに関して適切に単に内部のSCSI状態とSCSI副作用を扱うのに、この状態は終わり状態として創始者に重要です。 SCSI規格(例えば、場合a)、b)、およびcでコマンドとACAを列に並ばせる)によって定義されるようにSCSI文脈に依存するSCSIレベルでどのように追加行動を取らなければならないかもしれなくてもさえ、タスクが終えられた後に目標は、次のコマンドに関するUnit Attention状態がCHECK CONDITIONの状態、および47h/7FhのASC/ASCQ値があるそれぞれの影響を受けるI_T_L結びつきのためのどんな接続のときにも処理されたと報告しなければなりません--「ISCSIプロトコルイベントによってクリアされたいくつかのコマンド」など - [SAM2]と[SPC3)を見てください。
6.6. Format Errors
6.6. 形式誤り
The following two explicit violations of PDU layout rules are format errors:
PDUレイアウト規則の以下の2つの明白な違反が形式誤りです:
a) Illegal contents of any PDU header field except the Opcode
(legal values are specified in Section 10 iSCSI PDU Formats).
b) Inconsistent field contents (consistent field contents are
specified in Section 10 iSCSI PDU Formats).
a) Opcode(法定価格はセクション10 iSCSI PDU Formatsで指定される)を除いて、どんなPDUヘッダーに関する違法コンテンツも. b)をさばきます。 矛盾した分野コンテンツ(一貫した分野内容はセクション10 iSCSI PDU Formatsで指定されます)。
Format errors indicate a major implementation flaw in one of the parties.
形式誤りはパーティーのひとりで主要な実現欠点を示します。
When a target or an initiator receives an iSCSI PDU with a format error, it MUST immediately terminate all transport connections in the session either with a connection close or with a connection reset and escalate the format error to session recovery (see Section 6.1.4.4 Session Recovery).
目標か創始者が形式誤りでiSCSI PDUを受け取るとき、すぐに、近くか接続リセットとの関係と共にセッションにおけるすべての輸送の接続を終えて、形式誤りをセッション回復に徐々に拡大しなければならない、(セクション6.1.4を見てください、.4Session Recovery)
6.7. Digest Errors
6.7. ダイジェスト誤り
The discussion of the legal choices in handling digest errors below excludes session recovery as an explicit option, but either party detecting a digest error may choose to escalate the error to session recovery.
以下の取り扱いダイジェスト誤りにおける、法的な選択の議論は明白なオプションとしてセッション回復を除きますが、ダイジェスト誤りを検出する何れの当事者は、セッション回復に誤りを徐々に拡大するのを選ぶかもしれません。
Satran, et al. Standards Track [Page 78] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[78ページ]。
When a target or an initiator receives any iSCSI PDU, with a header digest error, it MUST either discard the header and all data up to the beginning of a later PDU or close the connection. Because the digest error indicates that the length field of the header may have been corrupted, the location of the beginning of a later PDU needs to be reliably ascertained by other means such as the operation of a sync and steering layer.
目標か創始者がヘッダーダイジェスト誤りでどんなiSCSI PDUも受け取るとき、それは、ヘッダーとすべてのデータを後のPDUの始まりまで捨てなければならないか、または接続を終えなければなりません。 ダイジェスト誤りが、ヘッダーの長さの分野が腐敗しているかもしれないのを示すので、後のPDUの始まりの位置は、同時性と操縦層の操作などの他の手段で確かに確かめられる必要があります。
When a target receives any iSCSI PDU with a payload digest error, it MUST answer with a Reject PDU with a reason code of Data-Digest-Error and discard the PDU.
目標がペイロードダイジェスト誤りでどんなiSCSI PDUも受けるとき、それは、Reject PDUと共にDataダイジェスト誤りの理由コードで答えて、PDUを捨てなければなりません。
- If the discarded PDU is a solicited or unsolicited iSCSI data
PDU (for immediate data in a command PDU, non-data PDU rule
below applies), the target MUST do one of the following:
a) Request retransmission with a recovery R2T.
b) Terminate the task with a response PDU with a CHECK
CONDITION Status and an iSCSI Condition of "protocol service
CRC error" (Section 10.4.7.2 Sense Data). If the target
chooses to implement this option, it MUST wait to receive
all the data (signaled by a Data PDU with the final bit set
for all outstanding R2Ts) before sending the response PDU.
A task management command (such as an abort task) from the
initiator during this wait may also conclude the task.
- No further action is necessary for targets if the discarded PDU
is a non-data PDU. In case of immediate data being present on
a discarded command, the immediate data is implicitly recovered
when the task is retried (see section 6.2.1), followed by the
entire data transfer for the task.
- 捨てられたPDUが請求されたか求められていないiSCSIデータPDU(コマンドPDUの即値データに関して、以下の非データPDU規則は適用される)であるなら、目標は以下の1つをしなければなりません: a) 回復R2T.b)で「再-トランスミッション」を要求してください。 CHECK CONDITION Statusと応答PDUと「プロトコルサービスCRC誤り」のiSCSI Conditionと共にタスクを終えてください、(セクション10.4.7、.2Sense Data) 目標が、このオプションを実行するのを選ぶなら、それは、応答PDUを送る前にすべてのデータ(すべての傑出しているR2Tsに設定された最終的なビットでData PDUによって合図される)を受け取るのを待たなければなりません。 また、この待ちの間の創始者からのタスク管理コマンド(アボートタスクなどの)はタスクを結論づけるかもしれません。 - さらなるどんな動作も捨てられたPDUが非データPDUであるなら目標に必要ではありません。 タスクが再試行されるとき(セクション6.2.1を見てください)、捨てられたコマンドのときに存在している即値データの場合には、即値データはそれとなく回復されます、全体のデータ転送がタスクのためにあとに続いていて。
When an initiator receives any iSCSI PDU with a payload digest error, it MUST discard the PDU.
創始者がペイロードダイジェスト誤りでどんなiSCSI PDUも受け取るとき、それはPDUを捨てなければなりません。
- If the discarded PDU is an iSCSI data PDU, the initiator MUST do
one of the following:
- 捨てられたPDUがiSCSIデータPDUであるなら、創始者は以下の1つをしなければなりません:
a) Request the desired data PDU through SNACK. In response to the
SNACK, the target MUST either resend the data PDU or reject the
SNACK with a Reject PDU with a reason code of "SNACK reject" in
which case:
i) If the status has not already been sent for the command,
the target MUST terminate the command with a CHECK
CONDITION Status and an iSCSI Condition of "SNACK rejected"
(Section 10.4.7.2 Sense Data).
ii) If the status was already sent, no further action is
necessary for the target. The initiator in this case MUST
wait for the status to be received and then discard it, so
as to internally signal the completion with CHECK CONDITION
a) SNACKを通して必要なデータPDUを要求してください。 SNACKに対応して、目標は、その場合「SNACK廃棄物」の理由コードでデータPDUを再送しなければならないか、またはReject PDUと共にSNACKを拒絶しなければなりません: i) 状態がコマンドのために既に送られないなら、目標が「拒絶されたSNACK」のCHECK CONDITION StatusとiSCSI Conditionとのコマンドを終えなければならない、(セクション10.4.7、.2Sense Data) . ii) 既に状態を送ったなら、さらなるどんな動作も目標に必要ではありません。 この場合、創始者は、状態が受け取られて、次に、それを捨てるのを待たなければなりません、内部的にCHECK CONDITIONとの完成に合図するために
Satran, et al. Standards Track [Page 79] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[79ページ]。
Status and an iSCSI Condition of "protocol service CRC
error" (Section 10.4.7.2 Sense Data).
b) Abort the task and terminate the command with an error.
「プロトコルサービスCRC誤り」の状態とiSCSI Condition、(セクション10.4.7、.2Sense Data) . b) タスクを中止してください、そして、誤りでコマンドを終えてください。
- If the discarded PDU is a response PDU, the initiator MUST do one
of the following:
- PDU、捨てられたPDUが応答であるなら、創始者は以下の1つをしなければなりません:
a) Request PDU retransmission with a status SNACK.
b) Logout the connection for recovery and continue the tasks on a
different connection instance as described in Section 6.2 Retry
and Reassign in Recovery.
c) Logout to close the connection (abort all the commands
associated with the connection).
a) 状態SNACK. bと要求PDU retransmission) ログアウト、回復のための接続、セクション6.2 Recovery. cのRetryとReassignで説明されるように異なった接続例に関するタスクを続けてください、) ログアウトして(接続に関連しているすべてのコマンドを中止してください)、接続を終えてください。
- No further action is necessary for initiators if the discarded PDU
is an unsolicited PDU (e.g., Async, Reject). Task timeouts as in
the initiator waiting for a command completion, or process
timeouts, as in the target waiting for a Logout, will ensure that
the correct operational behavior will result in these cases
despite the discarded PDU.
- さらなるどんな動作も捨てられたPDUが求められていないPDU(例えば、Async、Reject)であるなら創始者に必要ではありません。 コマンド完成を待っている創始者のようにタイムアウトに仕事を課してください。さもないと、過程タイムアウトは、Logoutを待つ目標のように捨てられたPDUにもかかわらず、正しい操作上の振舞いがこれらのケースをもたらすのを確実にするでしょう。
6.8. Sequence Errors
6.8. 系列誤り
When an initiator receives an iSCSI R2T/data PDU with an out of order R2TSN/DataSN or a SCSI response PDU with an ExpDataSN that implies missing data PDU(s), it means that the initiator must have detected a header or payload digest error on one or more earlier R2T/data PDUs. The initiator MUST address these implied digest errors as described in Section 6.7 Digest Errors. When a target receives a data PDU with an out of order DataSN, it means that the target must have hit a header or payload digest error on at least one of the earlier data PDUs. The target MUST address these implied digest errors as described in Section 6.7 Digest Errors.
創始者が故障しているR2TSN/DataSNかSCSI応答PDUと共に欠測値PDU(s)を含意するExpDataSNでiSCSI R2T/データPDUを受け取るとき、それは、創始者が1以前のR2T/データPDUsにヘッダーかペイロードダイジェスト誤りを検出したに違いないことを意味します。 創始者はセクション6.7 Digest Errorsで説明されるようにこれらの暗示しているダイジェスト誤りを記述しなければなりません。 目標が故障しているDataSNと共にデータPDUを受けるとき、それは、目標が少なくとも以前のデータPDUsの1つにヘッダーかペイロードダイジェスト誤りに当ったに違いないことを意味します。 目標はセクション6.7 Digest Errorsで説明されるようにこれらの暗示しているダイジェスト誤りを記述しなければなりません。
When an initiator receives an iSCSI status PDU with an out of order StatSN that implies missing responses, it MUST address the one or more missing status PDUs as described in Section 6.7 Digest Errors. As a side effect of receiving the missing responses, the initiator may discover missing data PDUs. If the initiator wants to recover the missing data for a command, it MUST NOT acknowledge the received responses that start from the StatSN of the relevant command, until it has completed receiving all the data PDUs of the command.
創始者がなくなった応答を含意する故障しているStatSNと共にiSCSI状態PDUを受け取るとき、状態PDUsがセクション6.7 Digest Errorsで説明されるようにいなくて寂しくて、それはものか以上を記述しなければなりません。 なくなった応答を受ける副作用として、創始者は欠測値PDUsを発見するかもしれません。 創始者がコマンドのための欠測値を回復したいなら、関連コマンドのStatSNから始める容認された応答を承諾してはいけません、コマンドのすべてのデータPDUsを受けるのを完成するまで。
When an initiator receives duplicate R2TSNs (due to proactive retransmission of R2Ts by the target) or duplicate DataSNs (due to proactive SNACKs by the initiator), it MUST discard the duplicates.
創始者が写しR2TSNs(目標はR2Tsの「再-トランスミッション」を予測する)か写しDataSNs(創始者はSNACKsを予測する)を受け取るとき、それは写しを捨てなければなりません。
Satran, et al. Standards Track [Page 80] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[80ページ]。
6.9. SCSI Timeouts
6.9. SCSIタイムアウト
An iSCSI initiator MAY attempt to plug a command sequence gap on the target end (in the absence of an acknowledgement of the command by way of ExpCmdSN) before the ULP timeout by retrying the unacknowledged command, as described in Section 6.2 Retry and Reassign in Recovery.
iSCSI創始者は、ULPタイムアウトの前に目標エンド(ExpCmdSNを通したコマンドの承認がないとき)に不承認のコマンドを再試行することによってコマンド・シーケンス赤字を埋めたのを試みるかもしれません、セクション6.2 RecoveryのRetryとReassignで説明されるように。
On a ULP timeout for a command (that carried a CmdSN of n), if the iSCSI initiator intends to continue the session, it MUST abort the command by either using an appropriate Task Management function request for the specific command, or a "close the connection" Logout. When using an ABORT TASK, if the ExpCmdSN is still less than (n+1), the target may see the abort request while missing the original command itself due to one of the following reasons:
コマンド(それはnのCmdSNを運んだ)のためのULPタイムアウトでは、iSCSI創始者がセッションを続けるつもりであるなら、それは特定のコマンドに適切なTask Management機能要求を使用するか、「接続を終えてください」というLogoutのどちらかによるコマンドを中止しなければなりません。 ABORT TASKを使用するときには、ExpCmdSNが(n+1)、目標がそうするかもしれないよりなお少ないなら、以下の理由の1つによるオリジナルのコマンド自体を逃している間、アボート要求を見てください:
- Original command was dropped due to digest error.
- Connection on which the original command was sent was
successfully logged out. Upon logout, the unacknowledged
commands issued on the connection being logged out are
discarded.
- オリジナルのコマンドはダイジェスト誤りのため落とされました。 - オリジナルのコマンドが送られた接続は首尾よくログアウトされました。 ログアウトしてください、そして、ログアウトされている接続のときに発行された不承認のコマンドは捨てられます。
If the abort request is received and the original command is missing, targets MUST consider the original command with that RefCmdSN to be received and issue a Task Management response with the response code: "Function Complete". This response concludes the task on both ends. If the abort request is received and the target can determine (based on the Referenced Task Tag) that the command was received and executed and also that the response was sent prior to the abort, then the target MUST respond with the response code of "Task Does Not Exist".
アボート要求が受信されていて、オリジナルのコマンドがなくなるなら、目標は応答コードで受けられて、Task Management応答を発行するためにそのRefCmdSNとのオリジナルのコマンドを考えなければなりません: 「機能完全です」。 この応答は両端でタスクを結論づけます。 アボート要求が受信されていて、目標が、コマンドが受け取られて、実行されて、また、応答がアボートの前に送られたことを決定できるなら(Referenced Task Tagに基づいています)、目標は「タスクは存在しない」応答コードで応じなければなりません。
6.10. Negotiation Failures
6.10. 交渉失敗
Text request and response sequences, when used to set/negotiate operational parameters, constitute the negotiation/parameter setting. A negotiation failure is considered to be one or more of the following:
操作上のパラメタを設定するか、または交渉するのに使用されると、テキスト要求と応答系列は交渉/パラメタ設定を設立します。 交渉失敗は以下の1つ以上であると考えられます:
- None of the choices, or the stated value, is acceptable to one
of the sides in the negotiation.
- The text request timed out and possibly terminated.
- The text request was answered with a Reject PDU.
- 選択、または額面のいずれも交渉で側の1つに許容できません。 - テキスト要求は、外で調節して、ことによると終わりました。 - テキスト要求はReject PDUと共に答えられました。
Satran, et al. Standards Track [Page 81] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[81ページ]。
The following two rules should be used to address negotiation failures:
以下の2つの規則が交渉失敗を記述するのに使用されるべきです:
- During Login, any failure in negotiation MUST be considered a
login process failure and the Login Phase must be terminated,
and with it, the connection. If the target detects the
failure, it must terminate the login with the appropriate Login
Response code.
- ログイン過程の失敗であると交渉におけるどんな失敗も考えなければならなくて、Loginの間、Login Phaseを終えられて、それ(接続)で考えなければなりません。 目標が失敗を検出するなら、それは適切なLogin Responseコードでログインを終えなければなりません。
- A failure in negotiation, while in the Full Feature Phase, will
terminate the entire negotiation sequence that may consist of a
series of text requests that use the same Initiator Task Tag.
The operational parameters of the session or the connection
MUST continue to be the values agreed upon during an earlier
successful negotiation (i.e., any partial results of this
unsuccessful negotiation MUST NOT take effect and MUST be
discarded).
- Full Feature Phaseにある間、交渉における失敗は同じInitiator Task Tagを使用する一連のテキスト要求から成るかもしれない全体の交渉系列を終えるでしょう。 セッションか接続の操作上のパラメタはずっと以前のうまくいっている交渉の間に同意された値であるに違いありません(この失敗の交渉のすなわちどんな部分的な結果も効いてはいけなくて、捨てなければなりません)。
6.11. Protocol Errors
6.11. プロトコル誤り
Mapping framed messages over a "stream" connection, such as TCP, makes the proposed mechanisms vulnerable to simple software framing errors. On the other hand, the introduction of framing mechanisms to limit the effects of these errors may be onerous on performance for simple implementations. Command Sequence Numbers and the above mechanisms for connection drop and reestablishment help handle this type of mapping errors.
TCPなどの「流れ」接続の上で縁どられたメッセージを写像するのに、提案されたメカニズムは簡単なソフトウェア縁どり誤りに傷つきやすくなります。 他方では、簡単な実現に、これらの誤りの影響を制限する縁どりメカニズムの導入は性能のときに煩わしいかもしれません。 接続のためのSequence民数記と上のメカニズムが落とすコマンドと再建は、誤りを写像するこのタイプを扱うのを助けます。
All violations of iSCSI PDU exchange sequences specified in this document are also protocol errors. This category of errors can only be addressed by fixing the implementations; iSCSI defines Reject and response codes to enable this.
また、本書では指定されたiSCSI PDU交換系列のすべての違反がプロトコル誤りです。 実現を修理することによって、誤りのこのカテゴリを記述できるだけです。 iSCSIは、これを可能にするためにRejectと応答コードを定義します。
6.12. Connection Failures
6.12. 接続失敗
iSCSI can keep a session in operation if it is able to keep/establish at least one TCP connection between the initiator and the target in a timely fashion. Targets and/or initiators may recognize a failing connection by either transport level means (TCP), a gap in the command sequence number, a response stream that is not filled for a long time, or by a failing iSCSI NOP (acting as a ping). The latter MAY be used periodically to increase the speed and likelihood of detecting connection failures. Initiators and targets MAY also use the keep-alive option on the TCP connection to enable early link failure detection on otherwise idle links.
それが直ちに創始者と目標との少なくとも1つのTCP接続を保つか、または確立できるなら、iSCSIは稼働中であるセッションを保つことができます。 目標、そして/または、創始者はレベルが意味するどちらの輸送(TCP)も、コマンド一連番号、長い間いっぱいにされない応答の流れにおけるずれか失敗iSCSI NOPによる失敗接続を認めるかもしれません(ピングとして機能して)。 後者は、接続失敗を検出する速度と可能性を広げるのに定期的に使用されるかもしれません。 また、創始者と目標は、TCP接続のときにそうでなければ、使用されていないリンクで早めのリンク失敗検出を可能にするのに生きている生活費オプションを使用するかもしれません。
Satran, et al. Standards Track [Page 82] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[82ページ]。
On connection failure, the initiator and target MUST do one of the following:
接続失敗では、創始者と目標は以下の1つをしなければなりません:
- Attempt connection recovery within the session (Section 6.1.4.3
Connection Recovery).
- セッション中に接続回復を試みてください、(セクション6.1.4、.3Connection Recovery)
- Logout the connection with the reason code "closes the
connection" (Section 10.14.5 Implicit termination of tasks),
re-issue missing commands, and implicitly terminate all active
commands. This option requires support for the
within-connection recovery class (Section 6.1.4.2 Recovery
Within-connection).
- ログアウトしてください。理由コードとの関係は「接続を終えます」、そして、(タスクのセクション10.14.5Implicit終了)なくなったコマンドを再発行してください、そして、それとなくすべての活発なコマンドを終えてください。 このオプションが接続の中の回復のクラスに支持を要する、(セクション6.1.4、.2Recovery Within-接続)
- Perform session recovery (Section 6.1.4.4 Session Recovery).
- セッション回復を実行してください、(セクション6.1.4、.4Session Recovery)
Either side may choose to escalate to session recovery (via the initiator dropping all the connections, or via an Async Message that announces the similar intent from a target), and the other side MUST give it precedence. On a connection failure, a target MUST terminate and/or discard all of the active immediate commands regardless of which of the above options is used (i.e., immediate commands are not recoverable across connection failures).
目標から同様の意図を発表するAsync Messageを通してどちらの側も、セッション回復に徐々に拡大するのを選ぶかもしれない、(創始者低下を通したすべての接続、)、反対側は優先権をそれに与えなければなりません。 接続失敗では、上のオプションのどれが使用されているかにかかわらず、目標は、活発な即座のコマンドのすべてを終える、そして/または、捨てなければなりません(すなわち、即座のコマンドは接続失敗の向こう側に回復可能ではありません)。
6.13. Session Errors
6.13. セッション誤り
If all of the connections of a session fail and cannot be reestablished in a short time, or if initiators detect protocol errors repeatedly, an initiator may choose to terminate a session and establish a new session.
セッションの接続のすべてが失敗して、まもなく復職できませんし、創始者が繰り返してプロトコル誤りを検出もするなら、創始者は、セッションを終えて、新しいセッションを確立するのを選ぶかもしれません。
In this case, the initiator takes the following actions:
この場合、創始者は以下の行動を取ります:
- Resets or closes all the transport connections.
- Terminates all outstanding requests with an appropriate
response before initiating a new session. If the same I_T
nexus is intended to be reestablished, the initiator MUST
employ session reinstatement (see section 5.3.5).
- すべての輸送の接続をリセットするか、または終えます。 - 新しいセッションを開始する前の適切な応答ですべての傑出している要求を終えます。 同じ私であるなら_T結びつきが復職することを意図して、創始者はセッション復職を使わなければなりません(セクション5.3.5を見てください)。
When the session timeout (the connection state timeout for the last failed connection) happens on the target, it takes the following actions:
セッションタイムアウト(最後に失敗した接続のための接続州のタイムアウト)が目標の上で起こると、以下の行動を取ります:
- Resets or closes the TCP connections (closes the session).
- Terminates all active tasks that were allegiant to the
connection(s) that constituted the session.
- TCP接続(セッションを終える)をリセットするか、または終えます。 - セッションを構成した接続へのallegiantであったすべてのアクティブ・タスクを終えます。
A target MUST also be prepared to handle a session reinstatement request from the initiator, that may be addressing session errors.
それは、また、創始者からのセッション復職要求を扱うように目標を準備しなければならなくて、セッション誤りを記述しているかもしれません。
Satran, et al. Standards Track [Page 83] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[83ページ]。
7. State Transitions
7. 状態遷移
iSCSI connections and iSCSI sessions go through several well-defined states from the time they are created to the time they are cleared.
iSCSI接続とiSCSIセッションはそれらが作成される時からそれらがきれいにされる時までいくつかの明確な州を通ります。
The connection state transitions are described in two separate but dependent state diagrams for ease in understanding. The first diagram, "standard connection state diagram", describes the connection state transitions when the iSCSI connection is not waiting for, or undergoing, a cleanup by way of an explicit or implicit Logout. The second diagram, "connection cleanup state diagram", describes the connection state transitions while performing the iSCSI connection cleanup.
接続状態遷移は理解における容易さのために2個の別々の、しかし、依存する州のダイヤグラムで説明されます。 iSCSI接続が明白であるか内在しているLogoutを通した待ちでない、また受けているaクリーンアップでないときに、「標準の接続州のダイヤグラム」という最初のダイヤグラムは接続状態遷移について説明します。 「接続クリーンアップ州のダイヤグラム」という2番目のダイヤグラムはiSCSI接続クリーンアップを実行している間、接続状態遷移について説明します。
The "session state diagram" describes the state transitions an iSCSI session would go through during its lifetime, and it depends on the states of possibly multiple iSCSI connections that participate in the session.
「セッション州のダイヤグラム」はiSCSIセッションが生涯直面している状態遷移について説明します、そして、それはセッションのときに参加することによると複数のiSCSI接続の州に頼っています。
States and state transitions are described in the text, tables and diagrams. The diagrams are used for illustration. The text and the tables are the governing specification.
州と状態遷移はテキスト、テーブル、およびダイヤグラムで説明されます。ダイヤグラムはイラストに使用されます。 テキストとテーブルは支配的な仕様です。
7.1. Standard Connection State Diagrams
7.1. 標準の接続州のダイヤグラム
7.1.1. State Descriptions for Initiators and Targets
7.1.1. 創始者と目標のための州の記述
State descriptions for the standard connection state diagram are as follows:
標準の接続州のダイヤグラムのための州の記述は以下の通りです:
-S1: FREE
-initiator: State on instantiation, or after successful
connection closure.
-target: State on instantiation, or after successful connection
closure.
-S2: XPT_WAIT
-initiator: Waiting for a response to its transport connection
establishment request.
-target: Illegal
-S3: XPT_UP
-initiator: Illegal
-target: Waiting for the Login process to commence.
-S4: IN_LOGIN
-initiator: Waiting for the Login process to conclude, possibly
involving several PDU exchanges.
-target: Waiting for the Login process to conclude, possibly
involving several PDU exchanges.
-S1: 創始者を解放してください: 具体化か、うまくいっている接続閉鎖の後の状態。 -以下を狙ってください。 具体化か、うまくいっている接続閉鎖の後の状態。 -S2: XPT_待創始者ち: 接続設立が要求する輸送への応答を待っています。 -以下を狙ってください。 不法な-S3: 創始者へのXPT_: 不法入国者目標: Loginの過程が始まるのを待っています。 -S4: _ログイン創始者で: ことによると数回のPDU交換にかかわって、Loginの過程が終わるのを待っています。 -以下を狙ってください。 ことによると数回のPDU交換にかかわって、Loginの過程が終わるのを待っています。
Satran, et al. Standards Track [Page 84] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[84ページ]。
-S5: LOGGED_IN
-initiator: In Full Feature Phase, waiting for all internal,
iSCSI, and transport events.
-target: In Full Feature Phase, waiting for all internal, iSCSI,
and transport events.
-S6: IN_LOGOUT
-initiator: Waiting for a Logout response.
-target: Waiting for an internal event signaling completion of
logout processing.
-S7: LOGOUT_REQUESTED
-initiator: Waiting for an internal event signaling readiness to
proceed with Logout.
-target: Waiting for the Logout process to start after having
requested a Logout via an Async Message.
-S8: CLEANUP_WAIT
-initiator: Waiting for the context and/or resources to initiate
the cleanup processing for this CSM.
-target: Waiting for the cleanup process to start for this CSM.
-S5: 創始者の登録された_: Full Feature Phase、内部ですべてを待つ、iSCSI、および輸送出来事で。 -以下を狙ってください。 Full Feature Phase、内部ですべてを待つ、iSCSI、および輸送出来事で。 -S6: _では、創始者はログアウトしています: Logout応答を待っています。 -以下を狙ってください。 内部のイベントシグナリング完成が待っている、処理しながら、ログアウトしてください。 -S7: ログアウトしてください。_は創始者を要求しました: Logoutを続ける内部のイベントシグナリング準備を待っています。 -以下を狙ってください。 Async Messageを通してLogoutを要求した後にLogoutの過程が始まるのを待っています。 -S8: クリーンアップ_待創始者ち: 文脈、そして/または、リソースがこのCSMのためにクリーンアップ処理を開始するのを待っています。 -以下を狙ってください。 クリーンアップの過程がこのCSMに出発するのを待っています。
7.1.2. State Transition Descriptions for Initiators and Targets
7.1.2. 創始者と目標のための状態遷移記述
-T1:
-initiator: Transport connect request was made (e.g., TCP SYN
sent).
-target: Illegal
-T2:
-initiator: Transport connection request timed out, a transport
reset was received, or an internal event of receiving a
Logout response (success) on another connection for a
"close the session" Logout request was received.
-target:Illegal
-T3:
-initiator: Illegal
-target: Received a valid transport connection request that
establishes the transport connection.
-T4:
-initiator: Transport connection established, thus prompting the
initiator to start the iSCSI Login.
-target: Initial iSCSI Login Request was received.
-T5:
-initiator: The final iSCSI Login Response with a Status-Class
of zero was received.
-target: The final iSCSI Login Request to conclude the Login
Phase was received, thus prompting the target to send the
final iSCSI Login Response with a Status-Class of zero.
-T1: -創始者: 輸送は接続します。要求をしました(例えば、TCP SYNは発信しました)。 -以下を狙ってください。 不法な-T2: -創始者: 輸送接続要求が外で調節されたか、輸送リセットを受けたか、または別の接続のときに「セッションを終えてください」というLogout要求のために、Logout応答(成功)を受ける内部の出来事を受け取りました。 -目標: 不法な-T3: -創始者: 不法入国者目標: 輸送接続を確立する有効な輸送接続要求を受け取りました。 -T4: -創始者: 確立された、その結果、創始者がiSCSI Loginを始動するようにうながした接続を輸送してください。 -以下を狙ってください。 初期のiSCSI Login Requestを受け取りました。 -T5: -創始者: ゼロStatus-クラスがある最終的なiSCSI Login Responseを受け取りました。 -以下を狙ってください。 結論すると、、最終的なiSCSI Login Request Login Phaseを受け取りました、その結果、目標がゼロStatus-クラスがある最終的なiSCSI Login Responseを送るようにうながします。
Satran, et al. Standards Track [Page 85] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[85ページ]。
-T6:
-initiator: Illegal
-target: Timed out waiting for an iSCSI Login, transport
disconnect indication was received, transport reset was
received, or an internal event indicating a transport
timeout was received. In all these cases, the connection is
to be closed.
-T7:
-initiator - one of the following events caused the transition:
- The final iSCSI Login Response was received with a
non-zero Status-Class.
- Login timed out.
- A transport disconnect indication was received.
- A transport reset was received.
- An internal event was received indicating a transport
timeout.
- An internal event of receiving a Logout response (success)
on another connection for a "close the session" Logout
request was received.
-T6: -創始者: 不法入国者目標: 外でiSCSI Loginを待ちながら調節されて、輸送分離指示を受けたか、輸送リセットを受けたか、または輸送タイムアウトを示す内部の出来事を受け取りました。 これらのすべての場合では、接続は閉店していることになっています。 -T7: -創始者--以下の出来事のひとりは変遷を引き起こしました: - 非ゼロのStatus-クラスと共に最終的なiSCSI Login Responseを受け取りました。 - ログインは外で調節されました。 - 輸送分離指示を受けました。 - 輸送リセットを受けました。 - 輸送タイムアウトを示しながら、内部の出来事を受け取りました。 - 別の接続のときに「セッションを終えてください」というLogout要求のために、Logout応答(成功)を受ける内部の出来事を受け取りました。
In all these cases, the transport connection is closed.
これらのすべての場合では、輸送接続は閉じられます。
-target - one of the following events caused the transition:
- The final iSCSI Login Request to conclude the Login Phase
was received, prompting the target to send the final iSCSI
Login Response with a non-zero Status-Class.
- Login timed out.
- Transport disconnect indication was received.
- Transport reset was received.
- An internal event indicating a transport timeout was
received.
- On another connection a "close the session" Logout request
was received.
In all these cases, the connection is to be closed.
-T8:
-initiator: An internal event of receiving a Logout response
(success) on another connection for a "close the session"
Logout request was received, thus closing this connection
requiring no further cleanup.
-target: An internal event of sending a Logout response
(success) on another connection for a "close the session"
Logout request was received, or an internal event of a
successful connection/session reinstatement is received,
thus prompting the target to close this connection cleanly.
-目標--以下の出来事のひとりは変遷を引き起こしました: - 結論すると、、最終的なiSCSI Login Request Login Phaseを受け取りました、目標が非ゼロのStatus-クラスがある最終的なiSCSI Login Responseを送るようにうながして。 - ログインは外で調節されました。 - 輸送分離指示を受けました。 - 輸送リセットを受けました。 - 輸送タイムアウトを示す内部の出来事を受け取りました。 - 別の接続のときに、「セッションを終えてください」というLogout要求を受け取りました。 これらのすべての場合では、接続は閉店していることになっています。 -T8: -創始者: 別の接続のときに「セッションを終えてください」というLogout要求のために、Logout応答(成功)を受ける内部の出来事を受け取りました、その結果、一層のクリーンアップを全く必要としないこの接続を終えます。 -以下を狙ってください。 「セッションを終えてください」というLogout要求のために、Logout応答(成功)を別の接続に送る内部の出来事を受け取ったか、うまくいっている接続/セッション復職の内部の出来事は、受け取られて、その結果、目標が清潔にこの接続を終えるようにうながしています。
Satran, et al. Standards Track [Page 86] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[86ページ]。
-T9, T10:
-initiator: An internal event that indicates the readiness to
start the Logout process was received, thus prompting an
iSCSI Logout to be sent by the initiator.
-target: An iSCSI Logout request was received.
-T11, T12:
-initiator: Async PDU with AsyncEvent "Request Logout" was
received.
-target: An internal event that requires the decommissioning of
the connection is received, thus causing an Async PDU with
an AsyncEvent "Request Logout" to be sent.
-T13:
-initiator: An iSCSI Logout response (success) was received, or
an internal event of receiving a Logout response (success)
on another connection for a "close the session" Logout
request was received.
-target: An internal event was received that indicates
successful processing of the Logout, which prompts an iSCSI
Logout response (success) to be sent; an internal event of
sending a Logout response (success) on another connection
for a "close the session" Logout request was received; or an
internal event of a successful connection/session
reinstatement is received. In all these cases, the
transport connection is closed.
-T9、T10: -創始者: Logoutの過程を始める準備を示す内部の出来事を受け取りました、その結果、iSCSI Logoutが創始者によって送られるようにうながします。 -以下を狙ってください。 iSCSI Logout要求を受け取りました。 -T11、T12: -創始者: AsyncEventとAsync PDUは「ログアウトするよう要求します」。受け取りました。 -以下を狙ってください。 接続を解任することを必要とする内部の出来事が受け取られている、その結果、AsyncEventと共にAsync PDUを引き起こすのは送るために「ログアウトするよう要求します」。 -T13: -創始者: iSCSI Logout応答(成功)を受けたか、または別の接続のときに「セッションを終えてください」というLogout要求のために、Logout応答(成功)を受ける内部の出来事を受け取りました。 -以下を狙ってください。 iSCSI Logout応答(成功)が送られるようにうながすLogoutのうまくいっている処理を示す内部の出来事を受け取りました。 「セッションを終えてください」というLogout要求のために、Logout応答(成功)を別の接続に送る内部の出来事を受け取りました。 または、うまくいっている接続/セッション復職の内部の出来事は受け取られています。 これらのすべての場合では、輸送接続は閉じられます。
-T14:
-initiator: Async PDU with AsyncEvent "Request Logout" was
received again.
-target: Illegal
-T15, T16:
-initiator: One or more of the following events caused this
transition:
-Internal event that indicates a transport connection
timeout was received thus prompting transport RESET or
transport connection closure.
-A transport RESET.
-A transport disconnect indication.
-Async PDU with AsyncEvent "Drop connection" (for this CID).
-Async PDU with AsyncEvent "Drop all connections".
-target: One or more of the following events caused this
transition:
-Internal event that indicates a transport connection
timeout was received, thus prompting transport RESET or
transport connection closure.
-An internal event of a failed connection/session
reinstatement is received.
-A transport RESET.
-A transport disconnect indication.
-T14: -創始者: AsyncEventとAsync PDUは「ログアウトするよう要求します」。再び、受け取りました。 -以下を狙ってください。 不法な-T15、T16: -創始者: 以下の出来事のより多くのひとりはこの変遷を引き起こしました: -その結果、輸送RESETか輸送接続閉鎖をうながしながら、輸送接続タイムアウトを示す内部の出来事を受け取りました。 -輸送RESET。 -輸送分離指示。 -AsyncEventとAsync PDUは「接続を落とす」(このCIDのために)。 -AsyncEventとAsync PDUは「すべての接続を落とします」。 -以下を狙ってください。 以下の出来事のより多くのひとりはこの変遷を引き起こしました: -輸送接続タイムアウトを示す内部の出来事を受け取って、その結果、輸送RESETか輸送接続閉鎖をうながしました。 -失敗した接続/セッション復職の内部の出来事は受け取られています。 -輸送RESET。 -輸送分離指示。
Satran, et al. Standards Track [Page 87] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[87ページ]。
-Internal emergency cleanup event was received which prompts
an Async PDU with AsyncEvent "Drop connection" (for this
CID), or event "Drop all connections".
-T17:
-initiator: One or more of the following events caused this
transition:
-Logout response, (failure i.e., a non-zero status) was
received, or Logout timed out.
-Any of the events specified for T15 and T16.
-target: One or more of the following events caused this
transition:
-Internal event that indicates a failure of the Logout
processing was received, which prompts a Logout response
(failure, i.e., a non-zero status) to be sent.
-Any of the events specified for T15 and T16.
-T18:
-initiator: An internal event of receiving a Logout response
(success) on another connection for a "close the session"
Logout request was received.
-target: An internal event of sending a Logout response
(success) on another connection for a "close the session"
Logout request was received, or an internal event of a
successful connection/session reinstatement is received. In
both these cases, the connection is closed.
-AsyncEvent「低下接続」(このCIDのための)と共にAsync PDUをうながす内部の非常時のクリーンアップ出来事を受け取ったか、または出来事は「すべての接続を落とします」。 -T17: -創始者: 以下の出来事のより多くのひとりはこの変遷を引き起こしました: -ログアウト、応答、(失敗、すなわち、非ゼロ状態) 受け取られているかLogoutの調節されたアウトはそうですか? -出来事のいずれもT15とT16に指定しました。 -以下を狙ってください。 以下の出来事のより多くのひとりはこの変遷を引き起こしました: -Logout処理の失敗(Logout応答(すなわち、失敗、非ゼロ状態)が送られるようにうながす)が受け取られたのを示す内部の出来事。 -出来事のいずれもT15とT16に指定しました。 -T18: -創始者: 別の接続のときに「セッションを終えてください」というLogout要求のために、Logout応答(成功)を受ける内部の出来事を受け取りました。 -以下を狙ってください。 「セッションを終えてください」というLogout要求のために、Logout応答(成功)を別の接続に送る内部の出来事を受け取ったか、またはうまくいっている接続/セッション復職の内部の出来事は受け取られています。 これらの場合の両方では、接続は閉じられます。
The CLEANUP_WAIT state (S8) implies that there are possible iSCSI tasks that have not reached conclusion and are still considered busy.
CLEANUP_WAIT州(S8)は、結論に達していなくて、忙しいとまだ考えられている可能なiSCSIタスクがあるのを含意します。
7.1.3. Standard Connection State Diagram for an Initiator
7.1.3. 創始者のための標準の接続州のダイヤグラム
Symbolic names for States:
Statesのための英字名:
S1: FREE
S2: XPT_WAIT
S4: IN_LOGIN
S5: LOGGED_IN
S6: IN_LOGOUT
S7: LOGOUT_REQUESTED
S8: CLEANUP_WAIT
S1: S2を解放してください: XPT_待ちS4: _では、S5はログインしています: S6の登録された_: _では、S7はログアウトしています: ログアウトしてください。_はS8を要求しました: クリーンアップ_は待っています。
Satran, et al. Standards Track [Page 88] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[88ページ]。
States S5, S6, and S7 constitute the Full Feature Phase operation of the connection.
州のS5、S6、およびS7は接続のFull Feature Phase操作を構成します。
The state diagram is as follows:
州のダイヤグラムは以下の通りです:
-------<-------------+
+--------->/ S1 \<----+ |
T13| +->\ /<-+ \ |
| / ---+--- \ \ |
| / | T2 \ | |
| T8 | |T1 | | |
| | | / |T7 |
| | | / | |
| | | / | |
| | V / / |
| | ------- / / |
| | / S2 \ / |
| | \ / / |
| | ---+--- / |
| | |T4 / |
| | V / | T18
| | ------- / |
| | / S4 \ |
| | \ / |
| | ---+--- | T15
| | |T5 +--------+---------+
| | | /T16+-----+------+ |
| | | / -+-----+--+ | |
| | | / / S7 \ |T12| |
| | | / +->\ /<-+ V V
| | | / / -+----- -------
| | | / /T11 |T10 / S8 \
| | V / / V +----+ \ /
| | ---+-+- ----+-- | -------
| | / S5 \T9 / S6 \<+ ^
| +-----\ /--->\ / T14 |
| ------- --+----+------+T17
+---------------------------+
-------<、-、-、-、-、-、-、-、-、-、-、-、--+ +--------->/S1\<。----+ | T13| +、-、>\/<-+\| | / ---+--- \ \ | | / | T2\| | | T8| |T1| | | | | | / |T7| | | | / | | | | | / | | | | V//| | | ------- / / | | | /S2\/| | | \ / / | | | ---+--- / | | | |T4/| | | V/| T18| | ------- / | | | /S4\| | | \ / | | | ---+--- | T15| | |T5+--------+---------+ | | | /T16+-----+------+ | | | | / -+-----+--+ | | | | | //S7\|T12| | | | | /+->、\、/<-+V V| | | / / -+----- ------- | | | //T11|T10 / S8\| | +に対するV//----+ \ / | | ---+-+- ----+-- | ------- | | / S5 \T9 / S6 \<+ ^ | +-----\ /--->\/T14| | ------- --+----+------+ T17+---------------------------+
Satran, et al. Standards Track [Page 89] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[89ページ]。
The following state transition table represents the above diagram. Each row represents the starting state for a given transition, which after taking a transition marked in a table cell would end in the state represented by the column of the cell. For example, from state S1, the connection takes the T1 transition to arrive at state S2. The fields marked "-" correspond to undefined transitions.
以下の状態遷移テーブルは上のダイヤグラムを表します。 各列は与えられた変遷のために始めの状態を表します。(テーブルセルの中でマークされた変遷を取った後に、それは、セルに関するコラムによって表された状態に終わるでしょう)。 例えば、州のS1から、接続は、州のS2に到着するようにT1変遷を取ります。 「-」であることが示される分野は未定義の変遷に対応しています。
+----+---+---+---+---+----+---+
|S1 |S2 |S4 |S5 |S6 |S7 |S8 |
---+----+---+---+---+---+----+---+
S1| - |T1 | - | - | - | - | - |
---+----+---+---+---+---+----+---+
S2|T2 |- |T4 | - | - | - | - |
---+----+---+---+---+---+----+---+
S4|T7 |- |- |T5 | - | - | - |
---+----+---+---+---+---+----+---+
S5|T8 |- |- | - |T9 |T11 |T15|
---+----+---+---+---+---+----+---+
S6|T13 |- |- | - |T14|- |T17|
---+----+---+---+---+---+----+---+
S7|T18 |- |- | - |T10|T12 |T16|
---+----+---+---+---+---+----+---+
S8| - |- |- | - | - | - | - |
---+----+---+---+---+---+----+---+
+----+---+---+---+---+----+---+ |S1|S2|S4|S5|S6|S7|S8| ---+----+---+---+---+---+----+---+ S1| - |T1| - | - | - | - | - | ---+----+---+---+---+---+----+---+ S2|T2|- |T4| - | - | - | - | ---+----+---+---+---+---+----+---+ S4|T7|- |- |T5| - | - | - | ---+----+---+---+---+---+----+---+ S5|T8|- |- | - |T9|T11|T15| ---+----+---+---+---+---+----+---+ S6|T13|- |- | - |T14|- |T17| ---+----+---+---+---+---+----+---+ S7|T18|- |- | - |T10|T12|T16| ---+----+---+---+---+---+----+---+ S8| - |- |- | - | - | - | - | ---+----+---+---+---+---+----+---+
7.1.4. Standard Connection State Diagram for a Target
7.1.4. 目標のための標準の接続州のダイヤグラム
Symbolic names for States:
Statesのための英字名:
S1: FREE
S3: XPT_UP
S4: IN_LOGIN
S5: LOGGED_IN
S6: IN_LOGOUT
S7: LOGOUT_REQUESTED
S8: CLEANUP_WAIT
S1: S3を解放してください: S4へのXPT_: _では、S5はログインしています: S6の登録された_: _では、S7はログアウトしています: ログアウトしてください。_はS8を要求しました: クリーンアップ_は待っています。
States S5, S6, and S7 constitute the Full Feature Phase operation of the connection.
州のS5、S6、およびS7は接続のFull Feature Phase操作を構成します。
Satran, et al. Standards Track [Page 90] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[90ページ]。
The state diagram is as follows:
州のダイヤグラムは以下の通りです:
-------<-------------+
+--------->/ S1 \<----+ |
T13| +->\ /<-+ \ |
| / ---+--- \ \ |
| / | T6 \ | |
| T8 | |T3 | | |
| | | / |T7 |
| | | / | |
| | | / | |
| | V / / |
| | ------- / / |
| | / S3 \ / |
| | \ / / | T18
| | ---+--- / |
| | |T4 / |
| | V / |
| | ------- / |
| | / S4 \ |
| | \ / |
| | ---+--- T15 |
| | |T5 +--------+---------+
| | | /T16+-----+------+ |
| | | / -+-----+---+ | |
| | | / / S7 \ |T12| |
| | | / +->\ /<-+ V V
| | | / / -+----- -------
| | | / /T11 |T10 / S8 \
| | V / / V \ /
| | ---+-+- ------- -------
| | / S5 \T9 / S6 \ ^
| +-----\ /--->\ / |
| ------- --+----+--------+T17
+---------------------------+
-------<、-、-、-、-、-、-、-、-、-、-、-、--+ +--------->/S1\<。----+ | T13| +、-、>\/<-+\| | / ---+--- \ \ | | / | T6\| | | T8| |T3| | | | | | / |T7| | | | / | | | | | / | | | | V//| | | ------- / / | | | /S3\/| | | \ / / | T18| | ---+--- / | | | |T4/| | | V/| | | ------- / | | | /S4\| | | \ / | | | ---+--- T15| | | |T5+--------+---------+ | | | /T16+-----+------+ | | | | / -+-----+---+ | | | | | //S7\|T12| | | | | /+->、\、/<-+V V| | | / / -+----- ------- | | | //T11|T10 / S8\| | V//V\/| | ---+-+- ------- ------- | | / S5 \T9 / S6 \ ^ | +-----\ /--->\/| | ------- --+----+--------+ T17+---------------------------+
The following state transition table represents the above diagram, and follows the conventions described for the initiator diagram.
以下の状態遷移テーブルは、上のダイヤグラムを表して、創始者ダイヤグラムのために説明されたコンベンションに続きます。
Satran, et al. Standards Track [Page 91] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[91ページ]。
+----+---+---+---+---+----+---+
|S1 |S3 |S4 |S5 |S6 |S7 |S8 |
---+----+---+---+---+---+----+---+
S1| - |T3 | - | - | - | - | - |
---+----+---+---+---+---+----+---+
S3|T6 |- |T4 | - | - | - | - |
---+----+---+---+---+---+----+---+
S4|T7 |- |- |T5 | - | - | - |
---+----+---+---+---+---+----+---+
S5|T8 |- |- | - |T9 |T11 |T15|
---+----+---+---+---+---+----+---+
S6|T13 |- |- | - |- |- |T17|
---+----+---+---+---+---+----+---+
S7|T18 |- |- | - |T10|T12 |T16|
---+----+---+---+---+---+----+---+
S8| - |- |- | - | - | - | - |
---+----+---+---+---+---+----+---+
+----+---+---+---+---+----+---+ |S1|S3|S4|S5|S6|S7|S8| ---+----+---+---+---+---+----+---+ S1| - |T3| - | - | - | - | - | ---+----+---+---+---+---+----+---+ S3|T6|- |T4| - | - | - | - | ---+----+---+---+---+---+----+---+ S4|T7|- |- |T5| - | - | - | ---+----+---+---+---+---+----+---+ S5|T8|- |- | - |T9|T11|T15| ---+----+---+---+---+---+----+---+ S6|T13|- |- | - |- |- |T17| ---+----+---+---+---+---+----+---+ S7|T18|- |- | - |T10|T12|T16| ---+----+---+---+---+---+----+---+ S8| - |- |- | - | - | - | - | ---+----+---+---+---+---+----+---+
7.2. Connection Cleanup State Diagram for Initiators and Targets
7.2. 創始者と目標のための接続クリーンアップ州のダイヤグラム
Symbolic names for states:
州への英字名:
R1: CLEANUP_WAIT (same as S8)
R2: IN_CLEANUP
R3: FREE (same as S1)
R1: クリーンアップ_待ち(S8と同じ)R2: _クリーンアップR3で: 無料(S1と同じこと)
Whenever a connection state machine (e.g., CSM-C) enters the CLEANUP_WAIT state (S8), it must go through the state transitions described in the connection cleanup state diagram either a) using a separate full-feature phase connection (let's call it CSM-E) in the LOGGED_IN state in the same session, or b) using a new transport connection (let's call it CSM-I) in the FREE state that is to be added to the same session. In the CSM-E case, an explicit logout for the CID that corresponds to CSM-C (either as a connection or session logout) needs to be performed to complete the cleanup. In the CSM-I case, an implicit logout for the CID that corresponds to CSM-C needs to be performed by way of connection reinstatement (section 5.3.4) for that CID. In either case, the protocol exchanges on CSM-E or CSM-I determine the state transitions for CSM-C. Therefore, this cleanup state diagram is only applicable to the instance of the connection in cleanup (i.e., CSM-C). In the case of an implicit logout for example, CSM-C reaches FREE (R3) at the time CSM-I reaches LOGGED_IN. In the case of an explicit logout, CSM-C reaches FREE (R3) when CSM-E receives a successful logout response while continuing to be in the LOGGED_IN state.
接続州のマシン(例えば、CSM-C)がCLEANUP_WAIT状態(S8)に入るときはいつも、それは、同じセッションのときに接続クリーンアップ州のダイヤグラムで説明された状態遷移でLOGGED_IN州で別々の完全な特徴フェーズ接続(それをCSM-Eと呼ぶ)を使用するa)を行かせなければならないか、または同じセッションに加えられることになっている無料状態に新しい輸送接続(それをCSM-Iと呼ぶ)を使用するb)を行かせなければなりません。 CSM-E場合で明白である、クリーンアップを完成するために実行されるべきCSM-C(接続かセッションとして、ログアウトする)の必要性に対応するCIDには、ログアウトしてください。 CSM-I場合で暗黙、そのCIDのための接続復職(セクション5.3.4)を通して実行されるべきCSM-Cの必要性に対応するCIDには、ログアウトしてください。 どちらの場合ではも、CSM-EかCSM-Iにおけるプロトコル交換はCSM-Cのために状態遷移を決定します。 したがって、このクリーンアップ州のダイヤグラムは単にクリーンアップ(すなわち、CSM-C)という接続の例に適切です。 ケース、暗黙、例えば、ログアウトしてください、そして、CSM-Cは時間CSM-I範囲の無料(R3)のLOGGED_INに達します。 ログアウトしてください、そして、CSM-Eがうまくいった状態でaを受けるとき、CSM-C範囲の無料(R3)はログアウトします。ケース、明白である、LOGGED_IN州にずっとある間の応答。
Satran, et al. Standards Track [Page 92] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[92ページ]。
An initiator must initiate an explicit or implicit connection logout for a connection in the CLEANUP_WAIT state, if the initiator intends to continue using the associated iSCSI session.
創始者は明白であるか暗黙接続を開始しなければなりません。CLEANUP_WAIT状態での接続のためにログアウトしてください、創始者が、関連iSCSIセッションを使用し続けるつもりであるなら。
The following state diagram applies to both initiators and targets.
以下の州のダイヤグラムは創始者と目標の両方に適用されます。
-------
/ R1 \
+--\ /<-+
/ ---+---
/ | \ M3
M1 | |M2 |
| | /
| | /
| | /
| V /
| ------- /
| / R2 \
| \ /
| -------
| |
| |M4
| |
| |
| |
| V
| -------
| / R3 \
+---->\ /
-------
------- /R1\+--\/<-+/---+--- / | \M3 M1| |M2| | | / | | / | | / | V/| ------- / | /R2\| \ / | ------- | | | |M4| | | | | | | V| ------- | /R3\+---->\/-------
The following state transition table represents the above diagram, and follows the same conventions as in earlier sections.
以下は、変遷テーブルが以前のセクションで上のダイヤグラムを表して、同じコンベンションに続くと述べます。
+----+----+----+
|R1 |R2 |R3 |
-----+----+----+----+
R1 | - |M2 |M1 |
-----+----+----+----+
R2 |M3 | - |M4 |
-----+----+----+----+
R3 | - | - | - |
-----+----+----+----+
+----+----+----+ |R1|R2|R3| -----+----+----+----+ R1| - |M2|M1| -----+----+----+----+ R2|M3| - |M4| -----+----+----+----+ R3| - | - | - | -----+----+----+----+
Satran, et al. Standards Track [Page 93] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[93ページ]。
7.2.1. State Descriptions for Initiators and Targets
7.2.1. 創始者と目標のための州の記述
-R1: CLEANUP_WAIT (Same as S8)
-initiator: Waiting for the internal event to initiate the
cleanup processing for CSM-C.
-target: Waiting for the cleanup process to start for CSM-C.
-R2: IN_CLEANUP
-initiator: Waiting for the connection cleanup process to
conclude for CSM-C.
-target: Waiting for the connection cleanup process to conclude
for CSM-C.
-R3: FREE (Same as S1)
-initiator: End state for CSM-C.
-target: End state for CSM-C.
-R1: クリーンアップ_待ち(S8と同じ)創始者: 内部の出来事がCSM-Cのためにクリーンアップ処理を開始するのを待っています。 -以下を狙ってください。 クリーンアップの過程がCSM-Cに出発するのを待っています。 -R2: _クリーンアップ創始者で: 接続クリーンアップの過程がCSM-Cのために終わるのを待っています。 -以下を狙ってください。 接続クリーンアップの過程がCSM-Cのために終わるのを待っています。 -R3: 創始者を解放してください(S1と同じ): CSM-C状態を終わらせてください。 -以下を狙ってください。 CSM-C状態を終わらせてください。
7.2.2. State Transition Descriptions for Initiators and Targets
7.2.2. 創始者と目標のための状態遷移記述
-M1: One or more of the following events was received:
-initiator:
-An internal event that indicates connection state timeout.
-An internal event of receiving a successful Logout response
on a different connection for a "close the session"
Logout.
-target:
-An internal event that indicates connection state timeout.
-An internal event of sending a Logout response (success) on
a different connection for a "close the session" Logout
request.
-M1: 以下の出来事の1つ以上を受け取りました: -創始者: -接続州のタイムアウトを示す内部の出来事。 -「セッションを終えてください」というLogoutのためにうまくいっているLogout応答を異なった接続に受ける内部の出来事。 -以下を狙ってください。 -接続州のタイムアウトを示す内部の出来事。 -「セッションを終えてください」というLogout要求のための異なった接続にLogout応答(成功)を送る内部の出来事。
-M2: An implicit/explicit logout process was initiated by the
initiator.
-In CSM-I usage:
-initiator: An internal event requesting the connection (or
session) reinstatement was received, thus prompting a
connection (or session) reinstatement Login to be sent
transitioning CSM-I to state IN_LOGIN.
-target: A connection/session reinstatement Login was
received while in state XPT_UP.
-In CSM-E usage:
-initiator: An internal event that indicates that an
explicit logout was sent for this CID in state LOGGED_IN.
-target: An explicit logout was received for this CID in
state LOGGED_IN.
-M2: 暗黙の、または、明白なログアウトの過程は創始者によって着手されました。 -CSM-I用法で: -創始者: 接続(または、セッション)復職を要求する内部の出来事を受け取りました、その結果、移行しているCSM-IがIN_LOGINを述べるためにa接続(または、セッション)復職Loginに送られるようにうながします。 -以下を狙ってください。 復職Loginが州のXPT_UPにある間に受け取られた接続/セッション。 -CSM-E用法で: -創始者: ログアウトしてください。それを示す内部の出来事、明白である、州のLOGGED_INのこのCIDのために、送りました。 -以下を狙ってください。 ログアウトしてください。明白である、州のLOGGED_INのこのCIDのために、受け取りました。
Satran, et al. Standards Track [Page 94] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[94ページ]。
-M3: Logout failure detected
-In CSM-I usage:
-initiator: CSM-I failed to reach LOGGED_IN and arrived into
FREE instead.
-target: CSM-I failed to reach LOGGED_IN and arrived into
FREE instead.
-In CSM-E usage:
-initiator: CSM-E either moved out of LOGGED_IN, or Logout
timed out and/or aborted, or Logout response (failure)
was received.
-target: CSM-E either moved out of LOGGED_IN, Logout timed
out and/or aborted, or an internal event that indicates a
failed Logout processing was received. A Logout response
(failure) was sent in the last case.
-M3: ログアウトしてください。失敗は-中にCSM-I用法を検出しました: -創始者: CSM-Iは、LOGGED_INに達しないで、代わりに無料に到着しました。 -以下を狙ってください。 CSM-Iは、LOGGED_INに達しないで、代わりに無料に到着しました。 -CSM-E用法で: -創始者: CSM-EがLOGGED_INから引っ越したか、Logoutが外で調節する、そして/または、中止になったか、またはLogout応答(失敗)を受けました。 -以下を狙ってください。 CSM-EがLOGGED_INから引っ越したか、Logoutが外で調節する、そして/または、中止になったか、または失敗したLogout処理を示す内部の出来事を受け取りました。 最後の場合でLogout応答(失敗)を送りました。
-M4: Successful implicit/explicit logout was performed.
-M4: ログアウトしてください。うまくいっている暗黙の/明白である、実行されました。
- In CSM-I usage:
-initiator: CSM-I reached state LOGGED_IN, or an internal
event of receiving a Logout response (success) on another
connection for a "close the session" Logout request was
received.
-target: CSM-I reached state LOGGED_IN, or an internal event
of sending a Logout response (success) on a different
connection for a "close the session" Logout request was
received.
- In CSM-E usage:
-initiator: CSM-E stayed in LOGGED_IN and received a Logout
response (success), or an internal event of receiving a
Logout response (success) on another connection for a
"close the session" Logout request was received.
-target: CSM-E stayed in LOGGED_IN and an internal event
indicating a successful Logout processing was received,
or an internal event of sending a Logout response
(success) on a different connection for a "close the
session" Logout request was received.
- CSM-I用法で: -創始者: CSM-私は州のLOGGED_INに着いたか、または別の接続のときに「セッションを終えてください」というLogout要求のために、Logout応答(成功)を受ける内部の出来事を受け取りました。 -以下を狙ってください。 CSM-私は州のLOGGED_INに着いたか、または「セッションを終えてください」というLogout要求のための異なった接続にLogout応答(成功)を送る内部の出来事を受け取りました。 - CSM-E用法で: -創始者: CSM-Eが、LOGGED_INにいて、Logout応答(成功)を受けたか、または別の接続のときに「セッションを終えてください」というLogout要求のために、Logout応答(成功)を受ける内部の出来事を受け取りました。 -以下を狙ってください。 CSM-EはLOGGED_INにいました、そして、うまくいっているLogout処理を示す内部の出来事を受け取ったか、または「セッションを終えてください」というLogout要求のための異なった接続にLogout応答(成功)を送る内部の出来事を受け取りました。
7.3. Session State Diagrams
7.3. セッション州のダイヤグラム
7.3.1. Session State Diagram for an Initiator
7.3.1. 創始者のためのセッション州のダイヤグラム
Symbolic Names for States:
州への英字名:
Q1: FREE
Q3: LOGGED_IN
Q4: FAILED
Q1: Q3を解放してください: Q4の登録された_: 失敗されます。
State Q3 represents the Full Feature Phase operation of the session.
州のQ3はセッションのFull Feature Phase操作を表します。
Satran, et al. Standards Track [Page 95] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[95ページ]。
The state diagram is as follows:
州のダイヤグラムは以下の通りです:
-------
/ Q1 \
+------>\ /<-+
/ ---+--- |
/ | |N3
N6 | |N1 |
| | |
| N4 | |
| +--------+ | /
| | | | /
| | | | /
| | V V /
-+--+-- -----+-
/ Q4 \ N5 / Q3 \
\ /<---\ /
------- -------
------- /Q1\+------>\/<-+/---+--- | / | |N3 N6| |N1| | | | | N4| | | +--------+ | / | | | | / | | | | / | | V V/-+(+)-----+/Q4\N5 / Q3\\/<。---\ / ------- -------
The state transition table is as follows:
状態遷移テーブルは以下の通りです:
+----+----+----+
|Q1 |Q3 |Q4 |
-----+----+----+----+
Q1 | - |N1 | - |
-----+----+----+----+
Q3 |N3 | - |N5 |
-----+----+----+----+
Q4 |N6 |N4 | - |
-----+----+----+----+
+----+----+----+ |Q1|Q3|Q4| -----+----+----+----+ Q1| - |N1| - | -----+----+----+----+ Q3|N3| - |N5| -----+----+----+----+ Q4|N6|N4| - | -----+----+----+----+
7.3.2. Session State Diagram for a Target
7.3.2. 目標のためのセッション州のダイヤグラム
Symbolic Names for States:
州への英字名:
Q1: FREE
Q2: ACTIVE
Q3: LOGGED_IN
Q4: FAILED
Q5: IN_CONTINUE
Q1: Q2を解放してください: アクティブなQ3: Q4の登録された_: 失敗したQ5: _では、続いてください。
State Q3 represents the Full Feature Phase operation of the session.
州のQ3はセッションのFull Feature Phase操作を表します。
Satran, et al. Standards Track [Page 96] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[96ページ]。
The state diagram is as follows:
州のダイヤグラムは以下の通りです:
-------
+------------------>/ Q1 \
/ +-------------->\ /<-+
| | ---+--- |
| | ^ | |N3
N6 | |N11 N9| V N1 |
| | +------ |
| | / Q2 \ |
| | \ / |
| --+---- +--+--- |
| / Q5 \ | |
| \ / N10 | |
| +-+---+------------+ |N2 /
| ^ | | | /
|N7| |N8 | | /
| | | | V /
-+--+-V V----+-
/ Q4 \ N5 / Q3 \
\ /<-------------\ /
------- -------
------- +------------------>/Q1\/+-------------->\/、<-+| | ---+--- | | | ^ | |N3 N6| |N11 N9| V N1| | | +------ | | | /Q2\| | | \ / | | --+---- +--+--- | | /Q5\| | | \/N10| | | +-+---+------------+ |N2/| ^ | | | / |N7| |N8| | / | | | | V/-+--+V V----+/Q4\N5 / Q3\\/<。-------------\ / ------- -------
The state transition table is as follows:
状態遷移テーブルは以下の通りです:
+----+----+----+----+----+
|Q1 |Q2 |Q3 |Q4 |Q5 |
-----+----+----+----+----+----+
Q1 | - |N1 | - | - | - |
-----+----+----+----+----+----+
Q2 |N9 | - |N2 | - | - |
-----+----+----+----+----+----+
Q3 |N3 | - | - |N5 | - |
-----+----+----+----+----+----+
Q4 |N6 | - | - | - |N7 |
-----+----+----+----+----+----+
Q5 |N11 | - |N10 |N8 | - |
-----+----+----+----+----+----+
+----+----+----+----+----+ |Q1|Q2|Q3|Q4|Q5| -----+----+----+----+----+----+ Q1| - |N1| - | - | - | -----+----+----+----+----+----+ Q2|N9| - |N2| - | - | -----+----+----+----+----+----+ Q3|N3| - | - |N5| - | -----+----+----+----+----+----+ Q4|N6| - | - | - |N7| -----+----+----+----+----+----+ Q5|N11| - |N10|N8| - | -----+----+----+----+----+----+
7.3.3. State Descriptions for Initiators and Targets
7.3.3. 創始者と目標のための州の記述
-Q1: FREE
-initiator: State on instantiation or after cleanup.
-target: State on instantiation or after cleanup.
-Q1: 創始者を解放してください: 具体化かクリーンアップの後の状態。 -以下を狙ってください。 具体化かクリーンアップの後の状態。
Satran, et al. Standards Track [Page 97] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[97ページ]。
-Q2: ACTIVE
-initiator: Illegal.
-target: The first iSCSI connection in the session transitioned
to IN_LOGIN, waiting for it to complete the login process.
-Q2: 活発な創始者: 不法。 -以下を狙ってください。 ログインの過程を完了するのを待っていて、セッションにおける最初のiSCSI接続はIN_LOGINに移行しました。
-Q3: LOGGED_IN
-initiator: Waiting for all session events.
-target: Waiting for all session events.
-Q3: 創始者の登録された_: すべてのセッション出来事を待っています。 -以下を狙ってください。 すべてのセッション出来事を待っています。
-Q4: FAILED
-initiator: Waiting for session recovery or session
continuation.
-target: Waiting for session recovery or session continuation.
-Q4: 創始者に失敗します: セッション回復かセッション継続を待っています。 -以下を狙ってください。 セッション回復かセッション継続を待っています。
-Q5: IN_CONTINUE
-initiator: Illegal.
-target: Waiting for session continuation attempt to reach a
conclusion.
-Q5: _では、創始者を続けてください: 不法。 -以下を狙ってください。 セッション継続を待って、結論に達するのを試みてください。
7.3.4. State Transition Descriptions for Initiators and Targets
7.3.4. 創始者と目標のための状態遷移記述
-N1:
-initiator: At least one transport connection reached the
LOGGED_IN state.
-target: The first iSCSI connection in the session had reached
the IN_LOGIN state.
-N1: -創始者: 少なくとも1つの輸送接続がLOGGED_IN州に達しました。 -以下を狙ってください。 セッションにおける最初のiSCSI接続はIN_LOGIN状態に着きました。
-N2:
-initiator: Illegal.
-target: At least one iSCSI connection reached the LOGGED_IN
state.
-N2: -創始者: 不法。 -以下を狙ってください。 少なくとも1つのiSCSI接続がLOGGED_IN州に達しました。
-N3:
-initiator: Graceful closing of the session via session closure
(Section 5.3.6 Session Continuation and Failure).
-target: Graceful closing of the session via session closure
(Section 5.3.6 Session Continuation and Failure) or a
successful session reinstatement cleanly closed the session.
-N3: -創始者: セッション閉鎖(セクション5.3.6のSession ContinuationとFailure)を通したセッションの優雅な閉鎖。 -以下を狙ってください。 セッション閉鎖(セクション5.3.6のSession ContinuationとFailure)を通したセッションの優雅な閉鎖かうまくいっているセッション復職が清潔にセッションを終えました。
-N4:
-initiator: A session continuation attempt succeeded.
-target: Illegal.
-N4: -創始者: セッション継続試みは成功しました。 -以下を狙ってください。 不法。
-N5:
-initiator: Session failure (Section 5.3.6 Session Continuation
and Failure) occurred.
-target: Session failure (Section 5.3.6 Session Continuation and
Failure) occurred.
-N5: -創始者: セッション失敗(セクション5.3.6のSession ContinuationとFailure)は起こりました。 -以下を狙ってください。 セッション失敗(セクション5.3.6のSession ContinuationとFailure)は起こりました。
Satran, et al. Standards Track [Page 98] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[98ページ]。
-N6:
-initiator: Session state timeout occurred, or a session
reinstatement cleared this session instance. This results
in the freeing of all associated resources and the session
state is discarded.
-target: Session state timeout occurred, or a session
reinstatement cleared this session instance. This results
in the freeing of all associated resources and the session
state is discarded.
-N6: -創始者: セッション州のタイムアウトが起こったか、またはセッション復職はこのセッション例をクリアしました。 これはすべての関連リソースの解放をもたらします、そして、セッション状態は捨てられます。 -以下を狙ってください。 セッション州のタイムアウトが起こったか、またはセッション復職はこのセッション例をクリアしました。 これはすべての関連リソースの解放をもたらします、そして、セッション状態は捨てられます。
-N7:
-initiator: Illegal.
-target: A session continuation attempt is initiated.
-N7: -創始者: 不法。 -以下を狙ってください。 セッション継続試みは開始されます。
-N8:
-initiator: Illegal.
-target: The last session continuation attempt failed.
-N8: -創始者: 不法。 -以下を狙ってください。 納会継続試みは失敗しました。
-N9:
-initiator: Illegal.
-target: Login attempt on the leading connection failed.
-N9: -創始者: 不法。 -以下を狙ってください。 主な接続へのログイン試みは失敗しました。
-N10:
-initiator: Illegal.
-target: A session continuation attempt succeeded.
-N10: -創始者: 不法。 -以下を狙ってください。 セッション継続試みは成功しました。
-N11:
-initiator: Illegal.
-target: A successful session reinstatement cleanly closed the
session.
-N11: -創始者: 不法。 -以下を狙ってください。 うまくいっているセッション復職は清潔にセッションを終えました。
8. Security Considerations
8. セキュリティ問題
Historically, native storage systems have not had to consider security because their environments offered minimal security risks. That is, these environments consisted of storage devices either directly attached to hosts or connected via a Storage Area Network (SAN) distinctly separate from the communications network. The use of storage protocols, such as SCSI, over IP-networks requires that security concerns be addressed. iSCSI implementations MUST provide means of protection against active attacks (e.g., pretending to be another identity, message insertion, deletion, modification, and replaying) and passive attacks (e.g., eavesdropping, gaining advantage by analyzing the data sent over the line).
彼らの環境が最小量のセキュリティ危険を提供したので、歴史的に、ネイティブのストレージシステムはセキュリティを考える必要はありませんでした。 すなわち、これらの環境は通信網から明瞭に別々の状態で直接ホストに愛着していたか、またはストレージ・エリア・ネットワーク(SAN)で接された記憶装置から成りました。 IP-ネットワークの上のSCSIなどのストレージプロトコルの使用は、安全上の配慮が扱われるのを必要とします。iSCSI実装は活発な攻撃(例えば、別のアイデンティティと、メッセージ挿入と、削除と、変更と、再演であるふりをする)と受け身の攻撃に対する保護の手段を前提としなければなりません(例えば、盗聴、データを解析することによって利点を獲得すると、系列は移動しました)。
Satran, et al. Standards Track [Page 99] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[99ページ]。
Although technically possible, iSCSI SHOULD NOT be configured without security. iSCSI configured without security should be confined, in extreme cases, to closed environments without any security risk. [RFC3723] specifies the mechanisms that must be used in order to mitigate risks fully described in that document.
技術的に可能なiSCSI SHOULD NOTですが、セキュリティなしで構成されてください。セキュリティなしで構成されたiSCSIは閉じ込められるべきです、極端な場合は、少しもセキュリティリスクのない閉じている環境に。 [RFC3723]はそのドキュメントで完全に説明された危険を緩和するのに使用しなければならないメカニズムを指定します。
The following section describes the security mechanisms provided by an iSCSI implementation.
以下のセクションはiSCSI実装によって提供されたセキュリティー対策について説明します。
8.1. iSCSI Security Mechanisms
8.1. iSCSIセキュリティー対策
The entities involved in iSCSI security are the initiator, target, and the IP communication end points. iSCSI scenarios in which multiple initiators or targets share a single communication end point are expected. To accommodate such scenarios, iSCSI uses two separate security mechanisms: In-band authentication between the initiator and the target at the iSCSI connection level (carried out by exchange of iSCSI Login PDUs), and packet protection (integrity, authentication, and confidentiality) by IPsec at the IP level. The two security mechanisms complement each other. The in-band authentication provides end-to-end trust (at login time) between the iSCSI initiator and the target while IPsec provides a secure channel between the IP communication end points.
iSCSIセキュリティにかかわる実体は、創始者と、目標と、IPコミュニケーションエンドポイントです。複数の創始者か目標がただ一つのコミュニケーションエンドポイントを共有するiSCSIシナリオは予想されます。 そのようなシナリオに対応するために、iSCSIは2台の別々のセキュリティー対策を使用します: iSCSI接続レベルにおける創始者と目標の間のバンドにおける認証(iSCSI Login PDUsの交換によって行われる)、およびIPsecによるIPレベルにおけるパケット保護(保全、認証、および秘密性)。 2台のセキュリティー対策が互いの補足となります。 IPsecはIPコミュニケーションエンドポイントの間に安全なチャンネルを提供しますが、バンドにおける認証は終わりから終わりへの信頼(ログイン時の)をiSCSI創始者と目標の間に供給します。
Further details on typical iSCSI scenarios and the relation between the initiators, targets, and the communication end points can be found in [RFC3723].
[RFC3723]で典型的なiSCSIシナリオに関する詳細と創始者と、目標と、コミュニケーションエンドポイントとの関係を見つけることができます。
8.2. In-band Initiator-Target Authentication
8.2. バンドにおける創始者目標認証
During login, the target MAY authenticate the initiator and the initiator MAY authenticate the target. The authentication is performed on every new iSCSI connection by an exchange of iSCSI Login PDUs using a negotiated authentication method.
ログインの間、目標は創始者を認証するかもしれません、そして、創始者は目標を認証するかもしれません。 認証は、交渉された認証方法を使用しながら、iSCSI Login PDUsの交換ですべての新しいiSCSI接続に実行されます。
The authentication method cannot assume an underlying IPsec protection, because IPsec is optional to use. An attacker should gain as little advantage as possible by inspecting the authentication phase PDUs. Therefore, a method using clear text (or equivalent) passwords is not acceptable; on the other hand, identity protection is not strictly required.
IPsecが使用するために任意であるので、認証方法は、基本的なIPsecが防護物であると仮定できません。 攻撃者はできるだけ認証フェーズPDUsを点検することによってほとんど利点を獲得するべきではありません。 したがって、クリアテキスト(または、同等物)パスワードを使用するメソッドは許容できません。 他方では、アイデンティティ保護は厳密に必要ではありません。
The authentication mechanism protects against an unauthorized login to storage resources by using a false identity (spoofing). Once the authentication phase is completed, if the underlying IPsec is not used, all PDUs are sent and received in clear. The authentication
認証機構は、偽名(スプーフィング)を使用することによって、ストレージリソースに権限のないログインから守ります。 基本的なIPsecが使用されていないなら認証フェーズがいったん完成されると、PDUsが送って受け取られているすべてがクリアされます。 認証
Satran, et al. Standards Track [Page 100] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[100ページ]。
mechanism alone (without underlying IPsec) should only be used when there is no risk of eavesdropping, message insertion, deletion, modification, and replaying.
盗聴、メッセージ挿入、削除、変更、および再演のリスクが全くないときだけ、メカニズムだけが使用されるべきです。
Section 11 iSCSI Security Text Keys and Authentication Methods defines several authentication methods and the exact steps that must be followed in each of them, including the iSCSI-text-keys and their allowed values in each step. Whenever an iSCSI initiator gets a response whose keys, or their values, are not according to the step definition, it MUST abort the connection. Whenever an iSCSI target gets a response whose keys, or their values, are not according to the step definition, it MUST answer with a Login reject with the "Initiator Error" or "Missing Parameter" status. These statuses are not intended for cryptographically incorrect values such as the CHAP response, for which "Authentication Failure" status MUST be specified. The importance of this rule can be illustrated in CHAP with target authentication (see Section 11.1.4 Challenge Handshake Authentication Protocol (CHAP)) where the initiator would have been able to conduct a reflection attack by omitting his response key (CHAP_R) using the same CHAP challenge as the target and reflecting the target's response back to the target. In CHAP, this is prevented because the target must answer the missing CHAP_R key with a Login reject with the "Missing Parameter" status.
セクション11 iSCSI Security TextキーズとAuthentication Methodsはそれぞれのそれらで従わなければならないいくつかの認証方法と正確な方法を定義します、各ステップにiSCSIテキストキーとそれらの許容値を含んでいて。 iSCSI創始者が返事をもらうときはいつも、ステップ定義に従って、キー、またはそれらの値がなくて、それは接続を中止しなければなりません。 iSCSI目標が返事をもらうときはいつも、ステップ定義に従って、キー、またはそれらの値がありません、とそれは「創始者誤り」か「なくなったパラメタ」状態があるLogin廃棄物で答えなければなりません。 これらの状態が暗号で意図しない、CHAP応答などの不正確な値、どの「認証失敗」として、状態を指定しなければならないか。 目標認証(セクション11.1.4チャレンジハンドシェイク式認証プロトコル(CHAP)を見る)がある創始者が目標として同じCHAP挑戦を使用することで彼の応答キー(CHAP_R)を省略して、目標の応答を目標に映し出すことによって反射攻撃を行うことができるだろうCHAPでこの規則の重要性を例証できます。 CHAPでは、目標が「なくなったパラメタ」状態があるLogin廃棄物によって主要ななくなったCHAP_Rに答えなければならないので、これは防がれます。
For some of the authentication methods, a key specifies the identity of the iSCSI initiator or target for authentication purposes. The value associated with that key MAY be different from the iSCSI name and SHOULD be configurable. (CHAP_N, see Section 11.1.4 Challenge Handshake Authentication Protocol (CHAP) and SRP_U, see Section 11.1.3 Secure Remote Password (SRP)).
認証方法のいくつかとして、キーは認証目的のためのiSCSI創始者か目標のアイデンティティを指定します。 それに主要な状態で関連づけられた値はiSCSI名とSHOULDと異なっているかもしれません。構成可能であってください。 (セクション11.1.4のチャレンジハンドシェイク式認証プロトコル(CHAP)とSRP_Uは、CHAPがセクション11.1.3Secure Remote Password(SRP)を見るのを見ます。)
8.2.1. CHAP Considerations
8.2.1. やつ問題
Compliant iSCSI initiators and targets MUST implement the CHAP authentication method [RFC1994] (according to Section 11.1.4 Challenge Handshake Authentication Protocol (CHAP) including the target authentication option).
言いなりになっているiSCSI創始者と目標は、CHAPが認証方法[RFC1994](目標認証オプションを含むセクション11.1.4チャレンジハンドシェイク式認証プロトコル(CHAP)によると)であると実装しなければなりません。
When CHAP is performed over a non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support use of up to 128 bit random CHAP secrets, including the means to generate such secrets and to accept them from an external generation source. Implementations MUST NOT provide secret generation (or expansion) means other than random generation.
CHAPが非暗号化されたチャンネルの上に実行されるとき、それはオフライン辞書攻撃に被害を受け易いです。 実装は最大128ビットの使用に無作為のCHAP秘密をサポートしなければなりません、そのような秘密を生成して、外部の世代ソースからそれらを受け入れる手段を含んでいて。 実装は無作為の世代以外の秘密の世代(または、拡張)手段を提供してはいけません。
An administrative entity of an environment in which CHAP is used with a secret that has less than 96 random bits MUST enforce IPsec encryption (according to the implementation requirements in Section
CHAPが無作為の96ビット未満を持っている秘密と共に使用される環境の管理実体がIPsec暗号化を実施しなければならない、(セクションにおける実装要件
Satran, et al. Standards Track [Page 101] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[101ページ]。
8.3.2 Confidentiality) to protect the connection. Moreover, in this case IKE authentication with group pre-shared cryptographic keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks by other members.
8.3.2、秘密性) 接続を保護するために。 そのうえ、オフライン辞書に対してグループのメンバーを保護するのが不可欠である場合、この場合グループのあらかじめ共有された暗号化キーSHOULD NOTが使用されているIKE認証は他のメンバーに攻撃されます。
CHAP secrets MUST be an integral number of bytes (octets). A compliant implementation SHOULD NOT continue with the login step in which it should send a CHAP response (CHAP_R, Section 11.1.4 Challenge Handshake Authentication Protocol (CHAP)) unless it can verify that the CHAP secret is at least 96 bits, or that IPsec encryption is being used to protect the connection.
CHAP秘密は不可欠のバイト数であるに違いありません(八重奏)。 SHOULD NOTがCHAP秘密が少なくとも96ビット、またはそのIPsec暗号化であることを確かめることができないならそれがCHAP応答(CHAP_R、セクション11.1.4チャレンジハンドシェイク式認証プロトコル(CHAP))を送るべきであるログイン手順で続けている対応する実装は、接続を保護するのに使用されています。
Any CHAP secret used for initiator authentication MUST NOT be configured for authentication of any target, and any CHAP secret used for target authentication MUST NOT be configured for authentication of any initiator. If the CHAP response received by one end of an iSCSI connection is the same as the CHAP response that the receiving endpoint would have generated for the same CHAP challenge, the response MUST be treated as an authentication failure and cause the connection to close (this ensures that the same CHAP secret is not used for authentication in both directions). Also, if an iSCSI implementation can function as both initiator and target, different CHAP secrets and identities MUST be configured for these two roles. The following is an example of the attacks prevented by the above requirements:
どんな目標の認証のためにも創始者認証に使用されるどんなCHAP秘密も構成してはいけません、そして、目標認証に使用されるどんなCHAP秘密もどんな創始者の認証のためにも構成されてはいけません。 iSCSI接続の片端によって受けられたCHAP応答が受信終点が同じCHAP挑戦のために生成したCHAP応答と同じであるなら、応答で、認証失敗として扱われて、接続は閉じなければなりません(これは、同じCHAP秘密が両方の方向への認証に使用されないのを確実にします)。 また、iSCSI実装が創始者と目標の両方として機能できるなら、これらの2つの役割のために異なったCHAP秘密とアイデンティティを構成しなければなりません。 ↓これは上記の要件によって防がれた攻撃に関する例です:
Rogue wants to impersonate Storage to Alice, and knows that a
single secret is used for both directions of Storage-Alice
authentication.
悪党は、アリスにStorageをまねたくて、ただ一つの秘密がStorage-アリス認証の両方の方向に使用されるのを知っています。
Rogue convinces Alice to open two connections to Rogue, and Rogue
identifies itself as Storage on both connections.
悪党は、2つの接続をRogueに開くようにアリスを説得します、そして、Rogueは両方の接続のときにそれ自体がStorageであると認識します。
Rogue issues a CHAP challenge on connection 1, waits for Alice to
respond, and then reflects Alice's challenge as the initial
challenge to Alice on connection 2.
悪党は、接続2のときにアリスへの初期の挑戦として接続1のときにCHAP挑戦を発行して、アリスが応じるのを待っていて、次に、アリスの挑戦を反映します。
If Alice doesn't check for the reflection across connections,
Alice's response on connection 2 enables Rogue to impersonate
Storage on connection 1, even though Rogue does not know the
Alice-Storage CHAP secret.
アリスが反射がないかどうか接続の向こう側にチェックしないなら、接続2のアリスの応答は、Rogueが接続1のときにStorageをまねるのを可能にします、Rogueがアリス-ストレージCHAP秘密を知りませんが。
Originators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bidirectional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs.
創始者はResponderによって双方向の認証のもう片方の方向に送られたCHAP挑戦を再利用してはいけません。 起こるなら、応答者は、この状態がないかどうかチェックして、iSCSI TCP接続を終えなければなりません。
Satran, et al. Standards Track [Page 102] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[102ページ]。
The same CHAP secret SHOULD NOT be configured for authentication of multiple initiators or multiple targets, as this enables any of them to impersonate any other one of them, and compromising one of them enables the attacker to impersonate any of them. It is recommended that iSCSI implementations check for use of identical CHAP secrets by different peers when this check is feasible, and take appropriate measures to warn users and/or administrators when this is detected.
同じCHAPの秘密のSHOULD NOTが複数の創始者か複数の目標の認証のために構成されて、これがそれらのどれかを可能にするとき、それら、および妥協についていかなる他の1つもまねるために、彼らのひとりは、攻撃者がそれらのどれかをまねるのを可能にします。 iSCSI実装が異なった同輩による同じCHAP秘密の使用がないかどうかこのチェックがいつ可能であるかをチェックして、これがいつ検出されるかをユーザ、そして/または、管理者に警告する穏当な処置を取るのは、お勧めです。
When an iSCSI initiator or target authenticates itself to counterparts in multiple administrative domains, it SHOULD use a different CHAP secret for each administrative domain to avoid propagating security compromises across domains.
iSCSIであるときに、創始者か目標が複数の管理ドメインの対応者にそれ自体を認証して、それはそれぞれの管理ドメインが、セキュリティを伝播するのを避けるように秘密の異なったCHAPがドメインの向こう側に感染するSHOULD使用です。
Within a single administrative domain: - A single CHAP secret MAY be used for authentication of an initiator to multiple targets. - A single CHAP secret MAY be used for an authentication of a target to multiple initiators when the initiators use an external server (e.g., RADIUS) to verify the target's CHAP responses and do not know the target's CHAP secret.
ただ一つの管理ドメインの中で: - ただ一つのCHAP秘密は創始者の認証にマルチターゲットに使用されるかもしれません。 - 創始者が目標のCHAP応答について確かめて、目標のCHAP秘密を知らないように、外部のサーバ(例えば、RADIUS)を使用すると、ただ一つのCHAP秘密は目標の認証に複数の創始者に使用されるかもしれません。
If an external response verification server (e.g., RADIUS) is not used, employing a single CHAP secret for authentication of a target to multiple initiators requires that all such initiators know that target secret. Any of these initiators can impersonate the target to any other such initiator, and compromise of such an initiator enables an attacker to impersonate the target to all such initiators. Targets SHOULD use separate CHAP secrets for authentication to each initiator when such risks are of concern; in this situation it may be useful to configure a separate logical iSCSI target with its own iSCSI Node Name for each initiator or group of initiators among which such separation is desired.
外部応答検証サーバ(例えば、RADIUS)が使用されていないなら、目標の認証のためのただ一つのCHAP秘密を複数の創始者に使うのは、そのようなすべての創始者がその目標秘密を知っているのを必要とします。 これらの創始者のどれかはいかなる他のそのような創始者にも目標をまねることができます、そして、そのような創始者の感染は攻撃者がそのようなすべての創始者に目標をまねるのを可能にします。 そのようなリスクが重要であるときに、SHOULDが使用する目標は認証のためのCHAP秘密を各創始者に切り離します。 この状況で、そのような分離が望まれている創始者の各創始者かグループのためにそれ自身のiSCSI Node Nameで別々の論理的なiSCSI目標を構成するのは役に立つかもしれません。
8.2.2. SRP Considerations
8.2.2. SRP問題
The strength of the SRP authentication method (specified in [RFC2945]) is dependent on the characteristics of the group being used (i.e., the prime modulus N and generator g). As described in [RFC2945], N is required to be a Sophie-German prime (of the form N = 2q + 1, where q is also prime) and the generator g is a primitive root of GF(n). In iSCSI authentication, the prime modulus N MUST be at least 768 bits.
SRP認証方法([RFC2945]では、指定される)の強さは使用されるグループ(すなわち、主要な係数Nとジェネレータg)の特性に依存しています。 [RFC2945]で説明されていて、NがソフィーGermanの主要(またqも主要であるところでフォームN=2q+1について)になるのに必要であり、ジェネレータgがGF(n)の原始根であるので。 iSCSI認証では、主要な係数Nは少なくとも768ビットでなければなりません。
The list of allowed SRP groups is provided in [RFC3723].
許容SRPグループのリストを[RFC3723]に提供します。
Satran, et al. Standards Track [Page 103] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[103ページ]。
8.3. IPsec
8.3. IPsec
iSCSI uses the IPsec mechanism for packet protection (cryptographic integrity, authentication, and confidentiality) at the IP level between the iSCSI communicating end points. The following sections describe the IPsec protocols that must be implemented for data integrity and authentication, confidentiality, and cryptographic key management.
iSCSIはパケット保護(暗号の保全、認証、および秘密性)にiSCSI交信エンドポイントの間のIPレベルにIPsecメカニズムを使用します。 以下のセクションはデータ保全、認証、秘密性、および暗号化キー管理のために実装しなければならないIPsecプロトコルについて説明します。
An iSCSI initiator or target may provide the required IPsec support fully integrated or in conjunction with an IPsec front-end device. In the latter case, the compliance requirements with regard to IPsec support apply to the "combined device". Only the "combined device" is to be considered an iSCSI device.
iSCSI創始者か目標は、完全に統合された必要なIPsecサポートを提供するか、またはIPsecフロントエンドデバイスに関連してそうするかもしれません。 後者の場合では、IPsecサポートに関する承諾要件は「結合したデバイス」に適用されます。 「結合したデバイス」だけ、がiSCSIデバイスであると考えられることになっています。
Detailed considerations and recommendations for using IPsec for iSCSI are provided in [RFC3723].
iSCSIにIPsecを使用するための詳細な問題と推薦を[RFC3723]に提供します。
8.3.1. Data Integrity and Authentication
8.3.1. データの保全と認証
Data authentication and integrity is provided by a cryptographic keyed Message Authentication Code in every sent packet. This code protects against message insertion, deletion, and modification. Protection against message replay is realized by using a sequence counter.
暗号の合わせられたメッセージ立証コードはデータ認証と保全をあらゆる送られたパケットに提供します。 このコードはメッセージ挿入、削除、および変更から守ります。 メッセージ再生に対する保護は、系列カウンタを使用することによって、実現されます。
An iSCSI compliant initiator or target MUST provide data integrity and authentication by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide data integrity and authentication by implementing IPsec with ESP in transport mode. The IPsec implementation MUST fulfill the following iSCSI specific requirements:
iSCSI対応することの創始者か目標が、超能力[RFC2406]でIPsec[RFC2401]を実装することによってデータ保全と認証をトンネルモードに提供しなければならなくて、交通機関でIPsecを実装するのによるデータ保全と認証に超能力を提供するかもしれません。 IPsec実装は以下のiSCSI決められた一定の要求を実現させなければなりません:
- HMAC-SHA1 MUST be implemented [RFC2404].
- AES CBC MAC with XCBC extensions SHOULD be implemented
[RFC3566].
- HMAC-SHA1 MUST、[RFC2404]であると実装されてください。 - XCBC拡大SHOULDが[RFC3566]であると実装されているAES CBC MAC。
The ESP anti-replay service MUST also be implemented.
また、超能力反再生サービスを実装しなければなりません。
At the high speeds iSCSI is expected to operate, a single IPsec SA could rapidly cycle through the 32-bit IPsec sequence number space. In view of this, it may be desirable in the future for an iSCSI implementation that operates at speeds of 1 Gbps or greater to implement the IPsec sequence number extension [SEQ-EXT].
操作するiSCSIが予想される高速では、独身のIPsec SAは32ビットのIPsec一連番号スペースを通して急速に循環できました。 これから見て、IPsec一連番号が拡大[SEQ-EXT]であると実装するのは、将来、1Gbpsの速度で作動するiSCSI実装に望ましいか、または、よりすばらしいかもしれません。
Satran, et al. Standards Track [Page 104] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[104ページ]。
8.3.2. Confidentiality
8.3.2. 秘密性
Confidentiality is provided by encrypting the data in every packet. When confidentiality is used it MUST be accompanied by data integrity and authentication to provide comprehensive protection against eavesdropping, message insertion, deletion, modification, and replaying.
あらゆるパケットでデータを暗号化することによって、秘密性を提供します。 秘密性が使用されているとき、データ保全と認証で盗聴に対する包括的な保護、メッセージ挿入、削除、変更、および再演を提供するためにそれに伴わなければなりません。
An iSCSI compliant initiator or target MUST provide confidentiality by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide confidentiality by implementing IPsec with ESP in transport mode, with the following iSCSI specific requirements:
iSCSI対応することの創始者か目標が、超能力[RFC2406]でIPsec[RFC2401]を実装することによってトンネルモードに秘密性を提供しなければならなくて、交通機関でIPsecを実装するのによる秘密性に超能力を提供するかもしれません、以下のiSCSI決められた一定の要求で:
- 3DES in CBC mode MUST be implemented [RFC2451].
- AES in Counter mode SHOULD be implemented [RFC3686].
- [RFC2451]であるとCBCモードによる3DESを実装しなければなりません。 - AES、CounterモードSHOULDで、[RFC3686]であると実装されてください。
DES in CBC mode SHOULD NOT be used due to its inherent weakness. The NULL encryption algorithm MUST also be implemented.
DES、CBCモードSHOULD NOTで、固有の弱点のため使用されてください。 また、NULL暗号化アルゴリズムを実装しなければなりません。
8.3.3. Policy, Security Associations, and Cryptographic Key Management
8.3.3. 方針、セキュリティ協会、および暗号化キー管理
A compliant iSCSI implementation MUST meet the cryptographic key management requirements of the IPsec protocol suite. Authentication, security association negotiation, and cryptographic key management MUST be provided by implementing IKE [RFC2409] using the IPsec DOI [RFC2407] with the following iSCSI specific requirements:
対応するiSCSI実装はIPsecプロトコル群に関する暗号化キー管理必要条件を満たさなければなりません。 IPsec DOI[RFC2407]を使用することでIKE[RFC2409]を実装することによって、認証、セキュリティ協会交渉、および暗号化キー管理を以下のiSCSI決められた一定の要求に提供しなければなりません:
- Peer authentication using a pre-shared cryptographic key MUST be
supported. Certificate-based peer authentication using digital
signatures MAY be supported. Peer authentication using the
public key encryption methods outlined in IKE sections 5.2 and
5.3[7] SHOULD NOT be used.
- あらかじめ共有された暗号化キーを使用する同輩認証をサポートしなければなりません。 デジタル署名を使用する証明書ベースの同輩認証はサポートされるかもしれません。 公開鍵暗号化メソッドを使用する同輩認証がIKEにセクション5.2と5.3[7] SHOULDについて概説しました。使用されないでください。
- When digital signatures are used to achieve authentication, an
IKE negotiator SHOULD use IKE Certificate Request Payload(s) to
specify the certificate authority. IKE negotiators SHOULD check
the pertinent Certificate Revocation List (CRL) before accepting
a PKI certificate for use in IKE authentication procedures.
- デジタル署名が達成するのにおいて使用されているとき、認証、IKE交渉者SHOULDは、認証局を指定するのにIKE Certificate Request有効搭載量を使用します。 PKI証明書を受け入れる前に、IKE交渉者SHOULDはIKE認証手順における使用がないかどうか適切なCertificate Revocation List(CRL)をチェックします。
- Conformant iSCSI implementations MUST support IKE Main Mode and
SHOULD support Aggressive Mode. IKE main mode with pre-shared
key authentication method SHOULD NOT be used when either the
initiator or the target uses dynamically assigned IP addresses.
While in many cases pre-shared keys offer good security,
situations in which dynamically assigned addresses are used force
the use of a group pre-shared key, which creates vulnerability to
a man-in-the-middle attack.
- Conformant iSCSI実装はIKE Main ModeとSHOULDサポートAggressive Modeをサポートしなければなりません。 創始者か目標のどちらかであるときに、あらかじめ共有された主要な認証方法SHOULD NOTが使用されているIKEの主なモードはダイナミックに割り当てられたIPアドレスを使用します。 あらかじめ共有されたキーが優れた警備体制、状況を提供する多くの場合では、中央の男性に対する脆弱性攻撃を作成する主要な状態であらかじめ共有されたグループの使用はダイナミックに割り当てられたアドレスがどれであるかで武力行使していましたが。
Satran, et al. Standards Track [Page 105] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[105ページ]。
- In the IKE Phase 2 Quick Mode, exchanges for creating the Phase 2
SA, the Identity Payload, fields MUST be present. ID_IPV4_ADDR,
ID_IPV6_ADDR (if the protocol stack supports IPv6) and ID_FQDN
Identity payloads MUST be supported; ID_USER_FQDN SHOULD be
supported. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, and
ID_DER_ASN1_GN formats SHOULD NOT be used. The ID_KEY_ID
Identity Payload MUST NOT be used.
- IKE Phase2クィックModeでは、2SA(Identity有効搭載量)がさばくPhaseを作成することへの交換は存在していなければなりません。 __ID IPV4_ADDR、ID IPV6_ADDR(プロトコル・スタックがIPv6をサポートするなら)とID_FQDN Identityペイロードを支えなければなりません。 _ID USER_FQDN SHOULD、サポートされてください。 IP Subnet、IP Address Range、ID_DER_ASN1_DN、およびID_DER_ASN1_GN形式SHOULD NOT、使用されてください。 ID_KEY_ID Identity有効搭載量を使用してはいけません。
Manual cryptographic keying MUST NOT be used because it does not provide the necessary re-keying support.
サポートを再合わせながら金策しないので、手動の暗号の合わせることを使用してはいけません。
When IPsec is used, the receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down the iSCSI TCP connection. If additional traffic is sent on it, a new IKE Phase 2 SA will be created to protect it.
IPsecが使用されているとき、IKE Phase2の領収書はメッセージSHOULD NOTを削除します。iSCSI TCP接続を取りこわす理由として、解釈されます。 それで追加トラフィックを送ると、それを保護するために新しいIKE Phase2SAを作成するでしょう。
The method used by the initiator to determine whether the target should be connected using IPsec is regarded as an issue of IPsec policy administration, and thus not defined in the iSCSI standard.
目標がIPsecを使用することで接続されるべきであるかどうか決定するのに創始者によって使用されたメソッドは、IPsec方針管理の問題と見なされて、iSCSI規格でこのようにして定義されません。
If an iSCSI target is discovered via a SendTargets request in a discovery session not using IPsec, the initiator should assume that it does not need IPsec to establish a session to that target. If an iSCSI target is discovered using a discovery session that does use IPsec, the initiator SHOULD use IPsec when establishing a session to that target.
iSCSI目標がIPsecを使用しないことで発見セッションにおけるSendTargets要求で発見されるなら、創始者は、IPsecがその目標にセッションを確立する必要はないと仮定するべきです。 その目標にセッションを確立するとき、iSCSI目標がIPsecを使用する発見セッションを使用していると発見されるなら、創始者SHOULDはIPsecを使用します。
9. Notes to Implementers
9. Implementersへの注意
This section notes some of the performance and reliability considerations of the iSCSI protocol. This protocol was designed to allow efficient silicon and software implementations. The iSCSI task tag mechanism was designed to enable Direct Data Placement (DDP - a DMA form) at the iSCSI level or lower.
このセクションはiSCSIプロトコルの性能と信頼性の問題のいくつかに注意します。 このプロトコルは、効率的なシリコンとソフトウェア実行を許容するように設計されました。 iSCSIタスクタグメカニズムは、iSCSIレベルにおいてより低く、Direct Data Placement(DDP--DMAフォーム)を有効にするように設計されました。
The guiding assumption made throughout the design of this protocol is that targets are resource constrained relative to initiators.
このプロトコルのデザイン中でされた誘導している仮定は目標が創始者に比例して抑制されたリソースであるということです。
Implementers are also advised to consider the implementation consequences of the iSCSI to SCSI mapping model as outlined in Section 3.4.3 Consequences of the Model.
また、Implementersが、実装がSCSIへのiSCSIがModelのセクション3.4.3Consequencesに概説されているようにモデルを写像する結果であると考えるようにアドバイスされます。
9.1. Multiple Network Adapters
9.1. 複数のネットワークアダプター
The iSCSI protocol allows multiple connections, not all of which need to go over the same network adapter. If multiple network connections are to be utilized with hardware support, the iSCSI protocol
iSCSIプロトコルは同じネットワークアダプターを調べるどの必要性のすべてではなく、複数の接続を許すか。 マルチネットワーク接続がハードウェアサポートと共に利用されることであるなら、iSCSIは議定書を作ります。
Satran, et al. Standards Track [Page 106] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[106ページ]。
command-data-status allegiance to one TCP connection ensures that there is no need to replicate information across network adapters or otherwise require them to cooperate.
1つのTCP接続におけるコマンドデータ状態忠誠は、ネットワークアダプターの向こう側に情報を模写するか、または別の方法で彼らが協力するのが必要である必要は全くないのを確実にします。
However, some task management commands may require some loose form of cooperation or replication at least on the target.
しかしながら、いくつかのタスク管理コマンドが少なくとも目標の上で何らかのゆるい形式の協力か模写を必要とするかもしれません。
9.1.1. Conservative Reuse of ISIDs
9.1.1. ISIDsの保守的な再利用
Historically, the SCSI model (and implementations and applications based on that model) has assumed that SCSI ports are static, physical entities. Recent extensions to the SCSI model have taken advantage of persistent worldwide unique names for these ports. In iSCSI however, the SCSI initiator ports are the endpoints of dynamically created sessions, so the presumptions of "static and physical" do not apply. In any case, the model clauses (particularly, Section 3.4.2 SCSI Architecture Model) provide for persistent, reusable names for the iSCSI-type SCSI initiator ports even though there does not need to be any physical entity bound to these names.
歴史的に、SCSIモデル(そして、そのモデルに基づく実装とアプリケーション)は、SCSIポートが静的であると仮定しました、物理的実体。 SCSIモデルへの最近の拡大は永続的な世界的なユニークな名前をこれらのポートに利用しました。 iSCSIでは、しかしながら、SCSI創始者ポートがダイナミックに作成されたセッションの終点であるので、「静的で物理的」の推定は適用されません。 どのような場合でも、そこですが、節(特にセクション3.4.2SCSI Architecture Model)がiSCSI-タイプSCSI創始者ポートのために永続的で、再利用できる名前に提供するモデルは、これらの名前に縛られたどんな物理的実体であるも必要がありません。
To both minimize the disruption of legacy applications and to better facilitate the SCSI features that rely on persistent names for SCSI ports, iSCSI implementations SHOULD attempt to provide a stable presentation of SCSI Initiator Ports (both to the upper OS-layers and to the targets to which they connect). This can be achieved in an initiator implementation by conservatively reusing ISIDs. In other words, the same ISID should be used in the Login process to multiple target portal groups (of the same iSCSI Target or different iSCSI Targets). The ISID RULE (Section 3.4.3 Consequences of the Model) only prohibits reuse to the same target portal group. It does not "preclude" reuse to other target portal groups. The principle of conservative reuse "encourages" reuse to other target portal groups. When a SCSI target device sees the same (InitiatorName, ISID) pair in different sessions to different target portal groups, it can identify the underlying SCSI Initiator Port on each session as the same SCSI port. In effect, it can recognize multiple paths from the same source.
レガシーアプリケーションの分裂を最小にして、永続的な名前をSCSIポートを当てにするSCSIの特徴をよりよく容易にするために、iSCSI実装SHOULDは、SCSI Initiator Ports(目標への上側のOS層と、そして、それらが接続する)の安定したプレゼンテーションを提供するのを試みます。 創始者実装で保守的にISIDsを再利用することによって、これを達成できます。 言い換えれば、同じISIDはLoginプロセスで複数の目標入り口のグループ(同じiSCSI Targetか異なったiSCSI Targetsの)に使用されるべきです。 ISID RULE(Modelのセクション3.4.3Consequences)は同じ目標入り口のグループに再利用を禁止するだけです。 それは他の目標入り口のグループに再利用を「排除しません」。 保守的な再利用の原則は他の目標入り口のグループに再利用を「奨励します」。 SCSI対象装置が、同じくらい(InitiatorName、ISID)が異なったセッションのときに異なった目標入り口のグループと対にされるのを見るとき、それは、各セッションでの基本的なSCSI Initiator Portが同じSCSIポートであると認識できます。 事実上、それは同じソースから複数の経路を認識できます。
9.1.2. iSCSI Name, ISID, and TPGT Use
9.1.2. iSCSI名、ISID、およびTPGT使用
The designers of the iSCSI protocol envisioned there being one iSCSI Initiator Node Name per operating system image on a machine. This enables SAN resource configuration and authentication schemes based on a system's identity. It supports the notion that it should be possible to assign access to storage resources based on "initiator device" identity.
iSCSIプロトコルのデザイナーはマシンの上でそこでオペレーティングシステムイメージあたりの存在1iSCSI Initiator Node Nameを思い描きました。 これはシステムのアイデンティティに基づくSANリソース構成と認証体系を可能にします。 「創始者デバイス」のアイデンティティに基づくストレージリソースへのアクセスを割り当てるのが可能であるべきであることはその考えを支持します。
Satran, et al. Standards Track [Page 107] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[107ページ]。
When there are multiple hardware or software components coordinated as a single iSCSI Node, there must be some (logical) entity that represents the iSCSI Node that makes the iSCSI Node Name available to all components involved in session creation and login. Similarly, this entity that represents the iSCSI Node must be able to coordinate session identifier resources (ISID for initiators) to enforce both the ISID and TSIH RULES (see Section 3.4.3 Consequences of the Model).
独身のiSCSI Nodeとして調整された複数のハードウェアかソフトウェアコンポーネントがあるとき、iSCSI Node Nameをセッション作成とログインにかかわるすべてのコンポーネントに利用可能にするiSCSI Nodeを表す何らかの(論理的)の実体があるに違いありません。 同様に、iSCSI Nodeを表すこの実体は、ISIDとTSIH RULESの両方を実施するために、セッション識別子リソース(創始者のためのISID)を調整できなければなりません(Modelのセクション3.4.3Consequencesを見てください)。
For targets, because of the closed environment, implementation of this entity should be straightforward. However, vendors of iSCSI hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide mechanisms for configuration of the iSCSI Node Name across the portal groups instantiated by multiple instances of these components within a target.
目標において、閉じている環境のために、この実体の実装は簡単であるべきです。 iSCSIハードウェア(例えば、NICsかHBAs)のベンダーは、目標のためにしかしながら、SHOULDが目標の中にこれらのコンポーネントの複数のインスタンスによって例示された入り口のグループの向こう側にiSCSI Node Nameの構成にメカニズムを提供することを意図しました。
However, complex targets making use of multiple Target Portal Group Tags may reconfigure them to achieve various quality goals. The initiators have two mechanisms at their disposal to discover and/or check reconfiguring targets - the discovery session type and a key returned by the target during login to confirm the TPGT. An initiator should attempt to "rediscover" the target configuration anytime a session is terminated unexpectedly.
しかしながら、複数のTarget Portal Group Tagsを利用するコンプレクス・ターゲットは、様々な上質の目標を達成するために彼らを再構成するかもしれません。 創始者には、目標を再構成する発見する、そして/または、チェックする彼らの自由に、2つのメカニズムがあります--セッションタイプとキーがログインの間の目標で戻って、TPGTを確認したという発見。 創始者は、セッションが不意に終えられるときはいつも、目標構成を「再発見すること」を試みるべきです。
For initiators, in the long term, it is expected that operating system vendors will take on the role of this entity and provide standard APIs that can inform components of their iSCSI Node Name and can configure and/or coordinate ISID allocation, use, and reuse.
創始者に関しては、長期で、オペレーティングシステムベンダーがISID配分、使用、および再利用をこの実体の役割を引き受けて、それらのiSCSI Node Nameの部品を知らせることができる標準のAPIを提供して、構成する、そして/または、調整できると予想されます。
Recognizing that such initiator APIs are not available today, other implementations of the role of this entity are possible. For example, a human may instantiate the (common) Node name as part of the installation process of each iSCSI component involved in session creation and login. This may be done either by pointing the component to a vendor-specific location for this datum or to a system-wide location. The structure of the ISID namespace (see Section 10.12.5 ISID and [RFC3721]) facilitates implementation of the ISID coordination by allowing each component vendor to independently (of other vendor's components) coordinate allocation, use, and reuse of its own partition of the ISID namespace in a vendor-specific manner. Partitioning of the ISID namespace within initiator portal groups managed by that vendor allows each such initiator portal group to act independently of all other portal groups when selecting an ISID for a login; this facilitates enforcement of the ISID RULE (see Section 3.4.3 Consequences of the Model) at the initiator.
そのような創始者APIが今日利用可能でないと認めて、この実体の役割の他の実装は可能です。 例えば、人間は、セッション作成にかかわるそれぞれのiSCSIの部品のインストールプロセスの一部として(一般的)のノード名を例示して、ログインするかもしれません。 ベンダー特有の位置にコンポーネントを向けることによって、このデータ、または、システム全体の位置にこれをするかもしれません。 それぞれのコンポーネントベンダーが独自にベンダー特有の方法における、それ自身のISID名前空間のパーティションの配分、使用、および再利用を調整するのを(他のベンダーのコンポーネントについて)許容することによって、ISID名前空間(セクション10.12.5ISIDと[RFC3721]を見る)の構造はISIDコーディネートの実装を容易にします。 ログインのためにISIDを選択するとき、そのベンダーによって経営された創始者入り口のグループの中のISID名前空間の仕切りで、そのようなそれぞれの創始者入り口のグループは他のすべての入り口のグループを単独行動を取ることができます。 これは創始者でISID RULE(Modelのセクション3.4.3Consequencesを見る)の実施を容易にします。
Satran, et al. Standards Track [Page 108] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[108ページ]。
A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in initiators MUST implement a mechanism for configuring the iSCSI Node Name. Vendors, and administrators must ensure that iSCSI Node Names are unique worldwide. It is therefore important that when one chooses to reuse the iSCSI Node Name of a disabled unit, not to re-assign that name to the original unit unless its worldwide uniqueness can be ascertained again.
創始者における使用のために意図するiSCSIハードウェア(例えば、NICsかHBAs)のベンダーは、iSCSI Node Nameを構成するためにメカニズムを実装しなければなりません。 ベンダー、および管理者はしなければなりません。iSCSI Node Namesが確実に世界中でユニークになるようにしてください。 したがって、1であるときに、再び世界的なユニークさを確かめることができないならそれが、オリジナルのユニットにその名前を再選任するのではなく、障害があるユニットのiSCSI Node Nameを再利用するのを選ぶのは、重要です。
In addition, a vendor of iSCSI hardware must implement a mechanism to configure and/or coordinate ISIDs for all sessions managed by multiple instances of that hardware within a given iSCSI Node. Such configuration might be either permanently pre-assigned at the factory (in a necessarily globally unique way), statically assigned (e.g., partitioned across all the NICs at initialization in a locally unique way), or dynamically assigned (e.g., on-line allocator, also in a locally unique way). In the latter two cases, the configuration may be via public APIs (perhaps driven by an independent vendor's software, such as the OS vendor) or via private APIs driven by the vendor's own software.
さらに、iSCSIハードウェアの業者は構成するメカニズムを実行しなければなりません、そして、すべてのセッションのためのコーディネートしているISIDsは与えられたiSCSI Nodeの中でそのハードウェアの複数の例で管理しました。 そのような構成は永久に静的に割り当てられた(例えば、すべてのNICsの向こう側に局所的にユニークな方法で初期化で仕切られます)工場(必ずグローバルにユニークな方法で)であらかじめ割り当てられるか、またはダイナミックに(例えば、局所的にユニークな方法でもオンラインアロケータ)を割り当てられるかもしれません。 後者の2つの場合には、公共のAPI(恐らく、OS業者などの独立している業者のソフトウェアを通り過ぎる)を通して、または、業者の自身のソフトウェアによって運転された個人的なAPIを通して構成があるかもしれません。
9.2. Autosense and Auto Contingent Allegiance (ACA)
9.2. Autosenseと自動偶然な忠誠(ACA)
Autosense refers to the automatic return of sense data to the initiator in case a command did not complete successfully. iSCSI initiators and targets MUST support and use autosense.
Autosenseはコマンドが首尾よく終了しなかった場合で創始者へのセンス・データの自動復帰について言及します。iSCSI創始者と目標は、autosenseを支持して、使用しなければなりません。
ACA helps preserve ordered command execution in the presence of errors. As iSCSI can have many commands in-flight between initiator and target, iSCSI initiators and targets SHOULD support ACA.
ACAは、誤りがあるとき命令されたコマンド実行を保存するのを助けます。 iSCSIが多くのコマンドを創始者と、目標と、iSCSI創始者と目標の間で機内にすることができるように、SHOULDはACAを支持します。
9.3. iSCSI Timeouts
9.3. iSCSIタイムアウト
iSCSI recovery actions are often dependent on iSCSI time-outs being recognized and acted upon before SCSI time-outs. Determining the right time-outs to use for various iSCSI actions (command acknowledgements expected, status acknowledgements, etc.) is very much dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI driver). As a guide, the implementer may use an average Nop-Out/Nop-In turnaround delay multiplied by a "safety factor" (e.g., 4) as a good estimate for the basic delay of the iSCSI stack for a given connection. The safety factor should account for the network load variability. For connection teardown the implementer may want to consider also the TCP common practice for the given infrastructure.
iSCSI回復動作はしばしばSCSIタイムアウトの前に認識されて、作用されるiSCSIタイムアウトに依存しています。 正しいタイムアウトが様々なiSCSI動作に(予想されたコマンド承認、状態承認など)を使用することを決定するのはインフラストラクチャにたいへん依存しています(ハードウェア、リンク、TCP/IPが積み重ねられます、iSCSIドライバー)。 ガイドとして、implementerは「セーフティ・ファクター」(例えば、4)が与えられた接続のためにiSCSIスタックの基本的な遅れのための良い見積りとして掛けられた中の外の平均したNop/Nopターンアラウンド遅れを使用するかもしれません。 セーフティ・ファクターはネットワーク負荷の可変性を説明するべきです。 また、接続分解のために、implementerは、与えられたインフラストラクチャのためにTCPが一般的な習慣であると考えたがっているかもしれません。
Satran, et al. Standards Track [Page 109] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[109ページ]。
Text negotiations MAY also be subject to either time-limits or limits in the number of exchanges. Those SHOULD be generous enough to avoid affecting interoperability (e.g., allowing each key to be negotiated on a separate exchange).
また、テキスト交渉は、交換の数がどちらかを条件としたタイムリミットか限界であるかもしれません。 それらのSHOULD、相互運用性(例えば、各キーが別々の交換に関して交渉されるのを許容する)に影響するのを避けることができるくらい寛大であってください。
The relation between iSCSI timeouts and SCSI timeouts should also be considered. SCSI timeouts should be longer than iSCSI timeouts plus the time required for iSCSI recovery whenever iSCSI recovery is planned. Alternatively, an implementer may choose to interlock iSCSI timeouts and recovery with SCSI timeouts so that SCSI recovery will become active only where iSCSI is not planned to, or failed to, recover.
また、iSCSIタイムアウトとSCSIタイムアウトとの関係は考えられるべきです。 SCSIタイムアウトはiSCSI回復が計画されているときはいつも、iSCSIタイムアウトと時間がiSCSI回復に必要であるというよりも長いはずです。 あるいはまた、iSCSIが計画していたか、または必ず計画して、回復することにすぎないところでは、implementerは、SCSI回復がアクティブになるようにSCSIタイムアウトに伴うiSCSIタイムアウトと回復を連動させるのを選ぶかもしれません。
The implementer may also want to consider the interaction between various iSCSI exception events - such as a digest failure - and subsequent timeouts. When iSCSI error recovery is active, a digest failure is likely to result in discovering a missing command or data PDU. In these cases, an implementer may want to lower the timeout values to enable faster initiation for recovery procedures.
また、implementerはダイジェスト失敗や、その後のタイムアウトなどの様々なiSCSI例外出来事の間の相互作用を考えたがっているかもしれません。 iSCSIエラー回復がアクティブであるときに、ダイジェスト失敗はなくなったコマンドを発見するか、データPDUをもたらしそうです。 これらの場合では、implementerは、リカバリ手順のための、より速い開始を可能にするためにタイムアウト値を下げたがっているかもしれません。
9.4. Command Retry and Cleaning Old Command Instances
9.4. コマンド再試行と古いコマンド例を掃除すること。
To avoid having old, retried command instances appear in a valid command window after a command sequence number wrap around, the protocol requires (see Section 3.2.2.1 Command Numbering and Acknowledging) that on every connection on which a retry has been issued, a non-immediate command be issued and acknowledged within a 2**31-1 commands interval from the CmdSN of the retried command. This requirement can be fulfilled by an implementation in several ways.
コマンド・シーケンス番号が巻きつけられた後に古くて、再試行されたコマンド例を有効なコマンドウィンドウに現れさせるのを避けるために、プロトコルは、再試行が発行されたすべての接続のときに2**31-1の中で発行されて、承諾された非即座のコマンドが再試行されたコマンドのCmdSNから間隔を命令するのを必要とします(セクション3.2.2の.1Command NumberingとAcknowledgingを見ます)。 この要件が実現でいくつかの方法で実現できます。
The simplest technique to use is to send a (non-retry) non-immediate SCSI command (or a NOP if no SCSI command is available for a while) after every command retry on the connection on which the retry was attempted. As errors are deemed rare events, this technique is probably the most effective, as it does not involve additional checks at the initiator when issuing commands.
使用する中で最も簡単なテクニックはあらゆるコマンド再試行の後に(非再試行している)非即座のSCSIコマンド(どんなSCSIも命令しないなら、NOPはしばらく、利用可能である)を再試行が試みられた接続に送ることです。 誤りがめったにない事件であると考えられるので、このテクニックはたぶん最も効果的です、命令を出すとき、創始者で追加チェックにかかわらないとき。
9.5. Synch and Steering Layer and Performance
9.5. 同時性、操縦層、およびパフォーマンス
While a synch and steering layer is optional, an initiator/target that does not have it working against a target/initiator that demands synch and steering may experience performance degradation caused by packet reordering and loss. Providing a synch and steering mechanism is recommended for all high-speed implementations.
同時性と操縦層が任意である間、同時性を要求する目標/創始者に不利に働いて、操縦するのをさせない創始者/目標は、パケット再命令と損失で引き起こされた性能退行になるかもしれません。 同時性と舵取り装置を提供するのはすべての高速実現のために推薦されます。
Satran, et al. Standards Track [Page 110] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[110ページ]。
9.6. Considerations for State-dependent Devices and Long-lasting SCSI
Operations
9.6. 州の依存する装置と持続的なSCSI操作のための問題
Sequential access devices operate on the principle that the position of the device is based on the last command processed. As such, command processing order and knowledge of whether or not the previous command was processed is of the utmost importance to maintain data integrity. For example, inadvertent retries of SCSI commands when it is not known if the previous SCSI command was processed is a potential data integrity risk.
装置が装置の位置が持続コマンドに基づいているという原則で操作する順アクセスは処理されました。 そういうものとして、前のコマンドが処理されたかどうかに関するコマンド処理注文と知識は、データ保全を維持するためには最重要性のものです。 例えば、SCSIの不注意な再試行は、前のSCSIコマンドが処理されたならそれがいつ知られていないかが、潜在的データ保全のリスクであると命令します。
For a sequential access device, consider the scenario in which a SCSI SPACE command to backspace one filemark is issued and then re-issued due to no status received for the command. If the first SPACE command was actually processed, the re-issued SPACE command, if processed, will cause the position to change. Thus, a subsequent write operation will write data to the wrong position and any previous data at that position will be overwritten.
順アクセス装置に関しては、バックスペースキーを押して印字位置を一字分戻るために、1filemarkがSCSI SPACEが命令するもので発行されるか、そして、その時がコマンドのために取られなかった状態の全くため再発行したシナリオを考えてください。 最初のSPACEコマンドが実際に処理されたなら、処理されると、再発行されたSPACEコマンドは変化する立場を引き起こすでしょう。 その結果、aその後、意志が上書きされると間違った位置へのデータとその位置のどんな前のデータにも書く操作を書いてください。
For a medium changer device, consider the scenario in which an EXCHANGE MEDIUM command (the SOURCE ADDRESS and DESTINATION ADDRESS are the same thus performing a swap) is issued and then re-issued due to no status received for the command. If the first EXCHANGE MEDIUM command was actually processed, the re-issued EXCHANGE MEDIUM command, if processed, will perform the swap again. The net effect is that a swap was not performed thus leaving a data integrity exposure.
中型の切換器装置に関しては、EXCHANGE MEDIUMコマンド(SOURCE ADDRESSとDESTINATION ADDRESSはその結果、スワッピングを実行するのにおいて同じである)がコマンドのために取られなかった状態の全くため発行されて、次に再発行されるシナリオを考えてください。 最初のEXCHANGE MEDIUMコマンドが実際に処理されたなら、処理されると、再発行されたEXCHANGE MEDIUMコマンドは再びスワッピングを実行するでしょう。 ネットの効果はその結果、データ保全露出を残して、スワッピングが実行されなかったということです。
All commands that change the state of the device (as in SPACE commands for sequential access devices, and EXCHANGE MEDIUM for medium changer device), MUST be issued as non-immediate commands for deterministic and in order delivery to iSCSI targets.
装置(順アクセス装置のためのSPACEコマンド、および中型の切換器装置のためのEXCHANGE MEDIUMのように)の状態を変えるすべてのコマンド、非即座のコマンドとして発行しなければならない、決定論、そして、iSCSIへの注文配送が狙うコネ。
For many of those state changing commands, the execution model also assumes that the command is executed exactly once. Devices implementing READ POSITION and LOCATE provide a means for SCSI level command recovery and new tape-class devices should support those commands. In their absence a retry at SCSI level is difficult and error recovery at iSCSI level is advisable.
また、それらの州の変化コマンドの多くのために、実行モデルは、コマンドがまさに一度実行されると仮定します。 READ POSITIONとLOCATEを実行する装置がSCSIの平らなコマンド回復に手段を提供します、そして、新しいテープクラス装置はそれらのコマンドをサポートするはずです。 彼らの不在では、SCSIレベルにおける再試行は難しいです、そして、iSCSIレベルにおけるエラー回復は賢明です。
Devices operating on long latency delivery subsystems and performing long lasting SCSI operations may need mechanisms that enable connection replacement while commands are running (e.g., during an extended copy operation).
長い潜在配送サブシステムを作動させて、持続的なSCSI操作を実行する装置はコマンドが走行(例えば、拡張コピー操作の間の)ですが、接続交換を可能にするメカニズムを必要とするかもしれません。
Satran, et al. Standards Track [Page 111] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[111ページ]。
9.6.1. Determining the Proper ErrorRecoveryLevel
9.6.1. 適切なErrorRecoveryLevelを決定します。
The implementation and use of a specific ErrorRecoveryLevel should be determined based on the deployment scenarios of a given iSCSI implementation. Generally, the following factors must be considered before deciding on the proper level of recovery:
特定のErrorRecoveryLevelの実現と使用は与えられたiSCSI実現の展開シナリオに基づいて決定しているべきです。 一般に、適切なレベルの回復を決める前に、以下の要素を考えなければなりません:
a) Application resilience to I/O failures.
b) Required level of availability in the face of transport
connection failures.
c) Probability of transport layer "checksum escape". This in
turn decides the iSCSI digest failure frequency, and thus the
criticality of iSCSI-level error recovery. The details of
estimating this probability are outside the scope of this
document.
a) 入出力失敗b)へのアプリケーション弾力 輸送接続失敗c)に直面して必要なレベルの有用性 トランスポート層「チェックサムエスケープ」の確率。 これは、順番にiSCSIダイジェスト失敗頻度について決めて、その結果、iSCSI-レベルエラー回復の臨界について決めます。 このドキュメントの範囲の外にこの確率を見積もる詳細があります。
A consideration of the above factors for SCSI tape devices as an example suggests that implementations SHOULD use ErrorRecoveryLevel=1 when transport connection failure is not a concern and SCSI level recovery is unavailable, and ErrorRecoveryLevel=2 when the connection failure is also of high likelihood during a backup/retrieval.
例が、輸送接続失敗が関心でないときに、実現SHOULDがErrorRecoveryLevel=1を使用するのを示して、SCSIが回復を平らにするとき、SCSIテープ装置のための上記の要素の考慮は入手できません、そして、接続失敗であるときに、バックアップ/検索の間、ErrorRecoveryLevel=2は高いまた見込みについてものです。
For extended copy operations, implementations SHOULD use ErrorRecoveryLevel=2 whenever there is a relatively high likelihood of connection failure.
拡張コピー操作のために、接続失敗の比較的高い見込みがあるときはいつも、実現SHOULDはErrorRecoveryLevel=2を使用します。
10. iSCSI PDU Formats
10. iSCSI PDU形式
All multi-byte integers that are specified in formats defined in this document are to be represented in network byte order (i.e., big endian). Any field that appears in this document assumes that the most significant byte is the lowest numbered byte and the most significant bit (within byte or field) is the lowest numbered bit unless specified otherwise.
本書では定義された書式で指定されるすべてのマルチバイト整数はネットワークバイトオーダー(すなわち、ビッグエンディアン)で表されることです。 現れるどんな野原も、最も重要なバイトが最も低い番号付のバイトであると本書では仮定します、そして、別の方法で指定されない場合、最も重要なビット(バイトか分野の中の)は最も低い番号付のビットです。
Any compliant sender MUST set all bits not defined and all reserved fields to zero unless specified otherwise. Any compliant receiver MUST ignore any bit not defined and all reserved fields unless specified otherwise. Receipt of reserved code values in defined fields MUST be reported as a protocol error.
別の方法で指定されない場合、どんな言いなりになっている送付者もビットが定義しなかったすべてとすべての予約された分野をゼロに設定しなければなりません。 別の方法で指定されない場合、どんな言いなりになっている受信機も定義されなかったどんなビットとすべての予約された分野も無視しなければなりません。 プロトコル誤りとして定義された分野の予約されたコード値の領収書を報告しなければなりません。
Reserved fields are marked by the word "reserved", some abbreviation of "reserved", or by "." for individual bits when no other form of marking is technically feasible.
「予約された分野は「予約」という言葉、「予約」の何らかの略語によって示されます。」. 」 個々のビットにおいて、何か他のものがいつマークを形成しないかは、技術的に可能です。
Satran, et al. Standards Track [Page 112] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[112ページ]。
10.1. iSCSI PDU Length and Padding
10.1. iSCSI PDUの長さと詰め物
iSCSI PDUs are padded to the closest integer number of four byte words. The padding bytes SHOULD be sent as 0.
iSCSI PDUsは4バイトの単語の最も近い整数に水増しされます。 バイトSHOULDを水増しして、0として送ってください。
10.2. PDU Template, Header, and Opcodes
10.2. PDUテンプレート、ヘッダー、およびOpcodes
All iSCSI PDUs have one or more header segments and, optionally, a data segment. After the entire header segment group a header-digest MAY follow. The data segment MAY also be followed by a data-digest.
すべてのiSCSI PDUsには、1つ以上のヘッダー・セグメントと任意にデータ・セグメントがあります。 全体のヘッダー・セグメントグループの、あとにヘッダーダイジェストについて行くかもしれません。 また、データダイジェストはデータ・セグメントのあとに続くかもしれません。
The Basic Header Segment (BHS) is the first segment in all of the iSCSI PDUs. The BHS is a fixed-length 48-byte header segment. It MAY be followed by Additional Header Segments (AHS), a Header-Digest, a Data Segment, and/or a Data-Digest.
Basic Header Segment(BHS)はiSCSI PDUsのすべてで最初のセグメントです。 BHSは固定長の48バイトのヘッダー・セグメントです。 Additional Header Segments(AHS)、Header-ダイジェスト、Data Segment、そして/または、Data-ダイジェストはそれのあとに続くかもしれません。
Satran, et al. Standards Track [Page 113] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[113ページ]。
The overall structure of an iSCSI PDU is as follows:
iSCSI PDUの全体的な構造は以下の通りです:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0/ Basic Header Segment (BHS) /
+/ /
+---------------+---------------+---------------+---------------+
48/ Additional Header Segment 1 (AHS) (optional) /
+/ /
+---------------+---------------+---------------+---------------+
/ Additional Header Segment 2 (AHS) (optional) /
+/ /
+---------------+---------------+---------------+---------------+
----
+---------------+---------------+---------------+---------------+
/ Additional Header Segment n (AHS) (optional) /
+/ /
+---------------+---------------+---------------+---------------+
----
+---------------+---------------+---------------+---------------+
k/ Header-Digest (optional) /
+/ /
+---------------+---------------+---------------+---------------+
l/ Data Segment(optional) /
+/ /
+---------------+---------------+---------------+---------------+
m/ Data-Digest (optional) /
+/ /
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0/基本的なヘッダー・セグメント(BHS)/+//+---------------+---------------+---------------+---------------+ 48/追加しているヘッダー・セグメント1(AHS)の(任意)の/+//+---------------+---------------+---------------+---------------+/追加しているヘッダー・セグメント2(AHS)の(任意)の/+//+---------------+---------------+---------------+---------------+ ---- +---------------+---------------+---------------+---------------+/追加しているHeader Segment n(AHS)の(任意)の/+//+---------------+---------------+---------------+---------------+ ---- +---------------+---------------+---------------+---------------+ ヘッダーk/ダイジェストの(任意)の/+//+---------------+---------------+---------------+---------------+ l/データのSegmentの(任意)の/+//+---------------+---------------+---------------+---------------+ m/は(任意)の/+//+をデータで読みこなします。---------------+---------------+---------------+---------------+
All PDU segments and digests are padded to the closest integer number of four byte words. For example, all PDU segments and digests start at a four byte word boundary and the padding ranges from 0 to 3 bytes. The padding bytes SHOULD be sent as 0.
すべてのPDUセグメントとダイジェストは4バイトの単語の最も近い整数に水増しされます。 例えば、すべてのPDUセグメントとダイジェストは4バイトの語境界で始まります、そして、詰め物は0〜3バイトに及びます。 バイトSHOULDを水増しして、0として送ってください。
iSCSI response PDUs do not have AH Segments.
iSCSI応答PDUsには、AH Segmentsがありません。
10.2.1. Basic Header Segment (BHS)
10.2.1. 基本的なヘッダー・セグメント(BHS)
The BHS is 48 bytes long. The Opcode and DataSegmentLength fields appear in all iSCSI PDUs. In addition, when used, the Initiator Task Tag and Logical Unit Number always appear in the same location in the header.
BHSは48バイト長です。 OpcodeとDataSegmentLength野原はすべてのiSCSI PDUsに現れます。 さらに、使用されると、Initiator Task TagとLogical Unit Numberはヘッダーに同じ位置にいつも現れます。
Satran, et al. Standards Track [Page 114] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[114ページ]。
The format of the BHS is:
BHSの形式は以下の通りです。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|I| Opcode |F| Opcode-specific fields |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Opcode-specific fields |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20/ Opcode-specific fields /
+/ /
+---------------+---------------+---------------+---------------+
48
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | 私| Opcode|F| Opcode特有の分野| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| LUNかOpcode特有の分野| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20/ Opcode特有の分野/+//+---------------+---------------+---------------+---------------+ 48
10.2.1.1 I
10.2.1.1 私
For request PDUs, the I bit set to 1 is an immediate delivery marker.
要求PDUsに関しては、1に設定されたIビットは即座の配送マーカーです。
10.2.1.2. Opcode
10.2.1.2. Opcode
The Opcode indicates the type of iSCSI PDU the header encapsulates.
Opcodeはヘッダーが要約するiSCSI PDUのタイプを示します。
The Opcodes are divided into two categories: initiator opcodes and target opcodes. Initiator opcodes are in PDUs sent by the initiator (request PDUs). Target opcodes are in PDUs sent by the target (response PDUs).
Opcodesは2つのカテゴリに分割されます: 創始者opcodesと目標opcodes。 創始者opcodesが創始者によって送られたPDUsにあります(PDUsを要求してください)。 目標opcodesが目標(応答PDUs)によって送られたPDUsにあります。
Initiators MUST NOT use target opcodes and targets MUST NOT use initiator opcodes.
創始者は目標opcodesを使用してはいけません、そして、目標は創始者opcodesを使用してはいけません。
Initiator opcodes defined in this specification are:
この仕様に基づき定義された創始者opcodesは以下の通りです。
0x00 NOP-Out
0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block)
0x02 SCSI Task Management function request
0x03 Login Request
0x04 Text Request
0x05 SCSI Data-Out (for WRITE operations)
0x06 Logout Request
0x10 SNACK Request
0x1c-0x1e Vendor specific codes
0×00 外の外のNOP0×01SCSI Command(SCSI Command Descriptor Blockを要約する)0×02SCSI Task Management機能要求0×03Login Request0x04Text Request0x05SCSI Data(WRITE操作のための)0×06Logout Request0x10のSNACK Request 0x1c-0x1e Vendorの特定のコード
Satran, et al. Standards Track [Page 115] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[115ページ]。
Target opcodes are:
目標opcodesは以下の通りです。
0x20 NOP-In
0x21 SCSI Response - contains SCSI status and possibly sense
information or other response information.
0x22 SCSI Task Management function response
0x23 Login Response
0x24 Text Response
0x25 SCSI Data-In - for READ operations.
0x26 Logout Response
0x31 Ready To Transfer (R2T) - sent by target when it is ready
to receive data.
0x32 Asynchronous Message - sent by target to indicate certain
special conditions.
0x3c-0x3e Vendor specific codes
0x3f Reject
0×20 中のNOP0×21SCSI Response--SCSI状態とことによると感覚情報か他の応答情報を含んでいます。 0×22 READ操作のための中のSCSI Task Management機能応答0x23Login Response0x24Text Response0x25SCSI Data。 0×26はログアウトします。Response0x31Ready To Transfer(R2T)--それがデータを受け取る準備ができている目標で、発信しました。 0×32 非同期なMessage--目標で送って、ある特別な状態を示します。 0x3c-0x3eの業者の特定のコード0x3f Reject
All other opcodes are reserved.
他のすべてのopcodesが予約されています。
10.2.1.3. Final (F) bit
10.2.1.3. 最終的な(F)ビット
When set to 1 it indicates the final (or only) PDU of a sequence.
1に設定されると、それは系列の最終的な(単に)PDUを示します。
10.2.1.4. Opcode-specific Fields
10.2.1.4. Opcode特有の分野
These fields have different meanings for different opcode types.
これらの分野には、異なったopcodeタイプのための異なった意味があります。
10.2.1.5. TotalAHSLength
10.2.1.5. TotalAHSLength
Total length of all AHS header segments in units of four byte words including padding, if any.
もしあればそっと歩くのを含む4バイトのユニットの単語によるすべてのAHSヘッダー・セグメントの全長
The TotalAHSLength is only used in PDUs that have an AHS and MUST be 0 in all other PDUs.
TotalAHSLengthはAHSを持っているPDUsで使用されるだけであり、他のすべてのPDUsの0歳であるに違いありません。
10.2.1.6. DataSegmentLength
10.2.1.6. DataSegmentLength
This is the data segment payload length in bytes (excluding padding). The DataSegmentLength MUST be 0 whenever the PDU has no data segment.
これはバイト(詰め物を除いた)で表現されるデータ・セグメントペイロード長です。 PDUにデータ・セグメントが全くないときはいつも、DataSegmentLengthは0歳であるに違いありません。
10.2.1.7. LUN
10.2.1.7. LUN
Some opcodes operate on a specific Logical Unit. The Logical Unit Number (LUN) field identifies which Logical Unit. If the opcode does not relate to a Logical Unit, this field is either ignored or may be used in an opcode specific way. The LUN field is 64-bits and should
いくつかのopcodesが特定のLogical Unitを作動させます。 Logical Unit Number(LUN)分野はどのLogical Unitを特定するか。 opcodeがLogical Unitに関連しないなら、この分野は、無視されるか、またはopcodeの特定の方法で使用されるかもしれません。 そしてであるべきですLUN分野が64ビットである。
Satran, et al. Standards Track [Page 116] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[116ページ]。
be formatted in accordance with [SAM2]. For example, LUN[0] from [SAM2] is BHS byte 8 and so on up to LUN[7] from [SAM2], which is BHS byte 15.
[SAM2]に従って、フォーマットされてください。 例えば、[SAM2]からのLUN[7]まで、[SAM2]からのLUN[0]はBHSバイト8などです。(]はBHSバイト15です)。
10.2.1.8. Initiator Task Tag
10.2.1.8. 創始者タスクタグ
The initiator assigns a Task Tag to each iSCSI task it issues. While a task exists, this tag MUST uniquely identify the task session-wide. SCSI may also use the initiator task tag as part of the SCSI task identifier when the timespan during which an iSCSI initiator task tag must be unique extends over the timespan during which a SCSI task tag must be unique. However, the iSCSI Initiator Task Tag must exist and be unique even for untagged SCSI commands.
創始者はそれが発行するそれぞれのiSCSIタスクにTask Tagを割り当てます。 タスクが存在している間、このタグは唯一セッション全体でタスクを特定しなければなりません。 また、iSCSI創始者タスクタグがユニークであるに違いないtimespanでSCSIタスクタグがユニークであるに違いないtimespanに及ぶと、SCSIはSCSIタスク識別子の一部として創始者タスクタグを使用するかもしれません。 しかしながら、iSCSI Initiator Task Tagは存在していて、untagged SCSIコマンドにさえ、ユニークであるに違いありません。
10.2.2. Additional Header Segment (AHS)
10.2.2. 追加ヘッダー・セグメント(AHS)
The general format of an AHS is:
AHSの一般形式は以下の通りです。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0| AHSLength | AHSType | AHS-Specific |
+---------------+---------------+---------------+---------------+
4/ AHS-Specific /
+/ /
+---------------+---------------+---------------+---------------+
x
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0| AHSLength| AHSType| AHS特有です。| +---------------+---------------+---------------+---------------+ 4/ AHS特有の/+//+---------------+---------------+---------------+---------------+ x
10.2.2.1. AHSType
10.2.2.1. AHSType
The AHSType field is coded as follows:
AHSType分野は以下の通りコード化されます:
bit 0-1 - Reserved
ビット0-1--予約されます。
bit 2-7 - AHS code
ビット2-7--AHSコード
0 - Reserved
1 - Extended CDB
2 - Expected Bidirectional Read Data Length
3 - 63 Reserved
0--予約された1--拡張CDB2--双方向で予想されるのは3--63が予約したデータの長さを読みました。
10.2.2.2. AHSLength
10.2.2.2. AHSLength
This field contains the effective length in bytes of the AHS excluding AHSType and AHSLength and padding, if any. The AHS is padded to the smallest integer number of 4 byte words (i.e., from 0 up to 3 padding bytes).
この分野はバイトのAHSTypeを除くAHSとAHSLengthともしあればそっと歩く際に有効長を含んでいます。 AHSは4バイトの単語(すなわち、0上から3詰め物バイトまでの)の最もわずかな整数に水増しされます。
Satran, et al. Standards Track [Page 117] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[117ページ]。
10.2.2.3. Extended CDB AHS
10.2.2.3. 拡張CDB AHS
The format of the Extended CDB AHS is:
Extended CDB AHSの形式は以下の通りです。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0| AHSLength (CDBLength-15) | 0x01 | Reserved |
+---------------+---------------+---------------+---------------+
4/ ExtendedCDB...+padding /
+/ /
+---------------+---------------+---------------+---------------+
x
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0| AHSLength(CDBLength-15)| 0×01| 予約されます。| +---------------+---------------+---------------+---------------+ 4/ ExtendedCDB…+ 詰め物/+//+---------------+---------------+---------------+---------------+ x
This type of AHS MUST NOT be used if the CDBLength is less than 17. The length includes the reserved byte 3.
これをタイプします。AHS MUST NOTでは、CDBLengthが17歳未満であるなら使用されてください。 長さは予約されたバイト3を含んでいます。
10.2.2.4. Bidirectional Expected Read-Data Length AHS
10.2.2.4. データを読んでいる双方向の予想された長さのAHS
The format of the Bidirectional Read Expected Data Transfer Length AHS is:
Bidirectional Read Expected Data Transfer Length AHSの形式は以下の通りです。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0| AHSLength (0x0005) | 0x02 | Reserved |
+---------------+---------------+---------------+---------------+
4| Expected Read-Data Length |
+---------------+---------------+---------------+---------------+
8
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0| AHSLength(0×0005)| 0×02| 予約されます。| +---------------+---------------+---------------+---------------+ 4| 予想されたデータを読んでいる長さ| +---------------+---------------+---------------+---------------+ 8
10.2.3. Header Digest and Data Digest
10.2.3. ヘッダーダイジェストとデータは読みこなされます。
Optional header and data digests protect the integrity of the header and data, respectively. The digests, if present, are located, respectively, after the header and PDU-specific data, and cover respectively the header and the PDU data, each including the padding bytes, if any.
任意のヘッダーとデータダイジェストはそれぞれヘッダーとデータの保全を保護します。 ダイジェストは、もしあれば存在しているならヘッダーとPDU特有のデータの後にそれぞれ見つけられていて、それぞれ詰め物バイトを含むそれぞれヘッダーとPDUデータを含んでいます。
The existence and type of digests are negotiated during the Login Phase.
ダイジェストの存在とタイプはLogin Phaseの間、交渉されます。
The separation of the header and data digests is useful in iSCSI routing applications, in which only the header changes when a message is forwarded. In this case, only the header digest should be recalculated.
ヘッダーとデータダイジェストの分離はiSCSIルーティングアプリケーションで役に立ちます。そこでは、ヘッダーだけが、メッセージがいつ転送されるかを変えます。 この場合、ヘッダーダイジェストだけが再計算されるべきです。
Satran, et al. Standards Track [Page 118] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[118ページ]。
Digests are not included in data or header length fields.
ダイジェストはデータかヘッダ長分野に含まれていません。
A zero-length Data Segment also implies a zero-length data-digest.
また、無の長さのData Segmentはゼロ・レングスデータダイジェストを含意します。
10.2.4. Data Segment
10.2.4. データ・セグメント
The (optional) Data Segment contains PDU associated data. Its payload effective length is provided in the BHS field - DataSegmentLength. The Data Segment is also padded to an integer number of 4 byte words.
(任意)のデータSegmentはPDU関連データを含んでいます。 ペイロード有効長をBHS分野に提供します--DataSegmentLength。 また、Data Segmentは4バイトの単語の整数に水増しされます。
10.3. SCSI Command
10.3. SCSIコマンド
The format of the SCSI Command PDU is:
SCSI Command PDUの形式は以下の通りです。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|I| 0x01 |F|R|W|. .|ATTR | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| Logical Unit Number (LUN) |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Expected Data Transfer Length |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ SCSI Command Descriptor Block (CDB) /
+/ /
+---------------+---------------+---------------+---------------+
48/ AHS (Optional) /
+---------------+---------------+---------------+---------------+
x/ Header Digest (Optional) /
+---------------+---------------+---------------+---------------+
y/ (DataSegment, Command Data) (Optional) /
+/ /
+---------------+---------------+---------------+---------------+
z/ Data Digest (Optional) /
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | 私| 0×01|F|R|W|. . | ATTR| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| 論理ユニット番号(LUN)| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 予想されたデータ転送の長さ| +---------------+---------------+---------------+---------------+ 24| CmdSN| +---------------+---------------+---------------+---------------+ 28| ExpStatSN| +---------------+---------------+---------------+---------------+ 32/ SCSIコマンド記述子ブロック(CDB)/+//+---------------+---------------+---------------+---------------+ 48/ AHSの(任意)の/+---------------+---------------+---------------+---------------+ x/ヘッダーのDigestの(任意)の/+---------------+---------------+---------------+---------------+ y/(DataSegment、Command Data)(任意)の/+//+---------------+---------------+---------------+---------------+ z/データのDigestの(任意)の/+---------------+---------------+---------------+---------------+
Satran, et al. Standards Track [Page 119] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[119ページ]。
10.3.1. Flags and Task Attributes (byte 1)
10.3.1. 旗とタスク属性(バイト1)
The flags for a SCSI Command are:
SCSI Commandのための旗は以下の通りです。
bit 0 (F) is set to 1 when no unsolicited SCSI Data-Out PDUs follow
this PDU. When F=1 for a write and if Expected Data
Transfer Length is larger than the DataSegmentLength, the
target may solicit additional data through R2T.
どんな求められていない外のSCSI Data PDUsもこのPDUに続かないとき、ビット0(F)は1に設定されます。 aのためのF=1が書くとき、Expected Data Transfer LengthがDataSegmentLengthより大きいなら、目標はR2Tを通して追加データに請求するかもしれません。
bit 1 (R) is set to 1 when the command is expected to input data.
コマンドがデータを入力すると予想されるとき、ビット1(R)は1に設定されます。
bit 2 (W) is set to 1 when the command is expected to output data.
コマンドがデータを出力すると予想されるとき、ビット2(W)は1に設定されます。
bit 3-4 Reserved.
ビット3-4Reserved。
bit 5-7 contains Task Attributes.
ビット5-7はTask Attributesを含んでいます。
Task Attributes (ATTR) have one of the following integer values (see [SAM2] for details):
タスクAttributes(ATTR)には、以下の整数値の1つがあります(詳細に関して[SAM2]を見てください):
0 - Untagged
1 - Simple
2 - Ordered
3 - Head of Queue
4 - ACA
5-7 - Reserved
簡単な2(3--待ち行列4のヘッド--ACA5-7を注文する)が予約した0(Untagged1)
Setting both the W and the F bit to 0 is an error. Either or both of R and W MAY be 1 when either the Expected Data Transfer Length and/or Bidirectional Read Expected Data Transfer Length are 0, but they MUST NOT both be 0 when the Expected Data Transfer Length and/or Bidirectional Read Expected Data Transfer Length are not 0 (i.e., when some data transfer is expected the transfer direction is indicated by the R and/or W bit).
WとFビットの両方を0に設定するのは、誤りです。 Expected Data Transfer Length、そして/または、Bidirectional Read Expected Data Transfer Lengthが0歳であるときに、RとWのどちらかか両方が1であるかもしれませんが、Expected Data Transfer Length、そして/または、Bidirectional Read Expected Data Transfer Lengthが0歳(すなわち、何らかのデータ転送が予想されるとき、転送方向はR、そして/または、Wビットによって示される)でないときに、それらはともに0であるはずがありません。
10.3.2. CmdSN - Command Sequence Number
10.3.2. CmdSN--コマンド・シーケンス番号
Enables ordered delivery across multiple connections in a single session.
ただ一つのセッションにおける複数の接続の向こう側に命令された配送を可能にします。
10.3.3. ExpStatSN
10.3.3. ExpStatSN
Command responses up to ExpStatSN-1 (mod 2**32) have been received (acknowledges status) on the connection.
接続のときにExpStatSN-1(モッズ風の2**32)までのコマンド応答を受けました(状態を承認します)。
Satran, et al. Standards Track [Page 120] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[120ページ]。
10.3.4. Expected Data Transfer Length
10.3.4. 予想されたデータ転送の長さ
For unidirectional operations, the Expected Data Transfer Length field contains the number of bytes of data involved in this SCSI operation. For a unidirectional write operation (W flag set to 1 and R flag set to 0), the initiator uses this field to specify the number of bytes of data it expects to transfer for this operation. For a unidirectional read operation (W flag set to 0 and R flag set to 1), the initiator uses this field to specify the number of bytes of data it expects the target to transfer to the initiator. It corresponds to the SAM2 byte count.
単方向の操作のために、Expected Data Transfer Length分野はこのSCSI操作にかかわるデータのバイト数を含んでいます。 単方向、操作(W旗は1にセットしました、そして、R旗は0にセットした)、創始者用途にこの分野を書いて、それがこの操作のために移すと予想するデータのバイト数を指定してください。 単方向、操作(W旗は0にセットしました、そして、R旗は1にセットした)、創始者用途にこの分野を読み込んで、創始者に移すそれが目標を予想するデータのバイト数を指定してください。 それはSAM2バイト・カウントに対応しています。
For bidirectional operations (both R and W flags are set to 1), this field contains the number of data bytes involved in the write transfer. For bidirectional operations, an additional header segment MUST be present in the header sequence that indicates the Bidirectional Read Expected Data Transfer Length. The Expected Data Transfer Length field and the Bidirectional Read Expected Data Transfer Length field correspond to the SAM2 byte count
双方向の操作(RとW旗の両方が1に設定される)のために、この分野が中でかかわったデータ・バイトの数を含んでいる、転送を書いてください。 双方向の操作のために、追加ヘッダー・セグメントはBidirectional Read Expected Data Transfer Lengthを示すヘッダー系列で存在していなければなりません。 Expected Data Transfer Length分野とBidirectional Read Expected Data Transfer Length分野はSAM2バイト・カウントに対応しています。
If the Expected Data Transfer Length for a write and the length of the immediate data part that follows the command (if any) are the same, then no more data PDUs are expected to follow. In this case, the F bit MUST be set to 1.
aのためのExpected Data Transfer Lengthが書くか、そして、コマンド(もしあれば)に続く即値データ部分の長さが同じである、そして、それ以上のデータPDUsが全く続くと予想されません。 この場合、Fビットを1に設定しなければなりません。
If the Expected Data Transfer Length is higher than the FirstBurstLength (the negotiated maximum amount of unsolicited data the target will accept), the initiator MUST send the maximum amount of unsolicited data OR ONLY the immediate data, if any.
Expected Data Transfer LengthがFirstBurstLength(目標が受け入れる求められていないデータの交渉された最大の量)より高いなら、創始者はもしあれば最大の量の求められていないデータORに即値データだけを送らなければなりません。
Upon completion of a data transfer, the target informs the initiator (through residual counts) of how many bytes were actually processed (sent and/or received) by the target.
データ転送の完成のときに、いくつのバイトが実際に目標によって処理されたかについて(送る、そして/または、受け取ります)目標は創始者(残りのカウントによる)に知らせます。
10.3.5. CDB - SCSI Command Descriptor Block
10.3.5. CDB--SCSIコマンド記述子ブロック
There are 16 bytes in the CDB field to accommodate the commonly used CDBs. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS MUST be used to contain the CDB spillover.
一般的に使用されたCDBsを収容するために、16バイトがCDB分野にあります。 CDBが16バイトより大きいときはいつも、CDBあふれ出しを含むのにExtended CDB AHSを使用しなければなりません。
10.3.6. Data Segment - Command Data
10.3.6. データ・セグメント--コマンドデータ
Some SCSI commands require additional parameter data to accompany the SCSI command. This data may be placed beyond the boundary of the iSCSI header in a data segment. Alternatively, user data (e.g., from a WRITE operation) can be placed in the data segment (both cases are
いくつかのSCSIコマンドが、SCSIコマンドに伴うために追加パラメタデータを必要とします。 このデータはiSCSIヘッダーの境界を超えてデータ・セグメントに置かれるかもしれません。 あるいはまた、利用者データ(例えば、WRITE操作からの)をデータ・セグメントに置くことができる、(両方のケースはそうです。
Satran, et al. Standards Track [Page 121] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[121ページ]。
referred to as immediate data). These data are governed by the rules for solicited vs. unsolicited data outlined in Section 3.2.4.2 Data Transfer Overview.
即値データと呼ばれる、) これらのデータはセクション3.2.4に概説された求められていないデータに対して請求された.2Data Transfer Overviewのために規則で支配されます。
10.4. SCSI Response
10.4. SCSI応答
The format of the SCSI Response PDU is:
SCSI Response PDUの形式は以下の通りです。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x21 |1|. .|o|u|O|U|.| Response | Status |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| SNACK Tag or Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| ExpDataSN or Reserved |
+---------------+---------------+---------------+---------------+
40| Bidirectional Read Residual Count or Reserved |
+---------------+---------------+---------------+---------------+
44| Residual Count or Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
/ Data Segment (Optional) /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0×21|1|. . | o|u|O|U|. | 応答| 状態| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| 予約されます。| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 軽食タグか予約されています。| +---------------+---------------+---------------+---------------+ 24| StatSN| +---------------+---------------+---------------+---------------+ 28| ExpCmdSN| +---------------+---------------+---------------+---------------+ 32| MaxCmdSN| +---------------+---------------+---------------+---------------+ 36| ExpDataSNか予約されています。| +---------------+---------------+---------------+---------------+ 40| 双方向の読書残りのカウントか予約されています。| +---------------+---------------+---------------+---------------+ 44| 残りのカウントか予約されています。| +---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+/データ・セグメントの(任意)の/+//+---------------+---------------+---------------+---------------+ | データダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
Satran, et al. Standards Track [Page 122] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[122ページ]。
10.4.1. Flags (byte 1)
10.4.1. 旗(バイト1)
bit 1-2 Reserved.
ビット1-2Reserved。
bit 3 - (o) set for Bidirectional Read Residual Overflow. In this
case, the Bidirectional Read Residual Count indicates the number
of bytes that were not transferred to the initiator because the
initiator's Expected Bidirectional Read Data Transfer Length was
not sufficient.
ビット3--(o)はBidirectional Read Residual Overflowのためにセットしました。 この場合、Bidirectional Read Residual Countは創始者のExpected Bidirectional Read Data Transfer Lengthが十分でなかったので創始者に移されなかったバイト数を示します。
bit 4 - (u) set for Bidirectional Read Residual Underflow. In this
case, the Bidirectional Read Residual Count indicates the number
of bytes that were not transferred to the initiator out of the
number of bytes expected to be transferred.
ビット4--(u) Bidirectional Read Residual Underflowには、セットしてください。 この場合、Bidirectional Read Residual Countは移されると予想されたバイト数から創始者に移されなかったバイト数を示します。
bit 5 - (O) set for Residual Overflow. In this case, the Residual
Count indicates the number of bytes that were not transferred
because the initiator's Expected Data Transfer Length was not
sufficient. For a bidirectional operation, the Residual Count
contains the residual for the write operation.
ビット5--(O) Residual Overflowには、セットしてください。 この場合、Residual Countは創始者のExpected Data Transfer Lengthが十分でなかったので移されなかったバイト数を示します。 双方向の操作のために、Residual Countが残差を含んでいる、操作を書いてください。
bit 6 - (U) set for Residual Underflow. In this case, the Residual
Count indicates the number of bytes that were not transferred out
of the number of bytes that were expected to be transferred. For
a bidirectional operation, the Residual Count contains the
residual for the write operation.
ビット6--(U) Residual Underflowには、セットしてください。 この場合、Residual Countは移されると予想されたバイト数から移されなかったバイト数を示します。 双方向の操作のために、Residual Countが残差を含んでいる、操作を書いてください。
bit 7 - (0) Reserved.
ビット7--(0) 予約されました。
Bits O and U and bits o and u are mutually exclusive (i.e., having both o and u or O and U set to 1 is a protocol error). For a response other than "Command Completed at Target", bits 3-6 MUST be 0.
ビットOとUとビットoとuは互いに唯一です(すなわち、oとuかOとUセットの両方を1まで持つのは、プロトコル誤りです)。 「目標に終了するコマンド」を除いた応答のために、ビット3-6は0でなければなりません。
10.4.2. Status
10.4.2. 状態
The Status field is used to report the SCSI status of the command (as specified in [SAM2]) and is only valid if the Response Code is Command Completed at target.
Status分野は、コマンド([SAM2]で指定されるように)のSCSI状態を報告するのに使用されて、Response Codeが目標のCommand Completedである場合にだけ有効です。
Satran, et al. Standards Track [Page 123] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[123ページ]。
Some of the status codes defined in [SAM2] are:
[SAM2]で定義されたステータスコードのいくつかは以下の通りです。
0x00 GOOD
0x02 CHECK CONDITION
0x08 BUSY
0x18 RESERVATION CONFLICT
0x28 TASK SET FULL
0x30 ACA ACTIVE
0x40 TASK ABORTED
0×00 利益0x02は状態0x08 アクティブな0×40タスクが中止した忙しい0×18予約闘争0x28のタスクセットの完全な0×30ACAをチェックします。
See [SAM2] for the complete list and definitions.
全リストと定義に関して[SAM2]を見てください。
If a SCSI device error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set), the target MUST wait until it receives a Data PDU with the F bit set in the last expected sequence before sending the Response PDU.
創始者からのデータがまだ予想されていますが(コマンドPDUはすべてのデータを含んだというわけではありません、そして、目標は最終的なビットSetでData PDUを受けていません)、SCSIデバイス誤りが検出されるなら、Response PDUを送る前に最後に予想された系列で設定されたFビットでData PDUを受けるまで、目標は待たなければなりません。
10.4.3. Response
10.4.3. 応答
This field contains the iSCSI service response.
この分野はiSCSIサービス応答を含んでいます。
iSCSI service response codes defined in this specification are:
この仕様に基づき定義されたiSCSIサービス応答コードは以下の通りです。
0x00 - Command Completed at Target
0x01 - Target Failure
0x80-0xff - Vendor specific
0×00--Target0x01のコマンドCompleted(0×80 0xffである状態でFailureを狙う)ベンダー特有です。
All other response codes are reserved.
他のすべての応答コードが予約されています。
The Response is used to report a Service Response. The mapping of the response code into a SCSI service response code value, if needed, is outside the scope of this document. However, in symbolic terms response value 0x00 maps to the SCSI service response (see [SAM2] and [SPC3]) of TASK COMPLETE or LINKED COMMAND COMPLETE. All other Response values map to the SCSI service response of SERVICE DELIVERY OR TARGET FAILURE.
Responseは、Service Responseを報告するのに使用されます。 必要であるなら、SCSIサービス応答コード値への応答コードに関するマッピングはこのドキュメントの範囲の外のそうです。 しかしながら、シンボリックな用語で、応答値0x00はTASK COMPLETEかLINKED COMMAND COMPLETEのサービス応答([SAM2]と[SPC3]を見る)をSCSIに写像します。 他のResponse値がSCSIに写像するすべてがSERVICE DELIVERY OR TARGET FAILUREの応答を修理します。
If a PDU that includes SCSI status (Response PDU or Data-In PDU including status) does not arrive before the session is terminated, the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE.
セッションが終えられる前にSCSI状態(応答PDUか状態を含む中のData PDU)を含んでいるPDUが到着しないなら、SCSIサービス応答はSERVICE DELIVERY OR TARGET FAILUREです。
A non-zero Response field indicates a failure to execute the command in which case the Status and Flag fields are undefined.
非ゼロResponse分野はコマンドを実行しないことを示します、その場合、StatusとFlag分野は未定義です。
Satran, et al. Standards Track [Page 124] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[124ページ]。
10.4.4. SNACK Tag
10.4.4. 軽食タグ
This field contains a copy of the SNACK Tag of the last SNACK Tag accepted by the target on the same connection and for the command for which the response is issued. Otherwise it is reserved and should be set to 0.
この分野は同じ接続での目標と応答が発行されるコマンドのために受け入れられた最後のSNACK TagのSNACK Tagのコピーを含んでいます。 さもなければ、それは、予約されていて、0に設定されるべきです。
After issuing a R-Data SNACK the initiator must discard any SCSI status unless contained in an SCSI Response PDU carrying the same SNACK Tag as the last issued R-Data SNACK for the SCSI command on the current connection.
R-データSNACKを発行した後に、SCSI Response PDUに含まれていない場合、創始者は、現在の接続のときにSCSIコマンドのための最後に発行されたR-データSNACKと同じSNACK Tagを運びながら、どんなSCSI状態も捨てなければなりません。
For a detailed discussion on R-Data SNACK see Section 10.16 SNACK Request.
R-データの詳細な論議に関しては、SNACKはセクション10.16 SNACK Requestを見ます。
10.4.5. Residual Count
10.4.5. 残りのカウント
The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set the residual count and initiators may use it when the response code is "completed at target" (even if the status returned is not GOOD). If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred.
Residual Count分野はUビットかOビットのどちらかが設定される場合で有効であるに違いありません。 どちらのビットも設定されないなら、Residual Count分野は予約されています。 目標は残りのカウントを設定するかもしれません、そして、応答コードが「目標に完成される」とき(返された状態がGOODでなくても)、創始者はそれを使用するかもしれません。 Oビットが設定されるなら、Residual Countは創始者のExpected Data Transfer Lengthが十分でなかったので移されなかったバイト数を示します。 Uビットが設定されるなら、Residual Countは移されると予想されたバイト数から移されなかったバイト数を示します。
10.4.6. Bidirectional Read Residual Count
10.4.6. 双方向の読書残りのカウント
The Bidirectional Read Residual Count field MUST be valid in the case where either the u bit or the o bit is set. If neither bit is set, the Bidirectional Read Residual Count field is reserved. Targets may set the Bidirectional Read Residual Count and initiators may use it when the response code is "completed at target". If the o bit is set, the Bidirectional Read Residual Count indicates the number of bytes that were not transferred to the initiator because the initiator's Expected Bidirectional Read Transfer Length was not sufficient. If the u bit is set, the Bidirectional Read Residual Count indicates the number of bytes that were not transferred to the initiator out of the number of bytes expected to be transferred.
Bidirectional Read Residual Count分野はuビットかoビットのどちらかが設定される場合で有効であるに違いありません。 どちらのビットも設定されないなら、Bidirectional Read Residual Count分野は予約されています。 目標はBidirectional Read Residual Countを設定するかもしれません、そして、応答コードが「目標に完成される」とき、創始者はそれを使用するかもしれません。 oビットが設定されるなら、Bidirectional Read Residual Countは創始者のExpected Bidirectional Read Transfer Lengthが十分でなかったので創始者に移されなかったバイト数を示します。 uビットが設定されるなら、Bidirectional Read Residual Countは移されると予想されたバイト数から創始者に移されなかったバイト数を示します。
10.4.7. Data Segment - Sense and Response Data Segment
10.4.7. データ・セグメント--感覚と応答データ・セグメント
iSCSI targets MUST support and enable autosense. If Status is CHECK CONDITION (0x02), then the Data Segment MUST contain sense data for the failed command.
iSCSI目標は、autosenseをサポートして、有効にしなければなりません。 StatusがCHECK CONDITION(0×02)であるなら、Data Segmentは失敗したコマンドのためのセンス・データを含まなければなりません。
Satran, et al. Standards Track [Page 125] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[125ページ]。
For some iSCSI responses, the response data segment MAY contain some response related information, (e.g., for a target failure, it may contain a vendor specific detailed description of the failure).
いくつかのiSCSI応答のために、応答データ・セグメントが何らかの応答関連情報を含むかもしれない、(例えば、目標の故障によって、それは失敗のベンダーの特定の詳述を含むかもしれません。)
If the DataSegmentLength is not 0, the format of the Data Segment is as follows:
DataSegmentLengthが0歳でないなら、Data Segmentの形式は以下の通りです:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|SenseLength | Sense Data |
+---------------+---------------+---------------+---------------+
x/ Sense Data /
+---------------+---------------+---------------+---------------+
y/ Response Data /
/ /
+---------------+---------------+---------------+---------------+
z|
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|SenseLength| センス・データ| +---------------+---------------+---------------+---------------+ x/感覚Data/+---------------+---------------+---------------+---------------+ y/応答Data///+---------------+---------------+---------------+---------------+ z|
10.4.7.1. SenseLength
10.4.7.1. SenseLength
Length of Sense Data.
センス・データの長さ。
10.4.7.2. Sense Data
10.4.7.2. センス・データ
The Sense Data contains detailed information about a check condition and [SPC3] specifies the format and content of the Sense Data.
Sense Dataはチェック状態の詳細な情報を含んでいます、そして、[SPC3]はSense Dataの形式と内容を指定します。
Certain iSCSI conditions result in the command being terminated at the target (response Command Completed at Target) with a SCSI Check Condition Status as outlined in the next table:
あるiSCSI状態は次のテーブルに概説されているようにSCSI Check Condition Statusがある目標(Targetの応答Command Completed)で終えられるコマンドをもたらします:
Satran, et al. Standards Track [Page 126] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[126ページ]。
+--------------------------+----------+---------------------------+ | iSCSI Condition |Sense | Additional Sense Code & | | |Key | Qualifier | +--------------------------+----------+---------------------------+ | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 0x0c | | data |Command-0B| Write Error | +--------------------------+----------+---------------------------+ | Incorrect amount of data |Aborted | ASC = 0x0c ASCQ = 0x0d | | |Command-0B| Write Error | +--------------------------+----------+---------------------------+ | Protocol Service CRC |Aborted | ASC = 0x47 ASCQ = 0x05 | | error |Command-0B| CRC Error Detected | +--------------------------+----------+---------------------------+ | SNACK rejected |Aborted | ASC = 0x11 ASCQ = 0x13 | | |Command-0B| Read Error | +--------------------------+----------+---------------------------+
+--------------------------+----------+---------------------------+ | iSCSI状態|感覚| 追加センス・コード| | |キー| 資格を与える人| +--------------------------+----------+---------------------------+ | 予期していなさ、求められていませんさ|中止されます。| ASC=0x0c ASCQは0x0cと等しいです。| | データ|コマンド-0B| 誤りを書いてください。| +--------------------------+----------+---------------------------+ | 不正確なデータ量|中止されます。| ASC=0x0c ASCQは0x0dと等しいです。| | |コマンド-0B| 誤りを書いてください。| +--------------------------+----------+---------------------------+ | プロトコルサービスCRC|中止されます。| 0×47ASC=ASCQ=0×05| | 誤り|コマンド-0B| 検出されたCRC誤り| +--------------------------+----------+---------------------------+ | 拒絶されたSNACK|中止されます。| 0×11ASC=ASCQ=0×13| | |コマンド-0B| 誤りを読んでください。| +--------------------------+----------+---------------------------+
The target reports the "Incorrect amount of data" condition if during data output the total data length to output is greater than FirstBurstLength and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurstLength. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested.
出力する総データの長さがデータ出力の間、FirstBurstLengthと創始者が求められていない非即値データを送ったより大きいなら、目標は「不正確なデータ量」状態を報告しますが、求められていないデータの総量はFirstBurstLengthと異なっています。 目標は、R2Tへの回答が量に合っていないのでデータ量が発信したときの同じ誤りが要求されていると報告します。
10.4.8. ExpDataSN
10.4.8. ExpDataSN
The number of R2T and Data-In (read) PDUs the target has sent for the command.
目標がコマンドのために送ったR2Tと中のData(読む)PDUsの数。
This field MUST be 0 if the response code is not Command Completed at Target or the target sent no Data-In PDUs for the command.
応答コードがTargetのCommand Completedでない目標がコマンドのために中のData PDUsを全く送らなかったなら、この分野は0であるに違いありません。
10.4.9. StatSN - Status Sequence Number
10.4.9. StatSN--状態一連番号
StatSN is a Sequence Number that the target iSCSI layer generates per connection and that in turn, enables the initiator to acknowledge status reception. StatSN is incremented by 1 for every response/status sent on a connection except for responses sent as a result of a retry or SNACK. In the case of responses sent due to a retransmission request, the StatSN MUST be the same as the first time the PDU was sent unless the connection has since been restarted.
StatSNは、順番に目標iSCSI層が接続単位で生成するSequence Numberとそれであり、創始者が状態レセプションを承認するのを可能にします。 StatSNは再試行の結果、送られた応答以外の接続に送られたあらゆる応答/状態かSNACKのために1つ増加されます。 「再-トランスミッション」要求のため送られた応答の場合では、StatSNは以来接続を再出発していない場合1回目にPDUを送ったのと同じであるに違いありません。
Satran, et al. Standards Track [Page 127] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[127ページ]。
10.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator
10.4.10. ExpCmdSN--このInitiatorからの次のExpected CmdSN
ExpCmdSN is a Sequence Number that the target iSCSI returns to the initiator to acknowledge command reception. It is used to update a local variable with the same name. An ExpCmdSN equal to MaxCmdSN+1 indicates that the target cannot accept new commands.
ExpCmdSNは目標iSCSIがコマンドレセプションを承認するために創始者に返すSequence Numberです。 それは、同じ名前で局所変数をアップデートするのに使用されます。 MaxCmdSN+1と等しいExpCmdSNは、目標が新しいコマンドを受け入れることができないのを示します。
10.4.11. MaxCmdSN - Maximum CmdSN from this Initiator
10.4.11. MaxCmdSN--このInitiatorからの最大のCmdSN
MaxCmdSN is a Sequence Number that the target iSCSI returns to the initiator to indicate the maximum CmdSN the initiator can send. It is used to update a local variable with the same name. If MaxCmdSN is equal to ExpCmdSN-1, this indicates to the initiator that the target cannot receive any additional commands. When MaxCmdSN changes at the target while the target has no pending PDUs to convey this information to the initiator, it MUST generate a NOP-IN to carry the new MaxCmdSN.
MaxCmdSNは目標iSCSIが創始者が送ることができる最大のCmdSNを示すために創始者に返すSequence Numberです。 それは、同じ名前で局所変数をアップデートするのに使用されます。 MaxCmdSNがExpCmdSN-1と等しいなら、これは、目標が少しの追加コマンドも受け取ることができないのを創始者に示します。 目標にはこの情報を創始者に伝えるどんな未定のPDUsもありませんが、MaxCmdSNが目標で変化すると、それは、新しいMaxCmdSNを運ぶためにNOP-INを生成しなければなりません。
Satran, et al. Standards Track [Page 128] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[128ページ]。
10.5. Task Management Function Request
10.5. タスク管理機能要求
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|I| 0x02 |1| Function | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| Logical Unit Number (LUN) or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Referenced Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32| RefCmdSN or Reserved |
+---------------+---------------+---------------+---------------+
36| ExpDataSN or Reserved |
+---------------+---------------+---------------+---------------+
40/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | 私| 0×02|1| 機能| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| 論理ユニット番号(LUN)か予約されています。| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 参照をつけられたタスクタグか0xffffffff| +---------------+---------------+---------------+---------------+ 24| CmdSN| +---------------+---------------+---------------+---------------+ 28| ExpStatSN| +---------------+---------------+---------------+---------------+ 32| RefCmdSNか予約されています。| +---------------+---------------+---------------+---------------+ 36| ExpDataSNか予約されています。| +---------------+---------------+---------------+---------------+ 40/予約された/+//+---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
10.5.1. Function
10.5.1. 機能
The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks). The Task Management function codes are listed below. For a more detailed description of SCSI task management, see [SAM2].
Task Management機能は明らかに1Tasks(SCSIとiSCSIタスク)の実行を制御する方法を創始者に提供します。 Task Management機能コードは以下に記載されています。 SCSIタスク管理の、より詳細な記述に関しては、[SAM2]を見てください。
1 - ABORT TASK - aborts the task identified by the Referenced Task
Tag field.
1--ABORT TASK--タスクがReferenced Task Tag分野で特定したアボート。
2 - ABORT TASK SET - aborts all Tasks issued via this session on the
logical unit.
2(ABORT TASK SET)は論理装置のこのセッションで発行されたすべてのTasksを中止します。
3 - CLEAR ACA - clears the Auto Contingent Allegiance condition.
3(CLEAR ACA)はAuto Contingent Allegiance状態をクリアします。
Satran, et al. Standards Track [Page 129] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[129ページ]。
4 - CLEAR TASK SET - aborts all Tasks in the appropriate task set as
defined by the TST field in the Control mode page (see [SPC3]).
4(CLEAR TASK SET)はTST分野によってControlモードページで定義されるように適切なタスクセットですべてのTasksを中止します([SPC3]を見てください)。
5 - LOGICAL UNIT RESET
5--論理装置リセット
6 - TARGET WARM RESET
6--目標ウォームリセット
7 - TARGET COLD RESET
7--目標コールドリセット
8 - TASK REASSIGN - reassigns connection allegiance for the task
identified by the Referenced Task Tag field to this connection,
thus resuming the iSCSI exchanges for the task.
8(TASK REASSIGN)はReferenced Task Tag分野によってこの接続に特定されたタスクに関する接続忠誠を再選任します、その結果、タスクへのiSCSI交換を再開します。
For all these functions, the Task Management function response MUST be returned as detailed in Section 10.6 Task Management Function Response. All these functions apply to the referenced tasks regardless of whether they are proper SCSI tasks or tagged iSCSI operations. Task management requests must act on all the commands from the same session having a CmdSN lower than the task management CmdSN. LOGICAL UNIT RESET, TARGET WARM RESET and TARGET COLD RESET may affect commands from other sessions or commands from the same session with CmdSN equal or exceeding CmdSN.
これらのすべての機能において、セクション10.6 Task Management Function Responseで同じくらい詳細な状態でTask Management機能応答を返さなければなりません。 これらのすべての機能がそれらが適切なSCSIタスクかタグ付けをされたiSCSI操作であることにかかわらず参照をつけられたタスクに適用されます。 タスク管理要求はCmdSNをタスク管理CmdSNより低くする同じセッションからすべてのコマンドに影響しなければなりません。 LOGICAL UNIT RESET、TARGET WARM RESET、およびTARGET COLD RESETは他のセッションかコマンドからCmdSNの等しいか上回っているCmdSNとの同じセッションからコマンドに影響するかもしれません。
If the task management request is marked for immediate delivery, it must be considered immediately for execution, but the operations involved (all or part of them) may be postponed to allow the target to receive all relevant tasks. According to [SAM2], for all the tasks covered by the Task Management response (i.e., with CmdSN lower than the task management command CmdSN) but except the Task Management response to a TASK REASSIGN, additional responses MUST NOT be delivered to the SCSI layer after the Task Management response. The iSCSI initiator MAY deliver to the SCSI layer all responses received before the Task Management response (i.e., it is a matter of implementation if the SCSI responses, received before the Task Management response but after the task management request was issued, are delivered to the SCSI layer by the iSCSI layer in the initiator). The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI initiator after the Task Management response except for a task covered by a TASK REASSIGN.
タスク管理要求が即座の配送のためにマークされるなら、すぐ実行のためにそれを考えなければなりませんが、かかわった操作(それらのすべてか一部)は、目標がすべての関連タスクを受け取るのを許容するために延期されるかもしれません。 [SAM2]に従って、すべてに関して、タスクを、Task Management応答(すなわち、CmdSNがタスク管理コマンドCmdSNより低い)でカバーされますが、TASK REASSIGNへのTask Management応答、追加応答以外に、Task Management応答の後にSCSI層に提供してはいけません。 iSCSI創始者はTask Management応答の前に受けられたすべての応答をSCSI層に提供するかもしれません(すなわち、Task Management応答の前にもかかわらず、タスク管理要求が出された後を除いて、受けられたSCSI応答が創始者のiSCSI層のそばでSCSI層に提供されるかどうかが、実装の問題です)。 iSCSI目標は、タスク管理機能でカバーされたタスクのための応答が全くTASK REASSIGNでカバーされたタスク以外のTask Management応答の後にiSCSI創始者に提供されないのを確実にしなければなりません。
For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to respond to all valid target transfer tags (received via R2T, Text Response, NOP-In, or SCSI Data-In PDUs) related to the affected task set, even after issuing the task management request. The issuing initiator SHOULD however terminate (i.e., by setting the F-bit to 1) these response sequences as quickly as possible. The target on its part MUST wait for responses on all affected target
ABORT TASK SETとCLEAR TASK SETに関しては、影響を受けるタスクセットに関連するすべての有効な目標転送タグ(R2T、Text Response、中のNOP、または中のSCSI Data PDUsを通して、受信する)と、タスク管理要求を出した後にさえ、発行している創始者は、応じ続けなければなりません。 しかしながら、発行している創始者SHOULDはできるだけ急速にこれらの応答系列を終えます(すなわち、F-ビットを1に設定することによって)。 部分の上の目標はすべての影響を受ける目標の上で応答を待たなければなりません。
Satran, et al. Standards Track [Page 130] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[130ページ]。
transfer tags before acting on either of these two task management requests. In case all or part of the response sequence is not received (due to digest errors) for a valid TTT, the target MAY treat it as a case of within-command error recovery class (see Section 6.1.4.1 Recovery Within-command) if it is supporting ErrorRecoveryLevel >= 1, or alternatively may drop the connection to complete the requested task set function.
これらの2つのタスク管理要求のどちらかに影響する前に、タグを移してください。 応答系列のすべてか一部が有効なTTTのために受け取られないといけないので(ダイジェスト誤りのため)、ErrorRecoveryLevel>が=1であるとサポートしているか、またはあるいはまた、要求されたタスクセット機能を完成するために接続を下げるかもしれないなら、目標はコマンドの中のエラー回復のクラス(セクション6.1.4.1Recovery Within-コマンドを見る)に関するケースとしてそれを扱うかもしれません。
If an ABORT TASK is issued for a task created by an immediate command then RefCmdSN MUST be that of the Task Management request itself (i.e., CmdSN and RefCmdSN are equal); otherwise RefCmdSN MUST be set to the CmdSN of the task to be aborted (lower than CmdSN).
ABORT TASKが即座のコマンドで作成されたタスクのために発行されるなら、RefCmdSNはTask Management要求自体のものであるに違いありません(すなわち、CmdSNとRefCmdSNは等しいです)。 さもなければ、RefCmdSNは中止されるように(CmdSNより低い)タスクのCmdSNに用意ができなければなりません。
If the connection is still active (it is not undergoing an implicit or explicit logout), ABORT TASK MUST be issued on the same connection to which the task to be aborted is allegiant at the time the Task Management Request is issued. If the connection is implicitly or explicitly logged out (i.e., no other request will be issued on the failing connection and no other response will be received on the failing connection), then an ABORT TASK function request may be issued on another connection. This Task Management request will then establish a new allegiance for the command to be aborted as well as abort it (i.e., the task to be aborted will not have to be retried or reassigned, and its status, if issued but not acknowledged, will be reissued followed by the Task Management response).
接続がまだ活発である、(受けていない、暗黙か明白である、ログアウト、)、ABORT TASK MUST、Task Management Requestが発行されるとき中止されるべきタスクがallegiantであるのと同じ接続のときに、発行されてください。 接続がそれとなくか明らかにログアウトされるなら(失敗接続のときにすなわち、他の要求を全く出さないでしょう、そして、失敗接続のときに他の応答を全く受けないでしょう)、ABORT TASK機能要求は別の接続のときに出されるかもしれません。 このTask Management要求は、次に、中止されるべきコマンドに関する新たな忠誠を確立して、それを中止するでしょう(すなわち、中止されるべきタスクは、再試行される必要はありませんし、また再選任される必要はないでしょう、そして、Task Management応答があとに続いていて、発行されますが、承認されないと、状態は再発行されるでしょう)。
At the target an ABORT TASK function MUST NOT be executed on a Task Management request; such a request MUST result in Task Management response of "Function rejected".
目標では、Task Management要求のときにABORT TASK機能を実行してはいけません。 そのような要求は「拒絶された機能」のTask Management応答をもたらさなければなりません。
For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2].
LOGICAL UNIT RESET機能のために、目標は[SAM2]にLogical Unit Reset機能によって書き取られるように反応しなければなりません。
The implementation of the TARGET WARM RESET function and the TARGET COLD RESET function is OPTIONAL and when implemented, should act as described below. The TARGET WARM RESET is also subject to SCSI access controls on the requesting initiator as defined in [SPC3]. When authorization fails at the target, the appropriate response as described in Section 10.6 Task Management Function Response MUST be returned by the target. The TARGET COLD RESET function is not subject to SCSI access controls, but its execution privileges may be managed by iSCSI mechanisms such as login authentication.
TARGET WARM RESET機能とTARGET COLD RESET機能の実現はOPTIONALです、そして、実行されると、以下で説明されるように行動するべきです。 TARGET WARM RESETはそうです、また、SCSIアクセスを条件として、要求のときに、[SPC3]で定義される創始者は制御しています。 認可が目標で失敗すると、目標はセクション10.6 Task Management Function Responseで説明される適切な応答を返さなければなりません。 TARGET COLD RESET機能はSCSIアクセス管理を受けることがありませんが、実行特権はログイン認証などのiSCSIメカニズムによって管理されるかもしれません。
When executing the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations on all Logical Units known by the issuing initiator. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators logged in with the servicing SCSI target port.
TARGET WARM RESETとTARGET COLD RESET機能を実行するとき、目標は発行している創始者によって知られていたすべてのLogical Unitsにおけるすべての未定の操作を中止します。 両方の機能は[SAM2]によって指定されたTarget Reset機能に同等です。 それらは整備点検SCSI目標ポートでログインされた多くの他の創始者に影響できます。
Satran, et al. Standards Track [Page 131] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[131ページ]。
The target MUST treat the TARGET COLD RESET function additionally as a power on event, thus terminating all of its TCP connections to all initiators (all sessions are terminated). For this reason, the Service Response (defined by [SAM2]) for this SCSI task management function may not be reliably delivered to the issuing initiator port.
目標は出来事でさらに、TARGET COLD RESET機能をパワーとして扱わなければなりません、その結果、すべての創始者とのTCP接続を皆、終えます(すべてのセッションが終えられます)。 この理由で、このSCSIタスク管理機能のためのService Response([SAM2]によって定義される)は発行している創始者ポートに確かに届けられないかもしれません。
For the TASK REASSIGN function, the target should reassign the connection allegiance to this new connection (and thus resume iSCSI exchanges for the task). TASK REASSIGN MUST ONLY be received by the target after the connection on which the command was previously executing has been successfully logged-out. The Task Management response MUST be issued before the reassignment becomes effective. For additional usage semantics see Section 6.2 Retry and Reassign in Recovery.
TASK REASSIGN機能のために、目標はこの新しい接続に接続忠誠を再選任するはずです(その結果、タスクへのiSCSI交換を再開してください)。 TASK REASSIGN MUST ONLY、目標で、首尾よく、コマンドが以前に実行されていた接続をログアウトした後に受け取ってください。 再割当てが有効になる前にTask Management応答を発行しなければなりません。 追加用法意味論に関しては、セクション6.2 RetryとRecoveryのReassignを見てください。
At the target a TASK REASSIGN function request MUST NOT be executed to reassign the connection allegiance of a Task Management function request, an active text negotiation task, or a Logout task; such a request MUST result in Task Management response of "Function rejected".
目標では、Task Management機能要求、アクティブなテキスト交渉タスク、またはLogoutタスクの接続忠誠を再選任するためにTASK REASSIGN機能要求を実行してはいけません。 そのような要求は「拒絶された機能」のTask Management応答をもたらさなければなりません。
TASK REASSIGN MUST be issued as an immediate command.
TASK REASSIGN MUST、即座のコマンドとして、発行されてください。
10.5.2. TotalAHSLength and DataSegmentLength
10.5.2. TotalAHSLengthとDataSegmentLength
For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
このPDU TotalAHSLengthとDataSegmentLengthが0歳であるに違いないので。
10.5.3. LUN
10.5.3. LUN
This field is required for functions that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all others.
この分野は、特定のLU(ABORT TASK、CLEAR TASK SET、ABORT TASK SET、CLEAR ACA、LOGICAL UNIT RESET)を記述する機能に必要であり、すべての他のもので予約されます。
10.5.4. Referenced Task Tag
10.5.4. 参照をつけられたタスクタグ
The Initiator Task Tag of the task to be aborted for the ABORT TASK function or reassigned for the TASK REASSIGN function. For all the other functions this field MUST be set to the reserved value 0xffffffff.
ABORT TASK機能のために中止されるべきであるか、またはTASK REASSIGN機能のために再選任されるべきタスクのInitiator Task Tag。 他のすべての機能において、予約された値の0xffffffffにこの分野を設定しなければなりません。
10.5.5. RefCmdSN
10.5.5. RefCmdSN
If an ABORT TASK is issued for a task created by an immediate command then RefCmdSN MUST be that of the Task Management request itself (i.e., CmdSN and RefCmdSN are equal).
ABORT TASKが即座のコマンドで作成されたタスクのために発行されるなら、RefCmdSNはTask Management要求自体のものであるに違いありません(すなわち、CmdSNとRefCmdSNは等しいです)。
Satran, et al. Standards Track [Page 132] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[132ページ]。
For an ABORT TASK of a task created by non-immediate command RefCmdSN MUST be set to the CmdSN of the task identified by the Referenced Task Tag field. Targets must use this field as described in section 10.6.1 when the task identified by the Referenced Task Tag field is not with the target.
非即座のコマンドで作成されたタスクのABORT TASKにおいて、RefCmdSNはReferenced Task Tag分野によって特定されたタスクのCmdSNに用意ができなければなりません。 目標はReferenced Task Tag分野によって特定されたタスクが目標でないとき、セクション10.6.1で説明されるようにこの分野を使用しなければなりません。
Otherwise, this field is reserved.
さもなければ、この分野は予約されています。
10.5.6. ExpDataSN
10.5.6. ExpDataSN
For recovery purposes, the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command, this number is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirectional command, ExpDataSN will contain an updated data acknowledgement reference number or the value 0; the latter indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-In PDUs (if any) starting with the data acknowledgement reference number. The number of retransmitted PDUs may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSegmentLength in the reassignment. The target MAY also send no more Data-In PDUs if all data has been acknowledged.
回復目的のために、iSCSI目標と創始者はデータ承認参照番号を維持します--創始者による不承認の最初の入力DataSN番号。 新しいコマンドを発行するとき、この数は0に設定されます。 機能がTASK REASSIGNであるなら、ExpDataSNはアップデートされたデータ承認参照番号か値0を含むでしょう。(TASK REASSIGNは以前に発行されたReadかBidirectionalコマンドに関する新たな接続忠誠を確立します)。 データ承認参照番号が変わりがないのを示す後者。 創始者はそれが承諾しなかった前の実行からどんなデータPDUsも捨てなければなりません、そして、データ承認参照番号から始まって、目標はすべての中のData PDUs(もしあれば)を伝えなければなりません。 オリジナルのトランスミッション依存と同じくらいがオンであったなら、再割当てにMaxRecvDataSegmentLengthにおける変化があったなら、再送されたPDUsの数はそうするかもしれません。 また、すべてのデータが承認されたなら、目標はそれ以上の中のData PDUsを全く送らないかもしれません。
The value of ExpDataSN MUST be 0 or higher than the DataSN of the last acknowledged Data-In PDU, but not larger than DataSN+1 of the last Data-In PDU sent by the target. Any other value MUST be ignored by the target.
ExpDataSNの値は目標によって送られた中の最後のDataのDataSN+1より大きいPDUではなく、最後に承認された中のData PDUのDataSNより0以上でなければなりません。 目標でいかなる他の値も無視しなければなりません。
For other functions this field is reserved.
他の機能において、この分野は予約されています。
Satran, et al. Standards Track [Page 133] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[133ページ]。
10.6. Task Management Function Response
10.6. タスク管理機能応答
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x22 |1| Reserved | Response | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------------------------------------------------------+
8/ Reserved /
/ /
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0×22|1| 予約されます。| 応答| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------------------------------------------------------+ 8/予約された///+---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 予約されます。| +---------------+---------------+---------------+---------------+ 24| StatSN| +---------------+---------------+---------------+---------------+ 28| ExpCmdSN| +---------------+---------------+---------------+---------------+ 32| MaxCmdSN| +---------------+---------------+---------------+---------------+ 36/予約された/+//+---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET COLD RESET, TARGET WARM RESET and TASK REASSIGN, the target performs the requested Task Management function and sends a Task Management response back to the initiator. For TASK REASSIGN, the new connection allegiance MUST ONLY become effective at the target after the target issues the Task Management Response.
機能のABORT TASK、ABORT TASK SET、CLEAR ACA、CLEAR TASK SET、LOGICAL UNIT RESET、TARGET COLD RESET、TARGET WARM RESET、およびTASK REASSIGNのために、目標は、要求されたTask Management機能を実行して、Task Management応答を創始者に送り返します。 TASK REASSIGNに関しては、目標がTask Management Responseを発行した後に新たな接続忠誠は目標で有効になるだけでよいです。
10.6.1. Response
10.6.1. 応答
The target provides a Response, which may take on the following values:
目標はResponseを提供します:(Responseは以下の値を呈するかもしれません)。
a) 0 - Function complete.
b) 1 - Task does not exist.
c) 2 - LUN does not exist.
d) 3 - Task still allegiant.
e) 4 - Task allegiance reassignment not supported.
a) 0--機能は. b)を完成します。 1--タスクが存在していない、c) 2--LUNが存在していない、d) 3--まだallegiant. eに仕事を課してください、) 4--支持されなかった忠誠再割当てに仕事を課してください。
Satran, et al. Standards Track [Page 134] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[134ページ]。
f) 5 - Task management function not supported.
g) 6 - Function authorization failed.
h) 255 - Function rejected.
f) 5--タスク管理機能は. g)を支持しませんでした。 6--機能認可は. h)に失敗しました。 拒絶された255--機能。
All other values are reserved.
他のすべての値が予約されています。
For a discussion on usage of response codes 3 and 4, see Section 6.2.2 Allegiance Reassignment.
応答コード3と4の用法についての議論に関しては、セクション6.2.2Allegiance Reassignmentを見てください。
For the TARGET COLD RESET and TARGET WARM RESET functions, the target cancels all pending operations across all Logical Units known to the issuing initiator. For the TARGET COLD RESET function, the target MUST then close all of its TCP connections to all initiators (terminates all sessions).
TARGET COLD RESETとTARGET WARM RESET機能のために、目標は発行している創始者にとって知られているすべてのLogical Unitsの向こう側にすべての未定の操作を中止します。 そして、TARGET COLD RESET機能のために、目標はTCP接続のすべてをすべての創始者に閉じなければなりません(すべてのセッションに、終えます)。
The mapping of the response code into a SCSI service response code value, if needed, is outside the scope of this document. However, in symbolic terms Response values 0 and 1 map to the SCSI service response of FUNCTION COMPLETE. All other Response values map to the SCSI service response of FUNCTION REJECTED. If a Task Management function response PDU does not arrive before the session is terminated, the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE.
必要であるなら、SCSIサービス応答コード値への応答コードに関するマッピングはこのドキュメントの範囲の外のそうです。 しかしながら、Response値0と1がSCSIに写像するシンボリックな用語で、FUNCTION COMPLETEの応答を修理してください。 他のResponse値がSCSIに写像するすべてがFUNCTION REJECTEDの応答を修理します。 Task Management機能応答であるなら、セッションが終えられる前にPDUは到着しないで、SCSIサービス応答はSERVICE DELIVERY OR TARGET FAILUREです。
The response to ABORT TASK SET and CLEAR TASK SET MUST only be issued by the target after all of the commands affected have been received by the target, the corresponding task management functions have been executed by the SCSI target, and the delivery of all responses delivered until the task management function completion have been confirmed (acknowledged through ExpStatSN) by the initiator on all connections of this session. For the exact timeline of events, refer to Section 10.6.2 Task Management Actions on Task Sets.
目標で影響を受けるコマンドのすべてを受け取った後に目標でABORT TASK SETとCLEAR TASK SET MUSTへの応答を発行するだけであって、対応するタスク管理機能はSCSI目標、およびこのセッションのすべての接続のときに創始者によって確認されて(ExpStatSNを通して承認されます)、タスク管理機能完成が渡すまで応答が渡したすべての配送で実行されました。 出来事の正確なスケジュールについて、Task Setsの上のセクション10.6.2Task Management Actionsを参照してください。
For the ABORT TASK function,
ABORT TASK機能のために
a) If the Referenced Task Tag identifies a valid task leading to
a successful termination, then targets must return the
"Function complete" response.
b) If the Referenced Task Tag does not identify an existing task,
but if the CmdSN indicated by the RefCmdSN field in the Task
Management function request is within the valid CmdSN window
and less than the CmdSN of the Task Management function
request itself, then targets must consider the CmdSN received
and return the "Function complete" response.
a) Referenced Task Tagがうまくいっている終了につながる有効なタスクを特定するなら、目標は「機能完全な」応答に. b)を返さなければなりません。 Task Management機能要求におけるRefCmdSN分野によって示されたCmdSNがReferenced Task Tagが既存のタスクを特定しませんが、有効なCmdSNの窓の中にあって、Task Management機能要求自体のCmdSNより少ないなら、目標は、CmdSNが「機能完全な」応答を受けて、返すと考えなければなりません。
Satran, et al. Standards Track [Page 135] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[135ページ]。
c) If the Referenced Task Tag does not identify an existing task
and if the CmdSN indicated by the RefCmdSN field in the Task
Management function request is outside the valid CmdSN window,
then targets must return the "Task does not exist" response.
c) Referenced Task Tagが既存のタスクを特定しないで、有効なCmdSNの窓の外にTask Management機能要求におけるRefCmdSN分野によって示されたCmdSNがあるなら、目標は「タスクは存在していない」という応答を返さなければなりません。
10.6.2. Task Management Actions on Task Sets
10.6.2. タスクセットへのタスク管理動作
The execution of ABORT TASK SET and CLEAR TASK SET Task Management function requests consists of the following sequence of events in the specified order on each of the entities.
ABORT TASK SETとCLEAR TASK SET Task Management機能要求の実行は指定された順序でそれぞれの実体における出来事の以下の系列から成ります。
The initiator:
創始者:
a) Issues ABORT TASK SET/CLEAR TASK SET request.
b) Continues to respond to each target transfer tag received
for the affected task set.
c) Receives any responses for the tasks in the affected task
set (may process them as usual because they are guaranteed
to be valid).
d) Receives the task set management response, thus concluding
all the tasks in the affected task set.
a) ABORT TASK SET/CLEAR TASK SET要求b)を発行します。 影響を受けにおいて、受け取られていているそれぞれの目標転送タグにタスクセットc)を反応させ続けています。 影響を受けるタスクのタスクが. d)を設定するので(それらが有効になるように保証されるので、いつものようにそれらを処理するかもしれません)、どんな応答も受けます。 タスクセット管理応答を受けて、その結果、影響を受けるタスクセットにおけるすべてのタスクを結論づけます。
The target:
目標:
a) Receives the ABORT TASK SET/CLEAR TASK SET request.
b) Waits for all target transfer tags to be responded to and
for all affected tasks in the task set to be received.
c) Propagates the command to and receives the response from the
target SCSI layer.
d) Takes note of last-sent StatSN on each of the connections in
the iSCSI sessions (one or more) sharing the affected task
set, and waits for acknowledgement of each StatSN (may
solicit for acknowledgement by way of a NOP-In). If some
tasks originate from non-iSCSI I_T_L nexi then the means by
which the target insures that all affected tasks have
returned their status to the initiator are defined by the
specific protocol.
a) 受信、ABORT TASK SET/CLEAR TASK SETは. b)を要求します。 タスクとすべての影響を受けるタスクのために反応して、タスクでは. c)が受け取るためにセットしていたということであることをすべての目標転送タグを待っています。 目標SCSI層からコマンドを伝播して、応答を受ける、d) iSCSIセッション(1以上)における接続各人のときに影響を受けるタスクセットを共有しながら最後送られたStatSNに注目して、それぞれのStatSN(中のNOPを通して承認を請うかもしれない)の承認を待っています。 タスクが由来するいくつか、非、-iSCSI I_T_Lはnexiして、次に、目標が、すべての影響を受けるタスクがそれらの状態を創始者に返したのを保障する手段は特定のプロトコルによって定義されます。
e) Sends the task set management response to the issuing
initiator.
e) タスクセット管理応答を発行している創始者に送ります。
Satran, et al. Standards Track [Page 136] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[136ページ]。
10.6.3. TotalAHSLength and DataSegmentLength
10.6.3. TotalAHSLengthとDataSegmentLength
For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
このPDU TotalAHSLengthとDataSegmentLengthが0歳であるに違いないので。
10.7. SCSI Data-Out & SCSI Data-In
10.7. 外のSCSIデータと中のSCSIデータ
The SCSI Data-Out PDU for WRITE operations has the following format:
WRITE操作のための外のSCSI Data PDUには、以下の形式があります:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x05 |F| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| Reserved |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32| Reserved |
+---------------+---------------+---------------+---------------+
36| DataSN |
+---------------+---------------+---------------+---------------+
40| Buffer Offset |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0×05|F| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| LUNか予約されています。| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 目標転送のタグか0xffffffff| +---------------+---------------+---------------+---------------+ 24| 予約されます。| +---------------+---------------+---------------+---------------+ 28| ExpStatSN| +---------------+---------------+---------------+---------------+ 32| 予約されます。| +---------------+---------------+---------------+---------------+ 36| DataSN| +---------------+---------------+---------------+---------------+ 40| バッファオフセット| +---------------+---------------+---------------+---------------+ 44| 予約されます。| +---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+ / DataSegment /+//+---------------+---------------+---------------+---------------+ | データダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
Satran, et al. Standards Track [Page 137] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[137ページ]。
The SCSI Data-In PDU for READ operations has the following format:
READ操作のための中のSCSI Data PDUには、以下の形式があります:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| StatSN or Reserved |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| DataSN |
+---------------+---------------+---------------+---------------+
40| Buffer Offset |
+---------------+---------------+---------------+---------------+
44| Residual Count |
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0×25|F|A|0 0 0|O|U|S| 予約されます。|状態かRsvd| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| LUNか予約されています。| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 目標転送のタグか0xffffffff| +---------------+---------------+---------------+---------------+ 24| StatSNか予約されています。| +---------------+---------------+---------------+---------------+ 28| ExpCmdSN| +---------------+---------------+---------------+---------------+ 32| MaxCmdSN| +---------------+---------------+---------------+---------------+ 36| DataSN| +---------------+---------------+---------------+---------------+ 40| バッファオフセット| +---------------+---------------+---------------+---------------+ 44| 残りのカウント| +---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+ / DataSegment /+//+---------------+---------------+---------------+---------------+ | データダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
Status can accompany the last Data-In PDU if the command did not end with an exception (i.e., the status is "good status" - GOOD, CONDITION MET or INTERMEDIATE CONDITION MET). The presence of status (and of a residual count) is signaled though the S flag bit. Although targets MAY choose to send even non-exception status in separate responses, initiators MUST support non-exception status in Data-In PDUs.
コマンドが例外による、(すなわち、状態は「良い状態」です--GOOD、CONDITION METまたはINTERMEDIATE CONDITION MET)少しの終わりもしなかったなら、状態は最後の中のData PDUに同伴できます。 S旗に噛み付きましたが、状態(そして残りのカウントについて)の存在は合図されます。 目標は、別々の応答における非例外状態さえ送るのを選ぶかもしれませんが、創始者は中のData PDUsの非例外状態を支持しなければなりません。
Satran, et al. Standards Track [Page 138] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[138ページ]。
10.7.1. F (Final) Bit
10.7.1. F(最終的)のビット
For outgoing data, this bit is 1 for the last PDU of unsolicited data or the last PDU of a sequence that answers an R2T.
発信データに関しては、このビットは求められていないデータの最後のPDUかR2Tに答える系列の最後のPDUのための1です。
For incoming data, this bit is 1 for the last input (read) data PDU of a sequence. Input can be split into several sequences, each having its own F bit. Splitting the data stream into sequences does not affect DataSN counting on Data-In PDUs. It MAY be used as a "change direction" indication for Bidirectional operations that need such a change.
受信データに関しては、このビットは系列の最後の入力(読む)データPDUのための1です。 それぞれそれ自身のFビットを持っていて、入力をいくつかの系列に分けることができます。 データ・ストリームを系列に分けるのは中のData PDUsを頼りにするDataSNに影響しません。 それはそのような変化を必要とするBidirectional操作に「変化指示」指示として使用されるかもしれません。
DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent and the total of all the DataSegmentLength of all PDUs in a sequence MUST not exceed MaxBurstLength (or FirstBurstLength for unsolicited data). However the number of individual PDUs in a sequence (or in total) may be higher than the MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength ratio (as PDUs may be limited in length by the sender capabilities). Using DataSegmentLength of 0 may increase beyond what is reasonable for the number of PDUs and should therefore be avoided.
DataSegmentLengthはそれが送られる方向のためにMaxRecvDataSegmentLengthを超えてはいけません、そして、次々にのすべてのPDUsのすべてのDataSegmentLengthの合計はMaxBurstLength(または、求められていないデータのためのFirstBurstLength)を超えてはいけません。 しかしながら、次々に(合計で)の個々のPDUsの数はMaxBurstLength(または、FirstBurstLength)よりMaxRecvDataSegmentLength比に大きいかもしれません(PDUsが送付者能力によって長さが制限されるとき)。 0のDataSegmentLengthを使用するのは、PDUsの数に、妥当なことを超えて増加するかもしれなくて、したがって、避けられるべきです。
For Bidirectional operations, the F bit is 1 for both the end of the input sequences and the end of the output sequences.
Bidirectionalに関しては、操作であり、Fビットは入力系列の両方の終わりと出力系列の終わりの1です。
10.7.2. A (Acknowledge) Bit
10.7.2. (承認します)ビット
For sessions with ErrorRecoveryLevel 1 or higher, the target sets this bit to 1 to indicate that it requests a positive acknowledgement from the initiator for the data received. The target should use the A bit moderately; it MAY only set the A bit to 1 once every MaxBurstLength bytes, or on the last Data-In PDU that concludes the entire requested read data transfer for the task from the target's perspective, and it MUST NOT do so more frequently. The target MUST NOT set to 1 the A bit for sessions with ErrorRecoveryLevel=0. The initiator MUST ignore the A bit set to 1 for sessions with ErrorRecoveryLevel=0.
ErrorRecoveryLevelより多くの1とのセッションのために、目標はデータのための創始者からの積極的な承認が受信されたよう要求するのを示す1にこのビットを設定します。 目標は適度にAビットを使用するはずです。 設定されるだけであって、AはかつてのあらゆるMaxBurstLengthに1まで噛み付きます。するかもしれない、バイト、またはオンであり、全体を結論づける最後の中のData PDUは、タスクのために目標の見解からデータ転送を読むよう要求して、それは、より頻繁にそうしてはいけません。 目標はErrorRecoveryLevel=0とのセッションのためにAビットを1に設定してはいけません。 創始者はErrorRecoveryLevel=0とのセッションのために1に設定されたAビットを無視しなければなりません。
On receiving a Data-In PDU with the A bit set to 1 on a session with ErrorRecoveryLevel greater than 0, if there are no holes in the read data until that Data-In PDU, the initiator MUST issue a SNACK of type DataACK except when it is able to acknowledge the status for the task immediately via ExpStatSN on other outbound PDUs if the status for the task is also received. In the latter case (acknowledgement through ExpStatSN), sending a SNACK of type DataACK in response to the A bit is OPTIONAL, but if it is done, it must not be sent after the status acknowledgement through ExpStatSN. If the initiator has detected holes in the read data prior to that Data-In PDU, it MUST
読書データにその中のData PDUまで穴が全くなければErrorRecoveryLevelより多くの0とのセッションのときに1に設定されたAビットで中のData PDUを受けると、また、タスクのための状態が取られるならタスクのために他の外国行きのPDUsの上のExpStatSNすぐを通して状態を承認できる時を除いて、創始者はタイプDataACKのSNACKを発行しなければなりません。 後者の場合(ExpStatSNを通した承認)では、Aビットに対応してタイプDataACKのSNACKを送るのは、OPTIONALですが、完了しているなら、状態承認の後にExpStatSNを通してそれを送ってはいけません。 創始者がその中のData PDUの前に読書データの穴を検出したなら、それは検出しなければなりませんでした。
Satran, et al. Standards Track [Page 139] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[139ページ]。
postpone issuing the SNACK of type DataACK until the holes are filled. An initiator also MUST NOT acknowledge the status for the task before those holes are filled. A status acknowledgement for a task that generated the Data-In PDUs is considered by the target as an implicit acknowledgement of the Data-In PDUs if such an acknowledgement was requested by the target.
穴がいっぱいにされるまでタイプDataACKのSNACKを発行するのを延期してください。 それらの穴がいっぱいにされる前に創始者もタスクのために状態を承認してはいけません。 そのような承認が目標によって要求されたなら、中のData PDUsを発生させたタスクのための状態承認は目標によって中のData PDUsの暗黙の承認と考えられます。
10.7.3. Flags (byte 1)
10.7.3. 旗(バイト1)
The last SCSI Data packet sent from a target to an initiator for a SCSI command that completed successfully (with a status of GOOD, CONDITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may also optionally contain the Status for the data transfer. As Sense Data cannot be sent together with the Command Status, if the command is completed with an error, then the response and sense data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be sent in a SCSI Data packet). If Status is sent with the data, then a SCSI Response PDU MUST NOT be sent as this would violate SCSI rules (a single status). For Bidirectional commands, the status MUST be sent in a SCSI Response PDU.
また、それが首尾よさに(GOOD、CONDITION MET、INTERMEDIATEまたはINTERMEDIATE CONDITION METの状態で)終了したSCSIコマンドのために目標から創始者に送られた最後のSCSI Dataパケットは任意にデータ転送のためのStatusを含むかもしれません。 コマンドが誤りで終了されているならCommand Statusと共にSense Dataを送ることができないので、そして、SCSI Response PDU(すなわち、SCSI Dataパケットで送ってはいけない)でデータを送らなければならない応答と感覚です。 データと共にStatusを送るなら、これがSCSI規則(ただ一つの状態)に違反するようにSCSI Response PDUを送ってはいけないその時です。 Bidirectionalコマンドにおいて、SCSI Response PDUで状態を送らなければなりません。
bit 2-4 - Reserved.
ビット2-4--予約されています。
bit 5-6 - used the same as in a SCSI Response. These bits are
only valid when S is set to 1. For details see Section
10.4.1 Flags (byte 1).
ビット5-6--SCSI Responseのように同じように使用されます。 Sが1に設定されるときだけ、これらのビットは有効です。 詳細に関しては、セクション10.4.1Flags(バイト1)を見てください。
bit 7 S (status)- set to indicate that the Command Status field
contains status. If this bit is set to 1, the F bit
MUST also be set to 1.
7秒間(状態)のビット--セットして、Command Status分野が状態を含むのを示してください。 また、このビットが1に設定されるなら、Fビットを1に設定しなければなりません。
The fields StatSN, Status, and Residual Count only have meaningful content if the S bit is set to 1 and their values are defined in Section 10.4 SCSI Response.
分野のStatSN、Status、およびResidual Countには、Sビットが1に設定されて、彼らの値がセクション10.4 SCSI Responseで定義される場合にだけ、重要な内容があります。
10.7.4. Target Transfer Tag and LUN
10.7.4. 目標転送のタグとLUN
On outgoing data, the Target Transfer Tag is provided to the target if the transfer is honoring an R2T. In this case, the Target Transfer Tag field is a replica of the Target Transfer Tag provided with the R2T.
発信データでは、転送がR2Tを尊敬しているなら、Target Transfer Tagを目標に提供します。 この場合、Target Transfer Tag分野はR2Tが提供されたTarget Transfer Tagのレプリカです。
On incoming data, the Target Transfer Tag and LUN MUST be provided by the target if the A bit is set to 1; otherwise they are reserved. The Target Transfer Tag and LUN are copied by the initiator into the SNACK of type DataACK that it issues as a result of receiving a SCSI Data-In PDU with the A bit set to 1.
受信データ、Target Transfer Tag、およびLUN MUSTでは、Aビットを1に設定するなら、目標は提供してください。 さもなければ、それらは予約されています。 Target Transfer TagとLUNは創始者によって1に設定されたAビットで中のSCSI Data PDUを受けることの結果、それが発行するタイプDataACKのSNACKにコピーされます。
Satran, et al. Standards Track [Page 140] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[140ページ]。
The Target Transfer Tag values are not specified by this protocol except that the value 0xffffffff is reserved and means that the Target Transfer Tag is not supplied. If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command; otherwise, the LUN field is reserved.
値の0xffffffffが、予約されていて、Target Transfer Tagが供給されないことを意味する以外に、Target Transfer Tag値はこのプロトコルによって指定されません。 Target Transfer Tagを提供するなら、LUN分野は、有効値を保って、コマンドで指定されたことなら何でもと一致しているに違いありません。 さもなければ、LUN分野は予約されています。
10.7.5. DataSN
10.7.5. DataSN
For input (read) or bidirectional Data-In PDUs, the DataSN is the input PDU number within the data transfer for the command identified by the Initiator Task Tag.
入力(読む)か双方向の中のData PDUsに関しては、DataSNはデータ転送の中のInitiator Task Tagによって特定されたコマンドの入力PDU番号です。
R2T and Data-In PDUs, in the context of bidirectional commands, share the numbering sequence (see Section 3.2.2.3 Data Sequencing).
R2Tと中のData PDUsが双方向のコマンドの文脈で付番系列を共有する、(セクション3.2.2を見てください、.3Data Sequencing)
For output (write) data PDUs, the DataSN is the Data-Out PDU number within the current output sequence. The current output sequence is either identified by the Initiator Task Tag (for unsolicited data) or is a data sequence generated for one R2T (for data solicited through R2T).
出力(書く)データPDUsにおいて、DataSNは経常産出高系列の中の外のData PDU番号です。 経常産出高系列は、Initiator Task Tag(求められていないデータのための)によって特定されるか、1R2T(R2Tを通して請求されたデータのための)のために発生するデータ系列です。
10.7.6. Buffer Offset
10.7.6. バッファオフセット
The Buffer Offset field contains the offset of this PDU payload data within the complete data transfer. The sum of the buffer offset and length should not exceed the expected transfer length for the command.
Buffer Offset分野は完全なデータ転送の中にこのPDUペイロードデータのオフセットを含んでいます。 バッファオフセットと長さの合計はコマンドのために予想された転送の長さを超えるべきではありません。
The order of data PDUs within a sequence is determined by DataPDUInOrder. When set to Yes, it means that PDUs have to be in increasing Buffer Offset order and overlays are forbidden.
系列の中のデータPDUsの順番はDataPDUInOrderによって決定されます。 はい、それに設定されると、PDUsが増加するBuffer Offsetオーダーにあるように持っている手段とオーバレイは禁じられます。
The ordering between sequences is determined by DataSequenceInOrder. When set to Yes, it means that sequences have to be in increasing Buffer Offset order and overlays are forbidden.
系列の間の注文はDataSequenceInOrderによって決定されます。 はい、それに設定されると、系列が増加するBuffer Offsetオーダーにあるように持っている手段とオーバレイは禁じられます。
10.7.7. DataSegmentLength
10.7.7. DataSegmentLength
This is the data payload length of a SCSI Data-In or SCSI Data-Out PDU. The sending of 0 length data segments should be avoided, but initiators and targets MUST be able to properly receive 0 length data segments.
これは中のSCSI Dataか外のSCSI Data PDUのデータペイロード長です。 0つの長さのデータ・セグメントの発信は避けられるべきですが、創始者と目標は適切に0つの長さのデータ・セグメントを受けることができなければなりません。
The Data Segments of Data-In and Data-Out PDUs SHOULD be filled to the integer number of 4 byte words (real payload) unless the F bit is set to 1.
Data Segments、中のDataとData出ているPDUs SHOULDでは、Fビットが1に設定されない場合、4バイトの単語(本当のペイロード)の整数にいっぱいにされてください。
Satran, et al. Standards Track [Page 141] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[141ページ]。
10.8. Ready To Transfer (R2T)
10.8. 移す準備ができています。(R2T)
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x31 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| R2TSN |
+---------------+---------------+---------------+---------------+
40| Buffer Offset |
+---------------+---------------+---------------+---------------+
44| Desired Data Transfer Length |
+---------------------------------------------------------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0×31|1| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| LUN| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 目標転送タグ| +---------------+---------------+---------------+---------------+ 24| StatSN| +---------------+---------------+---------------+---------------+ 28| ExpCmdSN| +---------------+---------------+---------------+---------------+ 32| MaxCmdSN| +---------------+---------------+---------------+---------------+ 36| R2TSN| +---------------+---------------+---------------+---------------+ 40| バッファオフセット| +---------------+---------------+---------------+---------------+ 44| 必要なデータ転送の長さ| +---------------------------------------------------------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
When an initiator has submitted a SCSI Command with data that passes from the initiator to the target (WRITE), the target may specify which blocks of data it is ready to receive. The target may request that the data blocks be delivered in whichever order is convenient for the target at that particular instant. This information is passed from the target to the initiator in the Ready To Transfer (R2T) PDU.
創始者が創始者から目標(WRITE)まで終わるデータでSCSI Commandを提出したとき、目標は、それをどのブロックのデータを受け取る準備ができているかを指定するかもしれません。 目標は、データ・ブロックが目標がその特定の瞬間に都合がよいどのオーダーで届けられるよう要求するかもしれません。 この情報はReady To Transfer(R2T)PDUで目標から創始者まで通過されます。
In order to allow write operations without an explicit initial R2T, the initiator and target MUST have negotiated the key InitialR2T to No during Login.
許容、Loginの間、明白なイニシャルのないR2T、創始者、および目標が主要なInitialR2Tを交渉したに違いない操作にいいえを書いてください。
An R2T MAY be answered with one or more SCSI Data-Out PDUs with a matching Target Transfer Tag. If an R2T is answered with a single Data-Out PDU, the Buffer Offset in the Data PDU MUST be the same as
R2T MAY、1外のSCSI Data PDUsと共に合っているTarget Transfer Tagで答えられてください。 R2Tであるなら、答えられたシングルでData出ているPDU、Buffer OffsetはData PDUが同じであるに違いないコネですか?
Satran, et al. Standards Track [Page 142] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[142ページ]。
the one specified by the R2T, and the data length of the Data PDU MUST be the same as the Desired Data Transfer Length specified in the R2T. If the R2T is answered with a sequence of Data PDUs, the Buffer Offset and Length MUST be within the range of those specified by R2T, and the last PDU MUST have the F bit set to 1. If the last PDU (marked with the F bit) is received before the Desired Data Transfer Length is transferred, a target MAY choose to Reject that
ものはR2Tで指定しました、そして、Data PDUのデータの長さはDesired Data Transfer LengthがR2Tで指定したのと同じであるに違いありません。 R2TがData PDUsの系列で答えられるなら、R2Tによって指定されたものの範囲の中にBuffer OffsetとLengthがあるに違いありません、そして、最後のPDU MUSTはFビットを1に設定させます。 Desired Data Transfer Lengthがわたっている前に最後のPDU(Fビットで、マークされる)が受け取られているなら、目標はRejectにそれを選ぶかもしれません。
PDU with "Protocol error" reason code. DataPDUInOrder governs the Data-Out PDU ordering. If DataPDUInOrder is set to Yes, the Buffer Offsets and Lengths for consecutive PDUs MUST form a continuous non-overlapping range and the PDUs MUST be sent in increasing offset order.
「プロトコル誤り」があるPDUはコードを推論します。 DataPDUInOrderは外のData PDU注文を治めます。 DataPDUInOrderがはい、Buffer Offsetsに用意ができて、連続したPDUsのためのLengthsが連続した非重なっている範囲を形成しなければならなくて、増加するのをPDUsを送らなければならないなら、オーダーを相殺してください。
The target may send several R2T PDUs. It, therefore, can have a number of pending data transfers. The number of outstanding R2T PDUs are 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を実現させなければなりません。
R2T PDUs MAY also be used to recover Data Out PDUs. Such an R2T (Recovery-R2T) is generated by a target upon detecting the loss of one or more Data-Out PDUs due to:
また、R2T PDUsは、Data Out PDUsを回収するのに使用されるかもしれません。 1外のData PDUsの損失を検出するとき、そのようなR2T(回復-R2T)は以下のため目標で発生します。
- Digest error
- Sequence error
- Sequence reception timeout
- ダイジェスト誤り--系列誤り--系列レセプションタイムアウト
A Recovery-R2T carries the next unused R2TSN, but requests part of or the entire data burst that an earlier R2T (with a lower R2TSN) had already requested.
Recovery-R2Tは未使用のR2TSN、要求だけが離れているか、または全体のデータが押し破いた次を運びます。以前のR2T(下側のR2TSNと)は既に要求されていた状態でそうしました。
DataSequenceInOrder governs the buffer offset ordering in consecutive R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts MUST refer to continuous non-overlapping ranges except for Recovery-R2Ts.
DataSequenceInOrderは連続したR2Tsを入るように命じるバッファオフセットを決定します。 はい、そして、DataSequenceInOrderがそうなら、連続したR2TsはRecovery-R2Ts以外の連続した非重なっている範囲を参照しなければなりません。
10.8.1. TotalAHSLength and DataSegmentLength
10.8.1. TotalAHSLengthとDataSegmentLength
For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
このPDU TotalAHSLengthとDataSegmentLengthが0歳であるに違いないので。
10.8.2. R2TSN
10.8.2. R2TSN
R2TSN is the R2T PDU input PDU number within the command identified by the Initiator Task Tag.
R2TSNはInitiator Task Tagによって特定されたコマンドの中のR2T PDU入力PDU番号です。
For bidirectional commands R2T and Data-In PDUs share the input PDU numbering sequence (see Section 3.2.2.3 Data Sequencing).
双方向のコマンドR2Tと中のData PDUsが入力PDU付番系列を共有する、(セクション3.2.2を見てください、.3Data Sequencing)
Satran, et al. Standards Track [Page 143] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[143ページ]。
10.8.3. StatSN
10.8.3. StatSN
The StatSN field will contain the next StatSN. The StatSN for this connection is not advanced after this PDU is sent.
StatSN分野は次のStatSNを含むでしょう。 このPDUを送った後にこの接続のためのStatSNは高度ではありません。
10.8.4. Desired Data Transfer Length and Buffer Offset
10.8.4. 必要なデータ転送の長さとバッファオフセット
The target specifies how many bytes it wants the initiator to send because of this R2T PDU. The target may request the data from the initiator in several chunks, not necessarily in the original order of the data. The target, therefore, also specifies a Buffer Offset that indicates the point at which the data transfer should begin, relative to the beginning of the total data transfer. The Desired Data Transfer Length MUST NOT be 0 and MUST not exceed MaxBurstLength.
目標は、それが、創始者にこのR2T PDUのためにいくつのバイトを送って欲しいかを指定します。 目標は必ずデータに関する最初の注文で要求するのではなく、創始者からいくつかの塊でデータを要求するかもしれません。 したがって、また、目標はデータ転送が始まるべきであるポイントを示すBuffer Offsetを指定します、総データ転送の始まりに比例して。 Desired Data Transfer Lengthは0歳であってはいけなく、MaxBurstLengthを超えてはいけません。
10.8.5. Target Transfer Tag
10.8.5. 目標転送タグ
The target assigns its own tag to each R2T request that it sends to the initiator. This tag can be used by the target to easily identify the data it receives. The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are only used by the target. There is no protocol rule about the Target Transfer Tag except that the value 0xffffffff is reserved and MUST NOT be sent by a target in an R2T.
目標は創始者に発信するというそれぞれのR2T要求にそれ自身のタグを割り当てます。 このタグは目標によって使用されて、容易にそれが受け取るデータを特定できます。 Target Transfer TagとLUNは発信データPDUsにコピーされて、目標によって使用されるだけです。 値の0xffffffffを予約されていて、R2Tの目標で送ってはいけない以外に、Target Transfer Tagに関するプロトコル規則が全くありません。
Satran, et al. Standards Track [Page 144] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[144ページ]。
10.9. Asynchronous Message
10.9. 非同期なメッセージ
An Asynchronous Message may be sent from the target to the initiator without correspondence to a particular command. The target specifies the reason for the event and sense data.
特定のコマンドへの通信なしで目標から創始者にAsynchronous Messageを送るかもしれません。 目標は出来事とセンス・データの理由を指定します。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x32 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| AsyncEvent | AsyncVCode | Parameter1 or Reserved |
+---------------+---------------+---------------+---------------+
40| Parameter2 or Reserved | Parameter3 or Reserved |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment - Sense Data and iSCSI Event Data /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0×32|1| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| LUNか予約されています。| + + 12| | +---------------+---------------+---------------+---------------+ 16| 0xffffffff| +---------------+---------------+---------------+---------------+ 20| 予約されます。| +---------------+---------------+---------------+---------------+ 24| StatSN| +---------------+---------------+---------------+---------------+ 28| ExpCmdSN| +---------------+---------------+---------------+---------------+ 32| MaxCmdSN| +---------------+---------------+---------------+---------------+ 36| AsyncEvent| AsyncVCode| Parameter1か予約されています。| +---------------+---------------+---------------+---------------+ 40| Parameter2か予約されています。| Parameter3か予約されています。| +---------------+---------------+---------------+---------------+ 44| 予約されます。| +---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+/DataSegment--センス・データとiSCSIイベントデータ/+//+---------------+---------------+---------------+---------------+ | データダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
Some Asynchronous Messages are strictly related to iSCSI while others are related to SCSI [SAM2].
他のものはSCSI[SAM2]に関連しますが、いくつかのAsynchronous Messagesが厳密にiSCSIに関連します。
StatSN counts this PDU as an acknowledgeable event (StatSN is advanced), which allows for initiator and target state synchronization.
StatSNは承認可能出来事(StatSNは高度である)にこのPDUをみなします。(それは、創始者と目標州の同期を考慮します)。
Satran, et al. Standards Track [Page 145] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[145ページ]。
10.9.1. AsyncEvent
10.9.1. AsyncEvent
The codes used for iSCSI Asynchronous Messages (events) are:
iSCSI Asynchronous Messages(出来事)に使用されるコードは以下の通りです。
0 - a SCSI Asynchronous Event is reported in the sense data.
Sense Data that accompanies the report, in the data segment,
identifies the condition. The sending of a SCSI Event
(Asynchronous Event Reporting in SCSI terminology) is
dependent on the target support for SCSI asynchronous event
reporting (see [SAM2]) as indicated in the standard INQUIRY
data (see [SPC3]). Its use may be enabled by parameters in
the SCSI Control mode page (see [SPC3]).
0--SCSI Asynchronous Eventはセンス・データで報告されます。 データ・セグメントでレポートに伴う感覚Dataが状態を特定します。 SCSI Event(SCSI用語の非同期なEvent Reporting)の発信は標準のINQUIRYデータにみられるようにSCSI非同期的なイベント報告の目標サポート([SAM2]を見る)に依存しています([SPC3]を見てください)。 使用はSCSI Controlモードページのパラメタによって可能にされるかもしれません([SPC3]を見てください)。
1 - target requests Logout. This Async Message MUST be sent on
the same connection as the one requesting to be logged out.
The initiator MUST honor this request by issuing a Logout as
early as possible, but no later than Parameter3 seconds.
Initiator MUST send a Logout with a reason code of "Close the
connection" OR "Close the session" to close all the
connections. Once this message is received, the initiator
SHOULD NOT issue new iSCSI commands on the connection to be
logged out. The target MAY reject any new I/O requests that
it receives after this Message with the reason code "Waiting
for Logout". If the initiator does not Logout in Parameter3
seconds, the target should send an Async PDU with iSCSI event
code "Dropped the connection" if possible, or simply terminate
the transport connection. Parameter1 and Parameter2 are
reserved.
1--目標はLogoutを要求します。 ログアウトされるよう要求されているものと同じ接続にこのAsync Messageを送らなければなりません。 創始者はできるだけ早くLogoutを発行しますが、Parameter3秒までにこの要求を光栄に思わなければなりません。 創始者は発信しなければなりません。「接続を終えてください」というORの理由コードがあるLogoutは、すべての接続を終えるために「セッションを終えます」。 このメッセージがいったん受信されるようになると、創始者SHOULD NOT問題の新しいiSCSIは、接続のときにログアウトされると命令します。 目標がこのMessageの後に理由コードで受信するというどんな新しい入出力要求も拒絶するかもしれない、「待っている、ログアウト、」 創始者がParameter3秒にどんなLogoutもしないなら、目標を発信させるはずです。できれば、iSCSIイベントコードがあるAsync PDUが「接続を落とした」か、または単に輸送接続を終えてください。 Parameter1とParameter2は予約されています。
2 - target indicates it will drop the connection. The Parameter1
field indicates the CID of the connection that is going to be
dropped.
2--目標は、接続を落とすのを示します。 Parameter1分野は落とされる接続のCIDを示します。
The Parameter2 field (Time2Wait) indicates, in seconds, the
minimum time to wait before attempting to reconnect or
reassign.
Parameter2分野(Time2Wait)は秒に再接続するか、または再選任する試みの前に待つ最小の時間を示します。
The Parameter3 field (Time2Retain) indicates the maximum time
allowed to reassign commands after the initial wait (in
Parameter2).
Parameter3分野(Time2Retain)は、初期の待ち(Parameter2の)の後にコマンドを再選任するために最大の日限を示します。
If the initiator does not attempt to reconnect and/or reassign
the outstanding commands within the time specified by
Parameter3, or if Parameter3 is 0, the target will terminate
all outstanding commands on this connection. In this case, no
other responses should be expected from the target for the
outstanding commands on this connection.
創始者が、所定の期間内にParameter3による傑出しているコマンドを再接続する、そして/または、再選任するのを試みないか、またはParameter3が0歳であるなら、目標はこの接続のすべての傑出しているコマンドを終えるでしょう。 この場合、この接続のときに傑出しているコマンドのための目標から他の応答を全く予想するべきではありません。
Satran, et al. Standards Track [Page 146] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[146ページ]。
A value of 0 for Parameter2 indicates that reconnect can be
attempted immediately.
Parameter2が、それが再接続されるのを示すので、すぐに、0の値を試みることができます。
3 - target indicates it will drop all the connections of this
session.
3--目標は、このセッションのすべての接続を落とすのを示します。
Parameter1 field is reserved.
Parameter1分野は予約されています。
The Parameter2 field (Time2Wait) indicates, in seconds, the
minimum time to wait before attempting to reconnect. The
Parameter3 field (Time2Retain) indicates the maximum time
allowed to reassign commands after the initial wait (in
Parameter2).
Parameter2分野(Time2Wait)は秒に再接続するのを試みる前に待つ最小の時間を示します。 Parameter3分野(Time2Retain)は、初期の待ち(Parameter2の)の後にコマンドを再選任するために最大の日限を示します。
If the initiator does not attempt to reconnect and/or reassign
the outstanding commands within the time specified by
Parameter3, or if Parameter3 is 0, the session is terminated.
創始者が、所定の期間内にParameter3による傑出しているコマンドを再接続する、そして/または、再選任するのを試みないか、またはParameter3が0歳であるなら、セッションは終えられます。
In this case, the target will terminate all outstanding
commands in this session; no other responses should be
expected from the target for the outstanding commands in this
session. A value of 0 for Parameter2 indicates that reconnect
can be attempted immediately.
この場合、目標はこのセッションにおけるすべての傑出しているコマンドを終えるでしょう。 このセッションにおける傑出しているコマンドのための目標から他の応答を全く予想するべきではありません。 Parameter2が、それが再接続されるのを示すので、すぐに、0の値を試みることができます。
4 - target requests parameter negotiation on this connection. The
initiator MUST honor this request by issuing a Text Request
(that can be empty) on the same connection as early as
possible, but no later than Parameter3 seconds, unless a Text
Request is already pending on the connection, or by issuing a
Logout Request. If the initiator does not issue a Text
Request the target may reissue the Asynchronous Message
requesting parameter negotiation.
4--目標はこの接続のパラメタ交渉を要求します。 創始者は同じ接続のときにできるだけ早く、Text Request(それは空である場合がある)を発行しますが、Parameter3秒までにこの要求を光栄に思わなければなりません、Text Requestが接続、またはLogout Requestを発行することによって既に未定でない場合。 創始者がText Requestを発行しないなら、目標はパラメタ交渉を要求するAsynchronous Messageを再発行するかもしれません。
255 - vendor specific iSCSI Event. The AsyncVCode details the
vendor code, and data MAY accompany the report.
255--業者の特定のiSCSI Event。 AsyncVCodeは業者コードを詳しく述べます、そして、データはレポートに伴うかもしれません。
All other event codes are reserved.
他のすべてのイベントコードが予約されています。
10.9.2. AsyncVCode
10.9.2. AsyncVCode
AsyncVCode is a vendor specific detail code that is only valid if the AsyncEvent field indicates a vendor specific event. Otherwise, it is reserved.
AsyncVCodeはAsyncEvent分野が業者の特定のイベントを示す場合にだけ有効な業者特定の詳細コードです。 さもなければ、それは予約されています。
10.9.3. LUN
10.9.3. LUN
The LUN field MUST be valid if AsyncEvent is 0. Otherwise, this field is reserved.
LUN分野はAsyncEventが0歳であるなら有効であるに違いありません。 さもなければ、この分野は予約されています。
Satran, et al. Standards Track [Page 147] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[147ページ]。
10.9.4. Sense Data and iSCSI Event Data
10.9.4. センス・データとiSCSIイベントデータ
For a SCSI event, this data accompanies the report in the data segment and identifies the condition.
SCSI出来事に関しては、このデータは、データ・セグメントでレポートに伴って、状態を特定します。
For an iSCSI event, additional vendor-unique data MAY accompany the Async event. Initiators MAY ignore the data when not understood while processing the rest of the PDU.
iSCSI出来事に関しては、追加業者ユニークなデータはAsync出来事に伴うかもしれません。 PDUの残りを処理している間、理解されていないと、創始者はデータを無視するかもしれません。
If the DataSegmentLength is not 0, the format of the DataSegment is as follows:
DataSegmentLengthが0歳でないなら、DataSegmentの形式は以下の通りです:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|SenseLength | Sense Data |
+---------------+---------------+---------------+---------------+
x/ Sense Data /
+---------------+---------------+---------------+---------------+
y/ iSCSI Event Data /
/ /
+---------------+---------------+---------------+---------------+
z|
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|SenseLength| センス・データ| +---------------+---------------+---------------+---------------+ x/感覚Data/+---------------+---------------+---------------+---------------+ y/ iSCSI Event Data / / /+---------------+---------------+---------------+---------------+ z|
10.9.4.1. SenseLength
10.9.4.1. SenseLength
This is the length of Sense Data. When the Sense Data field is empty (e.g., the event is not a SCSI event) SenseLength is 0.
これはSense Dataの長さです。 Sense Data分野が人影がないときに(例えば、出来事はSCSI出来事ではありません)、SenseLengthは0歳です。
Satran, et al. Standards Track [Page 148] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[148ページ]。
10.10. Text Request
10.10. テキスト要求
The Text Request is provided to allow for the exchange of information and for future extensions. It permits the initiator to inform a target of its capabilities or to request some special operations.
Text Requestは情報交換を考慮するために提供して今後の拡大のためのものです。 それは、創始者が能力の目標を知らせるか、またはいくつかの特殊作戦を要求することを許可します。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|I| 0x04 |F|C| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment (Text) /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | 私| 0×04|F|C| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| LUNか予約されています。| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 目標転送のタグか0xffffffff| +---------------+---------------+---------------+---------------+ 24| CmdSN| +---------------+---------------+---------------+---------------+ 28| ExpStatSN| +---------------+---------------+---------------+---------------+ 32/予約された/+//+---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+/DataSegment(テキスト)/+//+---------------+---------------+---------------+---------------+ | データダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
An initiator MUST have at most one outstanding Text Request on a connection at any given time.
創始者はその時々で最も1つに傑出しているText Requestを接続に持たなければなりません。
On a connection failure, an initiator must either explicitly abort any active allegiant text negotiation task or must cause such a task to be implicitly terminated by the target.
接続失敗では、創始者は、明らかにどんなアクティブなallegiantテキスト交渉タスクも中止しなければならないか、または目標でそのようなタスクをそれとなく終えさせなければなりません。
Satran, et al. Standards Track [Page 149] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[149ページ]。
10.10.1. F (Final) Bit
10.10.1. F(最終的)のビット
When set to 1, indicates that this is the last or only text request in a sequence of Text Requests; otherwise, it indicates that more Text Requests will follow.
いつが、1にセットして、これが次々にのText Requestsの最終か唯一のテキスト要求であることを示すか。 さもなければ、それは、より多くのText Requestsが続くのを示します。
10.10.2. C (Continue) Bit
10.10.2. C(続けている)ビット
When set to 1, indicates that the text (set of key=value pairs) in this Text Request is not complete (it will be continued on subsequent Text Requests); otherwise, it indicates that this Text Request ends a set of key=value pairs. A Text Request with the C bit set to 1 MUST have the F bit set to 0.
いつが、1にセットして、このText Requestのテキスト(主要な=値組のセット)が完全でないことを示すか(それはその後のText Requestsで続けられるでしょう)。 さもなければ、それは、このText Requestが1セットの主要な=値組を終わらせるのを示します。 1に設定されたCビットがあるText RequestはFビットを0に設定させなければなりません。
10.10.3. Initiator Task Tag
10.10.3. 創始者タスクタグ
The initiator assigned identifier for this Text Request. If the command is sent as part of a sequence of text requests and responses, the Initiator Task Tag MUST be the same for all the requests within the sequence (similar to linked SCSI commands). The I bit for all requests in a sequence also MUST be the same.
創始者はこのText Requestのために識別子を割り当てました。 テキスト要求と応答の系列の一部としてコマンドを送るなら、すべての要求に、Initiator Task Tagは系列の中で同じであるに違いありません(繋がっているSCSIコマンドと同様の)。 次々にのすべての要求のためのIビットも同じであるに違いありません。
10.10.4. Target Transfer Tag
10.10.4. 目標転送タグ
When the Target Transfer Tag is set to the reserved value 0xffffffff, it tells the target that this is a new request and the target resets any internal state associated with the Initiator Task Tag (resets the current negotiation state).
Target Transfer Tagが予約された値の0xffffffffに用意ができているとき、それは、これが新しい要求であり、目標がInitiator Task Tag(現在の交渉状態をリセットする)に関連しているどんな内部の状態もリセットすると目標に言います。
The target sets the Target Transfer Tag in a text response to a value other than the reserved value 0xffffffff whenever it indicates that it has more data to send or more operations to perform that are associated with the specified Initiator Task Tag. It MUST do so whenever it sets the F bit to 0 in the response. By copying the Target Transfer Tag from the response to the next Text Request, the initiator tells the target to continue the operation for the specific Initiator Task Tag. The initiator MUST ignore the Target Transfer Tag in the Text Response when the F bit is set to 1.
送るより多くのデータか実行する指定されたInitiator Task Tagに関連しているより多くの操作があるのを示すときはいつも、目標は予約された値の0xffffffff以外の値へのテキスト応答にTarget Transfer Tagをはめ込みます。 0へのFビットを応答にはめ込むときはいつも、それはそうしなければなりません。 次のText Requestへの応答からTarget Transfer Tagをコピーすることによって、創始者は、特定のInitiator Task Tagのために操作を続けるように目標に言います。 Fビットが1に設定されるとき、創始者はText ResponseでTarget Transfer Tagを無視しなければなりません。
This mechanism allows the initiator and target to transfer a large amount of textual data over a sequence of text-command/text-response exchanges, or to perform extended negotiation sequences.
このメカニズムで、創始者と目標は、テキストテキストコマンド/応答交換の系列の上に多量の原文のデータを移すか、または拡張交渉系列を実行します。
If the Target Transfer Tag is not 0xffffffff, the LUN field MUST be sent by the target in the Text Response.
Target Transfer Tagが0xffffffffでないなら、Text Responseの目標はLUN野原を送らなければなりません。
Satran, et al. Standards Track [Page 150] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[150ページ]。
A target MAY reset its internal negotiation state if an exchange is stalled by the initiator for a long time or if it is running out of resources.
交換が長い間創始者によって遅らせられるか、またはリソースを使い果たしているなら、目標は内部の交渉状態をリセットするかもしれません。
Long text responses are handled as in the following example:
長いテキスト応答は以下の例のように扱われます:
I->T Text SendTargets=All (F=1,TTT=0xffffffff)
T->I Text <part 1> (F=0,TTT=0x12345678)
I->T Text <empty> (F=1, TTT=0x12345678)
T->I Text <part 2> (F=0, TTT=0x12345678)
I->T Text <empty> (F=1, TTT=0x12345678)
...
T->I Text <part n> (F=1, TTT=0xffffffff)
I>TテキストSendTargetsはT>Iテキスト<第1部>(Fは0、TTT=0x12345678と等しい)I>Tテキスト<の空の>(Fは1、TTT=0x12345678と等しい)T>Iテキスト<第2部>(Fは0、TTT=0x12345678と等しい)I>Tテキストの<の空の>と等しいです(Fは1、TTT=0x12345678と等しいです)… T>I Text<パートn>。(1、F=TTT=0xffffffff)
10.10.5. Text
10.10.5. テキスト
The data lengths of a text request MUST NOT exceed the iSCSI target MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter). The text format is specified in Section 5.2 Text Mode Negotiation.
テキストの長さが要求するデータはiSCSI目標MaxRecvDataSegmentLengthを超えてはいけません(接続と指示あたりのaはパラメタを交渉しました)。 テキスト形式はセクション5.2 Text Mode Negotiationで指定されます。
Chapter 11 and Chapter 12 list some basic Text key=value pairs, some of which can be used in Login Request/Response and some in Text Request/Response.
連邦破産法11条と第12章はいくつかの基本的なText主要な=値組を記載します。Login Request/応答といくつかでText Request/応答にその或るものを使用できます。
A key=value pair can span Text request or response boundaries. A key=value pair can start in one PDU and continue on the next. In other words the end of a PDU does not necessarily signal the end of a key=value pair.
主要な=値組はText要求か応答境界にかかることができます。 主要な=値組は、1PDUで始まって、次で続くことができます。 言い換えれば、PDUの端は必ず主要な=値組の端に合図するというわけではありません。
The target responds by sending its response back to the initiator. The response text format is similar to the request text format. The text response MAY refer to key=value pairs presented in an earlier text request and the text in the request may refer to earlier responses.
目標は、応答を創始者に送り返すことによって、応じます。 応答テキスト形式は要求テキスト形式と同様です。 テキスト応答は以前のテキスト要求に示された主要な=値組について言及するかもしれません、そして、要求におけるテキストは以前の応答について言及するかもしれません。
Chapter 5 details the rules for the Text Requests and Responses.
第5章はText RequestsとResponsesのために規則を詳しく述べます。
Text operations are usually meant for parameter setting/ negotiations, but can also be used to perform some long lasting operations.
テキスト操作をパラメタ設定/交渉のために通常意味されますが、また、いくつかの持続的な操作を実行するのに使用できます。
Text operations that take a long time should be placed in their own Text request.
長くかかるテキスト操作はそれら自身のText要求に置かれるべきです。
Satran, et al. Standards Track [Page 151] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[151ページ]。
10.11. Text Response
10.11. テキスト応答
The Text Response PDU contains the target's responses to the initiator's Text request. The format of the Text field matches that of the Text request.
Text Response PDUは創始者のText要求への目標の応答を含んでいます。 Text分野の形式はText要求のものに合っています。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x24 |F|C| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment (Text) /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0×24|F|C| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| LUNか予約されています。| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 目標転送のタグか0xffffffff| +---------------+---------------+---------------+---------------+ 24| StatSN| +---------------+---------------+---------------+---------------+ 28| ExpCmdSN| +---------------+---------------+---------------+---------------+ 32| MaxCmdSN| +---------------+---------------+---------------+---------------+ 36/予約された/+//+---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+/DataSegment(テキスト)/+//+---------------+---------------+---------------+---------------+ | データダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
10.11.1. F (Final) Bit
10.11.1. F(最終的)のビット
When set to 1, in response to a Text Request with the Final bit set to 1, the F bit indicates that the target has finished the whole operation. Otherwise, if set to 0 in response to a Text Request with the Final Bit set to 1, it indicates that the target has more work to do (invites a follow-on text request). A Text Response with the F bit set to 1 in response to a Text Request with the F bit set to 0 is a protocol error.
1に設定されたFinalビットがあるText Requestに対応して1に設定されると、Fビットは、目標が操作全体を終えたのを示します。 さもなければ、Final BitとText Requestに対応した0へのセットが1にセットするなら、それは、目標にはしなければならない(フォローオンテキスト要求を招待します)より多くの仕事があるのを示します。 0に設定されたFビットがあるText Requestに対応して1に設定されたFビットがあるText Responseはプロトコル誤りです。
Satran, et al. Standards Track [Page 152] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[152ページ]。
A Text Response with the F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator.
1に設定されたFビットがあるText Responseは創始者から追加答えを必要とするかもしれない主要な=値組を含んではいけません。
A Text Response with the F bit set to 1 MUST have a Target Transfer Tag field set to the reserved value of 0xffffffff.
1に設定されたFビットがあるText Responseは0xffffffffの予約された値にTarget Transfer Tag分野を設定させなければなりません。
A Text Response with the F bit set to 0 MUST have a Target Transfer Tag field set to a value other than the reserved 0xffffffff.
0に設定されたFビットがあるText Responseは予約された0xffffffff以外の値にTarget Transfer Tag分野を設定させなければなりません。
10.11.2. C (Continue) Bit
10.11.2. C(続けている)ビット
When set to 1, indicates that the text (set of key=value pairs) in this Text Response is not complete (it will be continued on subsequent Text Responses); otherwise, it indicates that this Text Response ends a set of key=value pairs. A Text Response with the C bit set to 1 MUST have the F bit set to 0.
いつが、1にセットして、このText Responseのテキスト(主要な=値組のセット)が完全でないことを示すか(それはその後のText Responsesで続けられるでしょう)。 さもなければ、それは、このText Responseが1セットの主要な=値組を終わらせるのを示します。 1に設定されたCビットがあるText ResponseはFビットを0に設定させなければなりません。
10.11.3. Initiator Task Tag
10.11.3. 創始者タスクタグ
The Initiator Task Tag matches the tag used in the initial Text Request.
Initiator Task Tagは初期のText Requestで使用されるタグに合っています。
10.11.4. Target Transfer Tag
10.11.4. 目標転送タグ
When a target has more work to do (e.g., cannot transfer all the remaining text data in a single Text Response or has to continue the negotiation) and has enough resources to proceed, it MUST set the Target Transfer Tag to a value other than the reserved value of 0xffffffff. Otherwise, the Target Transfer Tag MUST be set to 0xffffffff.
目標がしなければならない(例えば、独身のText Responseのすべての残っているテキストデータを移すことができなければならないというわけではありませんし、また交渉を続けなければなりません)より多くの仕事を持っていて、続くことができるくらいのリソースを持っているとき、それは0xffffffffの予約された値以外の値にTarget Transfer Tagを設定しなければなりません。 さもなければ、Target Transfer Tagは0xffffffffに用意ができなければなりません。
When the Target Transfer Tag is not 0xffffffff, the LUN field may be significant.
Target Transfer Tagが0xffffffffでないときに、LUN分野は重要であるかもしれません。
The initiator MUST copy the Target Transfer Tag and LUN in its next request to indicate that it wants the rest of the data.
創始者はデータの残りが欲しいのを示すという次の要求にTarget Transfer TagとLUNをコピーしなければなりません。
When the target receives a Text Request with the Target Transfer Tag set to the reserved value of 0xffffffff, it resets its internal information (resets state) associated with the given Initiator Task Tag (restarts the negotiation).
目標がTarget Transfer Tagセットで0xffffffffの予約された値にText Requestを受けるとき、それは与えられたInitiator Task Tag(交渉を再開する)に関連している内部の情報(状態をリセットする)をリセットします。
When a target cannot finish the operation in a single Text Response, and does not have enough resources to continue, it rejects the Text Request with the appropriate Reject code.
目標が独身のText Responseで操作を終えることができないで、続くことができるくらいのリソースを持っていないとき、それは適切なRejectコードでText Requestを拒絶します。
Satran, et al. Standards Track [Page 153] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[153ページ]。
A target may reset its internal state associated with an Initiator Task Tag (the current negotiation state), state expressed through the Target Transfer Tag if the initiator fails to continue the exchange for some time. The target may reject subsequent Text Requests with the Target Transfer Tag set to the "stale" value.
目標はInitiator Task Tag(現在の交渉状態)に関連している内部の状態、創始者がしばらく交換を続けていないならTarget Transfer Tagを通して言い表された状態をリセットするかもしれません。 目標はTarget Transfer Tagセットで「聞き古した」値にその後のText Requestsを拒絶するかもしれません。
10.11.5. StatSN
10.11.5. StatSN
The target StatSN variable is advanced by each Text Response sent.
目標StatSN変数はText Responseが送ったそれぞれによって進められます。
10.11.6. Text Response Data
10.11.6. テキスト応答データ
The data lengths of a text response MUST NOT exceed the iSCSI initiator MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter).
テキスト応答のデータの長さはiSCSI創始者MaxRecvDataSegmentLengthを超えてはいけません(接続と指示あたりのaはパラメタを交渉しました)。
The text in the Text Response Data is governed by the same rules as the text in the Text Request Data (see Section 10.10.5 Text).
Text Response DataのテキストはText Request Dataのテキストと同じ規則で支配されます(セクション10.10.5Textを見てください)。
Although the initiator is the requesting party and controls the request-response initiation and termination, the target can offer key=value pairs of its own as part of a sequence and not only in response to the initiator.
創始者は、要求パーティーであり、要求応答開始と終了を監督しますが、目標は単に創始者に対応した系列の一部としてそれ自身の主要な=値組を提供できます。
10.12. Login Request
10.12. ログイン要求
After establishing a TCP connection between an initiator and a target, the initiator MUST start a Login Phase to gain further access to the target's resources.
創始者と目標とのTCP接続を確立した後に、創始者は、目標のリソースへのさらなるアクセスを得るためにLogin Phaseを始動しなければなりません。
The Login Phase (see Chapter 5) consists of a sequence of Login Requests and Responses that carry the same Initiator Task Tag.
Login Phase(第5章を参照する)は同じInitiator Task Tagを運ぶLogin RequestsとResponsesの系列から成ります。
Login Requests are always considered as immediate.
ログインRequestsは即座であるといつもみなされます。
Satran, et al. Standards Track [Page 154] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[154ページ]。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| ISID |
+ +---------------+---------------+
12| | TSIH |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| CID | Reserved |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN or Reserved |
+---------------+---------------+---------------+---------------+
32| Reserved |
+---------------+---------------+---------------+---------------+
36| Reserved |
+---------------+---------------+---------------+---------------+
40/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48/ DataSegment - Login Parameters in Text request Format /
+/ /
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|1| 0×03|T|C|. | . | CSG|NSG| バージョン最大| バージョン分| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| ISID| + +---------------+---------------+ 12| | TSIH| +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| Cid| 予約されます。| +---------------+---------------+---------------+---------------+ 24| CmdSN| +---------------+---------------+---------------+---------------+ 28| ExpStatSNか予約されています。| +---------------+---------------+---------------+---------------+ 32| 予約されます。| +---------------+---------------+---------------+---------------+ 36| 予約されます。| +---------------+---------------+---------------+---------------+ 40/予約された/+//+---------------+---------------+---------------+---------------+48/ DataSegment--TextのログインParametersはFormat/+//+を要求します。---------------+---------------+---------------+---------------+
10.12.1. T (Transit) Bit
10.12.1. T(トランジット)ビット
If set to 1, indicates that the initiator is ready to transit to the next stage.
1に設定して、次の舞台に通過するために創始者が準備ができているのを示します。
If the T bit is set to 1 and NSG is FullFeaturePhase, then this also indicates that the initiator is ready for the Final Login Response (see Chapter 5).
また、Tビットが1に設定されて、NSGがFullFeaturePhaseであるなら、これは、創始者がFinal Login Responseの準備ができているのを示します(第5章を参照してください)。
10.12.2. C (Continue) Bit
10.12.2. C(続けている)ビット
When set to 1, indicates that the text (set of key=value pairs) in this Login Request is not complete (it will be continued on subsequent Login Requests); otherwise, it indicates that this Login Request ends a set of key=value pairs. A Login Request with the C bit set to 1 MUST have the T bit set to 0.
いつが、1にセットして、このLogin Requestのテキスト(主要な=値組のセット)が完全でないことを示すか(それはその後のLogin Requestsで続けられるでしょう)。 さもなければ、それは、このLogin Requestが1セットの主要な=値組を終わらせるのを示します。 1に設定されたCビットがあるLogin RequestはTビットを0に設定させなければなりません。
Satran, et al. Standards Track [Page 155] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[155ページ]。
10.12.3. CSG and NSG
10.12.3. CSGとNSG
Through these fields, Current Stage (CSG) and Next Stage (NSG), the Login negotiation requests and responses are associated with a specific stage in the session (SecurityNegotiation, LoginOperationalNegotiation, FullFeaturePhase) and may indicate the next stage to which they want to move (see Chapter 5). The next stage value is only valid when the T bit is 1; otherwise, it is reserved.
これらの分野を通って、Current Stage(CSG)、Next Stage(NSG)、Login交渉要求、および応答は、セッション(SecurityNegotiation、LoginOperationalNegotiation、FullFeaturePhase)のときに特定のステージに関連していて、それらが動きたがっている次のステージを示すかもしれません(第5章を参照してください)。 Tビットが1であるときにだけ、次のステージ値は有効です。 さもなければ、それは予約されています。
The stage codes are:
ステージコードは以下の通りです。
- 0 - SecurityNegotiation
- 1 - LoginOperationalNegotiation
- 3 - FullFeaturePhase
- 0--SecurityNegotiation--1--LoginOperationalNegotiation--3--FullFeaturePhase
All other codes are reserved.
他のすべてのコードが予約されています。
10.12.4. Version
10.12.4. バージョン
The version number of the current draft is 0x00. As such, all devices MUST carry version 0x00 for both Version-min and Version-max.
現在の草稿のバージョン番号は0×00です。 そういうものとして、すべての装置がバージョン分とバージョン最大の両方のためのバージョン0x00を運ばなければなりません。
10.12.4.1. Version-max
10.12.4.1. バージョン最大
Maximum Version number supported.
数が支持した最大のバージョン。
All Login Requests within the Login Phase MUST carry the same Version-max.
Login Phaseの中のすべてのLogin Requestsが同じバージョン最大を運ばなければなりません。
The target MUST use the value presented with the first Login Request.
目標は最初のLogin Requestが与えられた値を使用しなければなりません。
10.12.4.2. Version-min
10.12.4.2. バージョン分
All Login Requests within the Login Phase MUST carry the same Version-min. The target MUST use the value presented with the first Login Request.
Login Phaseの中のすべてのLogin Requestsが同じバージョン分を運ばなければなりません。 目標は最初のLogin Requestが与えられた値を使用しなければなりません。
Satran, et al. Standards Track [Page 156] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[156ページ]。
10.12.5. ISID
10.12.5. ISID
This is an initiator-defined component of the session identifier and is structured as follows (see [RFC3721] and Section 9.1.1 Conservative Reuse of ISIDs for details):
これは、セッション識別子の創始者によって定義された成分であり、以下の通り(詳細に関してISIDsの[RFC3721]とセクション9.1.1保守党員Reuseを見る)構造化されます:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
8| T | A | B | C |
+---------------+---------------+---------------+---------------+
12| D |
+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 8| T| A| B| C| +---------------+---------------+---------------+---------------+ 12| D| +---------------+---------------+
The T field identifies the format and usage of A, B, C, and D as indicated below:
T分野は以下に示すようにA、B、C、およびDの形式と用法を特定します:
T
T
00b OUI-Format
A&B are a 22 bit OUI
(the I/G & U/L bits are omitted)
C&D 24 bit qualifier
01b EN - Format (IANA Enterprise Number)
A - Reserved
B&C EN (IANA Enterprise Number)
D - Qualifier
10b "Random"
A - Reserved
B&C Random
D - Qualifier
11b A,B,C&D Reserved
D24は資格を与える人01b ENに噛み付きました--00b OUI-形式AとBは22ビットのOUI(I/GとU/Lビットは省略される)Cです、そして、形式(IANAエンタープライズNumber)A--予約されたB&C EN(IANAエンタープライズNumber)D(資格を与える人の10bの「無作為」のA)はB&C Random Dを予約しました--資格を与える人11b A、B、C、およびD Reserved
For the T field values 00b and 01b, a combination of A and B (for 00b) or B and C (for 01b) identifies the vendor or organization whose component (software or hardware) generates this ISID. A vendor or organization with one or more OUIs, or one or more Enterprise Numbers, MUST use at least one of these numbers and select the appropriate value for the T field when its components generate ISIDs. An OUI or EN MUST be set in the corresponding fields in network byte order (byte big-endian).
T分野値の00bと01bのために、AとB(00bのための)かBとC(01bのための)の組み合わせはコンポーネント(ソフトウェアかハードウェア)がこのISIDを発生させる業者か組織を特定します。 コンポーネントがISIDsを発生させると、1OUIs、または1つ以上のエンタープライズ民数記との業者か組織が、少なくともこれらの数の1つを使用して、適切な値をT分野に選択しなければなりません。 OUIかEN MUST、ネットワークバイトオーダー(バイトビッグエンディアン)における対応する分野に設定されてください。
If the T field is 10b, B and C are set to a random 24-bit unsigned integer value in network byte order (byte big-endian). See [RFC3721] for how this affects the principle of "conservative reuse".
T分野が10bであるなら、BとCはネットワークバイトオーダー(バイトビッグエンディアン)における無作為の24ビットの符号のない整数値に設定されます。 これがどう「保守的な再利用」の原則に影響するように、[RFC3721]を見てくださいか。
Satran, et al. Standards Track [Page 157] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[157ページ]。
The Qualifier field is a 16 or 24-bit unsigned integer value that provides a range of possible values for the ISID within the selected namespace. It may be set to any value within the constraints specified in the iSCSI protocol (see Section 3.4.3 Consequences of the Model and Section 9.1.1 Conservative Reuse of ISIDs).
Qualifier分野は、選択された名前空間の中でさまざまな可能な値をISIDに供給する16か24ビットの符号のない整数値です。 それはiSCSIプロトコルで指定された規制の中にどんな値にも設定されるかもしれません(Modelのセクション3.4.3ConsequencesとISIDsのセクション9.1.1保守党員Reuseを見てください)。
The T field value of 11b is reserved.
11bのT分野価値は予約されています。
If the ISID is derived from something assigned to a hardware adapter or interface by a vendor, as a preset default value, it MUST be configurable to a value assigned according to the SCSI port behavior desired by the system in which it is installed (see Section 9.1.1 Conservative Reuse of ISIDs and Section 9.1.2 iSCSI Name, ISID, and TPGT Use). The resultant ISID MUST also be persistent over power cycles, reboot, card swap, etc.
業者によってハードウェアアダプターかインタフェースに割り当てられた何かからISIDを得るなら、aがデフォルト値をあらかじめセットしたので、それがインストールされるシステムによって望まれていたSCSIポートの振舞いに従って割り当てられた値に構成可能であるに違いありません(セクション9.1のISIDsのセクション9.1.1保守党員Reuse、.2iSCSI Name、ISID、およびTPGT Useを見てください)。 結果のISID MUSTはまた、パワーサイクルの間、しつこく、リブートして、カードはスワッピングですなど。
10.12.6. TSIH
10.12.6. TSIH
TSIH must be set in the first Login Request. The reserved value 0 MUST be used on the first connection for a new session. Otherwise, the TSIH sent by the target at the conclusion of the successful login of the first connection for this session MUST be used. The TSIH identifies to the target the associated existing session for this new connection.
TSIHは最初のLogin Requestで用意ができなければなりません。 最初の接続のときに新しいセッションに予約された値0を使用しなければなりません。 さもなければ、このセッションのための最初の接続のうまくいっているログインの結論における目標によって送られたTSIHを使用しなければなりません。 TSIHはこの新しい接続のために関連既存のセッションを目標に特定します。
All Login Requests within a Login Phase MUST carry the same TSIH.
Login Phaseの中のすべてのLogin Requestsが同じTSIHを運ばなければなりません。
The target MUST check the value presented with the first Login Request and act as specified in Section 5.3.1 Login Phase Start.
目標はセクション5.3.1Login Phase Startの指定されるとしての最初のLogin Requestと行為が与えられた値をチェックしなければなりません。
10.12.7. Connection ID - CID
10.12.7. 接続ID--Cid
A unique ID for this connection within the session.
セッション中のこの接続のための固有のID。
All Login Requests within the Login Phase MUST carry the same CID.
Login Phaseの中のすべてのLogin Requestsが同じCIDを運ばなければなりません。
The target MUST use the value presented with the first Login Request.
目標は最初のLogin Requestが与えられた値を使用しなければなりません。
A Login Request with a non-zero TSIH and a CID equal to that of an existing connection implies a logout of the connection followed by a Login (see Section 5.3.4 Connection Reinstatement). For the details of the implicit Logout Request, see Section 10.14 Logout Request.
A Login RequestはTSIHと既存の接続のものへのCID同輩が暗示する非ゼロaでLoginによって続かれた接続にログアウトします(セクション5.3.4Connection Reinstatementを見てください)。 内在しているLogout Requestの細部に関しては、セクション10.14 Logout Requestを見てください。
Satran, et al. Standards Track [Page 158] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[158ページ]。
10.12.8. CmdSN
10.12.8. CmdSN
CmdSN is either the initial command sequence number of a session (for the first Login Request of a session - the "leading" login), or the command sequence number in the command stream if the login is for a new connection in an existing session.
ログインが既存のセッションにおける新しい接続のためのものであるなら、CmdSNはコマンドの流れにおいてセッション(セッションの最初のLogin Requestのために--「先導」はログインする)の初期のコマンド・シーケンス番号かコマンド・シーケンス番号のどちらかです。
Examples:
例:
- Login on a leading connection - if the leading login carries
the CmdSN 123, all other Login Requests in the same Login Phase
carry the CmdSN 123 and the first non-immediate command in
FullFeaturePhase also carries the CmdSN 123.
- 同じLogin Phaseの他のすべてのLogin RequestsがCmdSN123を運びます、そして、主なログインがCmdSN123を運ぶなら、主な接続のときにログインしてください、そして、また、FullFeaturePhaseにおける最初の非即座のコマンドはCmdSN123を運びます。
- Login on other than a leading connection - if the current CmdSN
at the time the first login on the connection is issued is 500,
then that PDU carries CmdSN=500. Subsequent Login Requests
that are needed to complete this Login Phase may carry a CmdSN
higher than 500 if non-immediate requests that were issued on
other connections in the same session advance CmdSN.
- 主な接続を除いた、進行中のログイン--接続の最初のログインが発行されるとき現在のCmdSNが500歳であるなら、そのPDUはCmdSN=500を運びます。 同じセッションにおける他の接続のときに出された非即座の要求がCmdSNを進めるなら、このLogin Phaseを完成するのが必要であるその後のLogin RequestsはCmdSNを500より上に運ぶかもしれません。
If the Login Request is a leading Login Request, the target MUST use the value presented in CmdSN as the target value for ExpCmdSN.
Login Requestが主なLogin Requestであるなら、目標はExpCmdSNに目標値としてCmdSNに提示された値を使用しなければなりません。
10.12.9. ExpStatSN
10.12.9. ExpStatSN
For the first Login Request on a connection this is ExpStatSN for the old connection and this field is only valid if the Login Request restarts a connection (see Section 5.3.4 Connection Reinstatement).
接続での最初のLogin Requestに関しては、これは年取った接続のためのExpStatSNです、そして、Login Requestが接続を再出発する場合にだけ(セクション5.3.4Connection Reinstatementを見てください)、この分野は有効です。
For subsequent Login Requests it is used to acknowledge the Login Responses with their increasing StatSN values.
その後のLogin Requestsに関しては、それは、彼らの増加するStatSN値があるLogin Responsesを承認するのに使用されます。
10.12.10. Login Parameters
10.12.10. ログインパラメタ
The initiator MUST provide some basic parameters in order to enable the target to determine if the initiator may use the target's resources and the initial text parameters for the security exchange.
創始者は、目標が、創始者がセキュリティ交換に目標のリソースと初期のテキストパラメタを使用するかもしれないかどうか決定するのを可能にするためにいくつかの基本のパラメタを提供しなければなりません。
All the rules specified in Section 10.10.5 Text for text requests also hold for Login Requests. Keys and their explanations are listed in Chapter 11 (security negotiation keys) and Chapter 12 (operational parameter negotiation keys). All keys in Chapter 12, except for the X extension formats, MUST be supported by iSCSI initiators and targets. Keys in Chapter 11 only need to be supported when the function to which they refer is mandatory to implement.
また、セクション10.10.5Textでテキスト要求に指定されたすべての規則がLogin Requestsのために成立します。 キーと彼らの説明は連邦破産法11条(セキュリティ交渉キー)と第12章(操作上のパラメタ交渉キー)にリストアップされています。 iSCSI創始者と目標でX拡大形式以外の第12章のすべてのキーを支えなければなりません。 連邦破産法11条のキーは、それらが参照する機能が実行するために義務的であるときに、支持される必要があるだけです。
Satran, et al. Standards Track [Page 159] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[159ページ]。
10.13. Login Response
10.13. ログイン応答
The Login Response indicates the progress and/or end of the Login Phase.
Login ResponseはLogin Phaseの進歩、そして/または、端を示します。
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max | Version-active|
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| ISID |
+ +---------------+---------------+
12| | TSIH |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| Status-Class | Status-Detail | Reserved |
+---------------+---------------+---------------+---------------+
40/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48/ DataSegment - Login Parameters in Text request Format /
+/ /
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0×23|T|C|. | . | CSG|NSG| バージョン最大| バージョンアクティブです。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| ISID| + +---------------+---------------+ 12| | TSIH| +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグ| +---------------+---------------+---------------+---------------+ 20| 予約されます。| +---------------+---------------+---------------+---------------+ 24| StatSN| +---------------+---------------+---------------+---------------+ 28| ExpCmdSN| +---------------+---------------+---------------+---------------+ 32| MaxCmdSN| +---------------+---------------+---------------+---------------+ 36| 状態クラス| 状態詳細| 予約されます。| +---------------+---------------+---------------+---------------+ 40/予約された/+//+---------------+---------------+---------------+---------------+48/ DataSegment--TextのログインParametersはFormat/+//+を要求します。---------------+---------------+---------------+---------------+
10.13.1. Version-max
10.13.1. バージョン最大
This is the highest version number supported by the target.
これは目標によって支持される中で最も大きいバージョン番号です。
All Login Responses within the Login Phase MUST carry the same Version-max.
Login Phaseの中のすべてのLogin Responsesが同じバージョン最大を運ばなければなりません。
The initiator MUST use the value presented as a response to the first Login Request.
創始者は最初のLogin Requestへの応答として提示された値を使用しなければなりません。
Satran, et al. Standards Track [Page 160] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[160ページ]。
10.13.2. Version-active
10.13.2. バージョンアクティブです。
Indicates the highest version supported by the target and initiator. If the target does not support a version within the range specified by the initiator, the target rejects the login and this field indicates the lowest version supported by the target.
目標と創始者によって支持された中で最も高いバージョンを示します。 目標が創始者によって指定された範囲の中でバージョンを支持しないなら、目標はログインを拒絶します、そして、この分野は目標によって支持される中で最も低いバージョンを示します。
All Login Responses within the Login Phase MUST carry the same Version-active.
Login Phaseの中のすべてのLogin Responsesが同じようにバージョンアクティブな状態で運ばなければなりません。
The initiator MUST use the value presented as a response to the first Login Request.
創始者は最初のLogin Requestへの応答として提示された値を使用しなければなりません。
10.13.3. TSIH
10.13.3. TSIH
The TSIH is the target assigned session identifying handle. Its internal format and content are not defined by this protocol except for the value 0 that is reserved. With the exception of the Login Final-Response in a new session, this field should be set to the TSIH provided by the initiator in the Login Request. For a new session, the target MUST generate a non-zero TSIH and ONLY return it in the Login Final-Response (see Section 5.3 Login Phase).
TSIHはセッション特定ハンドルが割り当てられた目標です。 その内部の書式と内容は予約された値0以外のこのプロトコルによって定義されません。 新しいセッションにおけるLogin Final-応答を除いて、この分野はLogin Requestの創始者によって提供されたTSIHに設定されるべきです。 新しいセッションのために、目標は、非ゼロTSIHを発生させて、Login Final-応答でそれを返すだけでよいです(セクション5.3 Login Phaseを見てください)。
10.13.4. StatSN
10.13.4. StatSN
For the first Login Response (the response to the first Login Request), this is the starting status Sequence Number for the connection. The next response of any kind, including the next Login Response, if any, in the same Login Phase, will carry this number + 1. This field is only valid if the Status-Class is 0.
最初のLogin Response(最初のLogin Requestへの応答)に関しては、これは接続のための始めの状態Sequence Numberです。 同じLogin Phaseにもしあれば次のLogin Responseを含むどんな種類の次の応答もこの数+1つを運ぶでしょう。 この分野はStatus-クラスが0である場合にだけ有効です。
10.13.5. Status-Class and Status-Detail
10.13.5. 状態クラスと状態詳細
The Status returned in a Login Response indicates the execution status of the Login Phase. The status includes:
Login Responseで返されたStatusはLogin Phaseの実行状態を示します。 状態は:
Status-Class
Status-Detail
状態クラス状態詳細
0 Status-Class indicates success.
0状態クラスは成功を示します。
A non-zero Status-Class indicates an exception. In this case, Status-Class is sufficient for a simple initiator to use when handling exceptions, without having to look at the Status-Detail. The Status-Detail allows finer-grained exception handling for more sophisticated initiators and for better information for logging.
非ゼロのStatus-クラスは例外を示します。 この場合、例外を扱うとき、純真な創始者が使用するように、Status-クラスは十分です、Status-詳細を見る必要はなくて。 Status-詳細は、より洗練された創始者と伐採のための、より良い情報のための、よりきめ細かに粒状の例外処理を許容します。
Satran, et al. Standards Track [Page 161] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[161ページ]。
The status classes are as follows:
状態のクラスは以下の通りです:
0 - Success - indicates that the iSCSI target successfully
received, understood, and accepted the request. The numbering
fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if
Status-Class is 0.
0(成功)はiSCSI目標が首尾よく受信して、分かって、要請を受け入れたのを示します。 付番分野(StatSN、ExpCmdSN、MaxCmdSN)はStatus-クラスが0である場合にだけ有効です。
1 - Redirection - indicates that the initiator must take further
action to complete the request. This is usually due to the
target moving to a different address. All of the redirection
status class responses MUST return one or more text key
parameters of the type "TargetAddress", which indicates the
target's new address. A redirection response MAY be issued by
a target prior or after completing a security negotiation if a
security negotiation is required. A redirection SHOULD be
accepted by an initiator even without having the target
complete a security negotiation if any security negotiation is
required, and MUST be accepted by the initiator after the
completion of the security negotiation if any security
negotiation is required.
1(リダイレクション)は、創始者が要求を終了するためにさらなる行動を取らなければならないのを示します。 これは通常、異なったアドレスに動く目標のためです。 リダイレクション状態クラス応答のすべてが目標の新しいアドレスを示すタイプ「TargetAddress」の1つ以上のテキストの主要なパラメタを返さなければなりません。 優先的かセキュリティ交渉が必要であるならセキュリティ交渉を終了した後に、リダイレクション応答は目標によって発行されるかもしれません。 リダイレクションSHOULDを何かセキュリティ交渉が必要であるなら目標にセキュリティ交渉を終了さえさせないで創始者によって受け入れられて、何かセキュリティ交渉が必要であるなら、創始者はセキュリティ交渉の完成の後に受け入れなければなりません。
2 - Initiator Error (not a format error) - indicates that the
initiator most likely caused the error. This MAY be due to a
request for a resource for which the initiator does not have
permission. The request should not be tried again.
2(創始者Error(形式誤りでない))は、創始者がたぶん誤りを引き起こしたのを示します。 これは創始者が許可を持っていないリソースに関する要求のためであるかもしれません。 再び要求を試みるべきではありません。
3 - Target Error - indicates that the target sees no errors in the
initiator's Login Request, but is currently incapable of
fulfilling the request. The initiator may re-try the same
Login Request later.
3(目標Error)は、目標が創始者のLogin Requestの誤りを全く見ませんが、現在要求を実現させることができないのを示します。 創始者は後で同じLogin Requestを再試行するかもしれません。
The table below shows all of the currently allocated status codes. The codes are in hexadecimal; the first byte is the status class and the second byte is the status detail.
以下のテーブルは現在割り当てられたステータスコードのすべてを示しています。 16進にはコードがあります。 最初のバイトは状態のクラスです、そして、2番目のバイトは状態の詳細です。
-----------------------------------------------------------------
Status | Code | Description
|(hex) |
-----------------------------------------------------------------
Success | 0000 | Login is proceeding OK (*1).
-----------------------------------------------------------------
Target moved | 0101 | The requested iSCSI Target Name (ITN)
temporarily | | has temporarily moved
| | to the address provided.
-----------------------------------------------------------------
Target moved | 0102 | The requested ITN has permanently moved
permanently | | to the address provided.
-----------------------------------------------------------------
----------------------------------------------------------------- Status | Code | Description |(hex) | ----------------------------------------------------------------- Success | 0000 | Login is proceeding OK (*1). ----------------------------------------------------------------- Target moved | 0101 | The requested iSCSI Target Name (ITN) temporarily | | has temporarily moved | | to the address provided. ----------------------------------------------------------------- Target moved | 0102 | The requested ITN has permanently moved permanently | | to the address provided. -----------------------------------------------------------------
Satran, et al. Standards Track [Page 162] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 162] RFC 3720 iSCSI April 2004
Initiator | 0200 | Miscellaneous iSCSI initiator
error | | errors.
----------------------------------------------------------------
Authentication| 0201 | The initiator could not be
failure | | successfully authenticated or target
| | authentication is not supported.
-----------------------------------------------------------------
Authorization | 0202 | The initiator is not allowed access
failure | | to the given target.
-----------------------------------------------------------------
Not found | 0203 | The requested ITN does not
| | exist at this address.
-----------------------------------------------------------------
Target removed| 0204 | The requested ITN has been removed and
| |no forwarding address is provided.
-----------------------------------------------------------------
Unsupported | 0205 | The requested iSCSI version range is
version | | not supported by the target.
-----------------------------------------------------------------
Too many | 0206 | Too many connections on this SSID.
connections | |
-----------------------------------------------------------------
Missing | 0207 | Missing parameters (e.g., iSCSI
parameter | | Initiator and/or Target Name).
-----------------------------------------------------------------
Can't include | 0208 | Target does not support session
in session | | spanning to this connection (address).
-----------------------------------------------------------------
Session type | 0209 | Target does not support this type of
not supported | | of session or not from this Initiator.
-----------------------------------------------------------------
Session does | 020a | Attempt to add a connection
not exist | | to a non-existent session.
-----------------------------------------------------------------
Invalid during| 020b | Invalid Request type during Login.
login | |
-----------------------------------------------------------------
Target error | 0300 | Target hardware or software error.
-----------------------------------------------------------------
Service | 0301 | The iSCSI service or target is not
unavailable | | currently operational.
-----------------------------------------------------------------
Out of | 0302 | The target has insufficient session,
resources | | connection, or other resources.
-----------------------------------------------------------------
Initiator | 0200 | Miscellaneous iSCSI initiator error | | errors. ---------------------------------------------------------------- Authentication| 0201 | The initiator could not be failure | | successfully authenticated or target | | authentication is not supported. ----------------------------------------------------------------- Authorization | 0202 | The initiator is not allowed access failure | | to the given target. ----------------------------------------------------------------- Not found | 0203 | The requested ITN does not | | exist at this address. ----------------------------------------------------------------- Target removed| 0204 | The requested ITN has been removed and | |no forwarding address is provided. ----------------------------------------------------------------- Unsupported | 0205 | The requested iSCSI version range is version | | not supported by the target. ----------------------------------------------------------------- Too many | 0206 | Too many connections on this SSID. connections | | ----------------------------------------------------------------- Missing | 0207 | Missing parameters (e.g., iSCSI parameter | | Initiator and/or Target Name). ----------------------------------------------------------------- Can't include | 0208 | Target does not support session in session | | spanning to this connection (address). ----------------------------------------------------------------- Session type | 0209 | Target does not support this type of not supported | | of session or not from this Initiator. ----------------------------------------------------------------- Session does | 020a | Attempt to add a connection not exist | | to a non-existent session. ----------------------------------------------------------------- Invalid during| 020b | Invalid Request type during Login. login | | ----------------------------------------------------------------- Target error | 0300 | Target hardware or software error. ----------------------------------------------------------------- Service | 0301 | The iSCSI service or target is not unavailable | | currently operational. ----------------------------------------------------------------- Out of | 0302 | The target has insufficient session, resources | | connection, or other resources. -----------------------------------------------------------------
Satran, et al. Standards Track [Page 163] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 163] RFC 3720 iSCSI April 2004
(*1) If the response T bit is 1 in both the request and the matching response, and the NSG is FullFeaturePhase in both the request and the matching response, the Login Phase is finished and the initiator may proceed to issue SCSI commands.
(*1) If the response T bit is 1 in both the request and the matching response, and the NSG is FullFeaturePhase in both the request and the matching response, the Login Phase is finished and the initiator may proceed to issue SCSI commands.
If the Status Class is not 0, the initiator and target MUST close the TCP connection.
If the Status Class is not 0, the initiator and target MUST close the TCP connection.
If the target wishes to reject the Login Request for more than one reason, it should return the primary reason for the rejection.
If the target wishes to reject the Login Request for more than one reason, it should return the primary reason for the rejection.
10.13.6. T (Transit) bit
10.13.6. T (Transit) bit
The T bit is set to 1 as an indicator of the end of the stage. If the T bit is set to 1 and NSG is FullFeaturePhase, then this is also the Final Login Response (see Chapter 5). A T bit of 0 indicates a "partial" response, which means "more negotiation needed".
The T bit is set to 1 as an indicator of the end of the stage. If the T bit is set to 1 and NSG is FullFeaturePhase, then this is also the Final Login Response (see Chapter 5). A T bit of 0 indicates a "partial" response, which means "more negotiation needed".
A Login Response with a T bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator within the same stage.
A Login Response with a T bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator within the same stage.
If the status class is 0, the T bit MUST NOT be set to 1 if the T bit in the request was set to 0.
If the status class is 0, the T bit MUST NOT be set to 1 if the T bit in the request was set to 0.
10.13.7. C (Continue) Bit
10.13.7. C (Continue) Bit
When set to 1, indicates that the text (set of key=value pairs) in this Login Response is not complete (it will be continued on subsequent Login Responses); otherwise, it indicates that this Login Response ends a set of key=value pairs. A Login Response with the C bit set to 1 MUST have the T bit set to 0.
When set to 1, indicates that the text (set of key=value pairs) in this Login Response is not complete (it will be continued on subsequent Login Responses); otherwise, it indicates that this Login Response ends a set of key=value pairs. A Login Response with the C bit set to 1 MUST have the T bit set to 0.
10.13.8. Login Parameters
10.13.8. Login Parameters
The target MUST provide some basic parameters in order to enable the initiator to determine if it is connected to the correct port and the initial text parameters for the security exchange.
The target MUST provide some basic parameters in order to enable the initiator to determine if it is connected to the correct port and the initial text parameters for the security exchange.
All the rules specified in Section 10.11.6 Text Response Data for text responses also hold for Login Responses. Keys and their explanations are listed in Chapter 11 (security negotiation keys) and Chapter 12 (operational parameter negotiation keys). All keys in Chapter 12, except for the X extension formats, MUST be supported by iSCSI initiators and targets. Keys in Chapter 11, only need to be supported when the function to which they refer is mandatory to implement.
All the rules specified in Section 10.11.6 Text Response Data for text responses also hold for Login Responses. Keys and their explanations are listed in Chapter 11 (security negotiation keys) and Chapter 12 (operational parameter negotiation keys). All keys in Chapter 12, except for the X extension formats, MUST be supported by iSCSI initiators and targets. Keys in Chapter 11, only need to be supported when the function to which they refer is mandatory to implement.
Satran, et al. Standards Track [Page 164] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 164] RFC 3720 iSCSI April 2004
10.14. Logout Request
10.14. Logout Request
The Logout Request is used to perform a controlled closing of a connection.
The Logout Request is used to perform a controlled closing of a connection.
An initiator MAY use a Logout Request to remove a connection from a session or to close an entire session.
An initiator MAY use a Logout Request to remove a connection from a session or to close an entire session.
After sending the Logout Request PDU, an initiator MUST NOT send any new iSCSI requests on the closing connection. If the Logout Request is intended to close the session, new iSCSI requests MUST NOT be sent on any of the connections participating in the session.
After sending the Logout Request PDU, an initiator MUST NOT send any new iSCSI requests on the closing connection. If the Logout Request is intended to close the session, new iSCSI requests MUST NOT be sent on any of the connections participating in the session.
When receiving a Logout Request with the reason code of "close the connection" or "close the session", the target MUST terminate all pending commands, whether acknowledged via ExpCmdSN or not, on that connection or session respectively.
When receiving a Logout Request with the reason code of "close the connection" or "close the session", the target MUST terminate all pending commands, whether acknowledged via ExpCmdSN or not, on that connection or session respectively.
When receiving a Logout Request with the reason code "remove connection for recovery", the target MUST discard all requests not yet acknowledged via ExpCmdSN that were issued on the specified connection, and suspend all data/status/R2T transfers on behalf of pending commands on the specified connection.
When receiving a Logout Request with the reason code "remove connection for recovery", the target MUST discard all requests not yet acknowledged via ExpCmdSN that were issued on the specified connection, and suspend all data/status/R2T transfers on behalf of pending commands on the specified connection.
The target then issues the Logout Response and half-closes the TCP connection (sends FIN). After receiving the Logout Response and attempting to receive the FIN (if still possible), the initiator MUST completely close the logging-out connection. For the terminated commands, no additional responses should be expected.
The target then issues the Logout Response and half-closes the TCP connection (sends FIN). After receiving the Logout Response and attempting to receive the FIN (if still possible), the initiator MUST completely close the logging-out connection. For the terminated commands, no additional responses should be expected.
A Logout for a CID may be performed on a different transport connection when the TCP connection for the CID has already been terminated. In such a case, only a logical "closing" of the iSCSI connection for the CID is implied with a Logout.
A Logout for a CID may be performed on a different transport connection when the TCP connection for the CID has already been terminated. In such a case, only a logical "closing" of the iSCSI connection for the CID is implied with a Logout.
All commands that were not terminated or not completed (with status) and acknowledged when the connection is closed completely can be reassigned to a new connection if the target supports connection recovery.
All commands that were not terminated or not completed (with status) and acknowledged when the connection is closed completely can be reassigned to a new connection if the target supports connection recovery.
If an initiator intends to start recovery for a failing connection, it MUST use the Logout Request to "clean-up" the target end of a failing connection and enable recovery to start, or the Login Request with a non-zero TSIH and the same CID on a new connection for the same effect (see Section 10.14.3 CID). In sessions with a single connection, the connection can be closed and then a new connection reopened. A connection reinstatement login can be used for recovery (see Section 5.3.4 Connection Reinstatement).
If an initiator intends to start recovery for a failing connection, it MUST use the Logout Request to "clean-up" the target end of a failing connection and enable recovery to start, or the Login Request with a non-zero TSIH and the same CID on a new connection for the same effect (see Section 10.14.3 CID). In sessions with a single connection, the connection can be closed and then a new connection reopened. A connection reinstatement login can be used for recovery (see Section 5.3.4 Connection Reinstatement).
Satran, et al. Standards Track [Page 165] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 165] RFC 3720 iSCSI April 2004
A successful completion of a Logout Request with the reason code of "close the connection" or "remove the connection for recovery" results at the target in the discarding of unacknowledged commands received on the connection being logged out. These are commands that have arrived on the connection being logged out, but have not been delivered to SCSI because one or more commands with a smaller CmdSN has not been received by iSCSI. See Section 3.2.2.1 Command Numbering and Acknowledging. The resulting holes the in command sequence numbers will have to be handled by appropriate recovery (see Chapter 6) unless the session is also closed.
A successful completion of a Logout Request with the reason code of "close the connection" or "remove the connection for recovery" results at the target in the discarding of unacknowledged commands received on the connection being logged out. These are commands that have arrived on the connection being logged out, but have not been delivered to SCSI because one or more commands with a smaller CmdSN has not been received by iSCSI. See Section 3.2.2.1 Command Numbering and Acknowledging. The resulting holes the in command sequence numbers will have to be handled by appropriate recovery (see Chapter 6) unless the session is also closed.
The entire logout discussion in this section is also applicable for an implicit Logout realized via a connection reinstatement or session reinstatement. When a Login Request performs an implicit Logout, the implicit Logout is performed as if having the reason codes specified below:
The entire logout discussion in this section is also applicable for an implicit Logout realized via a connection reinstatement or session reinstatement. When a Login Request performs an implicit Logout, the implicit Logout is performed as if having the reason codes specified below:
Reason code Type of implicit Logout
-------------------------------------------
0 session reinstatement
1 connection reinstatement when
the operational ErrorRecoveryLevel < 2
2 connection reinstatement when
the operational ErrorRecoveryLevel = 2
Reason code Type of implicit Logout ------------------------------------------- 0 session reinstatement 1 connection reinstatement when the operational ErrorRecoveryLevel < 2 2 connection reinstatement when the operational ErrorRecoveryLevel = 2
Satran, et al. Standards Track [Page 166] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 166] RFC 3720 iSCSI April 2004
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|I| 0x06 |1| Reason Code | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------------------------------------------------------+
8/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| CID or Reserved | Reserved |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|I| 0x06 |1| Reason Code | Reserved | +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------------------------------------------------------+ 8/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| CID or Reserved | Reserved | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Header-Digest (Optional) | +---------------+---------------+---------------+---------------+
10.14.1. Reason Code
10.14.1. Reason Code
Reason Code indicates the reason for Logout as follows:
Reason Code indicates the reason for Logout as follows:
0 - close the session. All commands associated with the session
(if any) are terminated.
0 - close the session. All commands associated with the session (if any) are terminated.
1 - close the connection. All commands associated with connection
(if any) are terminated.
1 - close the connection. All commands associated with connection (if any) are terminated.
2 - remove the connection for recovery. Connection is closed and
all commands associated with it, if any, are to be prepared
for a new allegiance.
2 - remove the connection for recovery. Connection is closed and all commands associated with it, if any, are to be prepared for a new allegiance.
All other values are reserved.
All other values are reserved.
Satran, et al. Standards Track [Page 167] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 167] RFC 3720 iSCSI April 2004
10.14.2. TotalAHSLength and DataSegmentLength
10.14.2. TotalAHSLength and DataSegmentLength
For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
10.14.3. CID
10.14.3. CID
This is the connection ID of the connection to be closed (including closing the TCP stream). This field is only valid if the reason code is not "close the session".
This is the connection ID of the connection to be closed (including closing the TCP stream). This field is only valid if the reason code is not "close the session".
10.14.4. ExpStatSN
10.14.4. ExpStatSN
This is the last ExpStatSN value for the connection to be closed.
This is the last ExpStatSN value for the connection to be closed.
10.14.5. Implicit termination of tasks
10.14.5. Implicit termination of tasks
A target implicitly terminates the active tasks due to the iSCSI protocol in the following cases:
A target implicitly terminates the active tasks due to the iSCSI protocol in the following cases:
a) When a connection is implicitly or explicitly logged out with
the reason code of "Close the connection" and there are active
tasks allegiant to that connection.
a) When a connection is implicitly or explicitly logged out with the reason code of "Close the connection" and there are active tasks allegiant to that connection.
b) When a connection fails and eventually the connection state
times out (state transition M1 in Section 7.2.2 State
Transition Descriptions for Initiators and Targets) and there
are active tasks allegiant to that connection.
b) When a connection fails and eventually the connection state times out (state transition M1 in Section 7.2.2 State Transition Descriptions for Initiators and Targets) and there are active tasks allegiant to that connection.
c) When a successful recovery Logout is performed while there are
active tasks allegiant to that connection, and those tasks
eventually time out after the Time2Wait and Time2Retain
periods without allegiance reassignment.
c) When a successful recovery Logout is performed while there are active tasks allegiant to that connection, and those tasks eventually time out after the Time2Wait and Time2Retain periods without allegiance reassignment.
d) When a connection is implicitly or explicitly logged out with
the reason code of "Close the session" and there are active
tasks in that session.
d) When a connection is implicitly or explicitly logged out with the reason code of "Close the session" and there are active tasks in that session.
If the tasks terminated in any of the above cases are SCSI tasks, they must be internally terminated as if with CHECK CONDITION status. This status is only meaningful for appropriately handling the internal SCSI state and SCSI side effects with respect to ordering because this status is never communicated back as a terminating status to the initiator. However additional actions may have to be taken at SCSI level depending on the SCSI context as defined by the SCSI standards (e.g., queued commands and ACA, in cases a), b), and c), after the tasks are terminated, the target MUST report a Unit Attention condition on the next command processed on any connection for each affected I_T_L nexus with the status of CHECK CONDITION, and
If the tasks terminated in any of the above cases are SCSI tasks, they must be internally terminated as if with CHECK CONDITION status. This status is only meaningful for appropriately handling the internal SCSI state and SCSI side effects with respect to ordering because this status is never communicated back as a terminating status to the initiator. However additional actions may have to be taken at SCSI level depending on the SCSI context as defined by the SCSI standards (e.g., queued commands and ACA, in cases a), b), and c), after the tasks are terminated, the target MUST report a Unit Attention condition on the next command processed on any connection for each affected I_T_L nexus with the status of CHECK CONDITION, and
Satran, et al. Standards Track [Page 168] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 168] RFC 3720 iSCSI April 2004
the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT" - etc. - see [SAM2] and [SPC3]).
the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT" - etc. - see [SAM2] and [SPC3]).
10.15. Logout Response
10.15. Logout Response
The Logout Response is used by the target to indicate if the cleanup operation for the connection(s) has completed.
The Logout Response is used by the target to indicate if the cleanup operation for the connection(s) has completed.
After Logout, the TCP connection referred by the CID MUST be closed at both ends (or all connections must be closed if the logout reason was session close).
After Logout, the TCP connection referred by the CID MUST be closed at both ends (or all connections must be closed if the logout reason was session close).
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x26 |1| Reserved | Response | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------------------------------------------------------+
8/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| Reserved |
+---------------------------------------------------------------+
40| Time2Wait | Time2Retain |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|.| 0x26 |1| Reserved | Response | Reserved | +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------------------------------------------------------+ 8/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36| Reserved | +---------------------------------------------------------------+ 40| Time2Wait | Time2Retain | +---------------+---------------+---------------+---------------+ 44| Reserved | +---------------+---------------+---------------+---------------+ 48| Header-Digest (Optional) | +---------------+---------------+---------------+---------------+
Satran, et al. Standards Track [Page 169] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 169] RFC 3720 iSCSI April 2004
10.15.1. Response
10.15.1. Response
Logout Response:
Logout Response:
0 - connection or session closed successfully.
0 - connection or session closed successfully.
1 - CID not found.
1 - CID not found.
2 - connection recovery is not supported. If Logout reason code
was recovery and target does not support it as indicated by the
ErrorRecoveryLevel.
2 - connection recovery is not supported. If Logout reason code was recovery and target does not support it as indicated by the ErrorRecoveryLevel.
3 - cleanup failed for various reasons.
3 - cleanup failed for various reasons.
10.15.2. TotalAHSLength and DataSegmentLength
10.15.2. TotalAHSLength and DataSegmentLength
For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
10.15.3. Time2Wait
10.15.3. Time2Wait
If the Logout Response code is 0 and if the operational ErrorRecoveryLevel is 2, this is the minimum amount of time, in seconds, to wait before attempting task reassignment. If the Logout Response code is 0 and if the operational ErrorRecoveryLevel is less than 2, this field is to be ignored.
If the Logout Response code is 0 and if the operational ErrorRecoveryLevel is 2, this is the minimum amount of time, in seconds, to wait before attempting task reassignment. If the Logout Response code is 0 and if the operational ErrorRecoveryLevel is less than 2, this field is to be ignored.
This field is invalid if the Logout Response code is 1.
This field is invalid if the Logout Response code is 1.
If the Logout response code is 2 or 3, this field specifies the minimum time to wait before attempting a new implicit or explicit logout.
If the Logout response code is 2 or 3, this field specifies the minimum time to wait before attempting a new implicit or explicit logout.
If Time2Wait is 0, the reassignment or a new Logout may be attempted immediately.
If Time2Wait is 0, the reassignment or a new Logout may be attempted immediately.
10.15.4. Time2Retain
10.15.4. Time2Retain
If the Logout response code is 0 and if the operational ErrorRecoveryLevel is 2, this is the maximum amount of time, in seconds, after the initial wait (Time2Wait), the target waits for the allegiance reassignment for any active task after which the task state is discarded. If the Logout response code is 0 and if the operational ErrorRecoveryLevel is less than 2, this field is to be ignored.
If the Logout response code is 0 and if the operational ErrorRecoveryLevel is 2, this is the maximum amount of time, in seconds, after the initial wait (Time2Wait), the target waits for the allegiance reassignment for any active task after which the task state is discarded. If the Logout response code is 0 and if the operational ErrorRecoveryLevel is less than 2, this field is to be ignored.
This field is invalid if the Logout response code is 1.
This field is invalid if the Logout response code is 1.
Satran, et al. Standards Track [Page 170] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 170] RFC 3720 iSCSI April 2004
If the Logout response code is 2 or 3, this field specifies the maximum amount of time, in seconds, after the initial wait (Time2Wait), the target waits for a new implicit or explicit logout.
If the Logout response code is 2 or 3, this field specifies the maximum amount of time, in seconds, after the initial wait (Time2Wait), the target waits for a new implicit or explicit logout.
If it is the last connection of a session, the whole session state is discarded after Time2Retain.
If it is the last connection of a session, the whole session state is discarded after Time2Retain.
If Time2Retain is 0, the target has already discarded the connection (and possibly the session) state along with the task states. No reassignment or Logout is required in this case.
If Time2Retain is 0, the target has already discarded the connection (and possibly the session) state along with the task states. No reassignment or Logout is required in this case.
10.16. SNACK Request
10.16. SNACK Request
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x10 |1|.|.|.| Type | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or SNACK Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| Reserved |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
40| BegRun |
+---------------------------------------------------------------+
44| RunLength |
+---------------------------------------------------------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|.| 0x10 |1|.|.|.| Type | Reserved | +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| LUN or Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 20| Target Transfer Tag or SNACK Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| Reserved | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 40| BegRun | +---------------------------------------------------------------+ 44| RunLength | +---------------------------------------------------------------+ 48| Header-Digest (Optional) | +---------------+---------------+---------------+---------------+
If the implementation supports ErrorRecoveryLevel greater than zero, it MUST support all SNACK types.
If the implementation supports ErrorRecoveryLevel greater than zero, it MUST support all SNACK types.
Satran, et al. Standards Track [Page 171] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 171] RFC 3720 iSCSI April 2004
The SNACK is used by the initiator to request the retransmission of numbered-responses, data, or R2T PDUs from the target. The SNACK request indicates the numbered-responses or data "runs" whose retransmission is requested by the target, where the run starts with the first StatSN, DataSN, or R2TSN whose retransmission is requested and indicates the number of Status, Data, or R2T PDUs requested including the first. 0 has special meaning when used as a starting number and length:
The SNACK is used by the initiator to request the retransmission of numbered-responses, data, or R2T PDUs from the target. The SNACK request indicates the numbered-responses or data "runs" whose retransmission is requested by the target, where the run starts with the first StatSN, DataSN, or R2TSN whose retransmission is requested and indicates the number of Status, Data, or R2T PDUs requested including the first. 0 has special meaning when used as a starting number and length:
- When used in RunLength, it means all PDUs starting with the
initial.
- When used in both BegRun and RunLength, it means all
unacknowledged PDUs.
- When used in RunLength, it means all PDUs starting with the initial. - When used in both BegRun and RunLength, it means all unacknowledged PDUs.
The numbered-response(s) or R2T(s), requested by a SNACK, MUST be delivered as exact replicas of the ones that the target transmitted originally except for the fields ExpCmdSN, MaxCmdSN, and ExpDataSN, which MUST carry the current values. R2T(s)requested by SNACK MUST also carry the current value of StatSN.
The numbered-response(s) or R2T(s), requested by a SNACK, MUST be delivered as exact replicas of the ones that the target transmitted originally except for the fields ExpCmdSN, MaxCmdSN, and ExpDataSN, which MUST carry the current values. R2T(s)requested by SNACK MUST also carry the current value of StatSN.
The numbered Data-In PDUs, requested by a Data SNACK MUST be delivered as exact replicas of the ones that the target transmitted originally except for the fields ExpCmdSN and MaxCmdSN, which MUST carry the current values and except for resegmentation (see Section 10.16.3 Resegmentation).
The numbered Data-In PDUs, requested by a Data SNACK MUST be delivered as exact replicas of the ones that the target transmitted originally except for the fields ExpCmdSN and MaxCmdSN, which MUST carry the current values and except for resegmentation (see Section 10.16.3 Resegmentation).
Any SNACK that requests a numbered-response, Data, or R2T that was not sent by the target or was already acknowledged by the initiator, MUST be rejected with a reason code of "Protocol error".
Any SNACK that requests a numbered-response, Data, or R2T that was not sent by the target or was already acknowledged by the initiator, MUST be rejected with a reason code of "Protocol error".
10.16.1. Type
10.16.1. Type
This field encodes the SNACK function as follows:
This field encodes the SNACK function as follows:
0-Data/R2T SNACK - requesting retransmission of one or more Data-
In or R2T PDUs.
0-Data/R2T SNACK - requesting retransmission of one or more Data- In or R2T PDUs.
1-Status SNACK - requesting retransmission of one or more numbered
responses.
1-Status SNACK - requesting retransmission of one or more numbered responses.
2-DataACK - positively acknowledges Data-In PDUs.
2-DataACK - positively acknowledges Data-In PDUs.
3-R-Data SNACK - requesting retransmission of Data-In PDUs with
possible resegmentation and status tagging.
3-R-Data SNACK - requesting retransmission of Data-In PDUs with possible resegmentation and status tagging.
Satran, et al. Standards Track [Page 172] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 172] RFC 3720 iSCSI April 2004
All other values are reserved.
All other values are reserved.
Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST precede status acknowledgement for the given command.
Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST precede status acknowledgement for the given command.
10.16.2. Data Acknowledgement
10.16.2. Data Acknowledgement
If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the A bit set to 1. However, if the initiator has detected holes in the input sequence, it MUST postpone issuing the SNACK of type DataACK until the holes are filled. An initiator MAY ignore the A bit if it deems that the bit is being set aggressively by the target (i.e., before the MaxBurstLength limit is reached).
創始者がErrorRecoveryLevelより多くの1で働いているなら、1に設定されたAビットで中のData PDUを受けた後に、それはタイプDataACKのSNACKを発行しなければなりません。 しかしながら、創始者が入力系列の穴を検出したなら、それは、穴がいっぱいにされるまでタイプDataACKのSNACKを発行するのを延期しなければなりません。 ビットが目標によって積極的に設定されていると考えるなら(すなわち、MaxBurstLength限界に達する前に)、創始者はAビットを無視するかもしれません。
The DataACK is used to free resources at the target and not to request or imply data retransmission.
DataACKは、データ再送を目標でリソースを解放して、要求するか、または含意しないように使用されます。
An initiator MUST NOT request retransmission for any data it had already acknowledged.
創始者はそれが既に承認したどんなデータのためにも「再-トランスミッション」を要求してはいけません。
10.16.3. Resegmentation
10.16.3. Resegmentation
If the initiator MaxRecvDataSegmentLength changed between the original transmission and the time the initiator requests retransmission, the initiator MUST issue a R-Data SNACK (see Section 10.16.1 Type). With R-Data SNACK, the initiator indicates that it discards all the unacknowledged data and expects the target to resend it. It also expects resegmentation. In this case, the retransmitted Data-In PDUs MAY be different from the ones originally sent in order to reflect changes in MaxRecvDataSegmentLength. Their DataSN starts with the BegRun of the last DataACK received by the target if any was received; otherwise it starts with 0 and is increased by 1 for each resent Data-In PDU.
創始者MaxRecvDataSegmentLengthがオリジナルのトランスミッションと創始者が「再-トランスミッション」を要求する時の間で変化したなら、創始者はR-データSNACKを発行しなければなりません(セクション10.16.1Typeを見てください)。 創始者は、R-データSNACKと共に、すべての不承認のデータを捨てるのを示して、目標がそれを再送すると予想します。 また、それは「再-分割」を予想します。 この場合、再送された中のData PDUsは元々MaxRecvDataSegmentLengthにおける変化を反映するために送られたものと異なっているかもしれません。 もしあれば目標で最後のDataACKのBegRunを受け取っている彼らのDataSN始めを受けました。 さもなければ、中のData PDUを再送して、それは、0から始まって、それぞれのために1つ増強されます。
A target that has received a R-Data SNACK MUST return a SCSI Response that contains a copy of the SNACK Tag field from the R-Data SNACK in the SCSI Response SNACK Tag field as its last or only Response. For example, if it has already sent a response containing another value in the SNACK Tag field or had the status included in the last Data-In PDU, it must send a new SCSI Response PDU. If a target sends more than one SCSI Response PDU due to this rule, all SCSI responses must carry the same StatSN (see Section 10.4.4 SNACK Tag). If an initiator attempts to recover a lost SCSI Response (with a Status SNACK, see Section 10.16.1 Type) when more than one response has been sent, the target will send the SCSI Response with the latest content known to the target, including the last SNACK Tag for the command.
最終かResponseだけとしてSCSI Response SNACK Tag分野でSNACK MUSTがSNACK Tag分野のコピーを含むSCSI ResponseをR-データから返すR-データSNACKを受けた目標。 例えば、既にSNACK Tag分野に別の値を保管している応答を送るか、または最後の中のData PDUに状態を含ませていたなら、それは新しいSCSI Response PDUを送らなければなりません。 目標がこの規則のため1SCSI Response PDUを送るなら、すべてのSCSI応答が同じStatSNを運ばなければなりません(セクション10.4.4SNACK Tagを見てください)。 創始者が、1つ以上の応答を送ったとき、無くなっているSCSI Response(Status SNACKと共に、セクション10.16.1Typeを見る)を回収するのを試みると、最新の内容が目標に知られている状態で、目標はSCSI Responseを送るでしょう、コマンドのための最後のSNACK Tagを含んでいて。
Satran, et al. Standards Track [Page 173] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[173ページ]。
For considerations in allegiance reassignment of a task to a connection with a different MaxRecvDataSegmentLength, refer to Section 6.2.2 Allegiance Reassignment.
異なったMaxRecvDataSegmentLengthとの接続へのタスクの忠誠再割当てにおける問題について、セクション6.2.2Allegiance Reassignmentを参照してください。
10.16.4. Initiator Task Tag
10.16.4. 創始者タスクタグ
For Status SNACK and DataACK, the Initiator Task Tag MUST be set to the reserved value 0xffffffff. In all other cases, the Initiator Task Tag field MUST be set to the Initiator Task Tag of the referenced command.
Status SNACKとDataACKにおいて、Initiator Task Tagは予約された値の0xffffffffに用意ができなければなりません。 他のすべての場合では、参照をつけられたコマンドのInitiator Task TagにInitiator Task Tag分野を設定しなければなりません。
10.16.5. Target Transfer Tag or SNACK Tag
10.16.5. 目標転送タグか軽食タグ
For an R-Data SNACK, this field MUST contain a value that is different from 0 or 0xffffffff and is unique for the task (identified by the Initiator Task Tag). This value MUST be copied by the iSCSI target in the last or only SCSI Response PDU it issues for the command.
R-データSNACKに関しては、この分野は0か0xffffffffと異なった、タスク(Initiator Task Tagによって特定される)に、ユニークな値を含まなければなりません。 それがコマンドのために発行する最終か唯一のSCSI Response PDUのiSCSI目標でこの値をコピーしなければなりません。
For DataACK, the Target Transfer Tag MUST contain a copy of the Target Transfer Tag and LUN provided with the SCSI Data-In PDU with the A bit set to 1.
DataACKに関しては、Target Transfer TagはTarget Transfer Tagのコピーを含まなければなりません、そして、中のSCSI Data PDUがAビットで提供されたLUNは1にセットしました。
In all other cases, the Target Transfer Tag field MUST be set to the reserved value of 0xffffffff.
他のすべての場合では、0xffffffffの予約された値にTarget Transfer Tag分野を設定しなければなりません。
10.16.6. BegRun
10.16.6. BegRun
The DataSN, R2TSN, or StatSN of the first PDU whose retransmission is requested (Data/R2T and Status SNACK), or the next expected DataSN (DataACK SNACK).
DataSN、R2TSN、「再-トランスミッション」が要求されている最初のPDUのStatSN(データ/R2TとStatus SNACK)、または次の予想されたDataSN(DataACK SNACK)。
BegRun 0 when used in conjunction with RunLength 0 means resend all unacknowledged Data-In, R2T or Response PDUs.
RunLength0に関連して使用されると、BegRun0は、中のすべての不承認のData、R2TまたはResponse PDUsを再送することを意味します。
BegRun MUST be 0 for a R-Data SNACK.
BegRunはR-データSNACKのための0歳でなければなりません。
10.16.7. RunLength
10.16.7. RunLength
The number of PDUs whose retransmission is requested.
「再-トランスミッション」が要求されているPDUsの数。
RunLength 0 signals that all Data-In, R2T, or Response PDUs carrying the numbers equal to or greater than BegRun have to be resent.
RunLength0は、BegRunより等しいか、またはすばらしい状態で数を運ぶ中のすべてのData、R2T、またはResponse PDUsが再送されなければならないと合図します。
The RunLength MUST also be 0 for a DataACK SNACK in addition to R-Data SNACK.
また、RunLengthはR-データSNACKに加えたDataACK SNACKのための0歳でなければなりません。
Satran, et al. Standards Track [Page 174] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[174ページ]。
10.17. Reject
10.17. 廃棄物
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x3f |1| Reserved | Reason | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
16| 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| DataSN/R2TSN or Reserved |
+---------------+---------------+---------------+---------------+
40| Reserved |
+---------------+---------------+---------------+---------------+
44| Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
xx/ Complete Header of Bad PDU /
+/ /
+---------------+---------------+---------------+---------------+
yy/Vendor specific data (if any) /
/ /
+---------------+---------------+---------------+---------------+
zz| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0x3f|1| 予約されます。| 理由| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8/予約された/+//+---------------+---------------+---------------+---------------+ 16| 0xffffffff| +---------------+---------------+---------------+---------------+ 20| 予約されます。| +---------------+---------------+---------------+---------------+ 24| StatSN| +---------------+---------------+---------------+---------------+ 28| ExpCmdSN| +---------------+---------------+---------------+---------------+ 32| MaxCmdSN| +---------------+---------------+---------------+---------------+ 36| DataSN/R2TSNか予約されています。| +---------------+---------------+---------------+---------------+ 40| 予約されます。| +---------------+---------------+---------------+---------------+ 44| 予約されます。| +---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+ Bad PDU/+//+のxx/完全なHeader---------------+---------------+---------------+---------------+ yy/ベンダーの特定のデータ(もしあれば)///+---------------+---------------+---------------+---------------+ zz| データダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
Reject is used to indicate an iSCSI error condition (protocol, unsupported option, etc.).
廃棄物は、iSCSIエラー条件(プロトコル、非サポート・オプションなど)を示すのに使用されます。
Satran, et al. Standards Track [Page 175] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[175ページ]。
10.17.1. Reason
10.17.1. 理由
The reject Reason is coded as follows:
廃棄物Reasonは以下の通りコード化されます:
+------+----------------------------------------+------------------+ | Code | Explanation | Can the original | | (hex)| | PDU be re-sent? | +------+----------------------------------------+------------------+ | 0x01 | Reserved | no | | | | | | 0x02 | Data (payload) Digest Error | yes (Note 1) | | | | | | 0x03 | SNACK Reject | yes | | | | | | 0x04 | Protocol Error (e.g., SNACK request for| no | | | a status that was already acknowledged)| | | | | | | 0x05 | Command not supported | no | | | | | | 0x06 | Immediate Command Reject - too many | yes | | | immediate commands | | | | | | | 0x07 | Task in progress | no | | | | | | 0x08 | Invalid Data ACK | no | | | | | | 0x09 | Invalid PDU field | no (Note 2) | | | | | | 0x0a | Long Operation Reject - Can't generate | yes | | | Target Transfer Tag - out of resources | | | | | | | 0x0b | Negotiation Reset | no | | | | | | 0x0c | Waiting for Logout | no | +------+----------------------------------------+------------------+
+------+----------------------------------------+------------------+ | コード| 説明| 缶はオリジナルです。| | (十六進法)| | PDU、再送しますか? | +------+----------------------------------------+------------------+ | 0×01| 予約されます。| いいえ| | | | | | 0×02| データ(ペイロード)ダイジェスト誤り| はい(注意1)| | | | | | 0×03| 軽食廃棄物| はい| | | | | | 0×04| プロトコルError(|例えば、SNACKはいいえ| | | 既に承認された状態を要求します)| | | | | | | 0×05| サポートされなかったコマンド| いいえ| | | | | | 0×06| 即座のCommand Reject--多く過ぎる| はい| | | 即座のコマンド| | | | | | | 0×07| 進行中のタスク| いいえ| | | | | | 0×08| 無効のデータACK| いいえ| | | | | | 0×09| 無効のPDU分野| いいえ(注意2)| | | | | | 0x0a| 長いOperation Reject--生成することができません。| はい| | | リソースからの目標Transfer Tag| | | | | | | 0x0b| 交渉リセット| いいえ| | | | | | 0x0c| 待っている、ログアウト| いいえ| +------+----------------------------------------+------------------+
Note 1: For iSCSI, Data-Out PDU retransmission is only done if the target requests retransmission with a recovery R2T. However, if this is the data digest error on immediate data, the initiator may choose to retransmit the whole PDU including the immediate data.
注意1: iSCSIに関しては、目標が回復R2Tと共に「再-トランスミッション」を要求する場合にだけ、外のData PDU retransmissionをします。 しかしながら、これが即値データにおけるデータダイジェスト誤りであるなら、創始者は、即値データを含む全体のPDUを再送するのを選ぶかもしれません。
Note 2: A target should use this reason code for all invalid values of PDU fields that are meant to describe a task, a response, or a data transfer. Some examples are invalid TTT/ITT, buffer offset, LUN qualifying a TTT, and an invalid sequence number in a SNACK.
注意2: 目標はタスク、応答、またはデータ転送を説明することになっているPDU分野のすべての無効の値にこの理由コードを使用するはずです。 いくつかの例が、無効のTTT/ITTと、バッファオフセットと、TTTに資格を与えるLUNと、SNACKの無効の一連番号です。
All other values for Reason are reserved.
Reasonのための他のすべての値が予約されています。
Satran, et al. Standards Track [Page 176] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[176ページ]。
In all the cases in which a pre-instantiated SCSI task is terminated because of the reject, the target MUST issue a proper SCSI command response with CHECK CONDITION as described in Section 10.4.3 Response. In these cases in which a status for the SCSI task was already sent before the reject, no additional status is required. If the error is detected while data from the initiator is still expected (i.e., the command PDU did not contain all the data and the target has not received a Data-Out PDU with the Final bit set to 1 for the unsolicited data, if any, and all outstanding R2Ts, if any), the target MUST wait until it receives the last expected Data-Out PDUs with the F bit set to 1 before sending the Response PDU.
廃棄物のためにあらかじめ例示されたSCSIタスクが終えられるすべての場合では、目標はセクション10.4.3Responseで説明されるようにCHECK CONDITIONとの適切なSCSIコマンド応答を発行しなければなりません。 SCSIタスクのための状態が既に廃棄物の前に送られたこれらの場合では、どんな追加状態も必要ではありません。 創始者からのデータがまだ予想されていますが(すなわち、コマンドPDUはすべてのデータを含んだというわけではありません、そして、目標は求められていないデータのためにもしあれば1に設定されたFinalビットがある外のData PDUとすべての傑出しているR2Tsを受けるというわけではありませんでした、もしあれば)、誤りが検出されるなら、外のResponse PDUを送る前にFビットがあるPDUsが1に設定する最後に予想されたDataを受けるまで、目標は待たなければなりません。
For additional usage semantics of Reject PDU, see Section 6.3 Usage Of Reject PDU in Recovery.
Reject PDUの追加用法意味論に関しては、セクション6.3 RecoveryのUsage Of Reject PDUを見てください。
10.17.2. DataSN/R2TSN
10.17.2. DataSN/R2TSN
This field is only valid if the rejected PDU is a Data/R2T SNACK and the Reject reason code is "Protocol error" (see Section 10.16 SNACK Request). The DataSN/R2TSN is the next Data/R2T sequence number that the target would send for the task, if any.
この分野は拒絶されたPDUがData/R2T SNACKとコードが「プロトコル誤り」(セクション10.16 SNACK Requestを見る)であるReject理由である場合にだけ有効です。 DataSN/R2TSNはもしあれば目標がタスクのために送る次のData/R2T一連番号です。
10.17.3. StatSN, ExpCmdSN and MaxCmdSN
10.17.3. StatSN、ExpCmdSN、およびMaxCmdSN
These fields carry their usual values and are not related to the rejected command. StatSN is advanced after a Reject.
これらの分野は、それらの普通の値を運んで、拒絶されたコマンドに関連しません。 StatSNはRejectの後に進められます。
10.17.4. Complete Header of Bad PDU
10.17.4. 悪いPDUの完全なヘッダー
The target returns the header (not including digest) of the PDU in error as the data of the response.
目標は応答に関するデータとしてPDUのヘッダー(ダイジェストを含んでいない)を間違って、返します。
Satran, et al. Standards Track [Page 177] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[177ページ]。
10.18. NOP-Out
10.18. 外のNOP
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|I| 0x00 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment - Ping Data (optional) /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | 私| 0×00|1| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| LUNか予約されています。| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグか0xffffffff| +---------------+---------------+---------------+---------------+ 20| 目標転送のタグか0xffffffff| +---------------+---------------+---------------+---------------+ 24| CmdSN| +---------------+---------------+---------------+---------------+ 28| ExpStatSN| +---------------+---------------+---------------+---------------+ 32/予約された/+//+---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+/DataSegment--ピングデータ(任意の)/+//+---------------+---------------+---------------+---------------+ | データダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
A NOP-Out may be used by an initiator as a "ping request" to verify that a connection/session is still active and all its components are operational. The NOP-In response is the "ping echo".
接続/セッションがまだ活発であることを確かめるという「ピング要求」とそのすべてのコンポーネントが操作上であるので、外のNOPは創始者によって使用されるかもしれません。 中のNOP応答は「ピングエコー」です。
A NOP-Out is also sent by an initiator in response to a NOP-In.
また、外のNOPは中のNOPに対応して創始者によって送られます。
A NOP-Out may also be used to confirm a changed ExpStatSN if another PDU will not be available for a long time.
また、別のPDUが長い間利用可能にならないなら、外のNOPは、変えられたExpStatSNを確認するのに使用されるかもしれません。
Upon receipt of a NOP-In with the Target Transfer Tag set to a valid value (not the reserved 0xffffffff), the initiator MUST respond with a NOP-Out. In this case, the NOP-Out Target Transfer Tag MUST contain a copy of the NOP-In Target Transfer Tag.
中の有効値(予約された0xffffffffでない)に用意ができているTarget Transfer TagとNOPを受け取り次第、創始者は外のNOPと共に応じなければなりません。 この場合、外のNOP Target Transfer Tagは中のNOP Target Transfer Tagのコピーを含まなければなりません。
Satran, et al. Standards Track [Page 178] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[178ページ]。
10.18.1. Initiator Task Tag
10.18.1. 創始者タスクタグ
The NOP-Out MUST have the Initiator Task Tag set to a valid value only if a response in the form of NOP-In is requested (i.e., the NOP-Out is used as a ping request). Otherwise, the Initiator Task Tag MUST be set to 0xffffffff.
中のNOPの形における応答が要求される場合にだけ(すなわち、外のNOPはピング要求として使用されます)、外のNOPはInitiator Task Tagを有効値に用意ができさせなければなりません。 さもなければ、Initiator Task Tagは0xffffffffに用意ができなければなりません。
When a target receives the NOP-Out with a valid Initiator Task Tag, it MUST respond with a Nop-In Response (see Section 10.19 NOP-In).
目標が有効なInitiator Task Tagと共に外のNOPを受けるとき、それは中のNop Responseと共に応じなければなりません(中のセクション10.19NOPを見てください)。
If the Initiator Task Tag contains 0xffffffff, the I bit MUST be set to 1 and the CmdSN is not advanced after this PDU is sent.
Initiator Task Tagが0xffffffffを含んでいるなら、Iビットを1に設定しなければなりません、そして、このPDUを送った後にCmdSNは高度ではありません。
10.18.2. Target Transfer Tag
10.18.2. 目標転送タグ
A target assigned identifier for the operation.
目標は操作のために識別子を割り当てました。
The NOP-Out MUST only have the Target Transfer Tag set if it is issued in response to a NOP-In with a valid Target Transfer Tag. In this case, it copies the Target Transfer Tag from the NOP-In PDU. Otherwise, the Target Transfer Tag MUST be set to 0xffffffff.
それが中の有効なTarget Transfer TagとNOPに対応して発行されるなら、外のNOPはTarget Transfer Tagを用意ができさせるだけでよいです。 この場合、それはTarget Transfer Tagを中のNOP PDUを回避します。 さもなければ、Target Transfer Tagは0xffffffffに用意ができなければなりません。
When the Target Transfer Tag is set to a value other than 0xffffffff, the LUN field MUST also be copied from the NOP-In.
また、Target Transfer Tagが0xffffffff以外の値に用意ができているとき、中のNOPからLUN分野をコピーしなければなりません。
10.18.3. Ping Data
10.18.3. ピングデータ
Ping data are reflected in the NOP-In Response. The length of the reflected data are limited to MaxRecvDataSegmentLength. The length of ping data are indicated by the DataSegmentLength. 0 is a valid value for the DataSegmentLength and indicates the absence of ping data.
ピングデータは中のNOP Responseに反映されます。 反射したデータの長さはMaxRecvDataSegmentLengthに制限されます。 ピングデータの長さはDataSegmentLengthによって示されます。 0 DataSegmentLengthのための有効値であり、ピングデータの欠如を示します。
Satran, et al. Standards Track [Page 179] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[179ページ]。
10.19. NOP-In
10.19. 中のNOP
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x20 |1| Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| LUN or Reserved |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
20| Target Transfer Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
/ DataSegment - Return Ping Data /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|. | . | 0×20|1| 予約されます。| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength| DataSegmentLength| +---------------+---------------+---------------+---------------+ 8| LUNか予約されています。| + + 12| | +---------------+---------------+---------------+---------------+ 16| 創始者タスクタグか0xffffffff| +---------------+---------------+---------------+---------------+ 20| 目標転送のタグか0xffffffff| +---------------+---------------+---------------+---------------+ 24| StatSN| +---------------+---------------+---------------+---------------+ 28| ExpCmdSN| +---------------+---------------+---------------+---------------+ 32| MaxCmdSN| +---------------+---------------+---------------+---------------+ 36/予約された/+//+---------------+---------------+---------------+---------------+ 48| ヘッダーダイジェスト(任意の)| +---------------+---------------+---------------+---------------+/DataSegment--リターンピングデータ/+//+---------------+---------------+---------------+---------------+ | データダイジェスト(任意の)| +---------------+---------------+---------------+---------------+
NOP-In is either sent by a target as a response to a NOP-Out, as a "ping" to an initiator, or as a means to carry a changed ExpCmdSN and/or MaxCmdSN if another PDU will not be available for a long time (as determined by the target).
別のPDUが長い間利用可能でないなら(目標で決定するように)、外のNOPへの応答、創始者への「ピング」として目標で送るか、変えられたExpCmdSN、そして/または、MaxCmdSNを運ぶ手段のどちらかとして中のNOPがあります。
When a target receives the NOP-Out with a valid Initiator Task Tag (not the reserved value 0xffffffff), it MUST respond with a NOP-In with the same Initiator Task Tag that was provided in the NOP-Out request. It MUST also duplicate up to the first MaxRecvDataSegmentLength bytes of the initiator provided Ping Data. For such a response, the Target Transfer Tag MUST be 0xffffffff.
目標が有効なInitiator Task Tag(予約された値の0xffffffffでない)と共に外のNOPを受けるとき、それは中のNOPと共に外のNOP要求に提供されたのと同じInitiator Task Tagで応じなければなりません。 また、それは創始者の最初のMaxRecvDataSegmentLengthバイトの提供されたPing Dataをコピーしなければなりません。 そのような応答のために、Target Transfer Tagは0xffffffffでなければなりません。
Satran, et al. Standards Track [Page 180] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[180ページ]。
Otherwise, when a target sends a NOP-In that is not a response to a Nop-Out received from the initiator, the Initiator Task Tag MUST be set to 0xffffffff and the Data Segment MUST NOT contain any data (DataSegmentLength MUST be 0).
目標が別の方法でaを送る、NOP-In、すなわち、Nop-アウトへのどんな応答も創始者から受信されないで、Initiator Task Tagは0xffffffffに用意ができなければならなくて、Data Segmentは少しのデータも含んではいけません(DataSegmentLengthは0歳であるに違いありません)。
10.19.1. Target Transfer Tag
10.19.1. 目標転送タグ
If the target is responding to a NOP-Out, this is set to the reserved value 0xffffffff.
目標が外のNOPに応じることであるなら、これは予約された値の0xffffffffに設定されます。
If the target is sending a NOP-In as a Ping (intending to receive a corresponding NOP-Out), this field is set to a valid value (not the reserved 0xffffffff).
目標がPingとして中のNOPを送ることであるなら(外の対応するNOPを受け取るつもりであり)、この分野は有効値(予約された0xffffffffでない)に設定されます。
If the target is initiating a NOP-In without wanting to receive a corresponding NOP-Out, this field MUST hold the reserved value of 0xffffffff.
目標が外の対応するNOPを受け取りたくなくて中のNOPを開始することであるなら、この分野は0xffffffffの予約された値を保持しなければなりません。
10.19.2. StatSN
10.19.2. StatSN
The StatSN field will always contain the next StatSN. However, when the Initiator Task Tag is set to 0xffffffff, StatSN for the connection is not advanced after this PDU is sent.
StatSN分野はいつも次のStatSNを含むでしょう。 しかしながら、Initiator Task Tagが0xffffffffに用意ができているとき、このPDUを送った後に接続のためのStatSNは高度ではありません。
10.19.3. LUN
10.19.3. LUN
A LUN MUST be set to a correct value when the Target Transfer Tag is valid (not the reserved value 0xffffffff).
LUN MUST、Target Transfer Tagが有効である(予約された値の0xffffffffでない)ときには正しい値に設定されてください。
11. iSCSI Security Text Keys and Authentication Methods
11. iSCSIセキュリティテキストキーと認証方法
Only the following keys are used during the SecurityNegotiation stage of the Login Phase:
以下のキーだけがLogin PhaseのSecurityNegotiation台の間、使用されます:
SessionType
InitiatorName
TargetName
TargetAddress
InitiatorAlias
TargetAlias
TargetPortalGroupTag
AuthMethod and the keys used by the authentication methods
specified under Section 11.1 AuthMethod along with all of
their associated keys as well as Vendor Specific
Authentication Methods.
認証方法で使用されるSessionType InitiatorName TargetName TargetAddress InitiatorAlias TargetAlias TargetPortalGroupTag AuthMethodとキーはセクション11.1 Vendor Specific Authentication Methodsと同様にそれらの関連キーのすべてに伴うAuthMethodの下で指定しました。
Satran, et al. Standards Track [Page 181] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[181ページ]。
Other keys MUST NOT be used.
他のキーを使用してはいけません。
SessionType, InitiatorName, TargetName, InitiatorAlias, TargetAlias, and TargetPortalGroupTag are described in Chapter 12 as they can be used also in the OperationalNegotiation stage.
SessionType、InitiatorName、TargetName、InitiatorAlias、TargetAlias、およびTargetPortalGroupTagはまた、OperationalNegotiation段階で彼らを使用できるように第12章で説明されます。
All security keys have connection-wide applicability.
すべてのセキュリティキーには、接続全体の適用性があります。
11.1. AuthMethod
11.1. AuthMethod
Use: During Login - Security Negotiation Senders: Initiator and Target Scope: connection
使用: ログイン--セキュリティNegotiation Senders: 創始者と目標範囲: 接続
AuthMethod = <list-of-values>
AuthMethod=<リスト、-、値の>。
The main item of security negotiation is the authentication method (AuthMethod).
セキュリティ交渉の主な項目は認証方法(AuthMethod)です。
The authentication methods that can be used (appear in the list-of-values) are either those listed in the following table or are vendor-unique methods:
使用できる(値のリストでは、現れます)認証方法は、以下のテーブルに記載されたものであるかベンダー独自の方法です:
+------------------------------------------------------------+ | Name | Description | +------------------------------------------------------------+ | KRB5 | Kerberos V5 - defined in [RFC1510] | +------------------------------------------------------------+ | SPKM1 | Simple Public-Key GSS-API Mechanism | | | defined in [RFC2025] | +------------------------------------------------------------+ | SPKM2 | Simple Public-Key GSS-API Mechanism | | | defined in [RFC2025] | +------------------------------------------------------------+ | SRP | Secure Remote Password | | | defined in [RFC2945] | +------------------------------------------------------------+ | CHAP | Challenge Handshake Authentication Protocol| | | defined in [RFC1994] | +------------------------------------------------------------+ | None | No authentication | +------------------------------------------------------------+
+------------------------------------------------------------+ | 名前| 記述| +------------------------------------------------------------+ | KRB5| ケルベロスV5--[RFC1510]では、定義されます。| +------------------------------------------------------------+ | SPKM1| 簡単な公開鍵GSS-APIメカニズム| | | [RFC2025]では、定義されます。| +------------------------------------------------------------+ | SPKM2| 簡単な公開鍵GSS-APIメカニズム| | | [RFC2025]では、定義されます。| +------------------------------------------------------------+ | SRP| 安全なリモートパスワード| | | [RFC2945]では、定義されます。| +------------------------------------------------------------+ | やつ| チャレンジハンドシェイク式認証プロトコル| | | [RFC1994]では、定義されます。| +------------------------------------------------------------+ | なし| 認証がありません。| +------------------------------------------------------------+
The AuthMethod selection is followed by an "authentication exchange" specific to the authentication method selected.
メソッドが選択した認証に特定の「認証交換」はAuthMethod選択のあとに続いています。
The authentication method proposal may be made by either the initiator or the target. However the initiator MUST make the first step specific to the selected authentication method as soon as it is
創始者か目標のどちらかは認証方法提案をするかもしれません。 しかしながら、創始者はそれがそうであるとすぐに、第一歩を選択された認証方法に特定にしなければなりません。
Satran, et al. Standards Track [Page 182] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[182ページ]。
selected. It follows that if the target makes the authentication method proposal the initiator sends the first keys(s) of the exchange together with its authentication method selection.
選択にされる。 目標が認証をメソッド提案にするなら創始者が認証方法選択と共に交換の最初のキーを送るということになります。
The authentication exchange authenticates the initiator to the target, and optionally, the target to the initiator. Authentication is OPTIONAL to use but MUST be supported by the target and initiator.
認証交換が任意に目標に創始者を認証する、創始者への目標。 認証を使用へのOPTIONALですが、目標と創始者はサポートしなければなりません。
The initiator and target MUST implement CHAP. All other authentication methods are OPTIONAL.
創始者と目標はCHAPを実装しなければなりません。 他のすべての認証方法がOPTIONALです。
Private or public extension algorithms MAY also be negotiated for authentication methods. Whenever a private or public extension algorithm is part of the default offer (the offer made in absence of explicit administrative action) the implementer MUST ensure that CHAP is listed as an alternative in the default offer and "None" is not part of the default offer.
また、個人的であるか公共の拡大アルゴリズムは認証方法のために交渉されるかもしれません。 個人的であるか公共の拡大アルゴリズムがデフォルト申し出(明白な管理動作の欠如でされた申し出)の一部であるときはいつも、implementerは、CHAPがデフォルト申し出と「なにも」の代替手段がデフォルト申し出の一部でないので記載されているのを確実にしなければなりません。
Extension authentication methods MUST be named using one of the following two formats:
以下の2つの形式の1つを使用すると拡大認証方法を命名しなければなりません:
a) Z-reversed.vendor.dns_name.do_something=
b) Z<#><IANA-registered-string>=
a) Z-reversed.vendor.dns_name.do、_何かがb)と等しいです。 Z<#><IANAによって登録されたストリングの>=
Authentication methods named using the Z- format are used as private extensions. Authentication methods named using the Z# format are used as public extensions that must be registered with IANA and MUST be described by an informational RFC.
Z形式を使用すると指定された認証方法は個人的な拡大として使用されます。 Z#形式を使用すると指定された認証方法はIANAに示さなければならなくて、情報のRFCが説明しなければならない公共の拡大として使用されます。
For all of the public or private extension authentication methods, the method specific keys MUST conform to the format specified in Section 5.1 Text Format for standard-label.
For all of the public or private extension authentication methods, the method specific keys MUST conform to the format specified in Section 5.1 Text Format for standard-label.
To identify the vendor for private extension authentication methods, we suggest you use the reversed DNS-name as a prefix to the proper digest names.
To identify the vendor for private extension authentication methods, we suggest you use the reversed DNS-name as a prefix to the proper digest names.
The part of digest-name following Z- and Z# MUST conform to the format for standard-label specified in Section 5.1 Text Format.
The part of digest-name following Z- and Z# MUST conform to the format for standard-label specified in Section 5.1 Text Format.
Support for public or private extension authentication methods is OPTIONAL.
Support for public or private extension authentication methods is OPTIONAL.
The following subsections define the specific exchanges for each of the standardized authentication methods. As mentioned earlier the first step is always done by the initiator.
The following subsections define the specific exchanges for each of the standardized authentication methods. As mentioned earlier the first step is always done by the initiator.
Satran, et al. Standards Track [Page 183] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 183] RFC 3720 iSCSI April 2004
11.1.1. Kerberos
11.1.1. Kerberos
For KRB5 (Kerberos V5) [RFC1510] and [RFC1964], the initiator MUST use:
For KRB5 (Kerberos V5) [RFC1510] and [RFC1964], the initiator MUST use:
KRB_AP_REQ=<KRB_AP_REQ>
KRB_AP_REQ=<KRB_AP_REQ>
where KRB_AP_REQ is the client message as defined in [RFC1510].
where KRB_AP_REQ is the client message as defined in [RFC1510].
The default principal name assumed by an iSCSI initiator or target (prior to any administrative configuration action) MUST be the iSCSI Initiator Name or iSCSI Target Name respectively, prefixed by the string "iscsi/".
The default principal name assumed by an iSCSI initiator or target (prior to any administrative configuration action) MUST be the iSCSI Initiator Name or iSCSI Target Name respectively, prefixed by the string "iscsi/".
If the initiator authentication fails, the target MUST respond with a Login reject with "Authentication Failure" status. Otherwise, if the initiator has selected the mutual authentication option (by setting MUTUAL-REQUIRED in the ap-options field of the KRB_AP_REQ), the target MUST reply with:
If the initiator authentication fails, the target MUST respond with a Login reject with "Authentication Failure" status. Otherwise, if the initiator has selected the mutual authentication option (by setting MUTUAL-REQUIRED in the ap-options field of the KRB_AP_REQ), the target MUST reply with:
KRB_AP_REP=<KRB_AP_REP>
KRB_AP_REP=<KRB_AP_REP>
where KRB_AP_REP is the server's response message as defined in [RFC1510].
where KRB_AP_REP is the server's response message as defined in [RFC1510].
If mutual authentication was selected and target authentication fails, the initiator MUST close the connection.
If mutual authentication was selected and target authentication fails, the initiator MUST close the connection.
KRB_AP_REQ and KRB_AP_REP are binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 65536 bytes.
KRB_AP_REQ and KRB_AP_REP are binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 65536 bytes.
11.1.2. Simple Public-Key Mechanism (SPKM)
11.1.2. Simple Public-Key Mechanism (SPKM)
For SPKM1 and SPKM2 [RFC2025], the initiator MUST use:
For SPKM1 and SPKM2 [RFC2025], the initiator MUST use:
SPKM_REQ=<SPKM-REQ>
SPKM_REQ=<SPKM-REQ>
where SPKM-REQ is the first initiator token as defined in [RFC2025].
where SPKM-REQ is the first initiator token as defined in [RFC2025].
[RFC2025] defines situations where each side may send an error token that may cause the peer to re-generate and resend its last token. This scheme is followed in iSCSI, and the error token syntax is:
[RFC2025] defines situations where each side may send an error token that may cause the peer to re-generate and resend its last token. This scheme is followed in iSCSI, and the error token syntax is:
SPKM_ERROR=<SPKM-ERROR>
SPKM_ERROR=<SPKM-ERROR>
Satran, et al. Standards Track [Page 184] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 184] RFC 3720 iSCSI April 2004
However, SPKM-DEL tokens that are defined by [RFC2025] for fatal errors will not be used by iSCSI. If the target needs to send a SPKM-DEL token, it will, instead, send a Login "login reject" message with the "Authentication Failure" status and terminate the connection. If the initiator needs to send a SPKM-DEL token, it will close the connection.
However, SPKM-DEL tokens that are defined by [RFC2025] for fatal errors will not be used by iSCSI. If the target needs to send a SPKM-DEL token, it will, instead, send a Login "login reject" message with the "Authentication Failure" status and terminate the connection. If the initiator needs to send a SPKM-DEL token, it will close the connection.
In the following sections, we assume that no SPKM-ERROR tokens are required.
In the following sections, we assume that no SPKM-ERROR tokens are required.
If the initiator authentication fails, the target MUST return an error. Otherwise, if the AuthMethod is SPKM1 or if the initiator has selected the mutual authentication option (by setting mutual-state bit in the options field of the REQ-TOKEN in the SPKM-REQ), the target MUST reply with:
If the initiator authentication fails, the target MUST return an error. Otherwise, if the AuthMethod is SPKM1 or if the initiator has selected the mutual authentication option (by setting mutual-state bit in the options field of the REQ-TOKEN in the SPKM-REQ), the target MUST reply with:
SPKM_REP_TI=<SPKM-REP-TI>
SPKM_REP_TI=<SPKM-REP-TI>
where SPKM-REP-TI is the target token as defined in [RFC2025].
where SPKM-REP-TI is the target token as defined in [RFC2025].
If mutual authentication was selected and target authentication fails, the initiator MUST close the connection. Otherwise, if the AuthMethod is SPKM1, the initiator MUST continue with:
If mutual authentication was selected and target authentication fails, the initiator MUST close the connection. Otherwise, if the AuthMethod is SPKM1, the initiator MUST continue with:
SPKM_REP_IT=<SPKM-REP-IT>
SPKM_REP_IT=<SPKM-REP-IT>
where SPKM-REP-IT is the second initiator token as defined in [RFC2025]. If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status.
where SPKM-REP-IT is the second initiator token as defined in [RFC2025]. If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status.
SPKM requires support for very long authentication items.
SPKM requires support for very long authentication items.
All the SPKM-* tokens are binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 65536 bytes.
All the SPKM-* tokens are binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 65536 bytes.
11.1.3. Secure Remote Password (SRP)
11.1.3. Secure Remote Password (SRP)
For SRP [RFC2945], the initiator MUST use:
For SRP [RFC2945], the initiator MUST use:
SRP_U=<U> TargetAuth=Yes /* or TargetAuth=No */
SRP_U=<U> TargetAuth=Yes /* or TargetAuth=No */
The target MUST answer with a Login reject with the "Authorization Failure" status or reply with:
The target MUST answer with a Login reject with the "Authorization Failure" status or reply with:
SRP_GROUP=<G1,G2...> SRP_s=<s>
SRP_GROUP=<G1,G2...> SRP_s=<s>
Where G1,G2... are proposed groups, in order of preference.
Where G1,G2... are proposed groups, in order of preference.
Satran, et al. Standards Track [Page 185] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 185] RFC 3720 iSCSI April 2004
The initiator MUST either close the connection or continue with:
The initiator MUST either close the connection or continue with:
SRP_A=<A> SRP_GROUP=<G>
SRP_A=<A> SRP_GROUP=<G>
Where G is one of G1,G2... that were proposed by the target.
Where G is one of G1,G2... that were proposed by the target.
The target MUST answer with a Login reject with the "Authentication Failure" status or reply with:
The target MUST answer with a Login reject with the "Authentication Failure" status or reply with:
SRP_B=<B>
SRP_B=<B>
The initiator MUST close the connection or continue with:
The initiator MUST close the connection or continue with:
SRP_M=<M>
SRP_M=<M>
If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator sent TargetAuth=Yes in the first message (requiring target authentication), the target MUST reply with:
If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator sent TargetAuth=Yes in the first message (requiring target authentication), the target MUST reply with:
SRP_HM=<H(A | M | K)>
SRP_HM=<H(A | M | K)>
If the target authentication fails, the initiator MUST close the connection.
If the target authentication fails, the initiator MUST close the connection.
Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] (using the SHA1 hash function, such as SRP-SHA1) and G,Gn (Gn stands for G1,G2...) are identifiers of SRP groups specified in [RFC3723]. G, Gn, and U are text strings, s,A,B,M, and H(A | M | K) are binary-values. The length of s,A,B,M and H(A | M | K) in binary form (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes.
Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] (using the SHA1 hash function, such as SRP-SHA1) and G,Gn (Gn stands for G1,G2...) are identifiers of SRP groups specified in [RFC3723]. G, Gn, and U are text strings, s,A,B,M, and H(A | M | K) are binary-values. The length of s,A,B,M and H(A | M | K) in binary form (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes.
For the SRP_GROUP, all the groups specified in [RFC3723] up to 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be supported by initiators and targets. To guarantee interoperability, targets MUST always offer "SRP-1536" as one of the proposed groups.
For the SRP_GROUP, all the groups specified in [RFC3723] up to 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be supported by initiators and targets. To guarantee interoperability, targets MUST always offer "SRP-1536" as one of the proposed groups.
11.1.4. Challenge Handshake Authentication Protocol (CHAP)
11.1.4. Challenge Handshake Authentication Protocol (CHAP)
For CHAP [RFC1994], in the first step, the initiator MUST send:
For CHAP [RFC1994], in the first step, the initiator MUST send:
CHAP_A=<A1,A2...>
CHAP_A=<A1,A2...>
Where A1,A2... are proposed algorithms, in order of preference.
Where A1,A2... are proposed algorithms, in order of preference.
Satran, et al. Standards Track [Page 186] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 186] RFC 3720 iSCSI April 2004
In the second step, the target MUST answer with a Login reject with the "Authentication Failure" status or reply with:
In the second step, the target MUST answer with a Login reject with the "Authentication Failure" status or reply with:
CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>
CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>
Where A is one of A1,A2... that were proposed by the initiator.
Where A is one of A1,A2... that were proposed by the initiator.
In the third step, the initiator MUST continue with:
In the third step, the initiator MUST continue with:
CHAP_N=<N> CHAP_R=<R>
CHAP_N=<N> CHAP_R=<R>
or, if it requires target authentication, with:
or, if it requires target authentication, with:
CHAP_N=<N> CHAP_R=<R> CHAP_I=<I> CHAP_C=<C>
CHAP_N=<N> CHAP_R=<R> CHAP_I=<I> CHAP_C=<C>
If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator required target authentication, the target MUST either answer with a Login reject with "Authentication Failure" or reply with:
If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator required target authentication, the target MUST either answer with a Login reject with "Authentication Failure" or reply with:
CHAP_N=<N> CHAP_R=<R>
CHAP_N=<N> CHAP_R=<R>
If target authentication fails, the initiator MUST close the connection.
If target authentication fails, the initiator MUST close the connection.
Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, Algorithm, Identifier, Challenge, and Response as defined in [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C and R are large-binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes.
Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, Algorithm, Identifier, Challenge, and Response as defined in [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C and R are large-binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes.
For the Algorithm, as stated in [RFC1994], one value is required to be implemented:
For the Algorithm, as stated in [RFC1994], one value is required to be implemented:
5 (CHAP with MD5)
5 (CHAP with MD5)
To guarantee interoperability, initiators MUST always offer it as one of the proposed algorithms.
To guarantee interoperability, initiators MUST always offer it as one of the proposed algorithms.
12. Login/Text Operational Text Keys
12. Login/Text Operational Text Keys
Some session specific parameters MUST only be carried on the leading connection and cannot be changed after the leading connection login (e.g., MaxConnections, the maximum number of connections). This
Some session specific parameters MUST only be carried on the leading connection and cannot be changed after the leading connection login (e.g., MaxConnections, the maximum number of connections). This
Satran, et al. Standards Track [Page 187] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 187] RFC 3720 iSCSI April 2004
holds for a single connection session with regard to connection restart. The keys that fall into this category have the use: LO (Leading Only).
holds for a single connection session with regard to connection restart. The keys that fall into this category have the use: LO (Leading Only).
Keys that can only be used during login have the use: IO (initialize only), while those that can be used in both the Login Phase and Full Feature Phase have the use: ALL.
Keys that can only be used during login have the use: IO (initialize only), while those that can be used in both the Login Phase and Full Feature Phase have the use: ALL.
Keys that can only be used during Full Feature Phase use FFPO (Full Feature Phase only).
Keys that can only be used during Full Feature Phase use FFPO (Full Feature Phase only).
Keys marked as Any-Stage may also appear in the SecurityNegotiation stage while all other keys described in this chapter are operational keys.
Keys marked as Any-Stage may also appear in the SecurityNegotiation stage while all other keys described in this chapter are operational keys.
Keys that do not require an answer are marked as Declarative.
Keys that do not require an answer are marked as Declarative.
Key scope is indicated as session-wide (SW) or connection-only (CO).
Key scope is indicated as session-wide (SW) or connection-only (CO).
Result function, wherever mentioned, states the function that can be applied to check the validity of the responder selection. Minimum means that the selected value cannot exceed the offered value. Maximum means that the selected value cannot be lower than the offered value. AND means that the selected value must be a possible result of a Boolean "and" function with an arbitrary Boolean value (e.g., if the offered value is No the selected value must be No). OR means that the selected value must be a possible result of a Boolean "or" function with an arbitrary Boolean value (e.g., if the offered value is Yes the selected value must be Yes).
Result function, wherever mentioned, states the function that can be applied to check the validity of the responder selection. Minimum means that the selected value cannot exceed the offered value. Maximum means that the selected value cannot be lower than the offered value. AND means that the selected value must be a possible result of a Boolean "and" function with an arbitrary Boolean value (e.g., if the offered value is No the selected value must be No). OR means that the selected value must be a possible result of a Boolean "or" function with an arbitrary Boolean value (e.g., if the offered value is Yes the selected value must be Yes).
12.1. HeaderDigest and DataDigest
12.1. HeaderDigest and DataDigest
Use: IO Senders: Initiator and Target Scope: CO
Use: IO Senders: Initiator and Target Scope: CO
HeaderDigest = <list-of-values> DataDigest = <list-of-values>
HeaderDigest = <list-of-values> DataDigest = <list-of-values>
Default is None for both HeaderDigest and DataDigest.
Default is None for both HeaderDigest and DataDigest.
Digests enable the checking of end-to-end, non-cryptographic data integrity beyond the integrity checks provided by the link layers and the covering of the whole communication path including all elements that may change the network level PDUs such as routers, switches, and proxies.
Digests enable the checking of end-to-end, non-cryptographic data integrity beyond the integrity checks provided by the link layers and the covering of the whole communication path including all elements that may change the network level PDUs such as routers, switches, and proxies.
Satran, et al. Standards Track [Page 188] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 188] RFC 3720 iSCSI April 2004
The following table lists cyclic integrity checksums that can be negotiated for the digests and that MUST be implemented by every iSCSI initiator and target. These digest options only have error detection significance.
The following table lists cyclic integrity checksums that can be negotiated for the digests and that MUST be implemented by every iSCSI initiator and target. These digest options only have error detection significance.
+---------------------------------------------+ | Name | Description | Generator | +---------------------------------------------+ | CRC32C | 32 bit CRC |0x11edc6f41| +---------------------------------------------+ | None | no digest | +---------------------------------------------+
+---------------------------------------------+ | Name | Description | Generator | +---------------------------------------------+ | CRC32C | 32 bit CRC |0x11edc6f41| +---------------------------------------------+ | None | no digest | +---------------------------------------------+
The generator polynomial for this digest is given in hex-notation (e.g., 0x3b stands for 0011 1011 and the polynomial is x**5+X**4+x**3+x+1).
The generator polynomial for this digest is given in hex-notation (e.g., 0x3b stands for 0011 1011 and the polynomial is x**5+X**4+x**3+x+1).
When the Initiator and Target agree on a digest, this digest MUST be used for every PDU in Full Feature Phase.
When the Initiator and Target agree on a digest, this digest MUST be used for every PDU in Full Feature Phase.
Padding bytes, when present in a segment covered by a CRC, SHOULD be set to 0 and are included in the CRC.
Padding bytes, when present in a segment covered by a CRC, SHOULD be set to 0 and are included in the CRC.
The CRC MUST be calculated by a method that produces the same results as the following process:
The CRC MUST be calculated by a method that produces the same results as the following process:
- The PDU bits are considered as the coefficients of a
polynomial M(x) of degree n-1; bit 7 of the lowest numbered
byte is considered the most significant bit (x^n-1), followed
by bit 6 of the lowest numbered byte through bit 0 of the
highest numbered byte (x^0).
- The PDU bits are considered as the coefficients of a polynomial M(x) of degree n-1; bit 7 of the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the lowest numbered byte through bit 0 of the highest numbered byte (x^0).
- The most significant 32 bits are complemented.
- The most significant 32 bits are complemented.
- The polynomial is multiplied by x^32 then divided by G(x). The
generator polynomial produces a remainder R(x) of degree <= 31.
- The polynomial is multiplied by x^32 then divided by G(x). The generator polynomial produces a remainder R(x) of degree <= 31.
- The coefficients of R(x) are considered a 32 bit sequence.
- The coefficients of R(x) are considered a 32 bit sequence.
- The bit sequence is complemented and the result is the CRC.
- The bit sequence is complemented and the result is the CRC.
- The CRC bits are mapped into the digest word. The x^31
coefficient in bit 7 of the lowest numbered byte of the digest
continuing through to the byte up to the x^24 coefficient in
bit 0 of the lowest numbered byte, continuing with the x^23
coefficient in bit 7 of next byte through x^0 in bit 0 of the
highest numbered byte.
- The CRC bits are mapped into the digest word. The x^31 coefficient in bit 7 of the lowest numbered byte of the digest continuing through to the byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, continuing with the x^23 coefficient in bit 7 of next byte through x^0 in bit 0 of the highest numbered byte.
Satran, et al. Standards Track [Page 189] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 189] RFC 3720 iSCSI April 2004
- Computing the CRC over any segment (data or header) extended
to include the CRC built using the generator 0x11edc6f41 will
always get the value 0x1c2d19ed as its final remainder (R(x)).
This value is given here in its polynomial form (i.e., not
mapped as the digest word).
- Computing the CRC over any segment (data or header) extended to include the CRC built using the generator 0x11edc6f41 will always get the value 0x1c2d19ed as its final remainder (R(x)). This value is given here in its polynomial form (i.e., not mapped as the digest word).
For a discussion about selection criteria for the CRC, see [RFC3385]. For a detailed analysis of the iSCSI polynomial, see [Castagnoli93].
For a discussion about selection criteria for the CRC, see [RFC3385]. For a detailed analysis of the iSCSI polynomial, see [Castagnoli93].
Private or public extension algorithms MAY also be negotiated for digests. Whenever a private or public digest extension algorithm is part of the default offer (the offer made in absence of explicit administrative action) the implementer MUST ensure that CRC32C is listed as an alternative in the default offer and "None" is not part of the default offer.
Private or public extension algorithms MAY also be negotiated for digests. Whenever a private or public digest extension algorithm is part of the default offer (the offer made in absence of explicit administrative action) the implementer MUST ensure that CRC32C is listed as an alternative in the default offer and "None" is not part of the default offer.
Extension digest algorithms MUST be named using one of the following two formats:
Extension digest algorithms MUST be named using one of the following two formats:
a) Y-reversed.vendor.dns_name.do_something=
b) Y<#><IANA-registered-string>=
a) Y-reversed.vendor.dns_name.do_something= b) Y<#><IANA-registered-string>=
Digests named using the Y- format are used for private purposes (unregistered). Digests named using the Y# format (public extension) must be registered with IANA and MUST be described by an informational RFC.
Digests named using the Y- format are used for private purposes (unregistered). Digests named using the Y# format (public extension) must be registered with IANA and MUST be described by an informational RFC.
For private extension digests, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to the proper digest names.
For private extension digests, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to the proper digest names.
The part of digest-name following Y- and Y# MUST conform to the format for standard-label specified in Section 5.1 Text Format.
The part of digest-name following Y- and Y# MUST conform to the format for standard-label specified in Section 5.1 Text Format.
Support for public or private extension digests is OPTIONAL.
Support for public or private extension digests is OPTIONAL.
12.2. MaxConnections
12.2. MaxConnections
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
MaxConnections=<numerical-value-from-1-to-65535>
MaxConnections=<numerical-value-from-1-to-65535>
Default is 1. Result function is Minimum.
Default is 1. Result function is Minimum.
Satran, et al. Standards Track [Page 190] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 190] RFC 3720 iSCSI April 2004
Initiator and target negotiate the maximum number of connections requested/acceptable.
Initiator and target negotiate the maximum number of connections requested/acceptable.
12.3. SendTargets
12.3. SendTargets
Use: FFPO Senders: Initiator Scope: SW
Use: FFPO Senders: Initiator Scope: SW
For a complete description, see Appendix D. - SendTargets Operation -.
For a complete description, see Appendix D. - SendTargets Operation -.
12.4. TargetName
12.4. TargetName
Use: IO by initiator, FFPO by target - only as response to a SendTargets, Declarative, Any-Stage
Use: IO by initiator, FFPO by target - only as response to a SendTargets, Declarative, Any-Stage
Senders: Initiator and Target Scope: SW
Senders: Initiator and Target Scope: SW
TargetName=<iSCSI-name-value>
TargetName=<iSCSI-name-value>
Examples:
Examples:
TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678
TargetName=eui.020000023B040506
TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678 TargetName=eui.020000023B040506
The initiator of the TCP connection MUST provide this key to the remote endpoint in the first login request if the initiator is not establishing a discovery session. The iSCSI Target Name specifies the worldwide unique name of the target.
The initiator of the TCP connection MUST provide this key to the remote endpoint in the first login request if the initiator is not establishing a discovery session. The iSCSI Target Name specifies the worldwide unique name of the target.
The TargetName key may also be returned by the "SendTargets" text request (which is its only use when issued by a target).
The TargetName key may also be returned by the "SendTargets" text request (which is its only use when issued by a target).
TargetName MUST not be redeclared within the login phase.
TargetName MUST not be redeclared within the login phase.
Satran, et al. Standards Track [Page 191] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 191] RFC 3720 iSCSI April 2004
12.5. InitiatorName
12.5. InitiatorName
Use: IO, Declarative, Any-Stage Senders: Initiator Scope: SW
Use: IO, Declarative, Any-Stage Senders: Initiator Scope: SW
InitiatorName=<iSCSI-name-value>
InitiatorName=<iSCSI-name-value>
Examples:
Examples:
InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345
InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90
InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345 InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90
The initiator of the TCP connection MUST provide this key to the remote endpoint at the first Login of the Login Phase for every connection. The InitiatorName key enables the initiator to identify itself to the remote endpoint.
The initiator of the TCP connection MUST provide this key to the remote endpoint at the first Login of the Login Phase for every connection. The InitiatorName key enables the initiator to identify itself to the remote endpoint.
InitiatorName MUST not be redeclared within the login phase.
InitiatorName MUST not be redeclared within the login phase.
12.6. TargetAlias
12.6. TargetAlias
Use: ALL, Declarative, Any-Stage Senders: Target Scope: SW
Use: ALL, Declarative, Any-Stage Senders: Target Scope: SW
TargetAlias=<iSCSI-local-name-value>
TargetAlias=<iSCSI-local-name-value>
Examples:
Examples:
TargetAlias=Bob-s Disk
TargetAlias=Database Server 1 Log Disk
TargetAlias=Web Server 3 Disk 20
TargetAlias=Bob-s Disk TargetAlias=Database Server 1 Log Disk TargetAlias=Web Server 3 Disk 20
If a target has been configured with a human-readable name or description, this name SHOULD be communicated to the initiator during a Login Response PDU if SessionType=Normal (see Section 12.21 SessionType). This string is not used as an identifier, nor is it meant to be used for authentication or authorization decisions. It can be displayed by the initiator's user interface in a list of targets to which it is connected.
If a target has been configured with a human-readable name or description, this name SHOULD be communicated to the initiator during a Login Response PDU if SessionType=Normal (see Section 12.21 SessionType). This string is not used as an identifier, nor is it meant to be used for authentication or authorization decisions. It can be displayed by the initiator's user interface in a list of targets to which it is connected.
Satran, et al. Standards Track [Page 192] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 192] RFC 3720 iSCSI April 2004
12.7. InitiatorAlias
12.7. InitiatorAlias
Use: ALL, Declarative, Any-Stage Senders: Initiator Scope: SW
Use: ALL, Declarative, Any-Stage Senders: Initiator Scope: SW
InitiatorAlias=<iSCSI-local-name-value>
InitiatorAlias=<iSCSI-local-name-value>
Examples:
Examples:
InitiatorAlias=Web Server 4
InitiatorAlias=spyalley.nsa.gov
InitiatorAlias=Exchange Server
InitiatorAlias=Web Server 4 InitiatorAlias=spyalley.nsa.gov InitiatorAlias=Exchange Server
If an initiator has been configured with a human-readable name or description, it SHOULD be communicated to the target during a Login Request PDU. If not, the host name can be used instead. This string is not used as an identifier, nor is meant to be used for authentication or authorization decisions. It can be displayed by the target's user interface in a list of initiators to which it is connected.
If an initiator has been configured with a human-readable name or description, it SHOULD be communicated to the target during a Login Request PDU. If not, the host name can be used instead. This string is not used as an identifier, nor is meant to be used for authentication or authorization decisions. It can be displayed by the target's user interface in a list of initiators to which it is connected.
12.8. TargetAddress
12.8. TargetAddress
Use: ALL, Declarative, Any-Stage Senders: Target Scope: SW
Use: ALL, Declarative, Any-Stage Senders: Target Scope: SW
TargetAddress=domainname[:port][,portal-group-tag]
TargetAddress=domainname[:port][,portal-group-tag]
The domainname can be specified as either a DNS host name, a dotted-decimal IPv4 address, or a bracketed IPv6 address as specified in [RFC2732].
The domainname can be specified as either a DNS host name, a dotted-decimal IPv4 address, or a bracketed IPv6 address as specified in [RFC2732].
If the TCP port is not specified, it is assumed to be the IANA-assigned default port for iSCSI (see Section 13 IANA Considerations).
If the TCP port is not specified, it is assumed to be the IANA-assigned default port for iSCSI (see Section 13 IANA Considerations).
If the TargetAddress is returned as the result of a redirect status in a login response, the comma and portal group tag MUST be omitted.
If the TargetAddress is returned as the result of a redirect status in a login response, the comma and portal group tag MUST be omitted.
If the TargetAddress is returned within a SendTargets response, the portal group tag MUST be included.
If the TargetAddress is returned within a SendTargets response, the portal group tag MUST be included.
Satran, et al. Standards Track [Page 193] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 193] RFC 3720 iSCSI April 2004
Examples:
Examples:
TargetAddress=10.0.0.1:5003,1
TargetAddress=[1080:0:0:0:8:800:200C:417A],65
TargetAddress=[1080::8:800:200C:417A]:5003,1
TargetAddress=computingcenter.example.com,23
TargetAddress=10.0.0.1:5003,1 TargetAddress=[1080:0:0:0:8:800:200C:417A],65 TargetAddress=[1080::8:800:200C:417A]:5003,1 TargetAddress=computingcenter.example.com,23
Use of the portal-group-tag is described in Appendix D. - SendTargets Operation -. The formats for the port and portal-group-tag are the same as the one specified in Section 12.9 TargetPortalGroupTag.
Use of the portal-group-tag is described in Appendix D. - SendTargets Operation -. The formats for the port and portal-group-tag are the same as the one specified in Section 12.9 TargetPortalGroupTag.
12.9. TargetPortalGroupTag
12.9. TargetPortalGroupTag
Use: IO by target, Declarative, Any-Stage Senders: Target Scope: SW
Use: IO by target, Declarative, Any-Stage Senders: Target Scope: SW
TargetPortalGroupTag=<16-bit-binary-value>
TargetPortalGroupTag=<16-bit-binary-value>
Examples: TargetPortalGroupTag=1
Examples: TargetPortalGroupTag=1
The target portal group tag is a 16-bit binary-value that uniquely identifies a portal group within an iSCSI target node. This key carries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has the C bit set to 0 when TargetName is given by the initiator.
The target portal group tag is a 16-bit binary-value that uniquely identifies a portal group within an iSCSI target node. This key carries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has the C bit set to 0 when TargetName is given by the initiator.
For the complete usage expectations of this key see Section 5.3 Login Phase.
For the complete usage expectations of this key see Section 5.3 Login Phase.
12.10. InitialR2T
12.10. InitialR2T
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
InitialR2T=<boolean-value>
InitialR2T=<boolean-value>
Examples:
Examples:
I->InitialR2T=No
T->InitialR2T=No
I->InitialR2T=No T->InitialR2T=No
Satran, et al. Standards Track [Page 194] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 194] RFC 3720 iSCSI April 2004
Default is Yes. Result function is OR.
Default is Yes. Result function is OR.
The InitialR2T key is used to turn off the default use of R2T for unidirectional and the output part of bidirectional commands, thus allowing an initiator to start sending data to a target as if it has received an initial R2T with Buffer Offset=Immediate Data Length and Desired Data Transfer Length=(min(FirstBurstLength, Expected Data Transfer Length) - Received Immediate Data Length).
The InitialR2T key is used to turn off the default use of R2T for unidirectional and the output part of bidirectional commands, thus allowing an initiator to start sending data to a target as if it has received an initial R2T with Buffer Offset=Immediate Data Length and Desired Data Transfer Length=(min(FirstBurstLength, Expected Data Transfer Length) - Received Immediate Data Length).
The default action is that R2T is required, unless both the initiator and the target send this key-pair attribute specifying InitialR2T=No. Only the first outgoing data burst (immediate data and/or separate PDUs) can be sent unsolicited (i.e., not requiring an explicit R2T).
The default action is that R2T is required, unless both the initiator and the target send this key-pair attribute specifying InitialR2T=No. Only the first outgoing data burst (immediate data and/or separate PDUs) can be sent unsolicited (i.e., not requiring an explicit R2T).
12.11. ImmediateData
12.11. ImmediateData
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
ImmediateData=<boolean-value>
ImmediateData=<boolean-value>
Default is Yes. Result function is AND.
Default is Yes. Result function is AND.
The initiator and target negotiate support for immediate data. To turn immediate data off, the initiator or target must state its desire to do so. ImmediateData can be turned on if both the initiator and target have ImmediateData=Yes.
The initiator and target negotiate support for immediate data. To turn immediate data off, the initiator or target must state its desire to do so. ImmediateData can be turned on if both the initiator and target have ImmediateData=Yes.
If ImmediateData is set to Yes and InitialR2T is set to Yes (default), then only immediate data are accepted in the first burst.
If ImmediateData is set to Yes and InitialR2T is set to Yes (default), then only immediate data are accepted in the first burst.
If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send unsolicited data and the target MUST reject unsolicited data with the corresponding response code.
If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send unsolicited data and the target MUST reject unsolicited data with the corresponding response code.
If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-Out PDUs.
If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-Out PDUs.
If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-Out PDUs.
If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-Out PDUs.
Satran, et al. Standards Track [Page 195] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 195] RFC 3720 iSCSI April 2004
The following table is a summary of unsolicited data options:
The following table is a summary of unsolicited data options:
+----------+-------------+------------------+--------------+ |InitialR2T|ImmediateData| Unsolicited |Immediate Data| | | | Data Out PDUs | | +----------+-------------+------------------+--------------+ | No | No | Yes | No | +----------+-------------+------------------+--------------+ | No | Yes | Yes | Yes | +----------+-------------+------------------+--------------+ | Yes | No | No | No | +----------+-------------+------------------+--------------+ | Yes | Yes | No | Yes | +----------+-------------+------------------+--------------+
+----------+-------------+------------------+--------------+ |InitialR2T|ImmediateData| Unsolicited |Immediate Data| | | | Data Out PDUs | | +----------+-------------+------------------+--------------+ | No | No | Yes | No | +----------+-------------+------------------+--------------+ | No | Yes | Yes | Yes | +----------+-------------+------------------+--------------+ | Yes | No | No | No | +----------+-------------+------------------+--------------+ | Yes | Yes | No | Yes | +----------+-------------+------------------+--------------+
12.12. MaxRecvDataSegmentLength
12.12. MaxRecvDataSegmentLength
Use: ALL, Declarative Senders: Initiator and Target Scope: CO
Use: ALL, Declarative Senders: Initiator and Target Scope: CO
MaxRecvDataSegmentLength=<numerical-value-512-to-(2**24-1)>
MaxRecvDataSegmentLength=<numerical-value-512-to-(2**24-1)>
Default is 8192 bytes.
Default is 8192 bytes.
The initiator or target declares the maximum data segment length in bytes it can receive in an iSCSI PDU.
The initiator or target declares the maximum data segment length in bytes it can receive in an iSCSI PDU.
The transmitter (initiator or target) is required to send PDUs with a data segment that does not exceed MaxRecvDataSegmentLength of the receiver.
The transmitter (initiator or target) is required to send PDUs with a data segment that does not exceed MaxRecvDataSegmentLength of the receiver.
A target receiver is additionally limited by MaxBurstLength for solicited data and FirstBurstLength for unsolicited data. An initiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor unsolicited PDUs exceeding FirstBurstLength (or FirstBurstLength-Immediate Data Length if immediate data were sent).
A target receiver is additionally limited by MaxBurstLength for solicited data and FirstBurstLength for unsolicited data. An initiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor unsolicited PDUs exceeding FirstBurstLength (or FirstBurstLength-Immediate Data Length if immediate data were sent).
12.13. MaxBurstLength
12.13. MaxBurstLength
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
MaxBurstLength=<numerical-value-512-to-(2**24-1)>
MaxBurstLength=<numerical-value-512-to-(2**24-1)>
Satran, et al. Standards Track [Page 196] RFC 3720 iSCSI April 2004
Satran, et al. Standards Track [Page 196] RFC 3720 iSCSI April 2004
Default is 262144 (256 Kbytes). Result function is Minimum.
Default is 262144 (256 Kbytes). Result function is Minimum.
The initiator and target negotiate maximum SCSI data payload in bytes in a Data-In or a solicited Data-Out iSCSI sequence. A sequence consists of one or more consecutive Data-In or Data-Out PDUs that end with a Data-In or Data-Out PDU with the F bit set to one.
創始者と目標は中のDataのバイトか請求された外のData iSCSI系列で最大のSCSIデータペイロードを交渉します。 系列はその終わりに中のDataか外のData PDUと共に1つに設定されたFビットで中の1連続したDataか外のData PDUsから成ります。
12.14. FirstBurstLength
12.14. FirstBurstLength
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery Irrelevant when: ( InitialR2T=Yes and ImmediateData=No )
使用: 最低気温送付者: 創始者と目標範囲: SW Irrelevant、いつ: SessionTypeが発見Irrelevantと等しい、いつ: (InitialR2T=はいとImmediateData=ノー)
FirstBurstLength=<numerical-value-512-to-(2**24-1)>
=<数字のFirstBurstLength値-512、-、-(2**24-1)>。
Default is 65536 (64 Kbytes). Result function is Minimum.
デフォルトは65536(64キロバイト)です。 結果機能はMinimumです。
The initiator and target negotiate the maximum amount in bytes of unsolicited data an iSCSI initiator may send to the target during the execution of a single SCSI command. This covers the immediate data (if any) and the sequence of unsolicited Data-Out PDUs (if any) that follow the command.
創始者と目標はiSCSI創始者がただ一つのSCSIコマンドの実行の間に目標に送るかもしれない求められていないデータのバイトで表現される最大の量を交渉します。 これはコマンドに続く(もしあれば)の即値データと(もしあれば)の求められていない外のData PDUsの系列を含んでいます。
FirstBurstLength MUST NOT exceed MaxBurstLength.
FirstBurstLengthはMaxBurstLengthを超えてはいけません。
12.15. DefaultTime2Wait
12.15. DefaultTime2Wait
Use: LO Senders: Initiator and Target Scope: SW
使用: 最低気温送付者: 創始者と目標範囲: SW
DefaultTime2Wait=<numerical-value-0-to-3600>
DefaultTime2Waitは<の数字の値-0〜3600>と等しいです。
Default is 2. Result function is Maximum.
デフォルトは2です。 結果機能はMaximumです。
The initiator and target negotiate the minimum time, in seconds, to wait before attempting an explicit/implicit logout or an active task reassignment after an unexpected connection termination or a connection reset.
創始者と目標は予期していなかった接続終了か接続リセットの後に秒の明白な/を試みる前に暗黙の待ちに、ログアウトしてください。さもないと、能動態が再割当てに仕事を課す最小の時代に交渉します。
A value of 0 indicates that logout or active task reassignment can be attempted immediately.
0の値は、ログアウトしてください。さもないと、すぐにアクティブ・タスク再割当ては試みることができるのを示します。
Satran, et al. Standards Track [Page 197] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[197ページ]。
12.16. DefaultTime2Retain
12.16. DefaultTime2Retain
Use: LO Senders: Initiator and Target Scope: SW
使用: 最低気温送付者: 創始者と目標範囲: SW
DefaultTime2Retain=<numerical-value-0-to-3600>
DefaultTime2Retainは<の数字の値-0〜3600>と等しいです。
Default is 20. Result function is Minimum.
デフォルトは20です。 結果機能はMinimumです。
The initiator and target negotiate the maximum time, in seconds after an initial wait (Time2Wait), before which an active task reassignment is still possible after an unexpected connection termination or a connection reset.
創始者と目標は最大の時間を交渉します、初期の待ち(Time2Wait)の何秒も後に。その時、アクティブ・タスク再割当ては予期していなかった接続終了か接続リセットの後にまだ可能です。
This value is also the session state timeout if the connection in question is the last LOGGED_IN connection in the session.
また、問題の接続がセッションで最後のLOGGED_IN接続であるなら、この値はセッション州のタイムアウトです。
A value of 0 indicates that connection/task state is immediately discarded by the target.
0の値は、接続/タスク状態がすぐに目標によって捨てられるのを示します。
12.17. MaxOutstandingR2T
12.17. MaxOutstandingR2T
Use: LO Senders: Initiator and Target Scope: SW
使用: 最低気温送付者: 創始者と目標範囲: SW
MaxOutstandingR2T=<numerical-value-from-1-to-65535> Irrelevant when: SessionType=Discovery
MaxOutstandingR2Tが<の数字の値と等しい、-、-1〜65535>Irrelevant、いつ: SessionTypeは発見と等しいです。
Default is 1. Result function is Minimum.
デフォルトは1です。 結果機能はMinimumです。
Initiator and target negotiate the maximum number of outstanding R2Ts per task, excluding any implied initial R2T that might be part of that task. An R2T is considered outstanding until the last data PDU (with the F bit set to 1) is transferred, or a sequence reception timeout (Section 6.1.4.1 Recovery Within-command) is encountered for that data sequence.
創始者と目標は1タスクあたりの傑出しているR2Tsの最大数を交渉します、そのタスクの一部であるかもしれないどんな暗示している初期のR2Tを除いて。 最後のデータPDU(1に設定されたFビットがある)がわたるまで、R2Tが傑出していると考えられるか、または系列レセプションタイムアウト(セクション6.1.4.1Recovery Within-コマンド)はそのデータ系列のために遭遇します。
12.18. DataPDUInOrder
12.18. DataPDUInOrder
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
使用: 最低気温送付者: 創始者と目標範囲: SW Irrelevant、いつ: SessionTypeは発見と等しいです。
DataPDUInOrder=<boolean-value>
DataPDUInOrderは<ブール値>と等しいです。
Satran, et al. Standards Track [Page 198] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[198ページ]。
Default is Yes. Result function is OR.
デフォルトはそうです。はい。 結果機能はORです。
No is used by iSCSI to indicate that the data PDUs within sequences can be in any order. Yes is used to indicate that data PDUs within sequences have to be at continuously increasing addresses and overlays are forbidden.
いいえは、系列の中のデータPDUsが順不同である場合があることを示すのにiSCSIによって使用されます。 はいはアドレスを絶え間なく増加させるのに系列の中のデータPDUsがなければならないのを示すのに使用されます、そして、オーバレイは禁じられます。
12.19. DataSequenceInOrder
12.19. DataSequenceInOrder
Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery
使用: 最低気温送付者: 創始者と目標範囲: SW Irrelevant、いつ: SessionTypeは発見と等しいです。
DataSequenceInOrder=<boolean-value>
DataSequenceInOrderは<ブール値>と等しいです。
Default is Yes. Result function is OR.
デフォルトはそうです。はい。 結果機能はORです。
A Data Sequence is a sequence of Data-In or Data-Out PDUs that end with a Data-In or Data-Out PDU with the F bit set to one. A Data-Out sequence is sent either unsolicited or in response to an R2T. Sequences cover an offset-range.
その終わりにData Sequenceは1つに設定されたFビットがある中のDataか外のData PDUがある中のDataか外のData PDUsの系列です。 または、外のData系列を送る、求められていなさ、R2Tに対応して。 系列はオフセット範囲をカバーしています。
If DataSequenceInOrder is set to No, Data PDU sequences may be transferred in any order.
DataSequenceInOrderがいいえ、Data PDUに用意ができているなら、順不同に系列を移すかもしれません。
If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).
DataSequenceInOrderがわたっている連用が非減少している系列オフセットであったに違いないならはい、Data Sequencesに用意ができている、(R2Tバッファオフセット、書く、読書データ系列の中の最もわずかな中のSCSI Dataバッファオフセット、)
If DataSequenceInOrder is set to Yes, a target may retry at most the last R2T, and an initiator may at most request retransmission for the last read data sequence. For this reason, if ErrorRecoveryLevel is not 0 and DataSequenceInOrder is set to Yes then MaxOustandingR2T MUST be set to 1.
創始者は、DataSequenceInOrderがはい、目標に用意ができているなら最後のR2Tを高々再試行するかもしれなくて、最後に読まれたデータ系列のために「再-トランスミッション」を高々要求するかもしれません。 この理由で、ErrorRecoveryLevelが0歳でなく、DataSequenceInOrderがそしてはい、MaxOustandingR2Tに用意ができているなら、1に設定しなければなりません。
12.20. ErrorRecoveryLevel
12.20. ErrorRecoveryLevel
Use: LO Senders: Initiator and Target Scope: SW
使用: 最低気温送付者: 創始者と目標範囲: SW
ErrorRecoveryLevel=<numerical-value-0-to-2>
ErrorRecoveryLevelは<の数字の値-0〜2>と等しいです。
Satran, et al. Standards Track [Page 199] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[199ページ]。
Default is 0. Result function is Minimum.
デフォルトは0です。 結果機能はMinimumです。
The initiator and target negotiate the recovery level supported.
創始者と目標はレベルが支持した回復を交渉します。
Recovery levels represent a combination of recovery capabilities. Each recovery level includes all the capabilities of the lower recovery levels and adds some new ones to them.
回復レベルは回復能力の組み合わせを表します。 それぞれの回復レベルは、下側の回復レベルのすべての能力を含んで、いくつかの新しいものをそれらに加えます。
In the description of recovery mechanisms, certain recovery classes are specified. Section 6.1.5 Error Recovery Hierarchy describes the mapping between the classes and the levels.
回収機構の記述では、ある回復のクラスは指定されます。 セクション6.1 .5 Error Recovery Hierarchyはクラスとレベルの間のマッピングについて説明します。
12.21. SessionType
12.21. SessionType
Use: LO, Declarative, Any-Stage Senders: Initiator Scope: SW
使用: 叙述的な最低気温、いくらか、-、ステージ、Senders: 創始者範囲: SW
SessionType= <Discovery|Normal>
SessionTypeは<発見と等しいです。|正常な>。
Default is Normal.
デフォルトはNormalです。
The initiator indicates the type of session it wants to create. The target can either accept it or reject it.
創始者はそれが作成したがっているセッションのタイプを示します。 目標は、それを受け入れるか、またはそれを拒絶できます。
A discovery session indicates to the Target that the only purpose of this Session is discovery. The only requests a target accepts in this type of session are a text request with a SendTargets key and a logout request with reason "close the session".
発見セッションは、このSessionの唯一の目的が発見であることをTargetに示します。 目標がこのタイプのセッションのときに受け入れる唯一の要求はキーとaがログアウトするというSendTargetsとのテキスト要求が、理由で「セッションを終えてください」よう要求するということです。
The discovery session implies MaxConnections = 1 and overrides both the default and an explicit setting.
発見セッションは、MaxConnections=1を含意して、デフォルトと明白な設定の両方をくつがえします。
12.22. The Private or Public Extension Key Format
12.22. 個人的であるか公共の拡大主要な形式
Use: ALL Senders: Initiator and Target Scope: specific key dependent
使用: すべての送付者: 創始者と目標範囲: 特定の主要な扶養家族
X-reversed.vendor.dns_name.do_something=
X-reversed.vendor.dns_name.do_、何かが等しいです。
or
または
X<#><IANA-registered-string>=
X<#><IANAによって登録されたストリングの>=
Satran, et al. Standards Track [Page 200] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[200ページ]。
Keys with this format are used for public or private extension purposes. These keys always start with X- if unregistered with IANA (private) or X# if registered with IANA (public).
この形式があるキーは公共の、または、個人的な拡大目的に使用されます。 IANA(個人的な)かXと共に登録されていないなら、#IANA(公共の)に登録されるなら、これらのキーはいつもXから始めます。
For unregistered keys, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to the key-proper.
登録されていないキーに関しては、業者を特定するために、私たちは、あなたが接頭語として逆にされたDNS-名前を適切なキーに使用することを提案します。
The part of key-name following X- and X# MUST conform to the format for key-name specified in Section 5.1 Text Format.
XとX#に続く主要な名前の部分はセクション5.1 Text Formatで指定された主要な名前のための形式に従わなければなりません。
For IANA registered keys the string following X# must be registered with IANA and the use of the key MUST be described by an informational RFC.
IANAに関しては、情報のRFCはキーのIANAと使用で登録されていて、ストリングの次のX#、がそうしなければならない登録されたキーについて説明しなければなりません。
Vendor specific keys MUST ONLY be used in normal sessions.
通常のセッションのときに業者の特定のキーを使用するだけでよいです。
Support for public or private extension keys is OPTIONAL.
公共の、または、個人的な拡大キーのサポートはOPTIONALです。
13. IANA Considerations
13. IANA問題
This section conforms to [RFC2434].
このセクションは[RFC2434]に一致しています。
The well-known user TCP port number for iSCSI connections assigned by IANA is 3260 and this is the default iSCSI port. Implementations needing a system TCP port number may use port 860, the port assigned by IANA as the iSCSI system port; however in order to use port 860, it MUST be explicitly specified - implementations MUST NOT default to use of port 860, as 3260 is the only allowed default.
iSCSI接続のためのポートナンバーがIANAで割り当てた周知のユーザTCPは3260です、そして、これはデフォルトiSCSIポートです。 システムTCPポートナンバーを必要とする実現はポート860を使用するかもしれません、iSCSIシステムポートとしてIANAによって割り当てられたポート。 しかしながら、ポート860を使用するために、明らかにそれを指定しなければなりません--実現はポート860の使用をデフォルトとしてはいけません、3260が唯一の許容デフォルトであるので。
Extension keys, authentication methods, or digest types for which a vendor or group of vendors intend to provide publicly available descriptions MUST be described by an RFC and MUST be registered with IANA.
業者の業者かグループが公的に利用可能な記述を提供するつもりである拡大キー、認証方法、またはダイジェストタイプをRFCが説明しなければならなくて、IANAに示さなければなりません。
The IANA has set up the following three registries:
IANAは以下の3つの登録をセットアップしました:
a) iSCSI extended key registry
b) iSCSI authentication methods registry
c) iSCSI digests registry
a) iSCSIは主要な登録の認証方法登録c)iSCSIダイジェストb)iSCSI登録を広げました。
[RFC3723] also instructs IANA to maintain a registry for the values of the SRP_GROUP key. The format of these values must conform to the one specified for iSCSI extension item-label in Section 13.5.4 Standard iSCSI extension item-label format.
また、[RFC3723]は、SRP_GROUPキーの値のために登録を維持するようIANAに命令します。 これらの値の形式はセクション13.5.4Standard iSCSI拡大項目ラベル形式でiSCSI拡大項目ラベルに指定されたものに従わなければなりません。
Satran, et al. Standards Track [Page 201] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[201ページ]。
For the iSCSI authentication methods registry and the iSCSI digests registry, IANA MUST also assign a 16-bit unsigned integer number (the method number for the authentication method and the digest number for the digest).
また、iSCSI認証方法登録とiSCSIダイジェストのために、登録、IANA MUSTは16ビットの符号のない整数番号を割り当てます(認証方法の方法番号とダイジェストのダイジェスト番号)。
The following initial values for the registry for authentication methods are specified by the standards action of this document:
認証方法のための登録への以下の初期の値はこのドキュメントの規格機能で指定されます:
Authentication Method | Number |
+----------------------------------------+--------+
| CHAP | 1 |
+----------------------------------------+--------+
| SRP | 2 |
+----------------------------------------+--------+
| KRB5 | 3 |
+----------------------------------------+--------+
| SPKM1 | 4 |
+----------------------------------------+--------+
| SPKM2 | 5 |
+----------------------------------------+--------+
認証方法| 数| +----------------------------------------+--------+ | やつ| 1 | +----------------------------------------+--------+ | SRP| 2 | +----------------------------------------+--------+ | KRB5| 3 | +----------------------------------------+--------+ | SPKM1| 4 | +----------------------------------------+--------+ | SPKM2| 5 | +----------------------------------------+--------+
All other record numbers from 0 to 255 are reserved. IANA will register numbers above 255.
他のすべての記録的な0〜255までの数が予約されています。 IANAは255より上で数を示すでしょう。
Authentication methods with numbers above 255 MUST be unique within the registry and MUST be used with the prefix Z#.
255を超えた数がある認証方法を登録の中でユニークでなければならなく、接頭語Z#と共に使用しなければなりません。
The following initial values for the registry for digests are specified by the standards action of this document:
ダイジェストのための登録への以下の初期の値はこのドキュメントの規格機能で指定されます:
Digest | Number |
+----------------------------------------+--------+
| CRC32C | 1 |
+----------------------------------------+--------+
ダイジェスト| 数| +----------------------------------------+--------+ | CRC32C| 1 | +----------------------------------------+--------+
All other record numbers from 0 to 255 are reserved. IANA will register numbers above 255.
他のすべての記録的な0〜255までの数が予約されています。 IANAは255より上で数を示すでしょう。
Digests with numbers above 255 MUST be unique within the registry and MUST be used with the prefix Y#.
255を超えた数があるダイジェストを登録の中でユニークでなければならなく、接頭語Y#と共に使用しなければなりません。
The RFC that describes the item to be registered MUST indicate in the IANA Considerations section the string and iSCSI registry to which it should be recorded.
登録されるために項目について説明するRFCはIANA Considerations部でそれが記録されるべきであるストリングとiSCSI登録を示さなければなりません。
Extension Keys, Authentication Methods, and digests (iSCSI extension items) must conform to a number of requirements as described below.
Extensionキーズ、Authentication Methods、およびダイジェスト(iSCSI拡大の品目)は以下で説明されるように多くの要件に一致しなければなりません。
Satran, et al. Standards Track [Page 202] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[202ページ]。
13.1. Naming Requirements
13.1. 要件を命名します。
Each iSCSI extension item must have a unique name in its category. This name will be used as a standard-label for the key, access method, or digest and must conform to the syntax specified in Section 13.5.4 Standard iSCSI extension item-label format for iSCSI extension item-labels.
それぞれのiSCSI拡大の品目には、カテゴリにおけるユニークな名前がなければなりません。 この名前は、キー、アクセス法、またはダイジェストに標準ラベルとして使用されて、セクション13.5.4Standard iSCSI拡大項目ラベル形式でiSCSI拡大項目ラベルに指定された構文に従わなければなりません。
13.2. Mechanism Specification Requirements
13.2. メカニズム仕様書要求事項
For iSCSI extension items all of the protocols and procedures used by a given iSCSI extension item must be described, either in the specification of the iSCSI extension item itself or in some other publicly available specification, in sufficient detail for the iSCSI extension item to be implemented by any competent implementor. Use of secret and/or proprietary methods in iSCSI extension items are expressly prohibited. In addition, the restrictions imposed by [RFC1602] on the standardization of patented algorithms must be respected.
iSCSI拡大の品目において、iSCSI拡大の品目自体の仕様かある他の公的に利用可能な仕様で与えられたiSCSI拡大の品目によって用いられたプロトコルと手順のすべてについて説明しなければなりません、どんな有能な作成者もiSCSI拡大の品目を実行できるくらい詳細に。 iSCSI拡大の品目における秘密の、そして/または、独占である方法の使用は明白に禁止されています。 さらに、[RFC1602]によって特許をとられたアルゴリズムの標準化に課された制限を尊敬しなければなりません。
13.3. Publication Requirements
13.3. 公表要件
All iSCSI extension items must be described by an RFC. The RFC may be informational rather than Standards-Track, although Standards Track review and approval are encouraged for all iSCSI extension items.
RFCはすべてのiSCSI拡大の品目について説明しなければなりません。 RFCはStandards-道よりむしろ情報であるかもしれません、Standards Trackレビューと承認はすべてのiSCSI拡大の品目のために奨励されますが。
13.4. Security Requirements
13.4. セキュリティ要件
Any known security issues that arise from the use of the iSCSI extension item must be completely and fully described. It is not required that the iSCSI extension item be secure or that it be free from risks, but that the known risks be identified. Publication of a new iSCSI extension item does not require an exhaustive security review, and the security considerations section is subject to continuing evaluation.
iSCSI拡大の品目の使用から起こるどんな知られている安全保障問題についても完全に、そして完全に説明しなければなりません。 iSCSI拡大の品目が安全であるか、それにはリスクがありませんが、または知られている危険が特定されるのが必要ではありません。 新しいiSCSI拡大の品目の公表は評価を続けているレビュー、およびセキュリティ問題部を条件としている徹底的なセキュリティを必要としません。
Additional security considerations should be addressed by publishing revised versions of the iSCSI extension item specification.
追加担保問題はiSCSI拡大項目仕様の出版改訂版によって記述されるべきです。
For each of these registries, IANA must record the registered string, which MUST conform to the format rules described in Section 13.5.4 Standard iSCSI extension item-label format for iSCSI extension item-labels, and the RFC number that describes it. The key prefix (X#, Y# or Z#) is not part of the recorded string.
それぞれのこれらの登録に関しては、IANAは登録されたストリングとそれについて説明するRFC番号を記録しなければなりません。(ストリングはiSCSI拡大項目ラベルのためにセクション13.5.4Standard iSCSI拡大項目ラベル形式で説明された形式規則に一致しなければなりません)。 主要な接頭語(X#、Y#またはZ#)は記録されたストリングの一部ではありません。
Satran, et al. Standards Track [Page 203] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[203ページ]。
13.5. Registration Procedure
13.5. 登録手順
Registration of a new iSCSI extension item starts with the construction of an Internet Draft to become an RFC.
新しいiSCSI拡大の品目の登録はインターネットDraftの構造からRFCになり始めます。
13.5.1. Present the iSCSI extension item to the Community
13.5.1. iSCSI拡大の品目をCommunityに提示してください。
Send a proposed access type specification to the IPS WG mailing list, or if the IPS WG is disbanded at the registration time, to a mailing list designated by the IETF Transport Area Director for a review period of a month. The intent of the public posting is to solicit comments and feedback on the iSCSI extension item specification and a review of any security considerations.
IPS WGメーリングリストかそれともIPS WGが登録時に解散されるかどうかに提案されたアクセス型仕様を送ってください、1カ月のレビューの期間、IETF Transport Areaディレクターによって指定されたメーリングリストに。 公共の任命の意図はiSCSI拡大項目仕様とどんなセキュリティ問題のレビューのコメントとフィードバックにも請求することです。
13.5.2. iSCSI extension item review and IESG approval
13.5.2. iSCSI拡大項目レビューとIESG承認
When the one month period has passed, the IPS WG chair or a person nominated by the IETF Transport Area Director (the iSCSI extension item reviewer) forwards the Internet Draft to the IESG for publication as an informational RFC or rejects it. If the specification is a standards track document, the usual IETF procedures for such documents are followed.
1カ月の期間が経過したとき、IETF Transport Areaディレクター(iSCSI拡大項目評論家)によるIPS WGいすか任命された人が、公表のために情報のRFCとしてインターネットDraftをIESGに送るか、またはそれを拒絶します。 仕様が標準化過程ドキュメントであるなら、そのようなドキュメントのための普通のIETF手順は従われています。
Decisions made by the iSCSI extension item reviewer must be published within two weeks after the month-long review period. Decisions made by the iSCSI extension item reviewer can be appealed through the IESG appeal process.
一カ月間続いたレビューの期間の後2週間以内にiSCSI拡大項目評論家によってされた決定を発行しなければなりません。 IESG上告の過程でiSCSI拡大項目評論家によってされた決定は上告できます。
13.5.3. IANA Registration
13.5.3. IANA登録
Provided that the iSCSI extension item has either passed review or has been successfully appealed to the IESG, and the specification is published as an RFC, then IANA will register the iSCSI extension item and make the registration available to the community.
iSCSI拡大の品目がレビューに合格するか、または首尾よくIESGに上告されて、仕様がRFCとして発表されると、IANAはiSCSI拡大の品目を登録して、登録を共同体に利用可能にするでしょう。
13.5.4. Standard iSCSI extension item-label format
13.5.4. 標準のiSCSI拡大項目ラベル形式
The following character symbols are used iSCSI extension item-labels (the hexadecimal values represent Unicode code points):
以下のキャラクタシンボルは中古のiSCSI拡大項目ラベル(16進値はユニコードコード・ポイントを表す)です:
(a-z, A-Z) - letters (0-9) - digits "." (0x2e) - dot "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore
「(a-z、A-Z)--手紙(0-9)--ケタ」、」 (0x2e) - 「+」 (0x2b)を引いた(0x2d)と"_"(0x5f)の商業の"@"(0×40)が下線を引くドット「-」
Satran, et al. Standards Track [Page 204] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[204ページ]。
An iSCSI extension item-label is a string of one or more characters that consist of letters, digits, dot, minus, plus, commercial at, or underscore. An iSCSI extension item-label MUST begin with a capital letter and must not exceed 63 characters.
iSCSI拡大項目ラベルは文字、ケタ、そのうえ、商業を引いたドット、または強調から成る一連の1つ以上のキャラクタです。 iSCSI拡大項目ラベルは、大文字で始まらなければならなくて、63のキャラクタを超えてはいけません。
13.6. IANA Procedures for Registering iSCSI extension items
13.6. Registering iSCSI拡大の品目のためのIANA Procedures
The identity of the iSCSI extension item reviewer is communicated to the IANA by the IESG. Then, the IANA only acts in response to iSCSI extension item definitions that are approved by the iSCSI extension item reviewer and forwarded by the reviewer to the IANA for registration, or in response to a communication from the IESG that an iSCSI extension item definition appeal has overturned the iSCSI extension item reviewer's ruling.
iSCSI拡大項目評論家のアイデンティティはIESGによってIANAに伝えられます。 次に、IANAがiSCSI拡大項目評論家によって承認されて、登録のために評論家によってIANAに送られるiSCSI拡大項目定義に対応して行動するだけですか、またはiSCSI拡大項目定義上告がひっくり返したIESGからのコミュニケーションに対応してiSCSI拡大項目評論家は支配的です。
References
参照
Normative References
引用規格
[CAM] ANSI X3.232-199X, Common Access Method-3.
[CAM]ANSI X3.232-199X、一般的なアクセス方法-3。
[EUI] "Guidelines for 64-bit Global Identifier (EUI-64)",
http:
//standards.ieee.org/regauth/oui/tutorials/EUI64.html
[EUI] 「64ビットのグローバルな識別子(EUI-64)のためのガイドライン」、http: //standards.ieee.org/regauth/oui/tutorials/EUI64.html
[OUI] "IEEE OUI and Company_Id Assignments",
http://standards.ieee.org/regauth/oui
[OUI] 「IEEE OUIと会社_イド課題」、 http://standards.ieee.org/regauth/oui
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts-
Communication Layer", STD 3, RFC 1122, October 1989.
[RFC1122] ブレーデン、R.、エド、「インターネットホストコミュニケーションのための要件は層にする」STD3、RFC1122、10月1989日
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September
1993.
[RFC1510]コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[RFC1737] Sollins, K. and L. Masinter "Functional Requirements
for Uniform Resource Names"RFC 1737, December 1994.
[RFC1737]SollinsとK.とL.Masinter「一定のリソース名のための機能条件書」RFC1737、1994年12月。
Satran, et al. Standards Track [Page 205] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[205ページ]。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC1964] リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、1996年6月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
1982, August 1996.
[RFC1982]ElzとR.とR.ブッシュ、「通し番号演算」、RFC1982、1996年8月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
C.、「簡単な公開カギGSS-APIメカニズム(SPKM)」、RFC2025 1996年10月の[RFC2025]アダムス。
[RFC2045] Borenstein, N. and N. Freed, "MIME (Multipurpose
Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet
Message Bodies", RFC 2045, November 1996.
解放された[RFC2045]Borenstein、N.、およびN.、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC2045、1996年11月。
[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月。
[RFC2279] Yergeau, F., "UTF-8, a Transformation Format of ISO
10646", RFC 2279 October 1996.
[RFC2279]Yergeau、F.、「UTF-8、ISO10646の変化形式」RFC2279 1996年10月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2373] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter "Uniform
Resource Identifiers", RFC 2396, August 1998.
[RFC2396] バーナーズ・リーとT.とフィールディングとR.とL.Masinter「Uniform Resource Identifier」、RFC2396、1998年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
within ESP and AH", RFC 2404, November 1998.
そして、[RFC2404] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation of ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPの解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409、1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs.", BCP 26, RFC
2434, October 1998.
[RFC2434] NartenとT.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)
Satran, et al. Standards Track [Page 206] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[206ページ]。
[RFC2451] Pereira, R. and R. Adams " The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC2451] ペレイラ、R.、およびR.アダムス「超能力CBC-モード暗号アルゴリズム」、RFC2451、1998年11月。
[RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2451, December
1999.
[RFC2732] HindenとR.と大工とB.とL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2451、1999年12月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange
System", RFC 2945, September 2000.
[RFC2945] ウーと、T.と、「SRP認証と主要な交換システム」、RFC2945、9月2000日
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", STD 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、STD47、RFC3066、2001年1月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3454] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec", RFC 3566, September
2003.
[RFC3566] フランケル、S.、H.ハーバート、および「AES-XCBC-MAC-96アルゴリズムとIPsecとのその使用」、RFC3566、9月2003日
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode with IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC3686]Housley、R.、「IPsecがセキュリティ有効搭載量(超能力)を要約しているエー・イー・エス(AES)カウンタモードを使用します」、RFC3686、2004年1月。
[RFC3722] Bakke, M., "String Profile for Internet Small Computer
Systems Interface (iSCSI) Names", RFC 3722, March
2004.
[RFC3722]バッキー、M.、「インターネットの小さいコンピュータ・システムインタフェース(iSCSI)名のためのストリングプロフィール」、RFC3722、2004年3月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F.
Travostino, "Securing Block Storage Protocols over
IP", RFC 3723, March 2004.
[RFC3723] AbobaとB.とツェンとJ.とウォーカーとJ.とRanganとV.とF.Travostino、「ブロック格納プロトコルをIPの上に保証します」、RFC3723、2004年3月。
[SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2).
[SAM2]T10/1157D、SCSI構造モデル--2 (SAM-2。)
[SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC).
[SBC]NCITS.306-1998、SCSI-3はコマンド(SBC)を妨げます。
[SPC3] T10/1416-D, SCSI Primary Commands-3.
[SPC3]T10/1416-D、SCSIの第一のコマンド-3。
[UNICODE] Unicode Standard Annex #15, "Unicode Normalization
Forms", http://www.unicode.org/unicode/reports/tr15
[ユニコード]ユニコード規格別館#15、「ユニコード正常化フォーム」、 http://www.unicode.org/unicode/reports/tr15
Satran, et al. Standards Track [Page 207] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[207ページ]。
Informative References
有益な参照
[BOOT] P. Sarkar, et al., "Bootstrapping Clients using the
iSCSI Protocol", Work in Progress, July 2003.
[BOOT] P.サルカール、他、「iSCSIプロトコルを使用しているブートストラップ法クライアント」、Progress、2003年7月のWork。
[Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman "Optimization
of Cyclic Redundancy-Check Codes with 24 and 32 Parity
Bits", IEEE Transact. on Communications, Vol. 41, No.
6, June 1993.
IEEEは、「24と32のパリティビットとの周期的な冗長検査コードの最適化」と商取引します。[Castagnoli93]G.Castagnoli、S.Braeuer、およびM.Herrman. コミュニケーション、Vol.41、No.6、1993年6月で。
[CORD] Chadalapaka, M. and R. Elliott, "SCSI Command
Ordering Considerations with iSCSI", Work in Progress.
[コード] 「iSCSIと共に問題を注文するSCSIコマンド」というChadalapaka、M.、およびR.エリオットは進行中で働いています。
[RFC3347] Krueger, M., Haagens, R., Sapuntzakis, C. and M.
Bakke, "Small Computer Systems Interface protocol over
the Internet (iSCSI) Requirements and Design
Considerations", RFC 3347, July 2002.
[RFC3347] クルーガー、M.、Haagens、R.、Sapuntzakis、C.、およびM.バッキー、「小さいコンピュータシステムズInterfaceはインターネット(iSCSI)の要件とDesign Considerationsの上で議定書を作ります」、RFC3347、2002年7月。
[RFC3385] Sheinwald, D., Staran, J., Thaler, P. and V. Cavanna,
"Internet Protocol Small Computer System Interface
(iSCSI) Cyclic Redundancy Check (CRC)/Checksum
Considerations", RFC 3385, September 2002.
カヴァナ、[RFC3385] Sheinwald、D.、Staran、J.、ターレル、P.、およびRFC3385(2002年9月)対「インターネットプロトコルスモールコンピュータシステムインタフェース(iSCSI)周期冗長検査(CRC)/チェックサム問題」
[RFC3721] Bakke M., Hafner, J., Hufferd, J., Voruganti, K. and
M. Krueger, "Internet Small Computer Systems Interface
(iSCSI) Naming and Discovery, RFC 3721, March 2004.
[RFC3721]バッキーM.とハーフナー、J.とHufferdとJ.とVorugantiとK.とM.クルーガー、「インターネットの小さいコンピュータ・システムは(iSCSI)命名と発見を連結します、RFC3721、2004年3月。」
[SEQ-EXT] Kent, S., "IP Encapsulating Security Payload (ESP)",
Work in Progress, July 2002.
[SEQ-EXT] ケント、S.、「セキュリティ有効搭載量(超能力)を要約するIP」が進歩、2002年7月に働いています。
Satran, et al. Standards Track [Page 208] RFC 3720 iSCSI April 2004
Satran、他 規格はiSCSI2004年4月にRFC3720を追跡します[208ページ]。
Appendix A. Sync and Steering with Fixed Interval Markers
固定間隔マーカーとの付録A.の同時性と操縦
This appendix presents a simple scheme for synchronization (PDU boundary retrieval). It uses markers that include synchronization information placed at fixed intervals in the TCP stream.
この付録は同期(PDU境界検索)の簡単な計画を提示します。 それは定期的にTCPの流れに置かれた同期情報を含んでいるマーカーを使用します。
A Marker consists of:
Markerは以下から成ります。
Byte / 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0| Next-iSCSI-PDU-start pointer - copy #1 |
+---------------+---------------+---------------+---------------+
4| Next-iSCSI-PDU-start pointer - copy #2 |
+---------------+---------------+---------------+---------------+
バイト/0| 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0| 次のiSCSI-PDUが始まっているポインタ--コピー#1| +---------------+---------------+---------------+---------------+ 4| 次のiSCSI-PDUが始まっているポインタ--コピー#2| +---------------+---------------+---------------+---------------+
The Marker scheme uses payload byte stream counting that includes every byte placed by iSCSI in the TCP stream except for the markers themselves. It also excludes any bytes that TCP counts but are not originated by iSCSI.
Marker計画はiSCSIによってマーカー自身以外のTCPの流れに置かれたあらゆるバイトを含んでいるペイロードバイト・ストリーム勘定を使用します。 それは、また、TCPが数えるどんなバイトも除きますが、iSCSIによって溯源されません。
Markers MUST NOT be included in digest calculation.
ダイジェスト計算にマーカーを含んではいけません。
The Marker indicates the offset to the next iSCSI PDU header. The Marker is eight bytes in length and contains two 32-bit offset fields that indicate how many bytes to skip in the TCP stream in order to find the next iSCSI PDU header. The marker uses two copies of the pointer so that a marker that spans a TCP packet boundary should leave at least one valid copy in one of the packets.
Markerは次のiSCSI PDUヘッダーにオフセットを示します。 Markerは長さ8バイトであり、次のiSCSI PDUヘッダーを見つけるためにTCPの流れでいくつのバイトをスキップするかを示す2つの32ビットのオフセット分野を含んでいます。 マーカーがポインタのコピー2部を使用するので、TCPパケット境界にかかるマーカーはパケットの1つに有効なコピー少なくとも1部を残すはずです。
一覧
スポンサーリンク
