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.
著作権（C）インターネット協会（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].
この文書では、プロトコルの設計のための要件について説明しますが、プロトコル標準を定義していません。この中にもかかわらず、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "べきではない" "べきである" "ないものと"、 "推奨"、 "MAY"、および "オプション" 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（Small Computer Systems Interface）プロトコルを転送するためのプロトコルが含まれています。 SCSIストレージ・コントローラ（主にディスクおよびテープアレイおよびライブラリ）はIPネットワーク、特に、ギガビットイーサネット（GBE）、10ギガビットイーサネットに結合させることができるように、iSCSIプロトコルの初期バージョンは、TCP / IP上のSCSIトランスポートプロトコルのマッピングを定義します（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プロトコルはTCPにSCSIのマッピングであり、ANSI T10文書SCSI SAM2ドキュメント[SAM2、Pによって定義されるような「SCSI輸送」を構成します。 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.
何のオプション機能は、個々のオプションのnegotionsが失敗したときと同様に交渉されていない場合、正常に動作しなければなりません。
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： - IPv4とIPv6の両方と互換性がある - 特定のマシン上でTCPの他の多くのユーザーがあるかもしれない念頭に置いて、保守的にTCP接続を使用します。
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.
プロトコルデータユニット（PDU）の構造およびフォーマット、iSCSIプロトコルの動作に最小限の変更とのIPトランスポートプロトコルとしてTCP（用）SCTPの将来の置換を可能にするように設計されなければなりません。
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.
厳密にSCSIの配信は、イニシエータ/ターゲット・ペア間のiSCSIセッションを介してコマンドを命じ指定する必要があります。
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ターゲットを識別する手段を提供しなければなりません。
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の命名アーキテクチャは、EXTENDED COPYとして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パラレルバスまたはFibre Channelでコンピュータに接続されています。
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
- 拡張距離は範囲 - 接続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
- ポイント・ツー・ポイントの直接接続 - 専用ストレージLANは、一つ以上のLANセグメントからなる - 従来のLANトラフィックのミックスを運ぶ、共有LANプラスストレージトラフィック - のLAN-to-WAN拡張IPルータまたは担体を使用して-provided「IP Datatone」 - プライベートネットワークと公衆インターネット
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）強力なSANインフラストラクチャをサポートするための管理とディレクトリサービスアプリケーションの（6）開発などのMIB、LDAPまたはXMLスキーマなどのiSCSIデバイス管理のための仕様の開発を。
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）の憲章は、さまざまなプラットフォーム上で輻輳回避行動と幅広い実装を証明しているトランスポートを使用してIPにマッピングするSCSIの広範な目標を説明します。その幅広い憲章の中で、いくつかの輸送の代替案が考えられます。初期の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).
他のSCSIトランスポート（ファイバチャネル）と比較すると、ベンダーとユーザーコミュニティによって採用されるためには、iSCSIプロトコルは、コスト競争力の実現を有効にする必要があります。
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.
代替SCSIトランスポートの実装がそうであるように（1）iSCSIは、SCSI全体のタスクを処理I / Oアダプタを構築することを可能にしなければなりません。 （2）プロトコルは、I / Oアダプタが正確に一度ディスクトランザクションあたりのホストメモリを読み取るか、または書き込み、直接データ配置（「ゼロコピー」メモリ・アーキテクチャを、可能にすべきである。（3）プロトコルは、ホストソフトウェアに複雑な操作を許可すべきではありません、代替案に対するホスト命令パスの長さを増すことになります。
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 /秒）は、急速にいくつかの要因に、増加しています。
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).
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:
フレーミングのための他の技術的な要件は、「処理を加速し、」物理メディアインターフェイスで、ますます高いデータレートを処理する必要性から生じます。二つのニーズは、より高いデータレートに起因します：
(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.
まず、ベンダーは、より高いデータレートを達成するためのハードウェアソリューションにネットワークプロトコルをオフロードし、ネットワーク処理ハードウェアを生産しています。 「ゼロコピー」の概念は、データがパケット損失に並べ替えた場合でも、直接ワイヤオフ（整列）適切なメモリ位置にデータのブロックを格納しようとするものです。これは、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.
X 200ミリ秒の10Gbpsのネットワーク管250 MBに保持していることを考えます。 [赤道で世界中のスポット途中で土地ベースの通信を想定。ケーブル配線による追加距離を無視します。リピータとスイッチング遅延を無視してください。 5マイクロ秒/キロの唯一の光速の遅延を考慮してください。赤道で地球の円周は約です。 4万キロ（往復遅延は完全なパイプを維持するために考慮されなければなりません）。 10ギガビット/秒のX4万キロ×5マイクロ秒/キロのx B / 8B = 250メガバイト]。従来のTCPの実装では、TCPセグメントの損失は、そのセグメントが達成するために、<ネットワークラウンドトリップ>の少なくとも時間をとる、回収されるまで、ストリーム処理を停止しなければならないことを意味します。上記の例に続いて、実装は、ストリーム処理を再開する前に匿名のバッファへのデータの250メガバイトをキャッチする義務であろう。後に、このデータは、その適切な場所に移動する必要があります。 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タスクは、イニシエータが同時にターゲットに優れた複数のコマンドを持っているし、それらのコマンドの実行に順序の制約を表現することができます。コマンドは、それらがイニシエータ（FIFO順）に提示された順序でターゲットに到着した場合、タスクキューイングメカニズムは、有効です。 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プロトコルは、一つだけのトランスポート接続があった場合に対応している必要がありますので、プロトコルは同じ接続でコマンド、データ、およびステータスの旅行を持っている必要があります。
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が注文配達を提供して）データの後に受信されることを保証しているため、同じ接続上のデータとステータスを送信することが望ましいです。各接続は、別個のプロセッサによって管理される場合に、忠誠は、プロセッサ間通信の必要性を減少させます。この対称的なアプローチは、単一の接続アプローチの自然な拡張です。
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.
広範囲に議論された代替的なアプローチは、単一の接続とは異なる接続（非対称アプローチ）に関連するデータおよびステータスのすべてのコマンドを送信関与しました。この方式では、トランスポートは、コマンドが順序で到着を保証します。データとステータスの接続上のプロトコルは、おそらくハードウェアでシンプルな実現に自分自身を貸す、簡単です。このアプローチの一つの欠点は、コマンド接続は、データ接続対失敗した場合の回復手順が異なることです。いくつかは、接続がプロセッサに分散されたときに、このアプローチは、より大きなプロセッサ間通信を必要とすることを主張しました。
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プロトコルはCRCまたはSCSIデータブロック自体に計算されたダイジェスト他の機構、ならびに上の各コマンドおよびステータスメッセージを含まなければなりません。ゲートウェイがiSCSIヘッダを削除し、それらを再構築することができるので、別のヘッダCRCが必要です。二つのヘッダダイジェスト、ヘッダの不変部分のための1つの（アドレス）と変異体部分の一方は、中央のボックス（例えば、アドレス）によって変化してはならないヘッダの部分への変更に対する保護を提供するであろう。
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.
- IPv4とIPv6の両方と互換性があります。 - 指定したマシン上のTCPの他の多くのユーザーがあるかもしれない念頭に置いて、保守的にTCP接続を使用します。
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は、プロトコルデータユニット（PDU）の構造およびフォーマット、iSCSIプロトコルの動作に最小限の変更とのIPトランスポートプロトコルとしてTCP（用）SCTPの将来の置換を可能にするように設計されなければなりません。今日広く実装されていませんが、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プロトコルドキュメントは、推奨又はおよび/または使用を実施するのに必要な、OPTIONALであるか否かを各機能に指定しなければなりません。
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リフレクターにし、この順序を保証するための手段についてのグループミーティングを作業に多くの議論がなされてきました。ラフコンセンサスは、SCSIも搬送エラーの存在下で、イニシエータ/ターゲットペアの間のiSCSIセッションを介してコマンドのiSCSIは、厳密に順序付けられた配信を指定しなければならないことです。このコマンド注文メカニズムは、オフロード輸送を行っている複数のアダプタ間で必要な通信の量を最小限にするために努めるべきです。 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（自動偶発忠誠）は、そのうちの一つが故障した従属SCSIコマンドのシーケンスの実行を停止し、オプションのSCSIメカニズムです。それを取り巻く状況は複雑である - T10はSAM2にACAを特定し、ひいてはiSCSIは標準のドラフトすることを提案し、標準からの移行でACAを落とさないように（二つの独立した相互運用可能な実装を）それをサポートし、ACAが十分に実装されることを確認するために努力しなければなりません。これは、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ホストは（SCSI-Xは、任意の他のトランスポート上でSCSI、SCSI-FCP、またはSCSIパラレル指す）iSCSIターゲットを使用することができます。この要件は、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）を輸送することは、悪意のある攻撃のさまざまな全く新しい機会を開きます。攻撃は（アイデンティティスプーフィング、のman-in-the-middle）または受動形（盗聴）を活性形態をとることができます。
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リソースの不正使用を阻止するには、目標を支援します。 「プライベート」認証されたログイン義務付け保護されたアイデンティティ交換（最低でも明確なテキストのパスワードなし）。ブロックストレージの機密性は、アクセス穴を有することができ、企業や多くの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プロトコルドキュメントは、問題のそのセットを解決しようとすると、または管理エージェントを提供するために、デバイスのための手段を指定しません。実際には、管理データおよびプロトコルは、環境のニーズと管理アプリケーションのビジネスモデルを変更するため、MIBのか、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）は、1つまたは複数のIPアドレスにURLの<ホスト名>の部分を解決するために使用されるかもしれません。ホスト名が複数のアドレスに解決する場合、これらのアドレスは、機能（おそらくないパフォーマンス）の目的のために同等でなければなりません。これは、アドレスは限りパフォーマンスが問題ではないとして、互換的に使用できることを意味します。例えば、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）で識別され、それぞれが独自のLUマップをAccessID与えた方法でマッピングすることができます。このように、ターゲット内の指定された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の命名アーキテクチャは、EXTENDED COPYとしてSCSIサードパーティ・オペレーションのサポートに対処しなければなりません。ここで重要な問題は、SCSI LUの命名アーキテクチャに関連する - 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アドレスを介して利用可能であるかどうかを決定するいくつかの手段を提供しなければなりません。 iSCSIはちょうどSNMPなどとしてよく知られているポート番号に関連付けられているサービスのポイントは、あるホストでのサービスのポイントになることが期待されます。
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プロトコル仕様は、LUを発見するための特定のコマンドを提供し、このプロセスに関連するコマンドも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プロトコルは、そのよく知られたポート上のIPエンドポイントが与えられると、リクエスタに利用可能なSCSIターゲットのリストを発見する方法を提供しなければなりません。この発見サービスの使用はオプションでなければなりません。
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.
NATの（ネットワークアドレス変換）、ファイアウォール、プロキシサーバは、今日のインターネットでの現実です。これらのデバイスは、iSCSI用に開発されているデバイスのアクセス方法に多くの課題を提示します。例えば、iSCSIのリソース接続のためのURLの構文を指定すると、イニシエータは両方直接およびiSCSIプロキシサーバまたはNATを介してiSCSIターゲットデバイスをアドレス指定することを可能にします。 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.
IPアドレス指定とTCPポート番号のiSCSIプロトコルの使用はファイアウォールフレンドリーでなければなりません。これは、すべての接続要求は、通常、特定の、よく知られた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）：デバイス・モデルを実装し、アプリケーションクライアント[SAM-2、秒によって送信されたSCSIコマンドを実行し、ターゲット常駐エンティティ。 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）：論理ユニット[SAM-2、秒間64ビットの識別子。 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、秒をサポートしているデバイス。 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秒と同義。 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].
ターゲット：[SAM-2秒SCSIコマンドを受信および実行するための1つ以上の論理ユニットに導くSCSIデバイス。 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、秒のグループに関連付けられた作業を表す論理ユニット内のオブジェクト。 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].
トランザクション：情報の交換または他の[SAM-2、秒の代わりに一つのオブジェクトによって一部のサービスの実行に関与する2つのオブジェクト間の協力的相互作用。 3.1.109、P。 10]。
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
1.ブラドナーの、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.ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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。 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。 2001年7月20、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日。
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.エンドツーエンドのインターネットパケットダイナミクス、ネットワーク7,3上のIEEEトランザクション（1999年6月）頁277から292まで。
11. Stone J., Partridge, C. When the CRC and TCP checksum disagree, ACM Sigcomm (Sept. 2000).
11.石J.、ヤマウズラ、C. CRCとTCPチェックサムが不一致、ACM SIGCOMM（2000年9月）。
12. Malkin, G. and A. Harkin, "TFTP Blocksize Option", RFC 2348, May 1998.
12.マルキン、G.とA.ハーキン、 "TFTPブロックサイズオプション"、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.
彼らの広範なレビューコメントについてジュリアンSatran、IBMとDavidブラック、EMCに感謝します。
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
マージョリー・クルーガーヒューレット・パッカード株式会社8000山麓ブールバードローズ、CA 95747から5668、USA電話：+1 916 785から2656 Eメール：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
ランディHaagensヒューレット・パッカード株式会社8000山麓ブールバードローズ、CA 95747から5668、USA電話：+1 916 785から4578 Eメール：Randy_Haagens@hp.com
Costa Sapuntzakis Stanford University 353 Serra Mall Dr #407 Stanford, CA 94305 Phone: 650-723-2458 EMail: csapuntz@stanford.edu
コスタSapuntzakisスタンフォード大学353セラモール博士＃407スタンフォード、CA 94305電話：650-723-2458 Eメール：csapuntz@stanford.edu
Mark Bakke Cisco Systems, Inc. 6450 Wedgwood Road Maple Grove, MN 55311 Phone: +1 763 398-1054 EMail: mbakke@cisco.com
マークBakkeシスコシステムズ株式会社6450ウェッジウッド道路メープルグローブ、MN 55311電話：+1 763 398から1054 Eメール：mbakke@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。