draft-ietf-decade-arch-03.txt   draft-ietf-decade-arch-04.txt 
DECADE R. Alimi DECADE R. Alimi
Internet-Draft Google Internet-Draft Google
Intended status: Informational Y. Yang Intended status: Informational Y. Yang
Expires: March 31, 2012 Yale University Expires: May 3, 2012 Yale University
A. Rahman A. Rahman
InterDigital Communications, LLC InterDigital Communications, LLC
D. Kutscher D. Kutscher
NEC NEC
H. Liu H. Liu
Yale University Yale University
September 28, 2011 October 31, 2011
DECADE Architecture DECADE Architecture
draft-ietf-decade-arch-03 draft-ietf-decade-arch-04
Abstract Abstract
Content Distribution Applications (e.g., P2P applications) are widely Content Distribution Applications (e.g., P2P applications) are widely
used on the Internet and make up a large portion of the traffic in used on the Internet and make up a large portion of the traffic in
many networks. One technique to improve the network efficiency of many networks. One technique to improve the network efficiency of
these applications is to introduce storage capabilities within the these applications is to introduce storage capabilities within the
networks; this is the capability to be provided by DECADE (DECoupled networks; this is the capability to be provided by DECADE (DECoupled
Application Data Enroute). This document presents an architecture Application Data Enroute). This document presents an architecture
for DECADE, discusses the underlying principles, and identifies core for DECADE, discusses the underlying principles, and identifies core
components and protocols for supporting in-network storage components and protocols for introducing in-network storage for these
functionality for these applications. applications.
Requirements Language Requirements Language
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].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 31, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Functional Entities . . . . . . . . . . . . . . . . . . . . . 6 2. Functional Entities . . . . . . . . . . . . . . . . . . . . . 6
2.1. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 6 2.1. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 6
2.2. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 6 2.2. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 6
2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6 2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6
2.4. DECADE Content Provider . . . . . . . . . . . . . . . . . 6 2.4. Content Provider Using DECADE . . . . . . . . . . . . . . 6
2.5. DECADE Content Consumer . . . . . . . . . . . . . . . . . 7 2.5. Content Consumer Using DECADE . . . . . . . . . . . . . . 7
2.6. Content Distribution Application . . . . . . . . . . . . . 7 2.6. Content Distribution Application . . . . . . . . . . . . . 7
3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Architectural Principles . . . . . . . . . . . . . . . . . . . 9 4. Architectural Principles . . . . . . . . . . . . . . . . . . . 9
4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 10 4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 10
4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 11 4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 11
4.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 12 4.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 12
4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . . 12 4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . . 12
4.5. Resource and Data Access Control through User 4.5. Resource and Data Access Control through User
skipping to change at page 3, line 41 skipping to change at page 3, line 41
6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 23 6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 23 6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 23
6.2. Standard Data Transport (SDT) . . . . . . . . . . . . . . 26 6.2. Standard Data Transport (SDT) . . . . . . . . . . . . . . 26
7. Server-to-Server Protocols . . . . . . . . . . . . . . . . . . 29 7. Server-to-Server Protocols . . . . . . . . . . . . . . . . . . 29
7.1. Operational Overview . . . . . . . . . . . . . . . . . . . 29 7.1. Operational Overview . . . . . . . . . . . . . . . . . . . 29
8. Potential Optimizations . . . . . . . . . . . . . . . . . . . 30 8. Potential Optimizations . . . . . . . . . . . . . . . . . . . 30
8.1. Pipelining to Avoid Store-and-Forward Delays . . . . . . . 30 8.1. Pipelining to Avoid Store-and-Forward Delays . . . . . . . 30
8.2. Deduplication . . . . . . . . . . . . . . . . . . . . . . 31 8.2. Deduplication . . . . . . . . . . . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Appendix: Evaluation of Some Candidate Existing Appendix A. Appendix: Evaluation of Some Candidate Existing
Protocols for DECADE DRP and SDT . . . . . . . . . . 34 Protocols for DECADE DRP and SDT . . . . . . . . . . 34
A.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2. WEBDAV . . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.2. WEBDAV . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.3. CDMI . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.3. CDMI . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. In-Network Storage Components Mapped to DECADE Appendix B. In-Network Storage Components Mapped to DECADE
Architecture . . . . . . . . . . . . . . . . . . . . 42 Architecture . . . . . . . . . . . . . . . . . . . . 42
B.1. Data Access Interface . . . . . . . . . . . . . . . . . . 42 B.1. Data Access Interface . . . . . . . . . . . . . . . . . . 43
B.2. Data Management Operations . . . . . . . . . . . . . . . . 42 B.2. Data Management Operations . . . . . . . . . . . . . . . . 43
B.3. Data Search Capability . . . . . . . . . . . . . . . . . . 42 B.3. Data Search Capability . . . . . . . . . . . . . . . . . . 43
B.4. Access Control Authorization . . . . . . . . . . . . . . . 43 B.4. Access Control Authorization . . . . . . . . . . . . . . . 43
B.5. Resource Control Interface . . . . . . . . . . . . . . . . 43 B.5. Resource Control Interface . . . . . . . . . . . . . . . . 43
B.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 43 B.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 43
B.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 43 B.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
Content Distribution Applications are widely used on the Internet Content Distribution Applications are widely used on the Internet
today to distribute data, and they contribute a large portion of the today to distribute data, and they contribute a large portion of the
traffic in many networks. The DECADE architecture described in this traffic in many networks. The DECADE architecture described in this
document enables such applications to leverage in-network storage to document enables such applications to leverage in-network storage to
achieve more efficient content distribution. Specifically, in many achieve more efficient content distribution. Specifically, in many
subscriber networks, it can be expensive to upgrade network equipment subscriber networks, it can be expensive to upgrade network equipment
in the "last-mile", because it can involve replacing equipment and in the "last-mile", because it can involve replacing equipment and
skipping to change at page 5, line 32 skipping to change at page 5, line 32
This document presents an architecture for providing in-network This document presents an architecture for providing in-network
storage that can be integrated into Content Distribution storage that can be integrated into Content Distribution
Applications. The primary focus is P2P-based content distribution, Applications. The primary focus is P2P-based content distribution,
but the architecture may be useful to other applications with similar but the architecture may be useful to other applications with similar
characteristics and requirements. See [I-D.ietf-decade-reqs] for a characteristics and requirements. See [I-D.ietf-decade-reqs] for a
definition of the target applications supported by DECADE. definition of the target applications supported by DECADE.
The design philosophy of the DECADE architecture is to provide only The design philosophy of the DECADE architecture is to provide only
the core functionalities that are needed for applications to make use the core functionalities that are needed for applications to make use
of in-network storage. With such core functionalities, DECADE may be of in-network storage. Focusing on only core functionalities, DECADE
simpler and easier to support by storage providers. If more complex may be simpler and easier to support by service providers. If more
functionalities are needed by a certain application or class of complex functionalities are needed by a certain application or class
applications, it may be layered on top of DECADE. of applications, it may be layered on top of DECADE.
DECADE will leverage existing data transport and application-layer DECADE will leverage existing data transport and application-layer
protocols. The design is to work with a small set of alternative protocols. The design is to work with a small set of alternative
IETF protocols. In this document, we use "data transport" to refer IETF protocols. In this document, we use "data transport" to refer
to a protocol that is used to read data from and write data into to a protocol that is used to read data from and write data into
DECADE in-network storage. DECADE in-network storage.
This document proceeds in two steps. First, it details the core This document proceeds in two steps. First, it details the core
architectural principles that we use to guide the DECADE design. architectural principles that we use to guide the DECADE design.
Next, given these core principles, this document presents the core Next, given these core principles, this document presents the core
skipping to change at page 6, line 43 skipping to change at page 6, line 43
A DECADE storage provider deploys and/or manages DECADE storage A DECADE storage provider deploys and/or manages DECADE storage
server(s) within a network. A storage provider may also own or server(s) within a network. A storage provider may also own or
manage the network in which the DECADE servers are deployed, but this manage the network in which the DECADE servers are deployed, but this
is not mandatory. is not mandatory.
A DECADE storage provider, possibly in cooperation with one or more A DECADE storage provider, possibly in cooperation with one or more
network providers, determines deployment locations for DECADE servers network providers, determines deployment locations for DECADE servers
and determines the available resources for each. and determines the available resources for each.
2.4. DECADE Content Provider 2.4. Content Provider Using DECADE
A DECADE content provider accesses DECADE storage servers (by way of A content provider using DECADE accesses DECADE storage servers (by
a DECADE client) to upload and manage data. A content provider can way of a DECADE client) to upload and manage data. Such a content
access one or more storage servers. A content provider may be a provider can access one or more storage servers. Such a content
single process or a distributed application (e.g., in a P2P provider may be a single process or a distributed application (e.g.,
scenario), and may either be fixed or mobile. in a P2P scenario), and may either be fixed or mobile.
2.5. DECADE Content Consumer 2.5. Content Consumer Using DECADE
A DECADE content consumer accesses storage servers (by way of a A content consumer using DECADE accesses DECADE storage servers (by
DECADE client) to download data that has previously been stored by a way of a DECADE client). A content consumer can access one or more
DECADE content provider. A content consumer can access one or more DECADE storage servers. A content consumer may be a single process
storage servers. A content consumer may be a single process or a or a distributed application (e.g., in a P2P scenario), and may
distributed application (e.g., in a P2P scenario), and may either be either be fixed or mobile. An instance of a distributed application,
fixed or mobile. An instance of a distributed application, such as a such as a P2P application, may both provide content to and consume
P2P application, may both provide content to and consume content from content from DECADE storage servers.
DECADE storage servers.
2.6. Content Distribution Application 2.6. Content Distribution Application
A content distribution application (as a target application for A content distribution application (as a target application for
DECADE as described in [I-D.ietf-decade-reqs]) is a distributed DECADE as described in [I-D.ietf-decade-reqs]) is a distributed
application designed for dissemination of a possibly-large data set application designed for dissemination of a possibly-large data set
to multiple consumers. Content Distribution Applications typically to multiple consumers. Content Distribution Applications typically
divide content into smaller blocks for dissemination. divide content into smaller blocks for dissemination.
The term Application Developer refers to the developer of a The term Application Developer refers to the developer of a
skipping to change at page 19, line 7 skipping to change at page 19, line 7
Another advantage of this scheme is that a DECADE client knows the Another advantage of this scheme is that a DECADE client knows the
name of a data object before it is completely stored at the DECADE name of a data object before it is completely stored at the DECADE
server. This allows for particular optimizations, such as server. This allows for particular optimizations, such as
advertising data object while the data object is being stored, advertising data object while the data object is being stored,
removing store-and-forward delays. For example, a DECADE client A removing store-and-forward delays. For example, a DECADE client A
may simultaneously begin storing an object to a DECADE server, and may simultaneously begin storing an object to a DECADE server, and
advertise that the object is available to DECADE client B. If it is advertise that the object is available to DECADE client B. If it is
supported by the DECADE server, client B may begin downloading the supported by the DECADE server, client B may begin downloading the
object before A is finished storing the object. object before A is finished storing the object.
In certain scenarios (e.g., where a DECADE client has limited
computational power), it may be advantageous to offload the
computation of a data object's name to the DECADE Server. This
possibility is not considered in the current architecture, but may be
a topic for future extensions.
5.3.2. Application Usage 5.3.2. Application Usage
Recall from Section 5.1.1 that an Application typically includes its Recall from Section 5.1.1 that an Application typically includes its
own naming and sequencing scheme. It is important to note that the own naming and sequencing scheme. It is important to note that the
DECADE naming format does not attempt to replace any naming or DECADE naming format does not attempt to replace any naming or
sequencing of data objects already performed by an Application; sequencing of data objects already performed by an Application;
instead, the DECADE naming is intended to apply only to data objects instead, the DECADE naming is intended to apply only to data objects
referenced at the DECADE layer. referenced at the DECADE layer.
DECADE names are not necessarily correlated with the naming or DECADE names are not necessarily correlated with the naming or
skipping to change at page 27, line 8 skipping to change at page 27, line 8
A DECADE server provide a data access interface, and SDT is used to A DECADE server provide a data access interface, and SDT is used to
write objects to a server and to read (download) objects from a write objects to a server and to read (download) objects from a
server. Semantically, SDT is a client-server protocol, i.e., the server. Semantically, SDT is a client-server protocol, i.e., the
DECADE server always responds to client requests. DECADE server always responds to client requests.
An SDT used in DECADE SHOULD offer a transport mode that provides An SDT used in DECADE SHOULD offer a transport mode that provides
confidentiality and integrity. confidentiality and integrity.
6.2.1. Writing/Uploading Objects 6.2.1. Writing/Uploading Objects
For writing objects, a client uploads an object to a DECADE server. To write an object, a client first generates the object's name (see
The object on the server will be named (associated to an identifier), Section 5.3), and then uploads the object to a DECADE server and
and this name can be used to access (download) the object later, supplies the generated name. The name can be used to access
e.g., the client can pass the name as a reference to other client (download) the object later, e.g., the client can pass the name as a
that can then refer to the object. reference to other client that can then refer to the object.
DECADE objects can be self-contained objects such as multimedia DECADE objects can be self-contained objects such as multimedia
resources, files etc., but also chunks, such as chunks of a P2P resources, files etc., but also chunks, such as chunks of a P2P
distribution protocol that can be part of a containing object or a distribution protocol that can be part of a containing object or a
stream. stream.
A server MUST accept download requests for an object that is still A server MAY accept download requests for an object that is still
being uploaded. being uploaded.
The application that originates the objects MUST generate DECADE The application that originates the objects MUST generate DECADE
object names according to the naming specification in Section 5.3. object names according to the naming specification in Section 5.3.
The naming scheme provides that the name is unique. DECADE clients The naming scheme provides that the name is unique. DECADE clients
(as parts of application entities) upload a named object to a server, (as parts of application entities) upload a named object to a server,
and a DECADE server MUST NOT change the name. It MUST be possible and a DECADE server MUST NOT change the name. It MUST be possible
for downloading clients, to access the object using the original for downloading clients, to access the object using the original
name. A DECADE server MAY verify the integrity and other security name. A DECADE server MAY verify the integrity and other security
properties of uploaded objects. properties of uploaded objects.
skipping to change at page 29, line 9 skipping to change at page 29, line 9
NOT_FOUND: The DECADE server has not found anything matching NOT_FOUND: The DECADE server has not found anything matching
the request object name. the request object name.
PERMISSION_DENIED: The DECADE client lacked sufficient PERMISSION_DENIED: The DECADE client lacked sufficient
permission to read the object. permission to read the object.
NOT_AVAILABLE: The data object exists but is currently NOT_AVAILABLE: The data object exists but is currently
unavailable for download (e.g., due to server policy). unavailable for download (e.g., due to server policy).
Specifics regarding error handling, including additional error Specifics regarding error handling, including additional error
conditions, precedence for returned errors and its relation conditions (e.g. overload), precedence for returned errors and
with server policy, are defered to eventual protocol its relation with server policy, are defered to eventual
specification. protocol specification.
7. Server-to-Server Protocols 7. Server-to-Server Protocols
An important feature of DECADE is the capability for one DECADE An important feature of DECADE is the capability for one DECADE
server to directly download data objects from another DECADE server. server to directly download objects from another DECADE server. This
This capability allows Applications to directly replicate data capability allows Applications to directly replicate data objects
objects between servers without requiring end-hosts to use uplink between servers without requiring end-hosts to use uplink capacity to
capacity to upload data objects to a different DECADE server. upload data objects to a different DECADE server.
Similar to other operations in DRP and SDT, replicating data objects
between DECADE servers is an explicit operation.
To support this functionality, DECADE re-uses the already-specified To support this functionality, DECADE uses the DRP and SDT to support
protocols to support operations directly between servers. DECADE operations directly between servers. DECADE servers are not assumed
servers are not assumed to trust each other nor are configured to do to trust each other nor are configured to do so. All data operations
so. All data operations are performed on behalf of DECADE clients are performed on behalf of DECADE clients via explicit instruction.
via explicit instruction, so additional capabilities are needed in Note, however, that the objects being processed do not necessarily
the DECADE client-server protocols DECADE clients must be able to have to originate or terminate at the DECADE client (i.e. the object
indicate to a DECADE server the following additional parameters: may be limited to being exchanged between DECADE servers even if the
instruction is triggered by the client). DECADE clients thus must be
able to indicate to a DECADE server the following additional
parameters:
o which remote DECADE server(s) to access; o which remote DECADE server(s) to access;
o the operation to be performed (PUT or GET); and o the operation to be performed (e.g. PUT, GET); and
o Credentials indicating permission to perform the operation at the o Credentials indicating permission to perform the operation at the
remote DECADE server. remote DECADE server.
In this way, a DECADE server is also a DECADE client, and requests In this way, a DECADE server acts as a proxy for a DECADE client, and
may instantiate requests via that client. The operations are a DECADE client may instantiate requests via that proxy. The
performed as if the original requester had its own DECADE client co- operations are performed as if the original requester had its own
located with the DECADE server. It is this mode of operation that DECADE client co-located with the DECADE server. It is this mode of
provides substantial savings in uplink capacity. operation that provides substantial savings in uplink capacity. Note
that this mode of operation may also be triggered by an
administrative/management application outside the DECADE
architecture.
7.1. Operational Overview 7.1. Operational Overview
DECADE's server-to-server support is focused on reading and writing DECADE's server-to-server support is focused on reading and writing
data objects between DECADE servers. A DECADE GET or PUT request MAY data objects between DECADE servers. A DECADE GET or PUT request MAY
supply the following additional parameters: supply the following additional parameters:
REMOTE_SERVER: Address of the remote DECADE server. The format of REMOTE_SERVER: Address of the remote DECADE server. The format of
the address is out-of-scope of this document. the address is out-of-scope of this document.
skipping to change at page 30, line 19 skipping to change at page 30, line 20
the object (for a GET), or in which the object is to be stored the object (for a GET), or in which the object is to be stored
(for a PUT). (for a PUT).
TOKEN: Credentials to be used at the remote server. TOKEN: Credentials to be used at the remote server.
These parameters are used by the DECADE server to instantiate a These parameters are used by the DECADE server to instantiate a
request to the specified remote server. It is assumed that the data request to the specified remote server. It is assumed that the data
object referred to at the remote server is the same as the original object referred to at the remote server is the same as the original
request. It is also assumed that the operation performed at the request. It is also assumed that the operation performed at the
remote server is the same as the operation in the original request. remote server is the same as the operation in the original request.
Though explicitly supplying these may provide additional freedom, it Note that object attributes (see Section 6.1.4) may also be specified
is not clear what benefit they might provide. in the request to the remote server.
Note that when a DECADE client invokes a request a DECADE server with Note that when a DECADE client invokes a request a DECADE server with
these additional parameters, it is giving the DECADE server these additional parameters, it is giving the DECADE server
permission to act on its behalf. Thus, it would be wise for the permission to act (proxy) on its behalf. Thus, it would be wise for
supplied token to have narrow privileges (e.g., limited to only the the supplied token to have narrow privileges (e.g., limited to only
necessary data objects) or validity time (e.g., a small expiration the necessary data objects) or validity time (e.g., a small
time). expiration time).
In the case of a GET operation, the DECADE server is to retrieve the In the case of a GET operation, the DECADE server is to retrieve the
data object from the remote server using the specified credentials data object from the remote server using the specified credentials
(via a GET request to the remote server), and then return the object (via a GET request to the remote server), and then optionally return
to the client. In the case of a PUT operation, the DECADE server is the object to a client. In the case of a PUT operation, the DECADE
to store the object from the client, and then store the object to the server is to store the object to the remote server using the
remote server using the specified credentials (via a PUT request to specified credentials (via a PUT request to the remote server). The
the remote server). object may optionally be uploaded from the client or may already
exist at the proxying server.
8. Potential Optimizations 8. Potential Optimizations
As suggestions for the protocol design and eventual implementations, As suggestions for the protocol design and eventual implementations,
we discuss particular optimizations that are enabled by the DECADE we discuss particular optimizations that are enabled by the DECADE
Architecture discussed in this document. Architecture discussed in this document.
8.1. Pipelining to Avoid Store-and-Forward Delays 8.1. Pipelining to Avoid Store-and-Forward Delays
A DECADE server may choose to not fully store an object before A DECADE server may choose to not fully store an object before
skipping to change at page 31, line 18 skipping to change at page 31, line 21
data that needs to be stored. An optimization frequently applied in data that needs to be stored. An optimization frequently applied in
existing storage systems is de-duplication, which attempts to avoid existing storage systems is de-duplication, which attempts to avoid
storing identical data multiple times. A DECADE Server storing identical data multiple times. A DECADE Server
implementation may internally perform de-duplication of data on disk. implementation may internally perform de-duplication of data on disk.
The DECADE architecture enables additional forms of de-duplication. The DECADE architecture enables additional forms of de-duplication.
Note that these techniques may impact protocol design. Discussions Note that these techniques may impact protocol design. Discussions
of whether or not they should be adopted is out of the scope of this of whether or not they should be adopted is out of the scope of this
document. document.
8.2.1. Traffic Deduplication 8.2.1. Traffic De-duplication
8.2.1.1. Rationale 8.2.1.1. Rationale
When a DECADE client (A) indicates its DECADE account on a DECADE When a DECADE client (A) indicates its DECADE account on a DECADE
server (S) to fetch an object from a remote entity (R) (a DECADE server (S) to fetch an object from a remote entity (R) (a DECADE
server or DECADE client) and if the object is already stored locally server or DECADE client) and if the object is already stored locally
in S, S may perform Traffic Deduplication. This means that S does in S, S may perform Traffic De-duplication. This means that S does
not download the object from R, in order to save network traffic. In not download the object from R, in order to save network traffic. In
particular, S performs a challenge to make sure that the remote particular, S performs a challenge to make sure that the remote
entity R actually has the object and then replies with its local entity R actually has the object and then replies with its local
object copy directly. object copy directly.
8.2.1.2. An Example 8.2.1.2. An Example
As shown in Figure 7, without Traffic Deduplication, unnecessary As shown in Figure 7, without Traffic De-duplication, unnecessary
transfer of an object from R to S may happen, if the server S already transfer of an object from R to S may happen, if the server S already
has the object requested by A. If Traffic Deduplication is enabled, S has the object requested by A. If Traffic De-duplication is enabled,
only needs to challenge R to verify that it does have the data to S only needs to challenge R to verify that it does have the data to
avoid data-stealing attacks. avoid data-stealing attacks.
A S R A S R
+----------+ obj req +------------+ obj req +----------+ +----------+ obj req +------------+ obj req +----------+
| DECADE |=========>| A's |==========>| Remote | | DECADE |=========>| A's |==========>| Remote |
| CLIENT |<=========| Account |<==========| Entity | | CLIENT |<=========| Account |<==========| Entity |
+----------+ obj rsp +------------+ obj rsp +----------+ +----------+ obj rsp +------------+ obj rsp +----------+
(a) Without Traffic Deduplication (a) Without Traffic De-duplication
A S R A S R
+----------+ obj req +------------+ challenge +----------+ +----------+ obj req +------------+ challenge +----------+
| DECADE |=========>| A's |---------->| Remote | | DECADE |=========>| A's |---------->| Remote |
| CLIENT |<=========| Account |<----------| Entity | | CLIENT |<=========| Account |<----------| Entity |
+----------+ obj rsp +------------+ obj hash +----------+ +----------+ obj rsp +------------+ obj hash +----------+
(b) With Traffic Deduplication (b) With Traffic De-duplication
Figure 7 Figure 7
8.2.1.3. HTTP Compatibility of Challenge 8.2.1.3. HTTP Compatibility of Challenge
How to integrate traffic deduplication with HTTP is shown in How to integrate traffic de-duplication with HTTP is shown in
Appendix A.1.3. Appendix A.1.3.
8.2.2. Cross-Server Storage Deduplication 8.2.2. Cross-Server Storage De-duplication
The same object might be uploaded multiple times to different DECADE The same object might be uploaded multiple times to different DECADE
servers. For storage efficiency, storage providers may desire that a servers. For storage efficiency, storage providers may desire that a
single object be stored on one or a few servers. They might single object be stored on one or a few servers. They might
implement an internal mechanism to achieve the goal, for example, by implement an internal mechanism to achieve the goal, for example, by
redirecting requests to proper servers. DECADE supports the redirecting requests to proper servers. DECADE supports the
redirection of DECADE client requests to support further cross-server redirection of DECADE client requests to support further cross-server
storage deduplication. storage de-duplication.
9. Security Considerations 9. Security Considerations
In general, the security considerations mentioned in In general, the security considerations mentioned in
[I-D.ietf-decade-problem-statement] apply to this document as well. [I-D.ietf-decade-problem-statement] apply to this document as well.
In addition, it should be noted that the token-based approach In addition, it should be noted that the token-based approach
Section 5.4 provides authorization through token delegation. The Section 5.4 provides authorization through token delegation. The
strength of this authorization depends on several factors: strength of this authorization depends on several factors:
skipping to change at page 33, line 17 skipping to change at page 33, line 17
provided. provided.
Depending on the specific application, DECADE can be used to access Depending on the specific application, DECADE can be used to access
confidential information. Hence DECADE implementations SHOULD confidential information. Hence DECADE implementations SHOULD
provide a secure transport mode that allows for encryption. provide a secure transport mode that allows for encryption.
10. IANA Considerations 10. IANA Considerations
This document does not have any IANA considerations. This document does not have any IANA considerations.
11. References 11. Acknowledgments
11.1. Normative References We thank the following people for their contributions to this
document:
David Bryan
Yingjie Gu
David McDysan
Borje Ohlman
Haibin Song
Martin Stiemerling
Richard Woundy
Ning Zong
12. References
12.1. Normative References
[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.
11.2. Informative References 12.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV) Distributed Authoring and Versioning (WebDAV)
Access Control Protocol", RFC 3744, May 2004. Access Control Protocol", RFC 3744, May 2004.
[RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties fo [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties fo
skipping to change at page 33, line 48 skipping to change at page 34, line 23
[RFC4709] Reschke, J., "Mounting Web Distributed Authoring and [RFC4709] Reschke, J., "Mounting Web Distributed Authoring and
Versioning (WebDAV) Servers", RFC 4709, October 2006. Versioning (WebDAV) Servers", RFC 4709, October 2006.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007. Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010. RFC 5661, January 2010.
[RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
Network Storage Systems", RFC 6392, October 2011.
[I-D.ietf-decade-problem-statement] [I-D.ietf-decade-problem-statement]
Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement", Application Data Enroute (DECADE) Problem Statement",
draft-ietf-decade-problem-statement-03 (work in progress), draft-ietf-decade-problem-statement-04 (work in progress),
March 2011. October 2011.
[I-D.ietf-decade-survey]
Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
network Storage Systems", draft-ietf-decade-survey-06
(work in progress), August 2011.
[I-D.ietf-decade-reqs] [I-D.ietf-decade-reqs]
Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE
Requirements", draft-ietf-decade-reqs-03 (work in Requirements", draft-ietf-decade-reqs-04 (work in
progress), July 2011. progress), September 2011.
[GoogleStorageDevGuide] [GoogleStorageDevGuide]
"Google Storage Developer Guide", <http://code.google.com/ "Google Storage Developer Guide", <http://code.google.com/
apis/storage/docs/developer-guide.html>. apis/storage/docs/developer-guide.html>.
[GoogleFileSystem] [GoogleFileSystem]
Ghemawat, S., Gobioff, H., and S. Leung, "The Google File Ghemawat, S., Gobioff, H., and S. Leung, "The Google File
System", SOSP 2003, October 2003. System", SOSP 2003, October 2003.
[CDMI] "CDMI", <http://www.snia.org/cdmi>. [CDMI] "CDMI", <http://www.snia.org/cdmi>.
skipping to change at page 42, line 27 skipping to change at page 42, line 51
- COPY/MOVE operations - COPY/MOVE operations
- data containers - data containers
- naming scheme - naming scheme
Appendix B. In-Network Storage Components Mapped to DECADE Architecture Appendix B. In-Network Storage Components Mapped to DECADE Architecture
In this section we evaluate how the basic components of an in-network In this section we evaluate how the basic components of an in-network
storage system identified in Section 3 of [I-D.ietf-decade-survey] storage system identified in Section 3 of [RFC6392] map into the
map into the DECADE architecture. DECADE architecture.
It is important to note that complex and/or application-specific It is important to note that complex and/or application-specific
behavior is delegated to applications instead of tuning the storage behavior is delegated to applications instead of tuning the storage
system wherever possible. system wherever possible.
B.1. Data Access Interface B.1. Data Access Interface
Users can read and write objects of arbitrary size through the DECADE Users can read and write objects of arbitrary size through the DECADE
Client's Data Controller, making use of a standard data transport. Client's Data Controller, making use of a standard data transport.
 End of changes. 42 change blocks. 
100 lines changed or deleted 130 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/