Internet Engineering Task Force (IETF) C. Hellwig, Ed.
Request for Comments: 9561
Category: Standards Track C. Lever
ISSN: 2070-1721 Oracle
S. Faibish
Opendrives.com
D. Black
Dell Technologies
April 2024
This document specifies how to use the Parallel Network File System (pNFS) Small Computer System Interface (SCSI) Layout Type to access storage devices using the Non-Volatile Memory Express (NVMe) protocol family.
このドキュメントは、Parallel Network File System（PNFS）Small Computer System Interface（SCSI）レイアウトタイプを使用して、不揮発性メモリExpress（NVME）プロトコルファミリを使用してストレージデバイスにアクセスする方法を指定しています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9561.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9561で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
1.2. General Definitions
1.3. Numerical Conventions
2. SCSI Layout Mapping to NVMe
2.1. Volume Identification
2.2. Client Fencing
2.2.1. PRs - Key Registration
2.2.2. PRs - MDS Registration and Reservation
2.2.3. Fencing Action
2.2.4. Client Recovery after a Fence Action
2.3. Volatile Write Caches
3. Security Considerations
4. IANA Considerations
5. References
5.1. Normative References
5.2. Informative References
Acknowledgements
Authors' Addresses
NFSv4.1 [RFC8881] includes a pNFS feature that allows reads and writes to be performed by means other than directing read and write operations to the server. Through use of this feature, the server, in the role of metadata server, is responsible for managing file and directory metadata while separate means are provided to execute reads and writes.
NFSV4.1 [RFC8881]には、読み取りと書き込み操作をサーバーに向ける以外の手段で読み取りおよび書き込みを実行できるPNFS機能が含まれています。この機能を使用して、メタデータサーバーの役割でサーバーはファイルとディレクトリメタデータの管理を担当し、読み取りと書き込みを実行するための別々の手段が提供されます。
These other means of performing file reads and writes are defined by individual mapping types, which often have their own specifications.
ファイル読み取りと書き込みを実行するこれらの他の手段は、個々のマッピングタイプによって定義されます。
The pNFS Small Computer System Interface (SCSI) layout [RFC8154] is a layout type that allows NFS clients to directly perform I/O to block storage devices while bypassing the Metadata Server (MDS). It is specified by using concepts from the SCSI protocol family for the data path to the storage devices.
PNFS Small Computer System Interface（SCSI）レイアウト[RFC8154]は、NFSクライアントがメタデータサーバー（MDS）をバイパスしながらI/Oを直接実行できるようにストレージデバイスを直接実行できるレイアウトタイプです。ストレージデバイスへのデータパスについて、SCSIプロトコルファミリーの概念を使用して指定されています。
NVM Express (NVMe), or the Non-Volatile Memory Host Controller Interface Specification, is a set of specifications to talk to storage devices over a number of protocols such as PCI Express (PCIe), Fibre Channel (FC), TCP/IP, or Remote Direct Memory Access (RDMA) networking. NVMe is currently the predominantly used protocol to access PCIe Solid State Disks (SSDs), and it is increasingly being adopted for remote storage access to replace SCSI-based protocols such as iSCSI.
NVM Express（NVME）、または不揮発性メモリホストコントローラーインターフェイス仕様は、PCI Express（PCIE）、Fiber Channel（FC）、TCP/IPなどの多くのプロトコルを介してストレージデバイスと通信するための仕様のセットです。またはリモートダイレクトメモリアクセス（RDMA）ネットワーク。NVMEは現在、PCIEソリッドステートディスク（SSD）にアクセスするために主に使用されているプロトコルであり、ISCSIなどのSCSIベースのプロトコルを置き換えるリモートストレージアクセスにますます採用されています。
This document defines how NVMe Namespaces using the NVM Command Set [NVME-NVM] exported by NVMe Controllers implementing the NVMe Base specification [NVME-BASE] are to be used as storage devices using the SCSI Layout Type. The definition is independent of the underlying transport used by the NVMe Controller and thus supports Controllers implementing a wide variety of transports, including PCIe, RDMA, TCP, and FC.
このドキュメントでは、NVMEベース仕様[NVMEベース]を実装するNVMEコントローラーによってエクスポートされるNVMコマンドセット[NVME-NVM]を使用してNVMEネームスペースをSCSIレイアウトタイプを使用してストレージデバイスとして使用する方法を定義します。この定義は、NVMEコントローラーが使用する基礎となる輸送とは独立しているため、PCIE、RDMA、TCP、FCなど、さまざまなトランスポートを実装するコントローラーをサポートしています。
This document does not amend the existing SCSI layout document. Rather, it defines how NVMe Namespaces can be used within the SCSI Layout by establishing a mapping of the SCSI constructs used in the SCSI layout document to corresponding NVMe constructs.
このドキュメントは、既存のSCSIレイアウトドキュメントを修正しません。むしろ、SCSIレイアウトドキュメントで使用されるSCSIコンストラクトのマッピングを対応するNVMEコンストラクトにマッピングすることにより、SCSIレイアウト内でNVME名前空間を使用する方法を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following definitions are included to provide context for the reader.
読者にコンテキストを提供するために、次の定義が含まれています。
Client:
クライアント:
The "client" is the entity that accesses the NFS server's resources. The client may be an application that contains the logic to access the NFS server directly, or it may be part of the operating system that provides remote file system services for a set of applications.
「クライアント」は、NFSサーバーのリソースにアクセスするエンティティです。クライアントは、NFSサーバーに直接アクセスするロジックを含むアプリケーションである場合があります。または、アプリケーションのセットにリモートファイルシステムサービスを提供するオペレーティングシステムの一部である場合があります。
Metadata Server (MDS):
メタデータサーバー（MDS）：
The Metadata Server (MDS) is the entity responsible for coordinating client access to a set of file systems and is identified by a server owner.
Metadata Server（MDS）は、ファイルシステムのセットへのクライアントアクセスの調整を担当するエンティティであり、サーバーの所有者によって識別されます。
Numerical values defined in the SCSI specifications (e.g., [SPC5]) and the NVMe specifications (e.g., [NVME-BASE]) are represented using the same conventions as those specifications wherein a 'b' suffix denotes a binary (base 2) number (e.g., 110b = 6 decimal) and an 'h' suffix denotes a hexadecimal (base 16) number (e.g., 1ch = 28 decimal).
SCSI仕様（[SPC5]など）およびNVME仕様（[NVME-Base]など）で定義されている数値値は、「B」接尾辞がバイナリ（ベース2）数を示す仕様と同じ規則を使用して表されます。（例えば、110b = 6小数）および 'h'接尾辞は、16進数（ベース16）数（例：1ch = 28小数）を示します。
The SCSI layout definition [RFC8154] references only a few SCSI-specific concepts directly. This document provides a mapping from these SCSI concepts to NVM Express concepts that are used when using the pNFS SCSI layout with NVMe namespaces.
SCSIレイアウト定義[RFC8154]は、SCSI固有の概念を直接参照しています。このドキュメントは、これらのSCSIコンセプトからNVMの名前空間でPNFS SCSIレイアウトを使用するときに使用されるNVM Expressコンセプトへのマッピングを提供します。
The pNFS SCSI layout uses the Device Identification Vital Product Data (VPD) page (page code 83h) from [SPC5] to identify the devices used by a layout. Implementations that use NVMe namespaces as storage devices map NVMe namespace identifiers to a subset of the identifiers that the Device Identification VPD page supports for SCSI logical units.
PNFS SCSIレイアウトは、[SPC5]のデバイス識別Vital製品データ（VPD）ページ（ページコード83H）を使用して、レイアウトで使用されるデバイスを識別します。nvmeネームスペースをストレージデバイスとして使用する実装は、nvmeネームスペース識別子をマッピングして、デバイス識別VPDページがSCSI論理ユニットにサポートする識別子のサブセットにマッピングします。
To be used as storage devices for the pNFS SCSI layout, NVMe namespaces MUST support either the IEEE Extended Unique Identifier (EUI64) or Namespace Globally Unique Identifier (NGUID) value reported in a Namespace Identification Descriptor, the I/O Command Set Independent Identify Namespace data structure, and the Identify Namespace data structure, NVM Command Set [NVME-BASE]. If available, use of the NGUID value is preferred as it is the larger identifier.
PNFS SCSIレイアウトのストレージデバイスとして使用するには、nvmeネームスペースは、IEEE拡張ユニークな識別子（EUI64）または名前空間識別記述書で報告されているグローバルに一意の識別子（NGUID）値、I/Oコマンドセットの識別識別識別識別識別識別記述子のいずれかをサポートする必要があります。データ構造、および名前空間データ構造の識別、NVMコマンドセット[NVME-Base]。利用可能な場合は、NGUID値の使用がより大きな識別子であるため優先されます。
Note: The PS_DESIGNATOR_T10 and PS_DESIGNATOR_NAME have no equivalent in NVMe and cannot be used to identify NVMe storage devices.
注：ps_designator_t10およびps_designator_nameは、nvmeでは同等のものではなく、nvmeストレージデバイスの識別に使用することはできません。
The pnfs_scsi_base_volume_info4 structure for an NVMe namespace SHALL be constructed as follows:
NVMEネームスペースのPNFS_SCSI_VOLUME_INFO4構造は、次のように構築するものとします。
1. The "sbv_code_set" field SHALL be set to PS_CODE_SET_BINARY.
1. 「sbv_code_set」フィールドは、ps_code_set_binaryに設定するものとします。
2. The "pnfs_scsi_designator_type" field SHALL be set to PS_DESIGNATOR_EUI64.
2. 「pnfs_scsi_designator_type」フィールドは、ps_designator_eui64に設定する必要があります。
3. The "sbv_designator" field SHALL contain either the NGUID or the EUI64 identifier for the namespace. If both NGUID and EUI64 identifiers are available, then the NGUID identifier SHOULD be used as it is the larger identifier.
3. 「sbv_designator」フィールドには、名前空間のnguidまたはeui64識別子のいずれかが含まれます。NGUIDとEUI64の両方の識別子が利用可能な場合、より大きな識別子であるため、NGUID識別子を使用する必要があります。
RFC 8154 [RFC8154] specifies the "sbv_designator" field as an XDR variable length opaque<> (refer to Section 4.10 of RFC 4506 [RFC4506]). The length of that XDR opaque<> value (part of its XDR representation) indicates which NVMe identifier is present. That length MUST be 16 octets for an NVMe NGUID identifier and MUST be 8 octets for an NVMe EUI64 identifier. All other lengths MUST NOT be used with an NVMe namespace.
RFC 8154 [RFC8154]は、「SBV_Designator」フィールドをXDR変数長さの不透明<>として指定します（RFC 4506 [RFC4506]のセクション4.10を参照）。そのXDR Opaque <>値（XDR表現の一部）の長さは、どのNVME識別子が存在するかを示します。その長さは、NVME NGUID識別子の16オクテットでなければならず、NVME EUI64識別子の場合は8オクテットでなければなりません。他のすべての長さは、NVMEネームスペースで使用してはなりません。
The SCSI layout uses Persistent Reservations (PRs) to provide client fencing. For this to be achieved, both the MDS and the Clients have to register a key with the storage device, and the MDS has to create a reservation on the storage device.
SCSIレイアウトは、永続的な予約（PRS）を使用してクライアントフェンシングを提供します。これを達成するためには、MDSとクライアントの両方がストレージデバイスにキーを登録する必要があり、MDSはストレージデバイスに予約を作成する必要があります。
The following subsections provide a full mapping of the required PERSISTENT RESERVE IN and PERSISTENT RESERVE OUT SCSI commands [SPC5] to NVMe commands that MUST be used when using NVMe namespaces as storage devices for the pNFS SCSI layout.
以下のサブセクションは、PNFS SCSIレイアウトのストレージデバイスとしてNVME名空間を使用する場合に使用する必要があるNVMEコマンドに必要な永続的な予備の完全なマッピングと永続的な予備のSCSIコマンド[SPC5]をNVMEコマンドに提供します。
On NVMe namespaces, reservation keys are registered using the Reservation Register command (refer to Section 7.3 of [NVME-BASE]) with the Reservation Register Action (RREGA) field set to 000b (i.e., Register Reservation Key) and supplying the reservation key in the New Reservation Key (NRKEY) field.
NVME名空間では、予約キーは、予約登録登録登録簿（[NVMEベース]のセクション7.3を参照）を使用して登録されます。新しい予約キー（NRKEY）フィールド。
Reservation keys are unregistered using the Reservation Register command with the Reservation Register Action (RREGA) field set to 001b (i.e., Unregister Reservation Key) and supplying the reservation key in the Current Reservation Key (CRKEY) field.
予約キーは、予約レジスタアクション（REGA）フィールドを001B（つまり、Unregister Reservation Key）に設定し、現在の予約キー（CRKEY）フィールドに予約キーを提供することを使用して、登録されていません。
One important difference between SCSI Persistent Reservations and NVMe Reservations is that NVMe reservation keys always apply to all controllers used by a host (as indicated by the NVMe Host Identifier). This behavior is analogous to setting the ALL_TG_PT bit when registering a SCSI Reservation Key, and it is always supported by NVMe Reservations, unlike the ALL_TG_PT for which SCSI support is inconsistent and cannot be relied upon. Registering a reservation key with a namespace creates an association between a host and a namespace. A host that is a registrant of a namespace may use any controller with which that host is associated (i.e., that has the same Host Identifier, refer to Section 5.27.1.25 of [NVME-BASE]) to access that namespace as a registrant.
SCSIの永続的な予約とNVME予約の1つの重要な違いは、NVME予約キーが常にホストが使用するすべてのコントローラーに適用されることです（NVMEホスト識別子が示すように）。この動作は、SCSI予約キーを登録するときにALL_TG_PTビットを設定することに類似しており、SCSIサポートが一貫性がなく、依存することができないALL_TG_PTとは異なり、NVME予約によって常にサポートされています。名前空間で予約キーを登録すると、ホストと名前空間の間に関連性が生まれます。名前空間の登録者であるホストは、そのホストが関連付けられている任意のコントローラー（つまり、同じホスト識別子を持つ、[nvme-base]のセクション5.27.1.25を参照）を使用して、その名前空間に登録者としてアクセスできます。
Before returning a PNFS_SCSI_VOLUME_BASE volume to the client, the MDS needs to prepare the volume for fencing using PRs. This is done by registering the reservation generated for the MDS with the device (see Section 2.2.1) followed by a Reservation Acquire command (refer to Section 7.2 of [NVME-BASE]) with the Reservation Acquire Action (RACQA) field set to 000b (i.e., Acquire) and the Reservation Type (RTYPE) field set to 4h (i.e., Exclusive Access - Registrants Only Reservation).
PNFS_SCSI_VOLUME_BASEボリュームをクライアントに返す前に、MDSはPRSを使用してフェンシングのボリュームを準備する必要があります。これは、MDS用に生成された予約をデバイス（セクション2.2.1を参照）に登録し、続いて予約獲得コマンド（[nvme-base]のセクション7.2を参照）を登録します。000B（つまり、取得）と予約タイプ（RTYPE）フィールドは4H（つまり、排他的アクセス - 登録者のみ）に設定されています。
In case of a non-responding client, the MDS fences the client by executing a Reservation Acquire command (refer to Section 7.2 of [NVME-BASE]), with the Reservation Acquire Action (RACQA) field set to 001b (i.e., Preempt) or 010b (i.e., Preempt and Abort), the Current Reservation Key (CRKEY) field set to the server's reservation key, the Preempt Reservation Key (PRKEY) field set to the reservation key associated with the non-responding client, and the Reservation Type (RTYPE) field set to 4h (i.e., Exclusive Access - Registrants Only Reservation). The client can distinguish I/O errors due to fencing from other errors based on the Reservation Conflict NVMe status code.
非応答クライアントの場合、MDSは予約獲得コマンド（[nvme-base]のセクション7.2を参照）を実行することでクライアントにフェンスを獲得します。または010B（つまり、先制および中止）、サーバーの予約キーに設定された現在の予約キー（CRKEY）フィールド、非応答クライアントに関連付けられた予約キーに設定されたプリエンプトリザベーションキー（PRKEY）フィールド、および予約タイプ（RTYPE）フィールドは4Hに設定されています（つまり、排他的アクセス - 登録者のみ予約）。クライアントは、予約競合NVMEステータスコードに基づいて、他のエラーとフェンシングのためにI/Oエラーを区別できます。
If an NVMe command issued by the client to the storage device returns a non-retryable error (refer to the DNR bit defined in Figure 92 in [NVME-BASE]), the client MUST commit all layouts that use the storage device through the MDS, return all outstanding layouts for the device, forget the device ID, and unregister the reservation key.
クライアントがストレージデバイスに発行したNVMEコマンドが再び回復不可能なエラーを返した場合（[NVME-Base]の図92で定義されているDNRビットを参照）、クライアントはMDSを介してストレージデバイスを使用するすべてのレイアウトをコミットする必要があります。、デバイスのすべての未解決のレイアウトを返し、デバイスIDを忘れて、予約キーの登録を解除します。
For NVMe controllers, a volatile write cache is enabled if bit 0 of the Volatile Write Cache (VWC) field in the Identify Controller data structure, I/O Command Set Independent (refer to Figure 275 in [NVME-BASE]) is set and the Volatile Write Cache Enable (WCE) bit (i.e., bit 00) in the Volatile Write Cache Feature (Feature Identifier 06h) (refer to Section 5.27.1.4 of [NVME-BASE]) is set. If a volatile write cache is enabled on an NVMe namespace used as a storage device for the pNFS SCSI layout, the pNFS server (MDS) MUST use the NVMe Flush command to flush the volatile write cache to stable storage before the LAYOUTCOMMIT operation returns by using the Flush command (refer to Section 7.1 of [NVME-BASE]). The NVMe Flush command is the equivalent to the SCSI SYNCHRONIZE CACHE commands.
NVMEコントローラーの場合、識別コントローラーデータ構造の揮発性書き込みキャッシュ（VWC）フィールドのビット0が独立している場合、揮発性書き込みキャッシュが有効になります。揮発性書き込みキャッシュ機能（つまり、ビット00）の揮発性書き込みキャッシュ機能（機能識別子06H）のビット（ビット00）ビット（ビット00）ビット（[NVMEベース]のセクション5.27.1.4を参照）が設定されています。PNFS SCSIレイアウトのストレージデバイスとして使用されるNVME名前空間で揮発性書き込みキャッシュが有効になっている場合、PNFSサーバー（MDS）は、レイアウトコマット操作の前に揮発性書き込みキャッシュを安定したストレージにフラッシュするためにNVMEフラッシュコマンドを使用する必要があります。フラッシュコマンド（[nvme-base]のセクション7.1を参照）。NVMEフラッシュコマンドは、SCSI同期キャッシュコマンドに相当します。
NFSv4 clients access NFSv4 metadata servers using the NFSv4 protocol. The security considerations generally described in [RFC8881] apply to a client's interactions with the metadata server. However, NFSv4 clients and servers access NVMe storage devices at a lower layer than NFSv4. NFSv4 and RPC security are not directly applicable to the I/Os to data servers using NVMe. Refer to Sections 2.4.6 (Extents Are Permissions) and 4 (Security Considerations) of [RFC8154] for the security considerations of direct access to block storage from NFS clients.
NFSV4クライアントは、NFSV4プロトコルを使用してNFSV4メタデータサーバーにアクセスします。[RFC8881]で一般的に説明されているセキュリティ上の考慮事項は、メタデータサーバーとのクライアントのやり取りに適用されます。ただし、NFSV4クライアントとサーバーは、NFSV4よりも下層のNVMEストレージデバイスにアクセスします。NFSV4およびRPCセキュリティは、NVMEを使用してI/OSにデータサーバーに直接適用できません。NFSクライアントからのブロックストレージへの直接アクセスのセキュリティに関するセキュリティに関する考慮事項については、[RFC8154]のセクション2.4.6（Extentsは許可）および4（セキュリティ上の考慮事項）を参照してください。
pNFS with an NVMe layout can be used with NVMe transports (e.g., NVMe over PCIe [NVME-PCIE]) that provide essentially no additional security functionality. Or, pNFS may be used with storage protocols such as NVMe over TCP [NVME-TCP] that can provide significant transport layer security.
NVMEレイアウトを備えたPNFは、基本的に追加のセキュリティ機能を提供しないNVMEトランスポート（たとえば、NVME [NVME-PCIE]）で使用できます。または、PNFは、重要な輸送層のセキュリティを提供できるTCP [NVME-TCP]を介したNVMEなどのストレージプロトコルで使用できます。
It is the responsibility of those administering and deploying pNFS with an NVMe layout to ensure that appropriate protection is deployed to that protocol based on the deployment environment as well as the nature and sensitivity of the data and storage devices involved. When using IP-based storage protocols such as NVMe over TCP, data confidentiality and integrity SHOULD be provided for traffic between pNFS clients and NVMe storage devices by using a secure communication protocol such as Transport Layer Security (TLS) [RFC8446]. For NVMe over TCP, TLS SHOULD be used as described in [NVME-TCP] to protect traffic between pNFS clients and NVMe namespaces used as storage devices.
これは、NVMEレイアウトを使用してPNFを管理および展開する責任であり、展開環境に基づいて適切な保護がそのプロトコルに展開され、関係するデータおよびストレージデバイスの性質と感度を確実に展開することを保証します。TCPを介したNVMEなどのIPベースのストレージプロトコルを使用する場合、Transport Lay Security（TLS）[RFC8446]などの安全な通信プロトコルを使用して、PNFSクライアントとNVMEストレージデバイス間のトラフィックにデータの機密性と整合性を提供する必要があります。TCPを介したNVMEの場合、[NVME-TCP]に記載されているようにTLSを使用して、PNFSクライアントとストレージデバイスとして使用されるNVMEネームスペース間のトラフィックを保護する必要があります。
A secure communication protocol might not be needed for pNFS with NVMe layouts in environments where physical and/or logical security measures (e.g., air gaps, isolated VLANs) provide effective access control commensurate with the sensitivity and value of the storage devices and data involved (e.g., public website contents may be significantly less sensitive than a database containing personal identifying information, passwords, and other authentication credentials).
物理的および/または論理的なセキュリティ対策（空気のギャップ、孤立したVLANなど）が、関連するストレージデバイスとデータの感度と価値に見合った効果的なアクセス制御を提供する環境で、NVMEレイアウトを持つPNFには安全な通信プロトコルは必要ない場合があります（関連するデータの感度と価値（たとえば、パブリックWebサイトのコンテンツは、個人識別情報、パスワード、その他の認証資格情報を含むデータベースよりも著しく感度が低い場合があります。
Physical security is a common means for protocols not based on IP. In environments where the security requirements for the storage protocol cannot be met, pNFS with an NVMe layout SHOULD NOT be deployed.
物理的セキュリティは、IPに基づいていないプロトコルの一般的な手段です。ストレージプロトコルのセキュリティ要件を満たせない環境では、NVMEレイアウトを持つPNFSを展開しないでください。
When security is available for the data server storage protocol, it is generally at a different granularity and with a different notion of identity than NFSv4 (e.g., NFSv4 controls user access to files, and NVMe controls initiator access to volumes). As with pNFS with the block layout type [RFC5663], the pNFS client is responsible for enforcing appropriate correspondences between these security layers. In environments where the security requirements are such that client-side protection from access to storage outside of the layout is not sufficient, pNFS with a SCSI layout on a NVMe namespace SHOULD NOT be deployed.
データサーバーストレージプロトコルのセキュリティが利用可能である場合、それは一般に異なる粒度であり、NFSV4とは異なるアイデンティティの概念を備えています（たとえば、NFSV4はファイルへのユーザーアクセスを制御し、NVMEはボリュームへのイニシエーターアクセスを制御します）。ブロックレイアウトタイプ[RFC5663]のPNFSと同様に、PNFSクライアントは、これらのセキュリティレイヤー間の適切な対応を施行する責任があります。セキュリティ要件がある環境では、レイアウト外のストレージへのアクセスからクライアント側の保護が十分ではないため、NVMEネームスペースにSCSIレイアウトを備えたPNFは展開しないでください。
As with other block-oriented pNFS layout types, the metadata server is able to fence off a client's access to the data on an NVMe namespace used as a storage device. If a metadata server revokes a layout, the client's access MUST be terminated at the storage devices via fencing as specified in Section 2.2. The client has a subsequent opportunity to acquire a new layout.
他のブロック指向のPNFSレイアウトタイプと同様に、メタデータサーバーは、ストレージデバイスとして使用されるNVMEネームスペースのデータへのクライアントのアクセスをフェンスで囲むことができます。メタデータサーバーがレイアウトを取り消す場合、セクション2.2で指定されているように、フェンシングを介してクライアントのアクセスをストレージデバイスで終了する必要があります。クライアントは、新しいレイアウトを取得するその後の機会があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[NVME-BASE]
NVM Express, Inc., "NVM Express Base Specification",
Revision 2.0d, January 2024, <https://nvmexpress.org/wp-
content/uploads/NVM-Express-Base-Specification-2.0d-
2024.01.11-Ratified.pdf>.
[NVME-NVM] NVM Express, Inc., "NVM Express NVM Command Set
Specification", Revision 1.0d, December 2023,
<https://nvmexpress.org/wp-content/uploads/NVM-Express-
NVM-Command-Set-Specification-1.0d-
2023.12.28-Ratified.pdf>.
[NVME-TCP] NVM Express, Inc., "NVM Express TCP Transport
Specification", Revision 1.0d, December 2023,
<https://nvmexpress.org/wp-content/uploads/NVM-Express-
TCP-Transport-Specification-1.0d-2023.12.27-Ratified.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <https://www.rfc-editor.org/info/rfc4506>.
[RFC5663] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS
(pNFS) Block/Volume Layout", RFC 5663,
DOI 10.17487/RFC5663, January 2010,
<https://www.rfc-editor.org/info/rfc5663>.
[RFC8154] Hellwig, C., "Parallel NFS (pNFS) Small Computer System
Interface (SCSI) Layout", RFC 8154, DOI 10.17487/RFC8154,
May 2017, <https://www.rfc-editor.org/info/rfc8154>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS)
Version 4 Minor Version 1 Protocol", RFC 8881,
DOI 10.17487/RFC8881, August 2020,
<https://www.rfc-editor.org/info/rfc8881>.
[SPC5] INCITS Technical Committee T10, "SCSI Primary Commands - 5
(SPC-5)", INCITS 502-2019, 2019.
[NVME-PCIE]
NVM Express, Inc., "NVMe over PCIe Transport
Specification", Revision 1.0d, December 2023,
<https://nvmexpress.org/wp-content/uploads/NVM-Express-
PCIe-Transport-Specification-1.0d-
2023.12.27-Ratified.pdf>.
Carsten Bormann converted an earlier RFCXML v2 source for this document to a markdown source format.
Carsten Bormannは、このドキュメントの以前のRFCXML V2ソースをMarkdownソース形式に変換しました。
David Noveck provided ample feedback to various drafts of this document.
David Noveckは、この文書のさまざまなドラフトに十分なフィードバックを提供しました。
Christoph Hellwig (editor)
Email: hch@lst.de
Charles Lever
Oracle Corporation
United States of America
Email: chuck.lever@oracle.com
Sorin Faibish
Opendrives.com
11 Selwyn Road
Newton, MA 02461
United States of America
Phone: +1 617-510-0422
Email: s.faibish@opendrives.com
David L. Black
Dell Technologies
176 South Street
Hopkinton, MA 01748
United States of America
Email: david.black@dell.com