RFC3347 日本語訳
3347 Small Computer Systems Interface protocol over the Internet(iSCSI) Requirements and Design Considerations. M. Krueger, R.Haagens. July 2002. (Format: TXT=58097 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループM.クルーガー要求をネットワークでつないでください: 3347年のR.Haagensカテゴリ: 情報のヒューレット・パッカードのSapuntzakisスタンフォードM.バッキーシスコシステムズ社のC.2002年7月
Small Computer Systems Interface protocol over the Internet (iSCSI)
Requirements and Design Considerations
小さいコンピュータシステムズInterfaceはインターネット(iSCSI)の要件とDesign Considerationsの上で議定書を作ります。
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[2]で説明されるように本書では解釈されることであるべきですか?
Krueger, et al. Informational [Page 1] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[1ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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
1. 序論…2 2. 要件の概要…3 3. iSCSIは問題を設計します…7 3.1. 一般議論…7 3.2. パフォーマンス/費用…9 3.3. 縁どっています。11 3.4. 高帯域、帯域幅集合…13 4. プロトコルの実装/複雑さの容易さ…14 5. 信頼性と有用性…15 5.1. データの汚染の検出…15 5.2. 回復…15 6. 相互運用性…16 6.1. インターネットインフラストラクチャ…16 6.2. SCSI…16 7. セキュリティ問題…18 7.1. 広げることができるセキュリティ…18 7.2. 認証…18 7.3. データの保全…19 7.4. データ秘密性…19 8. 管理…19 8.1. 命名します。20 8.2. 発見…21 9. インターネットのアクセシビリティ…21 9.1. サービス妨害…21 9.2. NATs、Firewalls、およびProxyサーバ…22 9.3. 輻輳制御と輸送選択…22 10. 定義…22 11. 参照…23 12. 承認…24 13. 作者のアドレス…25 14. 完全な著作権宣言文…26
1. Introduction
1. 序論
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 Storage WorkingグループはIPプロトコルの上でブロックストレージデータを輸送する展開している包括的な技術でチャーターされます。 この取り組みは、インターネット(iSCSI)の上でSmallコンピュータシステムズInterface(SCSI)プロトコルを輸送するためにプロトコルを含んでいます。 iSCSIプロトコルの初期のバージョンはIPネットワークにSCSIストレージコントローラ(主にディスク、テープ配列、およびライブラリ)を配属されることができるように、TCP/IPの上でSCSIトランスポート・プロトコルに関するマッピングを定義するでしょう、著しくGigabitイーサネット(GbE)と10Gigabitイーサネット(10GbE)。
Krueger, et al. Informational [Page 2] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[2ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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 SAM-2ドキュメントによって定義されるように「SCSI輸送」を構成します。[SAM2、p。 3 「トランスポート・プロトコル」].
2. Summary of Requirements
2. 要件の概要
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.
SHOULDは、少ない遅れコミュニケーションを可能にするためにコントロールオーバーヘッドを最小にします。
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タスクを扱う入出力アダプタを組立てるのにおいて可能でなければならなくなってください。
SHOULD permit direct data placement architectures.
SHOULDはダイレクトデータプレースメントアーキテクチャを可能にします。
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.4High Bandwidth/帯域幅Aggregationから:
MUST operate over a single TCP connection.
単独のTCP接続の上で作動しなければなりません。
SHOULD support 'connection binding', and it MUST be optional to
implement.
SHOULDは'接続結合'をサポートします、そして、それは、実装するために任意でなければなりません。
From section 4 Ease of Implementation/Complexity of Protocol:
プロトコルのImplementation/複雑さのセクション4Easeから:
SHOULD keep the protocol simple.
SHOULDはプロトコルを簡単に保ちます。
SHOULD minimize optional features.
SHOULDはオプション機能を最小にします。
Krueger, et al. Informational [Page 3] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[3ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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:
Data Corruptionのセクション5.1Detectionから:
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ヘッダーはSHOULDをフォーマットします。他のデータ保全ダイジェスト計算メソッドを含むのにおいて、広げることができてください。
From section 5.2 Recovery:
セクション5.2Recoveryから:
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は映された目標か非常に利用可能なストレージ構成のフェイルオーバー体系を考慮に入れます。
SHOULD provide a method for sessions to be gracefully terminated
and restarted that can be initiated by either the initiator or
target.
SHOULDはセッションが優雅に終えられて、再開されるどちらかで着手できるメソッドに創始者か目標を提供します。
From section 6 Interoperability:
セクション6Interoperabilityから:
iSCSI protocol document MUST be clear and unambiguous.
iSCSIプロトコルドキュメントは、明確であって、明白であるに違いありません。
From section 6.1 Internet Infrastructure:
セクション6.1インターネットInfrastructureから:
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.
必須: -- IPv4とIPv6の両方と互換性があってください--保守的にTCP接続を使用してください、TCPの多くの他のユーザが与えられたマシンの上にいるかもしれないのを覚えておいて。
MUST NOT require changes to existing Internet protocols.
既存のインターネットプロトコルへの変化を必要としてはいけません。
SHOULD minimize required changes to existing TCP/IP
implementations.
SHOULDは既存の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.
IPトランスポート・プロトコルとしてiSCSIプロトコル操作への最小量の変化、プロトコルデータ単位(PDU)構造、および形式でSCTP(TCPのための)の今後の代替を許すように設計しなければなりません。
Krueger, et al. Informational [Page 4] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[4ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
From section 6.2 SCSI:
セクション6.2SCSIから:
Any feature SAM2 requires in a valid transport mapping MUST be
specified by iSCSI.
iSCSIはSAM2が有効な輸送マッピングで必要とする特徴を指定しなければなりません。
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.
コマンド注文メカニズムSHOULDは輸送オフロードをする複数のアダプターの向こう側に必要なコミュニケーションの量を最小にしようとします。
MUST specify for each feature whether it is OPTIONAL, RECOMMENDED
or REQUIRED to implement and/or use.
それが道具、そして/または、使用へのOPTIONAL、RECOMMENDEDまたはREQUIREDであるかを各特徴に指定しなければなりません。
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.
SHOULDはSCSIとSCSI Architecture Modelへの変化を追います。
MUST be capable of supporting all SCSI-3 command sets and device
types.
すべてのSCSI-3コマンドセットと装置タイプをサポートすることができなければならなくなってください。
SHOULD support ACA implementation.
SHOULDは、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.1Extensible Securityから:
SHOULD require minimal configuration and overhead in the insecure
operation.
SHOULDは不安定な操作で最小量の構成とオーバーヘッドを必要とします。
MUST provide for strong authentication when increased security is
required.
増強されたセキュリティが必要であるときに、強い認証に備えなければなりません。
SHOULD allow integration of new security mechanisms without
breaking backwards compatible operation.
SHOULDは後方に互換性がある壊すことのない新しいセキュリティー対策の統合に操作を許します。
Krueger, et al. Informational [Page 5] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[5ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
From section 7.2 Authentication:
セクション7.2Authenticationから:
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).
SHOULD NOTは追加データ保全保護プロトコル(IPSec、TLS)の使用を排除します。
From section 7.4 Data Confidentiality:
セクション7.4Data Confidentialityから:
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などのaデータ暗号化プロトコルの使用に超能力を供給しなければなりません。
From section 8 Management:
セクション8Managementから:
SHOULD be manageable using standard IP-based management protocols.
SHOULD、標準の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.1Namingから:
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は人間が読み込み可能なストリングであったならコード化するのを用意ができている国際的な人物でSHOULDを命名します。
Standard Internet lookup services SHOULD be used to resolve iSCSI
names.
標準のインターネットルックアップはSHOULDを調整します。iSCSI名を決議するのが使用されます。
Krueger, et al. Informational [Page 6] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[6ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
SHOULD deal with the complications of the new SCSI security
architecture.
SHOULDは新しいSCSIセキュリティー体系の複雑さに対処します。
iSCSI naming architecture MUST address support of SCSI 3rd party
operations such as EXTENDED COPY.
アーキテクチャを命名するiSCSIはEXTENDED COPYなどのSCSI3番目のパーティー操作のサポートを扱わなければなりません。
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のプロトコル依存するテクニックSHOULD、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インターネットAccessabilityから。
SHOULD be scrutinized for denial of service issues and they should
be addressed.
SHOULD、サービス問題の否定のために精査されてください。そうすれば、それらは扱われるべきです。
From section 9.2 Firewalls and Proxy Servers
セクション9.2FirewallsとProxyサーバから
SHOULD allow deployment where functional and optimizing middle-
boxes such as firewalls, proxy servers and NATs are present.
SHOULDは機能的であるところで展開を許します、そして、ファイアウォールなどの中央箱を最適化して、プロキシサーバとNATsは存在しています。
use of IP addresses and TCP ports SHOULD be firewall friendly.
ファイアウォールが好意的であったなら、IPアドレスとTCPの使用はSHOULDを移植します。
From section 9.3 Congestion Control and Transport Selection
セクション9.3のCongestion ControlとTransport Selectionから
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実装は複数の接続を使用してはいけません。
3. iSCSI Design Considerations
3. iSCSIデザイン問題
3.1. General Discussion
3.1. 一般議論
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によってコンピュータに取り付けられました。
Krueger, et al. Informational [Page 7] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[7ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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は以下のtopologiesをサポートするでしょう:
-- 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
-- 二地点間ダイレクト接続--1つ以上のLANセグメントから成ります--伝統的なLANトラフィックとストレージトラフィックのミックスを運ぶ共有されたLAN--ひたむきなストレージLAN、LANからWANへのIPルータかキャリヤーで提供された「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
IP LAN WANルータは、IPストレージネットワークを広い領域にリモートディスクアクセス(ストレージユーティリティのような)を可能にして、同時の状態で広げるのにおいて中古であって、非同期なリモートミラーリングであって、リモートであるかもしれません。
Krueger, et al. Informational [Page 8] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[8ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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.
バックアップをとって、回復します(テープアーチのように)。 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) イーサネットストレージNICs、関連するドライバー、およびプロトコル・ソフトウエアの開発。 [注意: iSCSIの高速アプリケーションが必要なスループットを達成するためにハードウェアにおけるiSCSI/TCP/IPインプリメンテーションの重要な部分を必要とすると予想されます。] (3) コンパチブルストレージコントローラの進化。 (4) そして、イーサネットストレージネットワークとFibre Channel、そして/または、平行なバスSCSIドメインの間に接続性を提供する翻訳ゲートウェイのありそうな開発。 (5) iSCSIデバイス管理のためのMIBsやLDAPやXML schemasなどの仕様の開発 (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).
初めは、Gigabitイーサネット付属のために急速な移行と共に10GbEに製品を提供できました。 ハードウェアで完全なプロトコル・スタックの性能経路を実装するのは代替のSCSI輸送で競争の激しい性能に、必要になるでしょう。 これらの新しいストレージNICsは今日のSCSIとFibre Channel HBAsに類似の完全な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 Storage作業部会(IPSWG)の特許はさまざまなプラットホームで混雑が回避行動と広い実装であると立証した輸送を使用することでSCSIをIPに写像するという広い目標について説明します。その広い特許の中では、いくつかの輸送選択肢が考えられるかもしれません。 初期のIPS仕事はTCPに焦点を合わせます、そして、この要件ドキュメントは興味があるそのドメインに制限されます。
3.2. Performance/Cost
3.2. パフォーマンス/費用
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輸送(繊維Channel)と比べると、iSCSIプロトコルは費用競争力実装を可能にしなければなりません。
Krueger, et al. Informational [Page 9] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[9ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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プロトコルSHOULDはコントロールオーバーヘッドを最小にします。(それは、延着するように加えます)。
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タスクを扱う入出力アダプタを組立てるのを可能にしなければなりません、輸送実装がする代替のSCSIとして。 (2) プロトコルSHOULDはデータプレースメントをダイレクトに可能にします。(「無コピー」メモリアーキテクチャ、入出力アダプタがまさにディスクトランザクション(3) プロトコルに一度ホストにメモリを読み込むか、または書くところでSHOULD NOTは複雑な操作をホストソフトウェアに課します、代替手段に比例してホスト指示経路の長さを増強するどれ。
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データを示します。 向上した性能を許容して、ダイレクトデータプレースメントは終点システムにおけるメモリバスと入出力バス荷重をかなり抑えます。 それはことによるとこれらのソリューションのコストを削減して、NICsに必要であるメモリを減らします。
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、スイッチ)は持つことのように通常なるというわけではないでしょう。
Krueger, et al. Informational [Page 10] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[10ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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).
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つのセクションがさらにダイレクトデータプレースメントと高帯域の必要性について論じます。
3.3. Framing
3.3. 縁どり
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、環境高帯域の出現、高い潜在、低いビット誤り率物理的なメディアは巨大なよりもみ皮製の要件を物理インターフェースソリューションに置きます。
Krueger, et al. Informational [Page 11] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[11ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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.
まず最初に、ベンダーは、より高いデータ信号速度を達成するためにハードウェア解決へネットワーク・プロトコルを積み下ろすネットワーク処理ハードウェアを作り出します。 「無コピー」の概念は直接ワイヤに適切な記憶域(並べられる)にブロックのデータを保存しようとします、データがパケット損失のため再命令されると。 これが、10Gigabit/秒以降の実際のデータ信号速度を追い立てるのに必要です。
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アリーナに成功しているように可能でなければなりません、高い遅れネットワーク。 何百ミリセカンドへのも10における潜在があるマルチギガビットIPネットワークの出現は挑戦を提示します。 そのような大きいパイプをいっぱいにするために、アプリケーションからの傑出している要求の10メガバイトを持つのが必要です。 さらに、いくつかのプロトコルが、故障していた状態でデータの再アセンブリのためのパケットが受け取られているときのバッファリングに対処するためにトランスポート層で潜在的に10メガバイトを必要とします。
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.
10Gbps x200msecにおけるネットワークパイプが250MBを保持すると考えてください。 [スポットハーフウェイが世界中であることの状態で赤道で陸のベースのコミュニケーションを仮定してください。 ケーブルルーティングのため追加距離を無視してください。 リピータと切り換え遅れを無視してください。 唯一の光速が5マイクロセカンド/kmの遅れであると考えてください。 赤道における地球の円周はおよそ40000km(パイプを完全に保つと往復の遅れを考えなければならない)です。 10 5マイクロセカンド/kmの40000kmのGb/秒xのx x B/8bは250MBと等しいです。]. 従来のTCP実装では、TCPセグメントの損失は、そのセグメント(少なくとも達成する<ネットワークの丸い旅行>の時かかる)が回復されるまでストリーム処理が止まらなければならないことを意味します。 上記の例に倣っていて、ストリーム処理を再開する前に実装が匿名のバッファの中に250MBのデータを捕らえるのが強いられるでしょう。 その後、このデータは、適切な位置に動かされる必要があるでしょう。 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プロトコル影響両方の「連結の必要性」と「加速している処理の必要性」の縁どり、しかしながら、ヘッダーに長さを含んでいるのが「連結の必要性」に十分であるかもしれない間、それはダイレクトデータプレースメントの必要性に役立たないでしょう。 開発された縁どりメカニズムはパケットが受信データストリームで一時なくなる場合でさえパケット境界の再同期を許容するはずです。
Krueger, et al. Informational [Page 12] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[12ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
3.4. High bandwidth, bandwidth aggregation
3.4. 高帯域、帯域幅集合
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コマンドの列を作りをする能力を主張するでしょう。 ドキュメントは便宜のための「接続結合」とこのテクニックを呼ぶでしょう。
Krueger, et al. Informational [Page 13] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[13ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
The iSCSI protocol SHOULD support connection binding, and it MUST be optional to implement.
iSCSIプロトコルSHOULDは接続に結合をサポートします、そして、それは、実装するために任意でなければなりません。
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つの輸送接続しかなかったケースを支えなければならないので、プロトコルで、コマンド、データ、および状態は同じ接続の上を移動しなければなりません。
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.
手広く議論した代替のアプローチは、異なった接続の単独結合におけるすべてのコマンド、関連データ、および状態(非対称のアプローチ)を送ることを伴いました。 この体系では、輸送は、コマンドが整然とした状態で到着するのを確実にします。 恐らくハードウェアにおける、より簡単な実現に適していて、データと状態接続でのプロトコルは、より簡単です。 このアプローチの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メーリングリストの参照がそうするかもしれません。
4. Ease of implementation/complexity of protocol
4. プロトコルの実装/複雑さの容易さ
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 SHOULDのデザイナーが、作成の要件を実現させるように努力することにおける問題を診断するのが簡単であれば簡単であるほど、できるだけ簡単にプロトコルを保っている間のIPの上のSCSI輸送は、より簡単です。
Krueger, et al. Informational [Page 14] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[14ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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 SHOULDはオプション機能を最小にします。 特徴が必要であると考えられるとき、プロトコルはセッション設立で特徴交渉を指定しなければなりません(ログインしてください)。 オプション機能が全く個人の選択交渉が失敗している時と同様に交渉されないとき、iSCSI輸送は正しく作動しなければなりません。
5. Reliability and Availability
5. 信頼性と有用性
5.1. Detection of Data Corruption
5.1. データの汚染の検出
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ヘッダーは読みこなします、ヘッダー(アドレス)の不変な部分への1、異形部分への1つは中央箱(eg、アドレス)によって決して変えられるべきでないヘッダーの一部への変化に対する保護を提供するでしょう。
The iSCSI header format SHOULD be extensible to include other digest calculation methods.
iSCSIヘッダーはSHOULDをフォーマットします。他のダイジェスト計算メソッドを含むのにおいて、広げることができてください。
5.2. Recovery
5.2. 回復
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プロトコルデザインは簡単さを強調している間、創始者、目標、または接続ネットワークインフラ(ケーブリング、ルータなどのデータ経路設備など)の失敗からのタイムリーな回復につながらなければなりません。
Krueger, et al. Informational [Page 15] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[15ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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プロトコル誤りは複数の「ストレージサーバ」を通してデータを狙うために経路を提供する映された目標か非常に利用可能なストレージ構成のためにSHOULDがアカウントフェイルオーバー体系を連れていくメカニズムを回収します。 これは高い有用性とクラスタリングのような層にされた技術の基礎を提供するでしょう。
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プロトコルSHOULDはセッションが優雅に終えられて、再開されるどちらかで着手できるメソッドに創始者か目標を提供します。 これが優雅に能力を提供する、フェイルオーバー、創始者、目標、またはメインテナンスがソフトウェアをアップグレードさせるのなどように仕事を課すリセットa目標後実行。
6. Interoperability
6. 相互運用性
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プロトコルドキュメントは、明確であって、明白であるに違いありません。
6.1. Internet infrastructure
6.1. インターネット基盤
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プロトコルは既存のインターネットプロトコルへの変化を必要としてはいけません、そして、SHOULDは既存の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.
IPトランスポート・プロトコルとしてiSCSIプロトコル操作への最小量の変化、プロトコルデータ単位(PDU)構造、および形式でSCTP(TCPのための)の今後の代替を許すようにiSCSIを設計しなければなりません。 今日広く実装されませんが、SCTPには、それを今後のiSCSI増進のための望ましい選択にする多くの設計上の特徴があります。
6.2. SCSI
6.2. SCSI
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
SCSI輸送であると考えられて、iSCSI規格はSCSI輸送のためにSCSI Architecture Model[SAM-2]の要件に従わなければなりません。 iSCSIはSAM2が有効な輸送マッピングで必要とする特徴を指定しなければなりません。 iSCSIプロトコルドキュメントはそうしなければなりません。
Krueger, et al. Informational [Page 16] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[16ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
specify for each feature whether it is OPTIONAL, RECOMMENDED or REQUIRED to implement and/or use.
それが道具、そして/または、使用へのOPTIONAL、RECOMMENDEDまたはREQUIREDであるか各特徴に指定してください。
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 Architectural Model[SAM-2]は創始者目標-LUN粒状でコマンドを注文するSCSI輸送が提供する期待を示します。 この注文を確実にする手段に関してIPS反射鏡とワーキンググループミーティングにおける多くの議論がありました。 荒いコンセンサスはiSCSIが創始者/目標組の間のiSCSIセッションの間のSCSIコマンドの厳密に命令された配送を指定しなければならないということです、輸送誤りがあるときさえ。 このコマンド注文メカニズムSHOULDは輸送オフロードをする複数のアダプターの向こう側に必要なコミュニケーションの量を最小にしようとします。 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の両方との相互作用を必要とします。 しかしながら、SCSI仕様が「輸送に依存する」野原と振舞いを示すところ以外に、iSCSIプロトコルはSCSI-3コマンドセットとSCSIクライアントコードへの変化を必要としてはいけません。 例えば、SCSIドキュメントへの変化は、より長いiSCSI目標名と潜在的により長いタイムアウトを反映するために必要になるでしょう。 T10との共同は、この要件を達成するために必要になるでしょう。
The iSCSI protocol SHOULD track changes to SCSI and the SCSI Architecture Model.
iSCSIはSCSIとSCSI Architecture ModelへのSHOULD道の変化について議定書の中で述べます。
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デバイスのすべてのnatively implementableであるに違いないことを意味するためにこれらの要件を解釈してはいけません。デバイスは処理能力かメモリを制限したかもしれません。
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(自動Contingent Allegiance)はそれらの1つが失敗すると依存するSCSIコマンドの系列の実行を止める任意のSCSIメカニズムです。 それを囲む状況は複雑です--T10がSAM2でACAを指定して、したがって、iSCSIは、それをサポートして、Proposed StandardからDraft Standardまでの変遷でACAを下げるのを避けることができるくらい(2つの独立している共同利用できる実装)ACAが実装されるのを確実にするよう努力しなければなりません。 これは、iSCSI SHOULDが、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"
iSCSIプロトコルは他のSCSI輸送へのゲートウェイの建設を考慮しなければなりません、[SPI-X]とSCSI FCP[FCP、FCP-2]に平行なSCSIを含めて。 「翻訳」を組み立てるのは可能であるに違いありません。
Krueger, et al. Informational [Page 17] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[17ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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-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コマンドを確かに輸送しなければなりません。 according to[SAM-2、p。 17.] 「サービス配送サブシステムの機能は送付者と受信機の間の要求か応答のエラーのないコピーを輸送することです」[SAM-2、p。 22]. iSCSIプロトコルは正しくiSCSIパケット滴、複製、不正、聞き古したパケット、および再注文に対処しなければなりません。
7. Security Considerations
7. セキュリティ問題
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)を輸送すると、さまざまな悪意ある攻撃の真新しい機会は開きます。 攻撃が能動態を取ることができる、(アイデンティティスプーフィング、中の男性、-、-、中央) または、受動形(盗聴)。
7.1. Extensible Security
7.1. 広げることができるセキュリティ
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セットにセキュリティ機能を要求するまた、イントラネットとして知られているVirtual兵士のNetworks(VPN)をセットアップしています。 iSCSIプロトコルは異なった安全保障政策を使うかもしれないさまざまなインターネット作業環境に適切です。増強されたセキュリティが必要であるときに、iSCSIは強い認証に備えなければなりません。 後方にコンパチブル操作を壊さないで、プロトコルSHOULDは不安定な操作で最小量の構成とオーバーヘッドを必要として、新しいセキュリティー対策の統合を許容します。
7.2. Authentication
7.2. 認証
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プロトコルは個人的な認証されたログインをサポートしなければなりません。
Krueger, et al. Informational [Page 18] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[18ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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などの標準のインターネットプロトコルを使用することで満たされるべきです。 終点は任意になにもに認証方法を交渉するかもしれません。
7.3. Data Integrity
7.3. データの保全
The iSCSI protocol SHOULD NOT preclude use of additional data integrity protection protocols (IPSec, TLS).
iSCSIプロトコルSHOULD NOTは追加データ保全保護プロトコル(IPSec、TLS)の使用を排除します。
7.4. Data Confidentiality
7.4. データの機密性
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などのデータ暗号化プロトコルの使用に超能力を供給しなければなりません。
8. Management
8. 管理
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
iSCSI実装SHOULD、標準のIPベースの管理プロトコルを使用することで、処理しやすくいてください。 しかしながら、iSCSIプロトコルドキュメントはiSCSIのためにネットワークインフラの中で管理体系を定義してはいけません。iSCSIはネットワーク資源(プリンタ、ファイルサーバー、NAS、アプリケーション・サーバーなど)の複雑な環境の中でさらに別リソースサービスになるでしょう。 確かに、iSCSIデバイスが提供する「ブロックストレージサービス」がどう包括的で、共有されたモデルと統合されるかを設計する取り組みがあるでしょう、ネットワークマネージメント
Krueger, et al. Informational [Page 19] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[19ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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デバイスはこれらの統合ネットワークマネージメントアプリケーションと対話したくなるでしょう。 iSCSIプロトコルドキュメントは、そのセットの問題を解決するか、またはデバイスが管理エージェントを提供する手段を指定するのを試みないでしょう。 事実上、MIBsかiSCSIプロトコルにおける明白な参照が記録するようにiSCSIデバイスを管理するいかなる他の手段の言及も全くあるべきではありません、管理データとプロトコルが環境の必要性と管理アプリケーションのビジネスモデルを交換するので。
8.1. Naming
8.1. 命名
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リソースが見つけられている手段は、既存のインターネット標準リソース位置のメソッドを使用しなければならないか、または広げなければなりません。 RFC2348[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は人間が読み込み可能なストリングであったならコード化するのを用意ができている国際的な人物でSHOULDを命名します。
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.
標準のインターネットルックアップはSHOULDを調整します。名前を決議するのが使用されます。 例えば、Domain Name Services(DNS)は、1つのURLの<ホスト名>部分を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-245 r9]と対話しなければなりません。 新しい機密保護モデルによって定義されたアーキテクチャを命名するプロキシに特別の注意を向けなければなりません。 この新しいモデルで、Access IDはホストを特定します、そして、ユニークなLU地図を各AccessIDに与える方法でSCSI Logical Unit民数記(LUNs)を写像できます。 したがって、目標の中の与えられたLUは異なったLUNsによって扱われるかもしれません。
Krueger, et al. Informational [Page 20] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[20ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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などのSCSI3番目のパーティー操作のサポートを扱わなければなりません。 ここの主要な問題はSCSI LUsのための命名アーキテクチャに関連します--iSCSIは名前かハンドルをパーティーの間に渡す手段を提供しなければなりません。iSCSIはXCOPYコマンドに使用できた名前かハンドルを提供する手段を指定して、そのコマンドで割り当てられた利用可能なスペースの中で合わなければなりません。 そして、それが可能であるに違いない、もちろん、XCOPYが正しい目標とLUへの名前を反-参照に狙うので(第三者)。
8.2. Discovery
8.2. 発見
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のプロトコル依存するテクニックSHOULD、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プロトコルは発見のメソッドを提供しなければなりません、ウェルノウンポートに関するIPエンドポイントを考えて、要請者にとって、利用可能なSCSI目標のリスト。 この発見サービスの使用は任意であるに違いありません。
Further discovery guidelines are outside the scope of this document and may be addressed in separate Informational documents.
さらなる発見ガイドラインは、このドキュメントの範囲の外にあって、別々のInformationalドキュメントで扱われるかもしれません。
9. Internet Accessibility
9. インターネットのアクセシビリティ
9.1. Denial of Service
9.1. サービス妨害
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の全面はサービス問題の潜在的否定のために精査されて、できるだけ用心されたSHOULDについて議定書の中で述べます。
Krueger, et al. Informational [Page 21] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[21ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
9.2. NATs, Firewalls and Proxy servers
9.2. NATs、Firewalls、およびProxyサーバ
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(ネットワークAddress Translator)、ファイアウォール、およびプロキシサーバは今日のインターネットの現実のものです。 これらのデバイスはiSCSIのために開発されるデバイスアクセス法への多くの挑戦を提示します。 例えば、創始者は直接とiSCSIプロキシサーバかNATを通してiSCSIリソース接続のためのURL構文を指定するのにiSCSI対象装置を扱うことができます。iSCSI SHOULDは機能的であるところで展開を許します、そして、ファイアウォールなどの中央箱を最適化して、プロキシサーバとNATsは存在しています。
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)襲撃に対してネットワークのそれほど信じられなかった領域から防御する可能な手段を提供するためにファイアウォールを通して作動するのは、重要です。 ファイアウォールにはにせの接続要求を捨てるためのはるかに大きい処理能力がノードを終わらせるよりあると思われます。
9.3. Congestion Control and Transport Selection
9.3. 輻輳制御と輸送選択
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実装は複数の接続を使用してはいけません。
10. Definitions
10. 定義
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コマンドを実行する目標居住者実体[SAM2、秒 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、秒 3.1.52、p。 7].
Krueger, et al. Informational [Page 22] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[22ページ]のRFC3347iSCSI要件とデザイン問題2002年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].
以下を狙ってください。 実行のためにSCSIコマンドを受け取って、1個以上の論理装置にそれを向けるSCSIデバイス[SAM-2秒 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].
トランザクション: もう片方を代表した1個のオブジェクトによる2個のオブジェクトの間の会話、情報交換にかかわるか、または何らかのサービスの実行[SAM-2、秒 3.1.109、p。 10].
11. References
11. 参照
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
1. ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
2. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
2. ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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. [サム-2]ANSI NCITS。 ウェーバー、ラルフO.、エディタ。 SCSIアーキテクチャモデル-2(SAM-2)。 T10は1157D.の回転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は1236D.の回転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.は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-245 r8] ハーフナー、ジム。 アクセスのための詳細な提案は制御されます。 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]。
Krueger, et al. Informational [Page 23] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[23ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
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.Endから終わりへのインターネットパケット力学、Networking7、3(1999年6月)pg277-292の上のIEEE Transactions。
11. Stone J., Partridge, C. When the CRC and TCP checksum disagree,
ACM Sigcomm (Sept. 2000).
11. ACM Sigcomm、ストーンJ.、Partridge、C.When CRC、およびTCPチェックサムは意見を異にします(2000年9月)。
12. Malkin, G. and A. Harkin, "TFTP Blocksize Option", RFC 2348, May
1998.
12. マルキン、G.、およびA.ハーキン(「TFTP Blocksizeオプション」、RFC2348)は1998がそうするかもしれません。
13. Floyd, S., "Congestion Control Principles", BCP 14, RFC 2914,
September 2000.
13. フロイド、S.、「輻輳制御プリンシプルズ」、BCP14、RFC2914、2000年9月。
12. Acknowledgements
12. 承認
Special thanks to Julian Satran, IBM and David Black, EMC for their extensive review comments.
ジュリアンSatran、IBM、およびデヴィッドBlackのおかげで特別であることで、彼らの大量のレビューのためのEMCはコメントします。
Krueger, et al. Informational [Page 24] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[24ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
13. Author's Addresses
13. 作者のアドレス
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
Blvdローズビル、マージョリークルーガーヒューレット・パッカード社8000のフットヒルズカリフォルニア95747-5668(米国)は以下に電話をします。 +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
Blvdローズビル、ランディHaagensヒューレット・パッカード社8000のフットヒルズカリフォルニア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
コスタSapuntzakisスタンフォード大学353セラMall博士#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
バッキーシスコシステムズInc.6450がウェッジウッド道路メープル・グローヴ、Mn55311電話であるとマークしてください: +1 763 398-1054 メールしてください: mbakke@cisco.com
Krueger, et al. Informational [Page 25] RFC 3347 iSCSI Requirements and Design Considerations July 2002
クルーガー、他 情報[25ページ]のRFC3347iSCSI要件とデザイン問題2002年7月
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Krueger, et al. Informational [Page 26]
クルーガー、他 情報[26ページ]
一覧
スポンサーリンク
