[要約] 要約： RFC 3347は、iSCSIプロトコルの要件と設計に関するガイドラインを提供しています。iSCSIは、インターネット上での小規模コンピュータシステムインターフェースの実装を可能にするものです。目的： RFC 3347の目的は、iSCSIプロトコルの要件と設計に関する情報を提供し、インターネット上での小規模コンピュータシステムインターフェースの実装を効果的にサポートすることです。
Network Working Group M. Krueger
Request for Comments: 3347 R. Haagens
Category: Informational Hewlett-Packard Corporation
C. Sapuntzakis
Stanford
M. Bakke
Cisco Systems
July 2002
Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations
インターネット上の小さなコンピューターシステムインターフェイスプロトコル（ISCSI）要件と設計上の考慮事項
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document specifies the requirements iSCSI and its related infrastructure should satisfy and the design considerations guiding the iSCSI protocol development efforts. In the interest of timely adoption of the iSCSI protocol, the IPS group has chosen to focus the first version of the protocol to work with the existing SCSI architecture and commands, and the existing TCP/IP transport layer. Both these protocols are widely-deployed and well-understood. The thought is that using these mature protocols will entail a minimum of new invention, the most rapid possible adoption, and the greatest compatibility with Internet architecture, protocols, and equipment.
このドキュメントは、ISCSIとその関連インフラストラクチャが満たす必要がある要件と、ISCSIプロトコル開発の取り組みを導く設計上の考慮事項を指定します。ISCSIプロトコルのタイムリーな採用のために、IPSグループは、既存のSCSIアーキテクチャとコマンド、および既存のTCP/IP輸送層と連携するために、プロトコルの最初のバージョンに焦点を合わせることを選択しました。これらのプロトコルはどちらも広く展開され、よく理解されています。これらの成熟したプロトコルを使用すると、最小限の新しい発明、可能な限り迅速な採用、およびインターネットアーキテクチャ、プロトコル、および機器との最大の互換性が必要になると考えられています。
Conventions used in this document
このドキュメントで使用されている規則
This document describes the requirements for a protocol design, but does not define a protocol standard. Nevertheless, 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 RFC-2119 [2].
このドキュメントでは、プロトコル設計の要件について説明しますが、プロトコル標準を定義していません。それにもかかわらず、キーワードは「必須」、「必要」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、「オプション」文書は、RFC-2119 [2]に記載されているように解釈されます。
Table of Contents
目次
1. Introduction.................................................2
2. Summary of Requirements......................................3
3. iSCSI Design Considerations..................................7
3.1. General Discussion...........................................7
3.2. Performance/Cost.............................................9
3.3. Framing.....................................................11
3.4. High bandwidth, bandwidth aggregation.......................13
4. Ease of implementation/complexity of protocol...............14
5. Reliability and Availability................................15
5.1. Detection of Data Corruption................................15
5.2. Recovery....................................................15
6. Interoperability............................................16
6.1. Internet infrastructure.....................................16
6.2. SCSI........................................................16
7. Security Considerations.....................................18
7.1. Extensible Security.........................................18
7.2. Authentication..............................................18
7.3. Data Integrity..............................................19
7.4. Data Confidentiality........................................19
8. Management..................................................19
8.1. Naming......................................................20
8.2. Discovery...................................................21
9. Internet Accessibility......................................21
9.1. Denial of Service...........................................21
9.2. NATs, Firewalls and Proxy servers...........................22
9.3. Congestion Control and Transport Selection..................22
10. Definitions.................................................22
11. References..................................................23
12. Acknowledgements............................................24
13. Author's Addresses..........................................25
14. Full Copyright Statement....................................26
The IP Storage Working group is chartered with developing comprehensive technology to transport block storage data over IP protocols. This effort includes a protocol to transport the Small Computer Systems Interface (SCSI) protocol over the Internet (iSCSI). The initial version of the iSCSI protocol will define a mapping of SCSI transport protocol over TCP/IP so that SCSI storage controllers (principally disk and tape arrays and libraries) can be attached to IP networks, notably Gigabit Ethernet (GbE) and 10 Gigabit Ethernet (10 GbE).
IPストレージワーキンググループは、IPプロトコルを介したブロックストレージデータを輸送するための包括的なテクノロジーの開発に焦点を当てています。この取り組みには、インターネット（ISCSI）を介して小型コンピューターシステムインターフェイス（SCSI）プロトコルを輸送するプロトコルが含まれます。ISCSIプロトコルの初期バージョンは、TCP/IPを介したSCSI輸送プロトコルのマッピングを定義して、SCSIストレージコントローラー（主にディスクとテープアレイおよびライブラリ）をIPネットワーク、特にギガビットイーサネット（GBE）および10ギガビットイーサネットに添付できるようにします。（10 GBE）。
The iSCSI protocol is a mapping of SCSI to TCP, and constitutes a "SCSI transport" as defined by the ANSI T10 document SCSI SAM-2 document [SAM2, p. 3, "Transport Protocols"].
ISCSIプロトコルは、SCSIのTCPへのマッピングであり、ANSI T10ドキュメントSCSI SAM-2ドキュメント[SAM2、p。3、「輸送プロトコル」]。
The iSCSI standard:
ISCSI標準：
From section 3.2 Performance/Cost:
セクション3.2からのパフォーマンス/コスト：
MUST allow implementations to equal or improve on the current state of the art for SCSI interconnects.
SCSI相互接続の現在の最新のアートに実装が等しく、または改善されることを許可する必要があります。
MUST enable cost competitive implementations.
コストの競争力のある実装を有効にする必要があります。
SHOULD minimize control overhead to enable low delay communications.
低遅延の通信を有効にするために、制御オーバーヘッドを最小限に抑える必要があります。
MUST provide high bandwidth and bandwidth aggregation.
高い帯域幅と帯域幅の集約を提供する必要があります。
MUST have low host CPU utilizations, equal to or better than current technology.
現在のテクノロジーと等しい、またはそれ以上のホストCPU利用が必要です。
MUST be possible to build I/O adapters that handle the entire SCSI task.
SCSIタスク全体を処理するI/Oアダプターを構築することが可能である必要があります。
SHOULD permit direct data placement architectures.
直接データ配置アーキテクチャを許可する必要があります。
MUST NOT impose complex operations on host software.
ホストソフトウェアに複雑な操作を課さないでください。
MUST provide for full utilization of available link bandwidth.
利用可能なリンク帯域幅を完全に利用する必要があります。
MUST allow an implementation to exploit parallelism (multiple connections) at the device interfaces and within the interconnect fabric.
デバイスインターフェイスおよびインターコネクトファブリック内での並列性（複数の接続）を活用できるようにする必要があります。
From section 3.4 High Bandwidth/Bandwidth Aggregation:
セクション3.4からの高い帯域幅/帯域幅の集約：
MUST operate over a single TCP connection.
単一のTCP接続で動作する必要があります。
SHOULD support 'connection binding', and it MUST be optional to implement.
「接続バインディング」をサポートする必要があり、実装することはオプションでなければなりません。
From section 4 Ease of Implementation/Complexity of Protocol:
セクション4から、プロトコルの実装/複雑さの容易さから：
SHOULD keep the protocol simple.
プロトコルをシンプルに保つ必要があります。
SHOULD minimize optional features.
オプションの機能を最小限に抑える必要があります。
MUST specify feature negotiation at session establishment (login).
セッション設立（ログイン）で機能交渉を指定する必要があります。
MUST operate correctly when no optional features are negotiated as well as when individual option negotions are unsuccessful.
オプションの機能が交渉されていない場合、および個々のオプション交渉が失敗した場合に正しく動作する必要があります。
From section 5.1 Detection of Data Corruption:
セクション5.1からのデータ腐敗の検出：
MUST support a data integrity check format for use in digest generation.
ダイジェスト生成で使用するためのデータ整合性チェック形式をサポートする必要があります。
MAY use separate digest for data and headers.
データとヘッダーに個別のダイジェストを使用する場合があります。
iSCSI header format SHOULD be extensible to include other data integrity digest calculation methods.
ISCSIヘッダー形式は拡張可能で、他のデータ整合性ダイジェスト計算方法を含める必要があります。
From section 5.2 Recovery:
セクション5.2からの回復：
MUST specify mechanisms to recover in a timely fashion from failures on the initiator, target, or connecting infrastructure.
イニシエーター、ターゲット、または接続インフラストラクチャの障害からタイムリーに回復するメカニズムを指定する必要があります。
MUST specify recovery methods for non-idempotent requests.
非公開リクエストのリカバリメソッドを指定する必要があります。
SHOULD take into account fail-over schemes for mirrored targets or highly available storage configurations.
ミラー化されたターゲットまたは非常に利用可能なストレージ構成のフェールオーバースキームを考慮する必要があります。
SHOULD provide a method for sessions to be gracefully terminated and restarted that can be initiated by either the initiator or target.
イニシエーターまたはターゲットのいずれかで開始できるセッションを優雅に終了および再起動する方法を提供する必要があります。
From section 6 Interoperability:
セクション6からの相互運用性：
iSCSI protocol document MUST be clear and unambiguous.
ISCSIプロトコルドキュメントは明確で明確でなければなりません。
From section 6.1 Internet Infrastructure:
セクション6.1からインターネットインフラストラクチャ：
MUST:
-- be compatible with both IPv4 and IPv6
-- use TCP connections conservatively, keeping in mind there may
be many other users of TCP on a given machine.
MUST NOT require changes to existing Internet protocols.
既存のインターネットプロトコルの変更を必要としないでください。
SHOULD minimize required changes to existing TCP/IP implementations.
既存のTCP/IP実装の必要な変更を最小限に抑える必要があります。
MUST be designed to allow future substitution of SCTP (for TCP) as an IP transport protocol with minimal changes to iSCSI protocol operation, protocol data unit (PDU) structures and formats.
ISCSIプロトコル操作、プロトコルデータユニット（PDU）構造および形式の最小限の変更を伴うIP輸送プロトコルとして、SCTP（TCPの場合）の将来の置換を可能にするように設計する必要があります。
From section 6.2 SCSI:
セクション6.2からSCSI：
Any feature SAM2 requires in a valid transport mapping MUST be specified by iSCSI.
SAM2が有効なトランスポートマッピングで必要とする機能は、ISCSIで指定する必要があります。
MUST specify strictly ordered delivery of SCSI commands over an iSCSI session between an initiator/target pair.
イニシエーター/ターゲットペア間のISCSIセッションでSCSIコマンドの厳密に順序付けられた配信を指定する必要があります。
The command ordering mechanism SHOULD seek to minimize the amount of communication necessary across multiple adapters doing transport off-load.
コマンド順序付けメカニズムは、輸送をオフロードする複数のアダプターで必要な通信の量を最小限に抑えることを求める必要があります。
MUST specify for each feature whether it is OPTIONAL, RECOMMENDED or REQUIRED to implement and/or use.
各機能に、オプション、推奨、または使用が必要か、および/または使用する必要があるかどうかを指定する必要があります。
MUST NOT require changes to the SCSI-3 command sets and SCSI client code except except where SCSI specifications point to "transport dependent" fields and behavior.
SCSI仕様が「従属」フィールドと動作を「輸送」と指している場合を除き、SCSI-3コマンドセットとSCSIクライアントコードの変更を必要としないでください。
SHOULD track changes to SCSI and the SCSI Architecture Model.
SCSIおよびSCSIアーキテクチャモデルの変更を追跡する必要があります。
MUST be capable of supporting all SCSI-3 command sets and device types.
すべてのSCSI-3コマンドセットとデバイスタイプをサポートできる必要があります。
SHOULD support ACA implementation.
ACA実装をサポートする必要があります。
MUST allow for the construction of gateways to other SCSI transports
他のSCSI輸送へのゲートウェイの建設を許可する必要があります
MUST reliably transport SCSI commands from the initiator to the target.
SCSIコマンドをイニシエーターからターゲットに確実に輸送する必要があります。
MUST correctly deal with iSCSI packet drop, duplication, corruption, stale packets, and re-ordering.
ISCSIパケットのドロップ、複製、腐敗、古いパケット、および再注文を正しく扱う必要があります。
From section 7.1 Extensible Security:
セクション7.1から拡張可能なセキュリティ：
SHOULD require minimal configuration and overhead in the insecure operation.
不安定な動作では、最小限の構成とオーバーヘッドが必要です。
MUST provide for strong authentication when increased security is required.
セキュリティの増加が必要な場合は、強力な認証を提供する必要があります。
SHOULD allow integration of new security mechanisms without breaking backwards compatible operation.
逆方向の互換操作を破ることなく、新しいセキュリティメカニズムを統合できるようにする必要があります。
From section 7.2 Authentication:
セクション7.2からの認証：
MAY support various levels of authentication security.
さまざまなレベルの認証セキュリティをサポートする場合があります。
MUST support private authenticated login.
プライベート認証ログインをサポートする必要があります。
iSCSI authenticated login MUST be resilient against attacks.
ISCSI認証ログインは、攻撃に対して回復力がある必要があります。
MUST support data origin authentication of its communications; data origin authentication MAY be optional to use.
データの起源認証をサポートする必要があります。データ起源の認証は、使用するのがオプションです。
From section 7.3 Data Integrity:
セクション7.3からのデータの整合性から：
SHOULD NOT preclude use of additional data integrity protection protocols (IPSec, TLS).
追加のデータ整合性保護プロトコル（IPSEC、TLS）の使用を妨げるべきではありません。
From section 7.4 Data Confidentiality:
セクション7.4からのデータの機密性：
MUST provide for the use of a data encryption protocol such as TLS or IPsec ESP to provide data confidentiality between iSCSI endpoints
ISCSIエンドポイント間でデータの機密性を提供するには、TLSやIPSEC ESPなどのデータ暗号化プロトコルを使用する必要があります
From section 8 Management:
セクション8の管理から：
SHOULD be manageable using standard IP-based management protocols.
標準のIPベースの管理プロトコルを使用して管理可能である必要があります。
iSCSI protocol document MUST NOT define the management architecture for iSCSI, or make explicit references to management objects such as MIB variables.
ISCSIプロトコルドキュメントは、ISCSIの管理アーキテクチャを定義したり、MIB変数などの管理オブジェクトを明示的に参照したりしてはなりません。
From section 8.1 Naming:
セクション8.1から命名：
MUST support the naming architecture of SAM-2. The means by which an iSCSI resource is located MUST use or extend existing Internet standard resource location methods.
SAM-2の命名アーキテクチャをサポートする必要があります。ISCSIリソースが配置されている手段は、既存のインターネット標準リソースの位置方法を使用または拡張する必要があります。
MUST provide a means of identifying iSCSI targets by a unique identifier that is independent of the path on which it is found.
ISCSIターゲットを識別する手段を提供する必要があります。これは、発見されたパスに依存しない一意の識別子によってISCSIターゲットを識別する必要があります。
The format for the iSCSI names MUST use existing naming authorities.
ISCSI名の形式は、既存の命名当局を使用する必要があります。
An iSCSI name SHOULD be a human readable string in an international character set encoding.
ISCSI名は、国際的なキャラクターセットエンコーディングの人間の読み取り可能な文字列である必要があります。
Standard Internet lookup services SHOULD be used to resolve iSCSI names.
標準のインターネット検索サービスを使用して、ISCSI名を解決する必要があります。
SHOULD deal with the complications of the new SCSI security architecture.
新しいSCSIセキュリティアーキテクチャの合併症に対処する必要があります。
iSCSI naming architecture MUST address support of SCSI 3rd party operations such as EXTENDED COPY.
ISCSIネーミングアーキテクチャは、拡張コピーなどのSCSIサードパーティ運用のサポートに対処する必要があります。
From section 8.2 Discovery:
セクション8.2の発見から：
MUST have no impact on the use of current IP network discovery techniques.
現在のIPネットワーク発見技術の使用に影響を与える必要はありません。
MUST provide some means of determining whether an iSCSI service is available through an IP address.
ISCSIサービスがIPアドレスを介して利用可能かどうかを判断するための何らかの手段を提供する必要があります。
SCSI protocol-dependent techniques SHOULD be used for further discovery beyond the iSCSI layer.
SCSIプロトコル依存技術は、ISCSI層を超えてさらなる発見に使用する必要があります。
MUST provide a method of discovering, given an IP end point on its well-known port, the list of SCSI targets available to the requestor. The use of this discovery service MUST be optional.
よく知られているポートのIPエンドポイントを考慮して、リクエストターが利用できるSCSIターゲットのリストを考慮して、発見する方法を提供する必要があります。このディスカバリーサービスの使用はオプションでなければなりません。
From section 9 Internet Accessability.
セクション9からインターネットアクセシビリティから。
SHOULD be scrutinized for denial of service issues and they should be addressed.
サービスの拒否のために精査する必要があり、それらに対処する必要があります。
From section 9.2 Firewalls and Proxy Servers
セクション9.2のファイアウォールとプロキシサーバーから
SHOULD allow deployment where functional and optimizing middle-boxes such as firewalls, proxy servers and NATs are present.
ファイアウォール、プロキシサーバー、NATなどの機能的および最適化中間ボックスが存在する場合、展開を許可する必要があります。
use of IP addresses and TCP ports SHOULD be firewall friendly.
IPアドレスとTCPポートの使用は、ファイアウォールに優しいはずです。
From section 9.3 Congestion Control and Transport Selection
セクション9.3からの混雑制御と輸送の選択から
MUST be a good network citizen with TCP-compatible congestion control (as defined in [RFC2914]).
TCP互換性のある混雑制御を備えた優れたネットワーク市民でなければなりません（[RFC2914]で定義されています）。
iSCSI implementations MUST NOT use multiple connections as a means to avoid transport-layer congestion control.
ISCSIの実装は、輸送層の混雑制御を避けるための手段として複数の接続を使用してはなりません。
Traditionally, storage controllers (e.g., disk array controllers, tape library controllers) have supported the SCSI-3 protocol and have been attached to computers by SCSI parallel bus or Fibre Channel.
従来、ストレージコントローラー（例：ディスクアレイコントローラー、テープライブラリコントローラー）は、SCSI-3プロトコルをサポートしており、SCSIパラレルバスまたはファイバーチャネルによってコンピューターに接続されてきました。
The IP infrastructure offers compelling advantages for volume/ block-oriented storage attachment. It offers the opportunity to take advantage of the performance/cost benefits provided by competition in the Internet marketplace. This could reduce the cost of storage network infrastructure by providing economies arising from the need to install and operate only a single type of network.
IPインフラストラクチャは、ボリューム/ブロック指向のストレージアタッチメントに魅力的な利点を提供します。インターネット市場での競争によって提供されるパフォーマンス/コストのメリットを活用する機会を提供します。これにより、単一の種類のネットワークのみをインストールして運用する必要性から生じる経済を提供することにより、ストレージネットワークインフラストラクチャのコストを削減できます。
In addition, the IP protocol suite offers the opportunity for a rich array of management, security and QoS solutions. Organizations may initially choose to operate storage networks based on iSCSI that are independent of (isolated from) their current data networks except for secure routing of storage management traffic. These organizations anticipated benefits from the high performance/cost of IP equipment and the opportunity for a unified management architecture. As security and QoS evolve, it becomes reasonable to build combined networks with shared infrastructure; nevertheless, it is likely that sophisticated users will choose to keep their storage sub-networks isolated to afford the best control of security and QoS to ensure a high-performance environment tuned to storage traffic.
さらに、IPプロトコルスイートは、豊富な管理、セキュリティ、QoSソリューションの機会を提供します。組織は、最初に、ストレージ管理トラフィックの安全なルーティングを除き、現在のデータネットワークから独立した（分離）ISCSIに基づいてストレージネットワークを運用することを選択できます。これらの組織は、IP機器の高性能/コストと統一された管理アーキテクチャの機会からの利益を期待していました。セキュリティとQoSが進化するにつれて、共有インフラストラクチャと組み合わせたネットワークを構築することが合理的になります。それにもかかわらず、洗練されたユーザーは、ストレージサブネットワークを隔離して、セキュリティとQoSの最良の制御を提供して、ストレージトラフィックに合わせて調整された高性能環境を確保することを選択する可能性があります。
Mapping SCSI over IP also provides:
IP上のSCSIのマッピングも提供します。
-- Extended distance ranges
-- Connectivity to "carrier class" services that support IP
The following applications for iSCSI are contemplated:
ISCSIの以下のアプリケーションが検討されています。
-- Local storage access, consolidation, clustering and pooling (as
in the data center)
-- Network client access to remote storage (eg. a "storage service
provider")
-- Local and remote synchronous and asynchronous mirroring between
storage controllers
-- Local and remote backup and recovery
iSCSI will support the following topologies:
ISCSIは次のトポロジをサポートします。
-- Point-to-point direct connections
-- Dedicated storage LAN, consisting of one or more LAN segments
-- Shared LAN, carrying a mix of traditional LAN traffic plus
storage traffic
-- LAN-to-WAN extension using IP routers or carrier-provided "IP
Datatone"
-- Private networks and the public Internet
IP LAN-WAN routers may be used to extend the IP storage network to the wide area, permitting remote disk access (as for a storage utility), synchronous and asynchronous remote mirroring, and remote backup and restore (as for tape vaulting). In the WAN, using TCP end-to-end avoids the need for specialized equipment for protocol conversion, ensures data reliability, copes with network congestion, and provides retransmission strategies adapted to WAN delays.
IP LAN-WANルーターを使用して、IPストレージネットワークを広い領域に拡張し、リモートディスクアクセス（ストレージユーティリティなど）、同期および非同期リモートミラーリング、およびリモートバックアップと復元（テープボールティングの場合）を許可します。WANでは、TCPエンドツーエンドを使用すると、プロトコル変換のための特殊な機器の必要性が回避され、データの信頼性が確保され、ネットワークの輻輳が対処され、WANの遅延に適応された再送信戦略が提供されます。
The iSCSI technology deployment will involve the following elements:
ISCSIテクノロジーの展開には、次の要素が含まれます。
(1) Conclusion of a complete protocol standard and supporting implementations; (2) Development of Ethernet storage NICs and related driver and protocol software; [NOTE: high-speed applications of iSCSI are expected to require significant portions of the iSCSI/TCP/IP implementation in hardware to achieve the necessary throughput.] (3) Development of compatible storage controllers; and (4) The likely development of translating gateways to provide connectivity between the Ethernet storage network and the Fibre Channel and/or parallel-bus SCSI domains. (5) Development of specifications for iSCSI device management such as MIBs, LDAP or XML schemas, etc. (6) Development of management and directory service applications to support a robust SAN infrastructure.
(1) 完全なプロトコル標準の結論と実装のサポート。（2）イーサネットストレージNICおよび関連するドライバーおよびプロトコルソフトウェアの開発。[注：ISCSIの高速アプリケーションは、必要なスループットを実現するためにハードウェアでISCSI/TCP/IP実装の重要な部分を必要とすると予想されます。]（3）互換性のあるストレージコントローラーの開発。（4）イーサネットストレージネットワークとファイバーチャネルおよび/または並列バスSCSIドメイン間の接続を提供するための翻訳ゲートウェイの開発の可能性。（5）MIBS、LDAP、XMLスキーマなどのISCSIデバイス管理の仕様の開発（6）堅牢なSANインフラストラクチャをサポートする管理およびディレクトリサービスアプリケーションの開発。
Products could initially be offered for Gigabit Ethernet attachment, with rapid migration to 10 GbE. For performance competitive with alternative SCSI transports, it will be necessary to implement the performance path of the full protocol stack in hardware. These new storage NICs might perform full-stack processing of a complete SCSI task, analogous to today's SCSI and Fibre Channel HBAs, and might also support all host protocols that use TCP (NFS, CIFS, HTTP, etc).
製品は最初にギガビットイーサネットアタッチメント用に提供される可能性があり、10 GBEに急速に移動します。代替SCSIトランスポートとの競争力のあるパフォーマンスのために、ハードウェアの完全なプロトコルスタックのパフォーマンスパスを実装する必要があります。これらの新しいストレージNICは、今日のSCSIおよびファイバーチャネルHBAに類似した完全なSCSIタスクのフルスタック処理を実行し、TCP（NFS、CIFS、HTTPなど）を使用するすべてのホストプロトコルをサポートする場合があります。
The charter of the IETF IP Storage Working Group (IPSWG) describes the broad goal of mapping SCSI to IP using a transport that has proven congestion avoidance behavior and broad implementation on a variety of platforms. Within that broad charter, several transport alternatives may be considered. Initial IPS work focuses on TCP, and this requirements document is restricted to that domain of interest.
IETF IPストレージワーキンググループ（IPSWG）の憲章は、さまざまなプラットフォームでの混雑回避行動と幅広い実装を証明したトランスポートを使用して、SCSIをIPにマッピングするという幅広い目標について説明しています。その幅広い憲章内では、いくつかの輸送の代替案を考慮することができます。最初のIPS作業はTCPに焦点を当てており、この要件文書はその関心のあるドメインに制限されています。
In general, iSCSI MUST allow implementations to equal or improve on the current state of the art for SCSI interconnects. This goal breaks down into several types of requirement:
一般に、ISCSIは、実装がSCSI相互接続の現在の最新の最新技術に等しいか改善することを許可する必要があります。この目標は、いくつかのタイプの要件に分類されます。
Cost competitive with alternative storage network technologies:
代替ストレージネットワークテクノロジーとの競争力のあるコスト：
In order to be adopted by vendors and the user community, the iSCSI protocol MUST enable cost competitive implementations when compared to other SCSI transports (Fibre Channel).
ベンダーとユーザーコミュニティに採用されるためには、ISCSIプロトコルは、他のSCSIトランスポート（ファイバーチャネル）と比較した場合、コストの競争力のある実装を有効にする必要があります。
Low delay communication:
低遅延の通信：
Conventional storage access is of a stop-and-wait remote procedure call type. Applications typically employ very little pipelining of their storage accesses, and so storage access delay directly impacts performance. The delay imposed by current storage interconnects, including protocol processing, is generally in the range of 100 microseconds. The use of caching in storage controllers means that many storage accesses complete almost instantly, and so the delay of the interconnect can have a high relative impact on overall performance. When stop-and-wait IO is used, the delay of the interconnect will affect performance. The iSCSI protocol SHOULD minimize control overhead, which adds to delay.
従来のストレージアクセスは、ストップアンドウェイトリモートプロシージャコールタイプです。アプリケーションは通常、ストレージアクセスのパイプライニングをほとんど使用していないため、ストレージアクセス遅延はパフォーマンスに直接影響します。プロトコル処理を含む電流ストレージの相互接続によって課される遅延は、一般に100マイクロ秒の範囲です。ストレージコントローラーでのキャッシングの使用は、多くのストレージアクセスがほぼ瞬時に完了することを意味するため、インターコネクトの遅延は全体的なパフォーマンスに大きな影響を与える可能性があります。停止して待っているIOを使用すると、相互接続の遅延がパフォーマンスに影響します。ISCSIプロトコルは、制御オーバーヘッドを最小限に抑える必要があり、これにより遅延が増加します。
Low host CPU utilization, equal to or better than current technology:
現在のテクノロジーと同等以上のホストCPU使用率：
For competitive performance, the iSCSI protocol MUST allow three key implementation goals to be realized:
競争力のあるパフォーマンスのために、ISCSIプロトコルは、3つの重要な実装目標を実現する必要があります。
(1) iSCSI MUST make it possible to build I/O adapters that handle an entire SCSI task, as alternative SCSI transport implementations do. (2) The protocol SHOULD permit direct data placement ("zero-copy" memory architectures, where the I/O adapter reads or writes host memory exactly once per disk transaction. (3) The protocol SHOULD NOT impose complex operations on the host software, which would increase host instruction path length relative to alternatives.
(1) ISCSIは、SCSIタスク全体を処理するI/Oアダプターを構築することを可能にする必要があります。（2）プロトコルは、ディスクトランザクションごとにホストメモリを1回正確に読み取るか、書き込みます。（3）プロトコルはホストソフトウェアに複雑な操作を課すべきではない、I/Oアダプターがホストメモリを正確に書き留める、直接データの配置（「ゼロコピー」メモリアーキテクチャを許可する必要があります。、代替案と比較して、ホスト命令パスの長さを増加させます。
Direct data placement (zero-copy iSCSI):
直接データ配置（ゼロコピーISCSI）：
Direct data placement refers to iSCSI data being placed directly "off the wire" into the allocated location in memory with no intermediate copies. Direct data placement significantly reduces the memory bus and I/O bus loading in the endpoint systems, allowing improved performance. It reduces the memory required for NICs, possibly reducing the cost of these solutions.
直接データの配置とは、ISCSIデータが中間コピーなしでメモリ内の割り当てられた場所に直接「ワイヤーから」配置されることを指します。直接データの配置により、エンドポイントシステムでのメモリバスとI/Oバスのロードが大幅に削減され、パフォーマンスが向上します。NICに必要なメモリを削減し、おそらくこれらのソリューションのコストを削減します。
This is an important implementation goal. In an iSCSI system, each of the end nodes (for example host computer and storage controller) should have ample memory, but the intervening nodes (NIC, switches) typically will not.
これは重要な実装目標です。ISCSIシステムでは、各エンドノード（ホストコンピューターとストレージコントローラーなど）には十分なメモリが必要ですが、介在するノード（NIC、スイッチ）は通常そうではありません。
High bandwidth, bandwidth aggregation:
高い帯域幅、帯域幅集約：
The bandwidth (transfer rate, MB/sec) supported by storage controllers is rapidly increasing, due to several factors:
ストレージコントローラーがサポートする帯域幅（転送速度、MB/SEC）は、いくつかの要因により急速に増加しています。
1. Increase in disk spindle and controller performance; 2. Use of ever-larger caches, and improved caching algorithms; 3. Increased scale of storage controllers (number of supported spindles, speed of interconnects).
1. ディスクスピンドルとコントローラーのパフォーマンスの向上。2.絶え間ないキャッシュの使用、およびキャッシュアルゴリズムの改善。3.ストレージコントローラーのスケールの増加（サポートされているスピンドルの数、相互接続の速度）。
The iSCSI protocol MUST provide for full utilization of available link bandwidth. The protocol MUST also allow an implementation to exploit parallelism (multiple connections) at the device interfaces and within the interconnect fabric.
ISCSIプロトコルは、利用可能なリンク帯域幅を完全に利用するために提供する必要があります。また、プロトコルは、デバイスインターフェイスおよびインターコネクトファブリック内で並列性（複数の接続）を活用できるようにする必要があります。
The next two sections further discuss the need for direct data placement and high bandwidth.
次の2つのセクションでは、直接データの配置と高い帯域幅の必要性についてさらに説明します。
Framing refers to the addition of information in a header, or the data stream to allow implementations to locate the boundaries of an iSCSI protocol data unit (PDU) within the TCP byte stream. There are two technical requirements driving framing: interfacing needs, and accelerated processing needs.
フレーミングとは、ヘッダーに情報の追加、またはデータストリームの追加を指し、実装がTCPバイトストリーム内のISCSIプロトコルデータユニット（PDU）の境界を特定できるようにします。フレーミングを駆動する2つの技術的要件があります。インターフェースのニーズと加速処理ニーズです。
A framing solution that addresses the "interfacing needs" of the iSCSI protocol will facilitate the implementation of a message-based upper layer protocol (iSCSI) on top of an underlying byte streaming protocol (TCP). Since TCP is a reliable transport, this can be accomplished by including a length field in the iSCSI header. Finding the protocol frame assumes that the receiver will parse from the beginning of the TCP data stream, and never make a mistake (lose alignment on packet headers).
ISCSIプロトコルの「インターフェースニーズ」に対処するフレーミングソリューションは、基礎となるバイトストリーミングプロトコル（TCP）の上にメッセージベースの上層プロトコル（ISCSI）の実装を促進します。TCPは信頼できる輸送であるため、これはISCSIヘッダーに長さフィールドを含めることで実現できます。プロトコルフレームを見つけると、受信者がTCPデータストリームの先頭から解析し、間違いを犯さないことを想定しています（パケットヘッダーのアライメントを失います）。
The other technical requirement for framing, "accelerated processing", stems from the need to handle increasingly higher data rates in the physical media interface. Two needs arise from higher data rates:
フレーミングの他の技術的要件である「加速処理」は、物理メディアインターフェイスのますます高いデータレートを処理する必要性に由来しています。より高いデータレートから2つのニーズが生じます。
(1) LAN environment - NIC vendors seek ways to provide "zero-copy" methods of moving data directly from the wire into application buffers.
(1) LAN環境-NICベンダーは、データをワイヤーからアプリケーションバッファーに直接移動する「ゼロコピー」方法を提供する方法を求めています。
(2) WAN environment- the emergence of high bandwidth, high latency, low bit error rate physical media places huge buffer requirements on the physical interface solutions.
(2) WAN環境 - 高帯域幅、高レイテンシ、低ビットエラーレートの出現物理メディアは、物理インターフェイスソリューションに大きなバッファー要件を置きます。
First, vendors are producing network processing hardware that offloads network protocols to hardware solutions to achieve higher data rates. The concept of "zero-copy" seeks to store blocks of data in appropriate memory locations (aligned) directly off the wire, even when data is reordered due to packet loss. This is necessary to drive actual data rates of 10 Gigabit/sec and beyond.
まず、ベンダーは、ネットワークプロトコルをハードウェアソリューションにオフロードして、より高いデータレートを実現するネットワーク処理ハードウェアを作成しています。「Zero-Copy」の概念は、パケットの損失のためにデータが再注文された場合でも、適切なメモリの場所に直接ワイヤーから直接データブロックを保存しようとしています。これは、10ギガビット/秒以上の実際のデータレートを駆動するために必要です。
Secondly, in order for iSCSI to be successful in the WAN arena it must be possible to operate efficiently in high bandwidth, high delay networks. The emergence of multi-gigabit IP networks with latencies in the tens to hundreds of milliseconds presents a challenge. To fill such large pipes, it is necessary to have tens of megabytes of outstanding requests from the application. In addition, some protocols potentially require tens of megabytes at the transport layer to deal with buffering for reassembly of data when packets are received out-of-order.
第二に、ISCSIがWANアリーナで成功するためには、高い帯域幅の高い遅延ネットワークで効率的に動作することが可能である必要があります。数十から数百ミリ秒のレイテンシを備えたマルチギガビットIPネットワークの出現は、課題を提示します。このような大きなパイプを埋めるには、アプリケーションからの顕著なリクエストの数十メガバイトを持つ必要があります。さらに、一部のプロトコルでは、パケットが注文不能に受信されたときにデータの再組み立てのためにバッファリングを処理するために、輸送層で数十メガバイトを必要とする可能性があります。
In both cases, the issue is the desire to minimize the amount of memory and memory bandwidth required for iSCSI hardware solutions.
どちらの場合も、問題は、ISCSIハードウェアソリューションに必要なメモリとメモリの帯域幅の量を最小限に抑えたいという要望です。
Consider that a network pipe at 10 Gbps x 200 msec holds 250 MB. [Assume land-based communication with a spot half way around the world at the equator. Ignore additional distance due to cable routing. Ignore repeater and switching delays; consider only a speed-of-light delay of 5 microsec/km. The circumference of the globe at the equator is approx. 40000 km (round-trip delay must be considered to keep the pipe full). 10 Gb/sec x 40000 km x 5 microsec/km x B / 8b = 250 MB]. In a conventional TCP implementation, loss of a TCP segment means that stream processing MUST stop until that segment is recovered, which takes at least a time of <network round trip> to accomplish. Following the example above, an implementation would be obliged to catch 250 MB of data into an anonymous buffer before resuming stream processing; later, this data would need to be moved to its proper location. Some proponents of iSCSI seek some means of putting data directly where it belongs, and avoiding extra data movement in the case of segment drop. This is a key concept in understanding the debate behind framing methodologies.
10 gbps x 200ミリ秒のネットワークパイプが250 MBを保持していることを考慮してください。[赤道の世界中の途中で陸上のコミュニケーションを想定してください。ケーブルルーティングのために追加の距離を無視します。リピーターとスイッチングの遅延を無視します。5マイクロセック/kmの速度遅延のみを検討してください。赤道での地球の円周は約です。40000 km（パイプをいっぱいにするために、往復遅延を考慮する必要があります）。10 gb/sec x 40000 km x 5 microsec/km x b/8b = 250 mb]。従来のTCP実装では、TCPセグメントの損失とは、そのセグメントが回復するまでストリーム処理を停止する必要があることを意味します。これには、少なくとも<ネットワークラウンドトリップ>の時間がかかります。上記の例に従って、ストリーム処理を再開する前に、実装は250 MBのデータを匿名バッファーにキャッチする義務があります。後で、このデータは適切な場所に移動する必要があります。ISCSIの支持者の中には、データが属する場所に直接データを置き、セグメントの低下の場合に追加のデータの動きを避けるための何らかの手段を求めています。これは、フレーミング方法論の背後にある議論を理解する上で重要な概念です。
The framing of the iSCSI protocol impacts both the "interfacing needs" and the "accelerated processing needs", however, while including a length in a header may suffice for the "interfacing needs", it will not serve the direct data placement needs. The framing mechanism developed should allow resynchronization of packet boundaries even in the case where a packet is temporarily missing in the incoming data stream.
ISCSIプロトコルのフレーミングは、「インターフェースのニーズ」と「加速処理のニーズ」の両方に影響しますが、ヘッダーに長さを含めると「インターフェースのニーズ」に十分である可能性がありますが、直接的なデータ配置のニーズには役立たない場合があります。開発されたフレーミングメカニズムは、着信データストリームで一時的にパケットが欠落している場合でも、パケットの境界を再同期させることを可能にするはずです。
At today's block storage transport throughput, any single link can be saturated by the volume of storage traffic. Scientific data applications and data replication are examples of storage applications that push the limits of throughput.
今日のブロックストレージトランスポートスループットでは、ストレージトラフィックの量によって単一のリンクを飽和させることができます。科学データアプリケーションとデータの複製は、スループットの制限を押し上げるストレージアプリケーションの例です。
Some applications, such as log updates, streaming tape, and replication, require ordering of updates and thus ordering of SCSI commands. An initiator may maintain ordering by waiting for each update to complete before issuing the next (a.k.a. synchronous updates). However, the throughput of synchronous updates decreases inversely with increases in network distances.
ログの更新、ストリーミングテープ、レプリケーションなどの一部のアプリケーションでは、更新の注文、したがってSCSIコマンドの注文が必要です。イニシエーターは、次のアップデートを発行する前に各更新が完了するのを待つことで注文を維持する場合があります（別名同期アップデート）。ただし、同期更新のスループットは、ネットワーク距離の増加とともに逆に減少します。
For greater throughput, the SCSI task queuing mechanism allows an initiator to have multiple commands outstanding at the target simultaneously and to express ordering constraints on the execution of those commands. The task queuing mechanism is only effective if the commands arrive at the target in the order they were presented to the initiator (FIFO order). The iSCSI standard must provide an ordered transport of SCSI commands, even when commands are sent along different network paths (see Section 5.2 SCSI). This is referred to as "command ordering".
スループットを大きくすると、SCSIタスクキューイングメカニズムにより、イニシエーターは複数のコマンドを同時にターゲットに際立たせ、それらのコマンドの実行に関する順序制約を表現できます。タスクキューイングメカニズムは、コマンドがターゲットに到達した場合にのみ有効です。ISCSI標準は、異なるネットワークパスに沿ってコマンドが送信された場合でも、SCSIコマンドの順序付けられた輸送を提供する必要があります（セクション5.2 SCSIを参照）。これは「コマンド注文」と呼ばれます。
The iSCSI protocol MUST operate over a single TCP connection to accommodate lower cost implementations. To enable higher performance storage devices, the protocol should specify a means to allow operation over multiple connections while maintaining the behavior of a single SCSI port. This would allow the initiator and target to use multiple network interfaces and multiple paths through the network for increased throughput. There are a few potential ways to satisfy the multiple path and ordering requirements.
ISCSIプロトコルは、より低コストの実装に対応するために、単一のTCP接続で動作する必要があります。より高いパフォーマンスストレージデバイスを有効にするために、プロトコルは、単一のSCSIポートの動作を維持しながら、複数の接続を介した動作を許可する手段を指定する必要があります。これにより、イニシエーターとターゲットが複数のネットワークインターフェイスとネットワークを介して複数のパスを使用して、スループットを増やすことができます。複数のパスと順序付け要件を満たすためのいくつかの潜在的な方法があります。
A popular way to satisfy the multiple-path requirement is to have a driver above the SCSI layer instantiate multiple copies of the SCSI transport, each communicating to the target along a different path. "Wedge" drivers use this technique today to attain high performance. Unfortunately, wedge drivers must wait for acknowledgement of completion of each request (stop-and-wait) to ensure ordered updates.
複数のパス要件を満たすための一般的な方法は、SCSI層の上のドライバーがSCSIトランスポートの複数のコピーをインスタンス化することであり、それぞれが異なるパスに沿ってターゲットに通信します。「ウェッジ」ドライバーは、今日この手法を使用して高性能を達成しています。残念ながら、ウェッジドライバーは、注文された更新を確保するために、各リクエストの完了（停留所）の完了（停留所）の承認を待つ必要があります。
Another approach might be for iSCSI protocol to use multiple instances of its underlying transport (e.g. TCP). The iSCSI layer would make these independent transport instances appear as one SCSI transport instance and maintain the ability to do ordered SCSI command queuing. The document will refer to this technique as "connection binding" for convenience.
別のアプローチは、ISCSIプロトコルが基礎となる輸送の複数のインスタンス（TCPなど）を使用することです。ISCSI層は、これらの独立した輸送インスタンスを1つのSCSIトランスポートインスタンスとして表示し、順序付けられたSCSIコマンドキューイングを行う機能を維持します。このドキュメントは、この手法を便利な「接続バインディング」と呼びます。
The iSCSI protocol SHOULD support connection binding, and it MUST be optional to implement.
ISCSIプロトコルは接続バインディングをサポートする必要があり、実装するにはオプションでなければなりません。
In the presence of connection binding, there are two ways to assign features to connections. In the symmetric approach, all the connections are identical from a feature standpoint. In the asymmetric model, connections have different features. For example, some connections may be used primarily for data transfers whereas others are used primarily for SCSI commands.
接続バインディングが存在する場合、接続に機能を割り当てる方法は2つあります。対称的なアプローチでは、すべての接続は機能の観点から同じです。非対称モデルでは、接続には異なる機能があります。たとえば、一部の接続は主にデータ転送に使用される場合がありますが、他の接続は主にSCSIコマンドに使用されます。
Since the iSCSI protocol must support the case where there was only one transport connection, the protocol must have command, data, and status travel over the same connection.
ISCSIプロトコルは、1つの輸送接続が1つしかなかった場合をサポートする必要があるため、プロトコルには同じ接続でコマンド、データ、およびステータス移動が必要です。
In the case of multiple connections, the iSCSI protocol must keep the command and its associated data and status on the same connection (connection allegiance). Sending data and status on the same connection is desirable because this guarantees that status is received after the data (TCP provides ordered delivery). In the case where each connection is managed by a separate processor, allegiance decreases the need for inter-processor communication. This symmetric approach is a natural extension of the single connection approach.
複数の接続の場合、ISCSIプロトコルは、コマンドとその関連データとステータスを同じ接続（接続忠誠）に維持する必要があります。同じ接続でデータとステータスを送信することが望ましいです。これにより、データがデータの後に受信されることが保証されます（TCPは順序付けられた配信を提供します）。各接続が個別のプロセッサによって管理されている場合、Allegianceはプロセッサ間通信の必要性を減少させます。この対称アプローチは、単一の接続アプローチの自然な拡張です。
An alternate approach that was extensively discussed involved sending all commands on a single connection and the associated data and status on a different connection (asymmetric approach). In this scheme, the transport ensures the commands arrive in order. The protocol on the data and status connections is simpler, perhaps lending itself to a simpler realization in hardware. One disadvantage of this approach is that the recovery procedure is different if a command connection fails vs. a data connection. Some argued that this approach would require greater inter-processor communication when connections are spread across processors.
広く議論された別のアプローチには、単一の接続ですべてのコマンドを送信し、関連するデータとステータスを異なる接続（非対称アプローチ）に送信することが含まれます。このスキームでは、輸送により、コマンドが順調に到着するようにします。データとステータス接続のプロトコルはよりシンプルで、おそらくハードウェアのより単純な実現に貸し出されます。このアプローチの不利な点の1つは、コマンド接続がデータ接続に失敗した場合、回復手順が異なることです。一部の人々は、このアプローチには、接続がプロセッサ全体に広がると、より大きなプロセッサ間通信が必要になると主張しました。
The reader may reference the mail archives of the IPS mailing list between June and September of 2000 for extensive discussions on symmetric vs asymmetric connection models.
読者は、対称接続モデルに関する広範な議論のために、2000年6月から9月の間にIPSメーリングリストのメールアーカイブを参照することができます。
Experience has shown that adoption of a protocol by the Internet community is inversely proportional to its complexity. In addition, the simpler the protocol, the easier it is to diagnose problems. The designers of iSCSI SHOULD strive to fulfill the requirements of the creating a SCSI transport over IP, while keeping the protocol as simple as possible.
経験によると、インターネットコミュニティによるプロトコルの採用は、その複雑さに反比例していることが示されています。さらに、プロトコルが簡単になるほど、問題の診断が容易になります。ISCSIの設計者は、プロトコルを可能な限りシンプルに保ちながら、IPを介してSCSIトランスポートを作成する要件を満たすよう努力する必要があります。
In the interest of simplicity, iSCSI SHOULD minimize optional features. When features are deemed necessary, the protocol MUST specify feature negotiation at session establishment (login). The iSCSI transport MUST operate correctly when no optional features are negotiated as well as when individual option negotiations are unsuccessful.
簡単にするために、ISCSIはオプションの機能を最小限に抑える必要があります。機能が必要とみなされる場合、プロトコルはセッション確立（ログイン）で機能交渉を指定する必要があります。ISCSIトランスポートは、オプションの機能が交渉されていない場合、および個々のオプションの交渉が失敗した場合に正しく動作する必要があります。
There have been several research papers that suggest that the TCP checksum calculation allows a certain number of bit errors to pass undetected [10] [11].
TCPチェックサムの計算により、一定数のビットエラーが検出されない[10] [11]を渡すことができることを示唆するいくつかの研究論文があります。
In order to protect against data corruption, the iSCSI protocol MUST support a data integrity check format for use in digest generation.
データの破損から保護するために、ISCSIプロトコルは、ダイジェスト生成で使用するためにデータ整合性チェック形式をサポートする必要があります。
The iSCSI protocol MAY use separate digests for data and headers. In an iSCSI proxy or gateway situation, the iSCSI headers are removed and re-built, and the TCP stream is terminated on either side. This means that even the TCP checksum is removed and recomputed within the gateway. To ensure the protection of commands, data, and status the iSCSI protocol MUST include a CRC or other digest mechanism that is computed on the SCSI data block itself, as well as on each command and status message. Since gateways may strip iSCSI headers and rebuild them, a separate header CRC is required. Two header digests, one for invariant portions of the header (addresses) and one for the variant portion would provide protection against changes to portions of the header that should never be changed by middle boxes (eg, addresses).
ISCSIプロトコルは、データとヘッダーに個別のダイジェストを使用する場合があります。ISCSIプロキシまたはゲートウェイの状況では、ISCSIヘッダーが削除および再構築され、TCPストリームは両側で終了します。これは、TCPチェックサムでさえ削除され、ゲートウェイ内で再計算されることを意味します。コマンド、データ、およびステータスの保護を確保するには、ISCSIプロトコルには、SCSIデータブロック自体と各コマンドおよびステータスメッセージに計算されるCRCまたはその他のダイジェストメカニズムを含める必要があります。ゲートウェイはISCSIヘッダーを剥がして再構築する可能性があるため、別のヘッダーCRCが必要です。ヘッダーの不変部分（アドレス）用（アドレス）とバリアント部分用の2つのヘッダーダイジェストは、中央のボックス（アドレス）で決して変更されないヘッダーの部分の変更に対する保護を提供します。
The iSCSI header format SHOULD be extensible to include other digest calculation methods.
ISCSIヘッダー形式は、他のダイジェスト計算方法を含めるために拡張可能である必要があります。
The SCSI protocol was originally designed for a parallel bus transport that was highly reliable. SCSI applications tend to assume that transport errors never happen, and when they do, SCSI application recovery tends to be expensive in terms of time and computational resources.
SCSIプロトコルは、もともと非常に信頼性の高い並列バス輸送用に設計されていました。SCSIアプリケーションは、輸送エラーが決して発生しないと仮定する傾向があり、SCSIアプリケーションの回復は時間と計算リソースの点で高価になる傾向があります。
iSCSI protocol design, while placing an emphasis on simplicity, MUST lead to timely recovery from failure of initiator, target, or connecting network infrastructure (cabling, data path equipment such as routers, etc).
ISCSIプロトコルの設計は、単純さに重点を置いている間、イニシエーター、ターゲット、またはネットワークインフラストラクチャの接続（ケーブル、ルーターなどのデータパス機器など）の故障からタイムリーな回復につながる必要があります。
iSCSI MUST specify recovery methods for non-idempotent requests, such as operations on tape drives.
ISCSIは、テープドライブの操作など、非公開のリクエストの回収方法を指定する必要があります。
The iSCSI protocol error recover mechanism SHOULD take into account fail-over schemes for mirrored targets or highly available storage configurations that provide paths to target data through multiple "storage servers". This would provide a basis for layered technologies like high availability and clustering.
ISCSIプロトコルエラー回復メカニズムは、複数の「ストレージサーバー」を介してデータをターゲットにするパスを提供するミラー化されたターゲットまたは非常に利用可能なストレージ構成のフェールオーバースキームを考慮する必要があります。これは、高可用性やクラスタリングなどの階層化されたテクノロジーの基礎を提供します。
The iSCSI protocol SHOULD also provide a method for sessions to be gracefully terminated and restarted that can be initiated by either the initiator or target. This provides the ability to gracefully fail over an initiator or target, or reset a target after performing maintenance tasks such as upgrading software.
ISCSIプロトコルは、イニシエーターまたはターゲットのいずれかで開始できるセッションを優雅に終了および再起動する方法を提供する必要があります。これにより、イニシエーターまたはターゲットを優雅に失敗したり、ソフトウェアのアップグレードなどのメンテナンスタスクを実行した後にターゲットをリセットする機能が提供されます。
It must be possible for initiators and targets that implement the required portions of the iSCSI specification to interoperate. While this requirement is so obvious that it doesn't seem worth mentioning, if the protocol specification contains ambiguous wording, different implementations may not interoperate. The iSCSI protocol document MUST be clear and unambiguous.
ISCSI仕様の必要な部分を実装して相互操作するために、開始者とターゲットが可能でなければなりません。この要件は非常に明白であるため、言及する価値はないように思われますが、プロトコル仕様に曖昧な言葉遣いが含まれている場合、異なる実装は相互運用しない場合があります。ISCSIプロトコルドキュメントは明確で明確でなければなりません。
The iSCSI protocol MUST:
ISCSIプロトコルは次のことが必要です。
-- be compatible with both IPv4 and IPv6.
-- use TCP connections conservatively, keeping in mind there may
be many other users of TCP on a given machine.
The iSCSI protocol MUST NOT require changes to existing Internet protocols and SHOULD minimize required changes to existing TCP/IP implementations.
ISCSIプロトコルは、既存のインターネットプロトコルの変更を必要としない必要があり、既存のTCP/IP実装の必要な変更を最小限に抑える必要があります。
iSCSI MUST be designed to allow future substitution of SCTP (for TCP) as an IP transport protocol with minimal changes to iSCSI protocol operation, protocol data unit (PDU) structures and formats. Although not widely implemented today, SCTP has many design features that make it a desirable choice for future iSCSI enhancement.
ISCSIは、ISCSIプロトコル操作、プロトコルデータユニット（PDU）構造および形式の最小限の変更を伴うIP輸送プロトコルとして、SCTP（TCPの場合）の将来の置換を可能にするように設計する必要があります。今日は広く実装されていませんが、SCTPには多くの設計機能があり、将来のISCSI強化に望ましい選択肢となっています。
In order to be considered a SCSI transport, the iSCSI standard must comply with the requirements of the SCSI Architecture Model [SAM-2] for a SCSI transport. Any feature SAM2 requires in a valid transport mapping MUST be specified by iSCSI. The iSCSI protocol document MUST specify for each feature whether it is OPTIONAL, RECOMMENDED or REQUIRED to implement and/or use.
SCSI輸送と見なされるためには、ISCSI標準はSCSI輸送のSCSIアーキテクチャモデル[SAM-2]の要件に準拠する必要があります。SAM2が有効なトランスポートマッピングで必要とする機能は、ISCSIで指定する必要があります。ISCSIプロトコルドキュメントは、各機能にオプション、推奨、または使用が必要か、および/または使用する必要があるかどうかを指定する必要があります。
The SCSI Architectural Model [SAM-2] indicates an expectation that the SCSI transport provides ordering of commands on an initiator target-LUN granularity. There has been much discussion on the IPS reflector and in working group meetings regarding the means to ensure this ordering. The rough consensus is that iSCSI MUST specify strictly ordered delivery of SCSI commands over an iSCSI session between an initiator/target pair, even in the presence of transport errors. This command ordering mechanism SHOULD seek to minimize the amount of communication necessary across multiple adapters doing transport off-load. If an iSCSI implementation does not require ordering it can instantiate multiple sessions per initiator-target pair.
SCSIアーキテクチャモデル[SAM-2]は、SCSIトランスポートがイニシエーターのターゲット-LUN粒度に関するコマンドの順序付けを提供するという期待を示しています。IPSリフレクターと、この注文を確保する手段に関するワーキンググループ会議について多くの議論がありました。大まかなコンセンサスは、ISCSIが輸送エラーが存在する場合でも、イニシエーター/ターゲットペア間のISCSIセッションでSCSIコマンドの厳密に順序付けられた配信を指定する必要があることです。このコマンド順序付けメカニズムは、輸送をオフロードする複数のアダプターで必要な通信の量を最小限に抑えることを求める必要があります。ISCSIの実装で注文を必要としない場合、イニシエーターターゲットペアごとに複数のセッションをインスタンス化できます。
iSCSI is intended to be a new SCSI "transport" [SAM2]. As a mapping of SCSI over TCP, iSCSI requires interaction with both T10 and IETF. However, the iSCSI protocol MUST NOT require changes to the SCSI-3 command sets and SCSI client code except where SCSI specifications point to "transport dependent" fields and behavior. For example, changes to SCSI documents will be necessary to reflect lengthier iSCSI target names and potentially lengthier timeouts. Collaboration with T10 will be necessary to achieve this requirement.
ISCSIは、新しいSCSI「輸送」[SAM2]になることを目的としています。TCPを介したSCSIのマッピングとして、ISCSIにはT10とIETFの両方との相互作用が必要です。ただし、ISCSIプロトコルは、SCSI仕様が「従属」フィールドと動作を「輸送する」ことを指している場合を除き、SCSI-3コマンドセットとSCSIクライアントコードの変更を必要としない必要があります。たとえば、SCSIドキュメントの変更は、より長いISCSIターゲット名と潜在的に長いタイムアウトを反映するために必要です。この要件を達成するには、T10とのコラボレーションが必要です。
The iSCSI protocol SHOULD track changes to SCSI and the SCSI Architecture Model.
ISCSIプロトコルは、SCSIおよびSCSIアーキテクチャモデルの変更を追跡する必要があります。
The iSCSI protocol MUST be capable of supporting all SCSI-3 command sets and device types. The primary focus is on supporting 'larger' devices: host computers and storage controllers (disk arrays, tape libraries). However, other command sets (printers, scanners) must be supported. These requirements MUST NOT be construed to mean that iSCSI must be natively implementable on all of today's SCSI devices, which might have limited processing power or memory.
ISCSIプロトコルは、すべてのSCSI-3コマンドセットとデバイスタイプをサポートできる必要があります。主な焦点は、「より大きな」デバイスをサポートすることです。ホストコンピューターとストレージコントローラー（ディスクアレイ、テープライブラリ）です。ただし、他のコマンドセット（プリンター、スキャナー）をサポートする必要があります。これらの要件は、ISCSIが処理能力またはメモリが制限されている可能性がある今日のすべてのSCSIデバイスでネイティブに実装できることを意味すると解釈されてはなりません。
ACA (Auto Contingent Allegiance) is an optional SCSI mechanism that stops execution of a sequence of dependent SCSI commands when one of them fails. The situation surrounding it is complex - T10 specifies ACA in SAM2, and hence iSCSI must support it and endeavor to make sure that ACA gets implemented sufficiently (two independent interoperable implementations) to avoid dropping ACA in the transition from Proposed Standard to Draft Standard. This implies iSCSI SHOULD support ACA implementation.
ACA（Auto Contingent Allegiance）は、そのうちの1つが失敗したときに一連の従属SCSIコマンドの実行を停止するオプションのSCSIメカニズムです。それを取り巻く状況は複雑です-T10はSAM2でACAを指定するため、ISCSIはそれをサポートし、ACAが十分に実装されるように努力する必要があります（2つの独立した相互運用可能な実装）。これは、ISCSIがACAの実装をサポートする必要があることを意味します。
The iSCSI protocol MUST allow for the construction of gateways to other SCSI transports, including parallel SCSI [SPI-X] and to SCSI FCP[FCP, FCP-2]. It MUST be possible to construct "translating" gateways so that iSCSI hosts can interoperate with SCSI-X devices; so that SCSI-X devices can communicate over an iSCSI network; and so that SCSI-X hosts can use iSCSI targets (where SCSI-X refers to parallel SCSI, SCSI-FCP, or SCSI over any other transport). This requirement is implied by support for SAM-2, but is worthy of emphasis. These are true application protocol gateways, and not just bridge/routers. The different standards have only the SCSI-3 command set layer in common. These gateways are not mere packet forwarders.
ISCSIプロトコルは、並列SCSI [SPI-X]やSCSI FCP [FCP、FCP-2]など、他のSCSI輸送へのゲートウェイの構築を許可する必要があります。ISCSIホストがSCSI-Xデバイスと相互操作できるように、「翻訳」ゲートウェイを構築することが可能である必要があります。そのため、SCSI-XデバイスはISCSIネットワークを介して通信できます。SCSI-XホストはISCSIターゲットを使用できます（SCSI-Xは、他の輸送で並列SCSI、SCSI-FCP、またはSCSIを指します）。この要件はSAM-2のサポートによって暗示されていますが、強調に値します。これらは、ブリッジ/ルーターだけでなく、真のアプリケーションプロトコルゲートウェイです。異なる標準には、共通のSCSI-3コマンドセットレイヤーのみがあります。これらのゲートウェイは、単なるパケット転送者ではありません。
The iSCSI protocol MUST reliably transport SCSI commands from the initiator to the target. According to [SAM-2, p. 17.] "The function of the service delivery subsystem is to transport an error-free copy of the request or response between the sender and the receiver" [SAM-2, p. 22]. The iSCSI protocol MUST correctly deal with iSCSI packet drop, duplication, corruption, stale packets, and re-ordering.
ISCSIプロトコルは、SCSIコマンドをイニシエーターからターゲットに確実に輸送する必要があります。[SAM-2、p。17.]「サービス配信サブシステムの機能は、送信者と受信者間のリクエストまたは応答のエラーのないコピーを輸送することです」[SAM-2、p。22]。ISCSIプロトコルは、ISCSIパケットのドロップ、複製、腐敗、古いパケット、および再注文を正しく扱う必要があります。
In the past, directly attached storage systems have implemented minimal security checks because the physical connection offered little chance for attack. Transporting block storage (SCSI) over IP opens a whole new opportunity for a variety of malicious attacks. Attacks can take the active form (identity spoofing, man-in-the-middle) or the passive form (eavesdropping).
過去には、直接接続されたストレージシステムは、物理的な接続が攻撃の機会をほとんど提供しなかったため、最小限のセキュリティチェックを実装しています。IP経由のブロックストレージ（SCSI）の輸送は、さまざまな悪意のある攻撃のためのまったく新しい機会を開きます。攻撃は、アクティブな形（アイデンティティスプーフィング、中間の男）またはパッシブフォーム（盗聴）を取ることができます。
The security services required for communications depends on the individual network configurations and environments. Organizations are setting up Virtual Private Networks(VPN), also known as Intranets, that will require one set of security functions for communications within the VPN and possibly many different security functions for communications outside the VPN to support geographically separate components. The iSCSI protocol is applicable to a wide range of internet working environments that may employ different security policies. iSCSI MUST provide for strong authentication when increased security is required. The protocol SHOULD require minimal configuration and overhead in the insecure operation, and allow integration of new security mechanisms without breaking backwards compatible operation.
通信に必要なセキュリティサービスは、個々のネットワーク構成と環境に依存します。組織は、イントラネットとも呼ばれる仮想プライベートネットワーク（VPN）をセットアップしています。これには、VPN内の通信に1つのセキュリティ関数が必要になり、VPN以外の通信には地理的に分離されたコンポーネントをサポートするための多くの異なるセキュリティ関数が必要になります。ISCSIプロトコルは、さまざまなセキュリティポリシーを使用する可能性のある幅広いインターネットワーキング環境に適用できます。ISCSIは、セキュリティの増加が必要な場合、強力な認証を提供する必要があります。プロトコルは、安全でない動作で最小限の構成とオーバーヘッドを必要とし、逆方向の互換操作を壊さずに新しいセキュリティメカニズムを統合できるようにする必要があります。
The iSCSI protocol MAY support various levels of authentication security, ranging from no authentication to secure authentication using public or private keys.
ISCSIプロトコルは、認証なしからパブリックキーまたはプライベートキーを使用した認証を保護するまで、さまざまなレベルの認証セキュリティをサポートする場合があります。
The iSCSI protocol MUST support private authenticated login.
ISCSIプロトコルは、プライベート認証ログインをサポートする必要があります。
Authenticated login aids the target in blocking the unauthorized use of SCSI resources. "Private" authenticated login mandates protected identity exchange (no clear text passwords at a minimum). Since block storage confidentiality is considered critical in enterprises and many IP networks may have access holes, organizations will want to protect their iSCSI resources.
認証されたログインは、SCSIリソースの不正使用をブロックする際に目標を支援します。「プライベート」認証されたログインは、保護されたID交換義務が義務付けられています（少なくとも明確なテキストパスワードはありません）。ブロックストレージの機密性は企業で重要であると考えられており、多くのIPネットワークにアクセスホールがある可能性があるため、組織はISCSIリソースを保護したいと考えています。
The iSCSI authenticated login MUST be resilient against attacks since many IP networks are vulnerable to packet inspection.
多くのIPネットワークはパケット検査に対して脆弱であるため、ISCSI認証ログインは攻撃に対して回復力がある必要があります。
In addition, the iSCSI protocol MUST support data origin authentication of its communications; data origin authentication MAY be optional to use. Data origin authentication is critical since IP networks are vulnerable to source spoofing, where a malicious third party pretends to send packets from the initiator's IP address. These requirements should be met using standard Internet protocols such as IPsec or TLS. The endpoints may negotiate the authentication method, optionally none.
さらに、ISCSIプロトコルは、その通信のデータ起源認証をサポートする必要があります。データ起源の認証は、使用するのがオプションです。IPネットワークはソースのスプーフィングに対して脆弱であるため、データオリジン認証は重要です。これにより、悪意のあるサードパーティがイニシエーターのIPアドレスからパケットを送信するふりをしています。これらの要件は、IPSECやTLSなどの標準的なインターネットプロトコルを使用して満たす必要があります。エンドポイントは、オプションで認証方法をネゴシエートする場合があります。
The iSCSI protocol SHOULD NOT preclude use of additional data integrity protection protocols (IPSec, TLS).
ISCSIプロトコルは、追加のデータ整合性保護プロトコル（IPSEC、TLS）の使用を妨げるべきではありません。
Block storage is used for storing sensitive information, where data confidentiality is critical. An application may encrypt the data blocks before writing them to storage - this provides the best protection for the application. Even if the storage or communications are compromised, the attacker will have difficulty reading the data.
ブロックストレージは、データの機密性が重要な機密情報の保存に使用されます。アプリケーションは、データブロックをストレージに書き込む前に、データブロックを暗号化する場合があります。これにより、アプリケーションに最適な保護が提供されます。ストレージまたは通信が侵害されたとしても、攻撃者はデータを読むのが困難になります。
In certain environments, encryption may be desired to provide an extra assurance of confidentiality. An iSCSI implementation MUST provide for the use of a data encryption protocol such as TLS or IPsec ESP to provide data confidentiality between iSCSI endpoints.
特定の環境では、機密性の追加保証を提供するために暗号化が望まれる場合があります。ISCSIの実装は、ISCSIエンドポイント間のデータの機密性を提供するために、TLSやIPSEC ESPなどのデータ暗号化プロトコルを使用するために提供する必要があります。
iSCSI implementations SHOULD be manageable using standard IP-based management protocols. However, the iSCSI protocol document MUST NOT define the management architecture for iSCSI within the network infrastructure. iSCSI will be yet another resource service within a complex environment of network resources (printers, file servers, NAS, application servers, etc). There will certainly be efforts to design how the "block storage service" that iSCSI devices provide is integrated into a comprehensive, shared model, network management environment. A "network administrator" (or "storage administrator") will desire to have integrated applications for assigning user names, resource names, etc. and indicating access rights. iSCSI devices presumably will want to interact with these integrated network management applications. The iSCSI protocol document will not attempt to solve that set of problems, or specify means for devices to provide management agents. In fact, there should be no mention of MIBs or any other means of managing iSCSI devices as explicit references in the iSCSI protocol document, because management data and protocols change with the needs of the environment and the business models of the management applications.
ISCSIの実装は、標準のIPベースの管理プロトコルを使用して管理可能である必要があります。ただし、ISCSIプロトコルドキュメントは、ネットワークインフラストラクチャ内のISCSIの管理アーキテクチャを定義してはなりません。ISCSIは、ネットワークリソースの複雑な環境（プリンター、ファイルサーバー、NAS、アプリケーションサーバーなど）内のさらに別のリソースサービスになります。ISCSIデバイスが提供する「ブロックストレージサービス」が、包括的な共有モデル、ネットワーク管理環境に統合されている方法を設計する努力が確かにあります。「ネットワーク管理者」（または「ストレージ管理者」）は、ユーザー名、リソース名などの割り当ておよびアクセス権を示すための統合アプリケーションを統合したいと考えています。ISCSIデバイスは、おそらくこれらの統合ネットワーク管理アプリケーションと対話したいと考えています。ISCSIプロトコルドキュメントは、その一連の問題を解決したり、デバイスが管理エージェントを提供する手段を指定しようとはしません。実際、MIBSまたはISCSIプロトコルドキュメントの明示的な参照としてISCSIデバイスを管理するその他の手段については、管理データとプロトコルが環境のニーズと管理アプリケーションのビジネスモデルに変化するため、言及されるべきではありません。
Whenever possible, iSCSI MUST support the naming architecture of SAM-2. Deviations and uncertainties MUST be made explicit, and comments and resolutions worked out between ANSI T10 and the IPS working group.
可能な限り、ISCSIはSAM-2の命名アーキテクチャをサポートする必要があります。逸脱と不確実性を明示的に行う必要があり、ANSI T10とIPSワーキンググループの間でコメントと解決策が機能する必要があります。
The means by which an iSCSI resource is located MUST use or extend existing Internet standard resource location methods. RFC 2348 [12] specifies URL syntax and semantics which should be sufficiently extensible for the iSCSI resource.
ISCSIリソースが配置されている手段は、既存のインターネット標準リソースの位置方法を使用または拡張する必要があります。RFC 2348 [12]は、ISCSIリソースに十分に拡張可能なURL構文とセマンティクスを指定します。
The iSCSI protocol MUST provide a means of identifying an iSCSI storage device by a unique identifier that is independent of the path on which it is found. This name will be used to correlate alternate paths to the same device. The format for the iSCSI names MUST use existing naming authorities, to avoid creating new central administrative tasks. An iSCSI name SHOULD be a human readable string in an international character set encoding.
ISCSIプロトコルは、発見されたパスに依存しない一意の識別子によってISCSIストレージデバイスを識別する手段を提供する必要があります。この名前は、同じデバイスに代替パスを相関させるために使用されます。ISCSI名の形式は、新しい中央管理タスクの作成を避けるために、既存の命名当局を使用する必要があります。ISCSI名は、国際的なキャラクターセットエンコーディングの人間の読み取り可能な文字列である必要があります。
Standard Internet lookup services SHOULD be used to resolve names. For example, Domain Name Services (DNS) MAY be used to resolve the <hostname> portion of a URL to one or multiple IP addresses. When a hostname resolves to multiple addresses, these addresses should be equivalent for functional (possibly not performance) purposes. This means that the addresses can be used interchangeably as long as performance isn't a concern. For example, the same set of SCSI targets MUST be accessible from each of these addresses.
標準のインターネット検索サービスを使用して、名前を解決する必要があります。たとえば、ドメイン名サービス（DNS）を使用して、URLの<Hostname>部分を1つまたは複数のIPアドレスに解決できます。ホスト名が複数のアドレスに解決する場合、これらのアドレスは、機能的な（おそらくパフォーマンスではない）目的と同等でなければなりません。これは、パフォーマンスが懸念されない限り、アドレスを交換可能に使用できることを意味します。たとえば、これらの各アドレスから同じセットのSCSIターゲットにアクセスできる必要があります。
An iSCSI device naming scheme MUST interact correctly with the proposed SCSI security architecture [99-245r9]. Particular attention must be directed to the proxy naming architecture defined by the new security model. In this new model, a host is identified by an Access ID, and SCSI Logical Unit Numbers (LUNs) can be mapped in a manner that gives each AccessID a unique LU map. Thus, a given LU within a target may be addressed by different LUNs.
ISCSIデバイスの命名スキームは、提案されているSCSIセキュリティアーキテクチャ[99-245R9]と正しく相互作用する必要があります。新しいセキュリティモデルによって定義されたプロキシネーミングアーキテクチャに特に注意を向ける必要があります。この新しいモデルでは、ホストがアクセスIDによって識別され、SCSI論理ユニット数（LUN）は、各AccessIDに一意のLUマップを提供する方法でマッピングできます。したがって、ターゲット内の特定のLUは、異なるLUNによって対処される場合があります。
The iSCSI naming architecture MUST address support of SCSI 3rd party operations such as EXTENDED COPY. The key issue here relates to the naming architecture for SCSI LUs - iSCSI must provide a means of passing a name or handle between parties. iSCSI must specify a means of providing a name or handle that could be used in the XCOPY command and fit within the available space allocated by that command. And it must be possible, of course, for the XCOPY target (the third party) to de-reference the name to the correct target and LU.
ISCSIネーミングアーキテクチャは、拡張コピーなどのSCSIサードパーティ運用のサポートに対処する必要があります。ここでの重要な問題は、SCSI LUSの命名アーキテクチャに関連しています-ISCSIは、当事者間で名前またはハンドルを渡す手段を提供する必要があります。ISCSIは、Xcopyコマンドで使用できる名前またはハンドルを提供し、そのコマンドによって割り当てられた利用可能なスペース内に適合する手段を指定する必要があります。そして、もちろん、Xcopyターゲット（サードパーティ）が正しいターゲットとLuに名前を解放することは可能である必要があります。
iSCSI MUST have no impact on the use of current IP network discovery techniques. Network management platforms discover IP addresses and have various methods of probing the services available through these IP addresses. An iSCSI service should be evident using similar techniques.
ISCSIは、現在のIPネットワーク発見技術の使用に影響を与える必要はありません。ネットワーク管理プラットフォームは、IPアドレスを発見し、これらのIPアドレスを通じて利用可能なサービスを調査するさまざまな方法を持っています。ISCSIサービスは、同様の手法を使用して明らかです。
The iSCSI specifications MUST provide some means of determining whether an iSCSI service is available through an IP address. It is expected that iSCSI will be a point of service in a host, just as SNMP, etc are points of services, associated with a well known port number.
ISCSI仕様は、ISCSIサービスがIPアドレスを介して利用可能かどうかを判断するための何らかの手段を提供する必要があります。SNMPなどがよく知られているポート番号に関連付けられているサービスのポイントであるように、ISCSIはホストのサービスのポイントになることが期待されています。
SCSI protocol-dependent techniques SHOULD be used for further discovery beyond the iSCSI layer. Discovery is a complex, multi-layered process. The SCSI protocol specifications provide specific commands for discovering LUs and the commands associated with this process will also work over iSCSI.
SCSIプロトコル依存技術は、ISCSI層を超えてさらなる発見に使用する必要があります。発見は、複雑で多層的なプロセスです。SCSIプロトコル仕様は、LUSを発見するための特定のコマンドを提供し、このプロセスに関連するコマンドもISCSIで機能します。
The iSCSI protocol MUST provide a method of discovering, given an IP end point on its well-known port, the list of SCSI targets available to the requestor. The use of this discovery service MUST be optional.
ISCSIプロトコルは、リクエスト担当者が利用できるSCSIターゲットのリストである有名なポートにIPエンドポイントを考慮して、発見する方法を提供する必要があります。このディスカバリーサービスの使用はオプションでなければなりません。
Further discovery guidelines are outside the scope of this document and may be addressed in separate Informational documents.
さらなる発見ガイドラインは、このドキュメントの範囲外であり、個別の情報文書で対処できます。
As with all services, the denial of service by either incorrect implementations or malicious agents is always a concern. All aspects of the iSCSI protocol SHOULD be scrutinized for potential denial of service issues, and guarded against as much as possible.
すべてのサービスと同様に、誤った実装または悪意のあるエージェントのいずれかによるサービスの拒否は常に懸念事項です。ISCSIプロトコルのすべての側面は、潜在的なサービス拒否の問題のために精査され、可能な限り守られるべきです。
NATs (Network Address Translator), firewalls, and proxy servers are a reality in today's Internet. These devices present a number of challenges to device access methods being developed for iSCSI. For example, specifying a URL syntax for iSCSI resource connection allows an initiator to address an iSCSI target device both directly and through an iSCSI proxy server or NAT. iSCSI SHOULD allow deployment where functional and optimizing middle-boxes such as firewalls, proxy servers and NATs are present.
NATS（ネットワークアドレス翻訳者）、ファイアウォール、プロキシサーバーは、今日のインターネットでは現実です。これらのデバイスは、ISCSI向けに開発されているデバイスアクセスメソッドに多くの課題を提示します。たとえば、ISCSIリソース接続のURL構文を指定することで、イニシエーターはISCSIターゲットデバイスに直接およびISCSIプロキシサーバーまたはNATの両方を介して対処できます。ISCSIは、ファイアウォール、プロキシサーバー、NATなどの中間ボックスが機能的かつ最適化されている場合、展開を許可する必要があります。
The iSCSI protocol's use of IP addressing and TCP port numbers MUST be firewall friendly. This means that all connection requests should normally be addressed to a specific, well-known TCP port. That way, firewalls can filter based on source and destination IP addresses, and destination (target) port number. Additional TCP connections would require different source port numbers (for uniqueness), but could be opened after a security dialogue on the control channel.
ISCSIプロトコルによるIPアドレスの使用とTCPポート番号の使用は、ファイアウォールに優しいものでなければなりません。これは、すべての接続要求が通常、特定の有名なTCPポートに宛ててアドレス指定する必要があることを意味します。そうすれば、ファイアウォールは、ソースおよび宛先IPアドレス、および宛先（ターゲット）ポート番号に基づいてフィルタリングできます。追加のTCP接続には、異なるソースポート番号（一意性）が必要ですが、制御チャネルでのセキュリティダイアログの後に開くことができます。
It's important that iSCSI operate through a firewall to provide a possible means of defending against Denial of Service (DoS) assaults from less-trusted areas of the network. It is assumed that a firewall will have much greater processing power for dismissing bogus connection requests than end nodes.
ISCSIはファイアウォールを介して動作し、ネットワークのあまり信頼されていない領域からのサービス拒否（DOS）の暴行を防御する手段を提供することが重要です。ファイアウォールは、終了ノードよりも偽の接続要求を却下するための処理能力がはるかに大きいと想定されています。
The iSCSI protocol MUST be a good network citizen with proven congestion control (as defined in [RFC2914]). In addition, iSCSI implementations MUST NOT use multiple connections as a means to avoid transport-layer congestion control.
ISCSIプロトコルは、実証済みの混雑制御を備えた優れたネットワーク市民でなければなりません（[RFC2914]で定義されています）。さらに、ISCSIの実装は、輸送層の混雑制御を避けるための手段として複数の接続を使用してはなりません。
Certain definitions are offered here, with references to the original document where applicable, in order to clarify the discussion of requirements. Definitions without references are the work of the authors and reviewers of this document.
特定の定義は、要件の議論を明確にするために、該当する場合は元のドキュメントへの参照とともに、ここで提供されています。参照のない定義は、この文書の著者とレビュアーの作業です。
Logical Unit (LU): A target-resident entity that implements a device model and executes SCSI commands sent by an application client [SAM-2, sec. 3.1.50, p. 7].
論理ユニット（LU）：デバイスモデルを実装し、アプリケーションクライアントが送信したSCSIコマンドを実行するターゲットレジデントエンティティ[SAM-2、Sec。3.1.50、p。7]。
Logical Unit Number (LUN): A 64-bit identifier for a logical unit [SAM-2, sec. 3.1.52, p. 7].
論理単位番号（LUN）：論理ユニットの64ビット識別子[SAM-2、sec。3.1.52、p。7]。
SCSI Device: A device that is connected to a service delivery subsystem and supports a SCSI application protocol [SAM-2, sec. 3.1.78, p. 9].
SCSIデバイス：サービス配信サブシステムに接続され、SCSIアプリケーションプロトコルをサポートするデバイス[SAM-2、Sec。3.1.78、p。9]。
Service Delivery Port (SDP): A device-resident interface used by the application client, device server, or task manager to enter and retrieve requests and responses from the service delivery subsystem. Synonymous with port (SAM-2 sec. 3.1.61) [SAM-2, sec. 3.1.89, p. 9].
サービス配信ポート（SDP）：アプリケーションクライアント、デバイスサーバー、またはタスクマネージャーがサービス提供サブシステムからリクエストと応答を入力して取得するために使用されるデバイスと居住のインターフェイス。ポートと同義（SAM-2秒3.1.61）[SAM-2、Sec。3.1.89、p。9]。
Target: A SCSI device that receives a SCSI command and directs it to one or more logical units for execution [SAM-2 sec. 3.1.97, p. 10].
ターゲット：SCSIコマンドを受信し、実行のために1つ以上の論理ユニットに向けたSCSIデバイス[SAM-2 sec。3.1.97、p。10]。
Task: An object within the logical unit representing the work associated with a command or a group of linked commands [SAM-2, sec. 3.1.98, p. 10].
タスク：コマンドまたはリンクされたコマンドのグループに関連付けられた作業を表す論理ユニット内のオブジェクト[SAM-2、Sec。3.1.98、p。10]。
Transaction: A cooperative interaction between two objects, involving the exchange of information or the execution of some service by one object on behalf of the other [SAM-2, sec. 3.1.109, p. 10].
トランザクション：2つのオブジェクト間の協力的な相互作用。情報の交換または他のオブジェクトに代わって1つのオブジェクトによる一部のサービスの実行を含む[SAM-2、Sec。3.1.109、p。10]。
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
1. Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
2. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
2. Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
3. [SAM-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Architecture Model -2 (SAM-2). T10 Project 1157-D. rev 23, 16 Mar 2002.
3. [SAM-2] Ansi ncits。ウェーバー、ラルフO.、編集者。SCSIアーキテクチャモデル-2（SAM -2）。T10プロジェクト1157-D。Rev 23、2002年3月16日。
4. [SPC-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Primary Commands 2 (SPC-2). T10 Project 1236-D. rev 20, 18 July 2001.
4. [SPC-2] Ansi ncits。ウェーバー、ラルフO.、編集者。SCSIプライマリコマンド2（SPC-2）。T10プロジェクト1236-D。Rev 20、2001年7月18日。
5. [CAM-3] ANSI NCITS. Dallas, William D., editor. Information Technology - Common Access Method - 3 (CAM-3)). X3T10 Project 990D. rev 3, 16 Mar 1998.
5. [CAM-3] Ansi ncits。ダラス、ウィリアムD.、編集者。情報技術 - 共通アクセス方法-3（CAM -3））。x3t10プロジェクト990d。Rev 3、1998年3月16日。
6. [99-245r8] Hafner, Jim. A Detailed Proposal for Access Controls. T10/99-245 revision 9, 26 Apr 2000.
6. [99-245R8]ハフナー、ジム。アクセス制御の詳細な提案。T10/99-245リビジョン9、2000年4月26日。
7. [SPI-X] ANSI NCITS. SCSI Parallel Interface - X.
7. [spi-x] ansi ncits。SCSIパラレルインターフェイス-X。
8. [FCP] ANSI NCITS. SCSI-3 Fibre Channel Protocol [ANSI X3.269:1996].
8. [FCP] ANSI NCITS。SCSI-3ファイバーチャネルプロトコル[ANSI X3.269：1996]。
9. [FCP-2] ANSI NCITS. SCSI-3 Fibre Channel Protocol - 2 [T10/1144-D].
9. [FCP-2] Ansi ncits。SCSI-3ファイバーチャネルプロトコル-2 [T10/1144-D]。
10. Paxon, V. End-to-end internet packet dynamics, IEEE Transactions on Networking 7,3 (June 1999) pg 277-292.
10. Paxon、V。エンドツーエンドのインターネットパケットダイナミクス、ネットワーキングに関するIEEEトランザクション7,3（1999年6月）PG 277-292。
11. Stone J., Partridge, C. When the CRC and TCP checksum disagree, ACM Sigcomm (Sept. 2000).
11. Stone J.、Partridge、C。CRCおよびTCPチェックサムが同意しない場合、ACM Sigcomm（2000年9月）。
12. Malkin, G. and A. Harkin, "TFTP Blocksize Option", RFC 2348, May 1998.
12. Malkin、G。およびA. Harkin、「TFTP BlockSize Option」、RFC 2348、1998年5月。
13. Floyd, S., "Congestion Control Principles", BCP 14, RFC 2914, September 2000.
13. フロイド、S。、「混雑制御原則」、BCP 14、RFC 2914、2000年9月。
Special thanks to Julian Satran, IBM and David Black, EMC for their extensive review comments.
IBMとDavid BlackのJulian Satranに感謝します。
Address comments to:
対処するコメント：
Marjorie Krueger Hewlett-Packard Corporation 8000 Foothills Blvd Roseville, CA 95747-5668, USA Phone: +1 916 785-2656 EMail: marjorie_krueger@hp.com
Marjorie Krueger Hewlett-Packard Corporation 8000 Foothills Blvd Roseville、CA 95747-5668、USA電話：1 916 785-2656メール：marjorie_krueger@hp.com
Randy Haagens Hewlett-Packard Corporation 8000 Foothills Blvd Roseville, CA 95747-5668, USA Phone: +1 916 785-4578 EMail: Randy_Haagens@hp.com
Randy Haagens Hewlett-Packard Corporation 8000 Foothills Blvd Roseville、CA 95747-5668、米国電話：1 916 785-4578電子メール：Randy_haagens@hp.com
Costa Sapuntzakis Stanford University 353 Serra Mall Dr #407 Stanford, CA 94305 Phone: 650-723-2458 EMail: csapuntz@stanford.edu
コスタ・サプンツァキス・スタンフォード大学353セラ・モールDR＃407スタンフォード、カリフォルニア94305電話：650-723-2458メール：csapuntz@stanford.edu
Mark Bakke Cisco Systems, Inc. 6450 Wedgwood Road Maple Grove, MN 55311 Phone: +1 763 398-1054 EMail: mbakke@cisco.com
Mark Bakke Cisco Systems、Inc。6450 Wedgwood Road Maple Grove、MN 55311電話：1 763 398-1054メール：mbakke@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。