draft-ietf-nfsv4-pnfs-block-disk-protection-03.txt   rfc6688.txt 
NFSv4 Working Group D. Black (ed.)
Internet-Draft EMC Corporation
Intended status: Proposed Standard J. Glasgow
Expires: December YY, 2012 Google
Updates: 5663 S. Faibish
EMC Corporation
June 22, 2012
pNFS block disk protection Internet Engineering Task Force (IETF) D. Black, Ed.
draft-ietf-nfsv4-pnfs-block-disk-protection-03 Request for Comments: 6688 EMC Corporation
Updates: 5663 J. Glasgow
Category: Standards Track Google
ISSN: 2070-1721 S. Faibish
EMC Corporation
July 2012
Status of this Memo Parallel NFS (pNFS) Block Disk Protection
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4)
Task Force (IETF), its areas, and its working groups. Note that to enable direct client access to file data on storage devices and
other groups may also distribute working documents as Internet- bypass the NFSv4 server. This can increase both performance and
Drafts. parallelism, but it requires additional client functionality, some of
which depends upon the type of storage used. The pNFS specification
for block storage (RFC 5663) describes how clients can identify the
volumes used for pNFS, but this mechanism requires communication with
the NFSv4 server. This document updates RFC 5663 to add a mechanism
that enables identification of block storage devices used by pNFS
file systems without communicating with the server. This enables
clients to control access to pNFS block devices when the client
initially boots, as opposed to waiting until the client can
communicate with the NFSv4 server.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (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 5741.
This Internet-Draft will expire on December 23, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6688.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to
enable direct client access to file data on storage, bypassing the
NFSv4 server. This can increase both performance and parallelism,
but requires additional client functionality, some of which depends
upon the type of storage used. The pNFS specification for block
storage (RFC 5663) describes how clients can identify the volumes
used for pNFS, but this mechanism requires communication with the
NFSv4 server. This document updates RFC 5663 to add a mechanism that
enables identification of block storage devices used by pNFS file
systems without communicating with the server. This enables clients
to control access to pNFS block devices when the client initially
boots, as opposed to waiting until the client can communicate with
the NFSv4 server.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ....................................................3
2. Conventions used in this document..............................4 2. Conventions Used in This Document ...............................4
3. GPT Partition Table Entry......................................4 3. GPT Partition Table Entry .......................................4
4. Security Considerations........................................5 4. Security Considerations .........................................5
5. IANA Considerations............................................5 5. References ......................................................5
6. References.....................................................6 5.1. Normative References .......................................5
6.1. Normative References......................................6 5.2. Informative References .....................................6
6.2. Informative References....................................6 6. Acknowledgements.................................................6
Acknowledgements..................................................6
Authors' Addresses................................................7
1. Introduction 1. Introduction
Figure 1 shows the overall architecture of a Parallel NFS (pNFS) Figure 1 shows the overall architecture of a Parallel NFS (pNFS)
system: system:
+-----------+ +-----------+
|+-----------+ +-----------+ |+-----------+ +-----------+
||+-----------+ | | ||+-----------+ | |
||| | NFSv4.1 + pNFS | | ||| | NFSv4.1 + pNFS | |
+|| Clients |<------------------------------>| MDS | +|| Clients |<------------------------------>| MDS |
+| | | | +| | | |
+-----------+ | | +-----------+ | |
||| +-----------+ ||| +-----------+
||| | ||| |
||| | ||| |
||| Storage +-----------+ | ||| Storage +-----------+ |
||| Protocol |+-----------+ | ||| Protocol |+-----------+ |
||+----------------||+-----------+ Control | ||+----------------||+-----------+ Control |
|+-----------------||| | Protocol | |+-----------------||| | Protocol |
+------------------+|| Storage |------------+ +------------------+|| Storage |------------+
+| Devices | +| Devices |
+-----------+ +-----------+
Figure 1 pNFS Architecture Figure 1. pNFS Architecture
In this document, "storage device" is used as a general term for a In this document, "storage device" is used as a general term for a
data server and/or storage server for any pNFS layout type. The data server and/or storage server for any pNFS layout type. The
MetaData Server (MDS) is the NFSv4 server that provides pNFS layouts MetaData Server (MDS) is the NFSv4 server that provides pNFS layouts
to clients and handles operations on file metadata (e.g., names, to clients and handles operations on file metadata (e.g., names and
attributes). attributes).
For the pNFS block protocol as specified in [RFC5663], client For the pNFS block protocol as specified in [RFC5663], client
identification of pNFS storage devices requires contacting the MDS to identification of pNFS storage devices requires contacting the MDS to
obtain device signature information. It is not possible for a pNFS obtain device signature information. It is not possible for a pNFS
client to reliably identify pNFS block storage devices without client to reliably identify pNFS block storage devices without
contacting the MDS because the device signature location and contents contacting the MDS, because the device signature location and
may vary among devices and servers; both device signature location contents may vary among devices and servers; both device signature
and contents are determined by the MDS, not the client. location and contents are determined by the MDS, not the client.
Typical operating system (OS) boot functionality scans and activates Typical operating system (OS) boot functionality scans and activates
block devices (e.g., SCSI) before activating the NFS client block devices (e.g., Small Computer System Interface (SCSI)) before
(including pNFS functionality). That sequence of operations creates activating the NFS client (including pNFS functionality). This
a window of time during which the client OS may modify a pNFS block sequence of operations creates a window of time during which the
device without contacting the server (e.g., by attempting to mount or client OS may modify a pNFS block device without contacting the
initialize a local physical filesystem). This document specifies an server (e.g., by attempting to mount or initialize a local physical
identification mechanism for pNFS block storage devices that can be filesystem). This document specifies an identification mechanism for
used by an OS implementation to remove this window of vulnerability. pNFS block storage devices that can be used by an OS implementation
to remove this window of vulnerability.
Many storage area network (SAN) storage systems provide quasi-static Many storage area network (SAN) storage systems provide quasi-static
access control mechanisms (e.g., Logical Unit Number (LUN) mapping access control mechanisms (e.g., Logical Unit Number (LUN) mapping
and/or masking) that operate at the granularity of individual hosts. and/or masking) that operate at the granularity of individual hosts.
While it is feasible to use such mechanisms to remove this window While it is feasible to use such mechanisms to remove this window
(e.g., by only enabling a client to access pNFS block storage devices (e.g., by only enabling a client to access pNFS block storage devices
after the client has contacted the responsible MDS), that usage is after the client has contacted the responsible MDS), such usage is
undesirable and potentially problematic. This is because the storage undesirable and potentially problematic. This is because the storage
access control mechanisms are quasi-static; they are typically access control mechanisms are quasi-static; they are typically
configured once to allow client access to the block pNFS storage configured once to allow client access to the block pNFS storage
devices and not reconfigured dynamically (e.g., based on crashes and devices and not reconfigured dynamically (e.g., based on crashes and
reboots). Block storage access controls can be changed to respond to reboots). Block storage access controls can be changed to respond to
unusual circumstances (e.g., to fence [remove access from] an unusual circumstances (e.g., to fence [remove access from] an
uncooperative pNFS client), but should not be used as part of routine uncooperative pNFS client), but should not be used as part of routine
client operations (e.g., reboot). A different mechanism is needed. client operations (e.g., reboot). A different mechanism is needed.
This document specifies an entry in the GUID partition table (GPT) This document specifies an entry in the GUID (Globally Unique
that can be used by a pNFS server to label pNFS storage devices. This Identifier) partition table (GPT) that can be used by a pNFS server
GPT entry is intended for shared pNFS storage devices that are to label pNFS storage devices. This GPT entry is intended for shared
accessible to pNFS clients and servers, and that may be accessible to pNFS storage devices that are accessible to pNFS clients and servers,
other hosts or systems. This entry enables pNFS clients as well as and that may be accessible to other hosts or systems. This entry
other hosts and systems to avoid accessing pNFS storage devices via enables pNFS clients, as well as other hosts and systems, to avoid
means other than pNFS. accessing pNFS storage devices via means other than pNFS.
2. Conventions used in this document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. GPT Partition Table Entry 3. GPT Partition Table Entry
The following mechanism enables pNFS clients to identify pNFS block The following mechanism enables pNFS clients to identify pNFS block
storage devices without contacting the server: storage devices without contacting the server:
- Each block storage device dedicated to pNFS includes a GUID - Each block storage device dedicated to pNFS includes a GUID
partition table (GPT) [GPT]. partition table (GPT) [GPT].
- The pNFS Block Storage partitions are identified in the GPT with - The pNFS block storage partitions are identified in the GPT
GUID e5b72a69-23e5-4b4d-b176-16532674fc34 which has been with GUID e5b72a69-23e5-4b4d-b176-16532674fc34, which has been
generated for this purpose. GPT GUID usage is well understood generated for this purpose. GPT GUID usage is well understood
and implemented. This document provides a definition for this and implemented. This document provides a definition for this
GUID and its usage. A central registration mechanism does not GUID and its usage. A central registration mechanism does not
exist for GPT GUIDs, or GUIDs in general by design, see exist for GPT GUIDs, or GUIDs in general, by design; see
[RFC4122]. [RFC4122].
This mechanism enables an operating system to prevent non-pNFS access This mechanism enables an operating system to prevent non-pNFS access
to pNFS block storage immediately upon boot. Servers that support to pNFS block storage immediately upon boot. Servers that support
pNFS block layouts SHOULD use the GPT and this GUID for all pNFS pNFS block layouts SHOULD use the GPT and this GUID for all pNFS
block storage devices. block storage devices.
A pNFS client operating system that supports block layouts SHOULD A pNFS client operating system that supports block layouts SHOULD
recognize this GUID and SHOULD use its presence to prevent data recognize this GUID and SHOULD use its presence to prevent data
access to pNFS block devices until a layout that includes the device access to pNFS block devices until a layout that includes the device
is received from the MDS. is received from the MDS.
skipping to change at page 5, line 32 skipping to change at page 5, line 32
Many current operating system versions support the GPT [GPT-W]. Many current operating system versions support the GPT [GPT-W].
4. Security Considerations 4. Security Considerations
The pNFS block layout security considerations in [RFC5663] apply to The pNFS block layout security considerations in [RFC5663] apply to
this document. this document.
The security considerations in [RFC4122] apply to the GUID specified The security considerations in [RFC4122] apply to the GUID specified
in this document. in this document.
5. IANA Considerations 5. References
There are no IANA considerations in this document.
6. References
6.1. Normative References 5.1. Normative References
[GPT] Unified EFI Forum, "Unified Extensible Firmware Interface [GPT] Unified EFI Forum, "Unified Extensible Firmware Interface
Specification", Version 2.3.1, Errata A, Section 5.3, Specification", Version 2.3.1, Errata A, Section 5.3,
September 2011, available from http://www.uefi.org . September 2011, available from http://www.uefi.org.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5663] Black, D., Glasgow, J., Fridella, S., "Parallel NFS (pNFS) [RFC5663] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS
Block/Volume Layout", RFC 5663, January 2010. (pNFS) Block/Volume Layout", RFC 5663, January 2010.
6.2. Informative References 5.2. Informative References
[GPT-W] http://en.wikipedia.org/wiki/GUID_Partition_Table [GPT-W] Wikipedia, "GUID Partition Table", July 2012,
http://en.wikipedia.org/w/
index.php?title=GUID_Partition_Table&oldid=502098731.
[RFC4122] Leach, P., Mealling, M., Salz, R., "A Universally Unique [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
IDentifier (UUID) URN Namespace", RFC 4122, July 2005. Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
Acknowledgements 6. Acknowledgements
This document was produced by the IETF NFSv4 Working Group. Review This document was produced by the IETF NFSv4 Working Group. Review
comments from members of the working group improved this document and comments from members of the working group improved this document and
are gratefully acknowledged. The authors would like to thank Tom are gratefully acknowledged. The authors would like to thank Tom
Talpey, and members of the IESG for helpful comments on this Talpey, and members of the IESG for helpful comments on this
document, and also Alex Burlyga for providing an appropriate document, and also Alex Burlyga for providing an appropriate
reference for the format of the GPT. reference for the format of the GPT.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
David L. Black (editor) David L. Black (editor)
EMC Corporation EMC Corporation
176 South Street 176 South Street
Hopkinton, MA 01748 Hopkinton, MA 01748
US USA
Phone: +1 (508) 293-7953 Phone: +1 (508) 293-7953
Email: david.black@emc.com EMail: david.black@emc.com
Jason Glasgow Jason Glasgow
Google Google
5 Cambridge Center, Floors 3-6 5 Cambridge Center, Floors 3-6
Cambridge, MA 02142 Cambridge, MA 02142
US USA
Phone: +1 (617) 575-1599 Phone: +1 (617) 575-1599
Email: jglasgow@google.com EMail: jglasgow@google.com
Sorin Faibish Sorin Faibish
EMC Corporation EMC Corporation
228 South Street 228 South Street
Hopkinton, MA 01748 Hopkinton, MA 01748
US USA
Phone: +1 (508) 305-8545 Phone: +1 (508) 305-8545
Email: sfaibish@emc.com EMail: sfaibish@emc.com
 End of changes. 43 change blocks. 
139 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/