draft-ietf-decade-arch-01.txt   draft-ietf-decade-arch-02.txt 
DECADE R. Alimi DECADE R. Alimi
Internet-Draft Google Internet-Draft Google
Intended status: Informational Y. Yang Intended status: Informational Y. Yang
Expires: November 22, 2011 Yale University Expires: January 12, 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
May 21, 2011 July 11, 2011
DECADE Architecture DECADE Architecture
draft-ietf-decade-arch-01 draft-ietf-decade-arch-02
Abstract Abstract
Peer-to-peer (P2P) applications have become widely used on the Content Distribution Applications (e.g., P2P applications) are widely
Internet today and make up a large portion of the traffic in many used on the Internet and make up a large portion of the traffic in
networks. One technique to improve the network efficiency of P2P many networks. One technique to improve the network efficiency of
applications is to introduce storage capabilities within the these applications is to introduce storage capabilities within the
networks. The DECADE Working Group has been formed with the goal of networks. This document presents an architecture, discusses the
developing an architecture to provide this capability. This document underlying principles, and identifies core components and protocols
presents an architecture, discusses the underlying principles, and for supporting in-network storage functionality for these
identifies core components and protocols supporting the architecture. applications.
Requirements Language
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 [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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 43 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 November 22, 2011. This Internet-Draft will expire on January 12, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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. Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Functional Entities . . . . . . . . . . . . . . . . . . . . . 6
2.1. DECADE Storage Servers . . . . . . . . . . . . . . . . . . 6 2.1. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 6
2.2. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6 2.2. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 6
2.3. DECADE Content Providers . . . . . . . . . . . . . . . . . 6 2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6
2.4. DECADE Content Consumers . . . . . . . . . . . . . . . . . 6 2.4. DECADE Content Provider . . . . . . . . . . . . . . . . . 6
2.5. Content Distribution Application . . . . . . . . . . . . . 6 2.5. DECADE Content Consumer . . . . . . . . . . . . . . . . . 7
2.6. Application End-Point . . . . . . . . . . . . . . . . . . 7 2.6. Content Distribution Application . . . . . . . . . . . . . 7
3. Architectural Principles . . . . . . . . . . . . . . . . . . . 7 2.6.1. Application End-Point . . . . . . . . . . . . . . . . 7
3.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 7 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 8 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 9 3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Explicit Control . . . . . . . . . . . . . . . . . . . . . 10 4. Architectural Principles . . . . . . . . . . . . . . . . . . . 9
3.5. Resource and Data Access Control through User 4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 10
Delegation . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 11
3.5.1. Resource Allocation . . . . . . . . . . . . . . . . . 10 4.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 12
3.5.2. User Delegations . . . . . . . . . . . . . . . . . . . 10 4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . . 12
4. System Components . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Resource and Data Access Control through User
4.1. Content Distribution Application . . . . . . . . . . . . . 13 Delegation . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Data Assembly . . . . . . . . . . . . . . . . . . . . 13 4.5.1. Resource Allocation . . . . . . . . . . . . . . . . . 12
4.1.2. Native Protocols . . . . . . . . . . . . . . . . . . . 14 4.5.2. User Delegations . . . . . . . . . . . . . . . . . . . 13
4.1.3. DECADE Client . . . . . . . . . . . . . . . . . . . . 14 5. System Components . . . . . . . . . . . . . . . . . . . . . . 13
4.2. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Content Distribution Application . . . . . . . . . . . . . 14
4.2.1. Access Control . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Data Assembly . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Resource Scheduling . . . . . . . . . . . . . . . . . 15 5.1.2. Native Protocols . . . . . . . . . . . . . . . . . . . 16
4.2.3. Data Store . . . . . . . . . . . . . . . . . . . . . . 15 5.1.3. DECADE Client . . . . . . . . . . . . . . . . . . . . 16
4.3. Protocols . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. DECADE Resource Protocol . . . . . . . . . . . . . . . 16 5.2.1. Access Control . . . . . . . . . . . . . . . . . . . . 17
4.3.2. Standard Data Transports . . . . . . . . . . . . . . . 16 5.2.2. Resource Scheduling . . . . . . . . . . . . . . . . . 17
4.4. Data Sequencing and Naming . . . . . . . . . . . . . . . . 16 5.2.3. Data Store . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. DECADE Data Object Naming Schame . . . . . . . . . . . 16 5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 18
4.4.2. Application Usage . . . . . . . . . . . . . . . . . . 17 5.3.1. DECADE Data Object Naming Scheme . . . . . . . . . . . 18
4.4.3. Application Usage Example . . . . . . . . . . . . . . 17 5.3.2. Application Usage . . . . . . . . . . . . . . . . . . 19
4.5. Token-based Authentication and Resource Control . . . . . 19 5.3.3. Application Usage Example . . . . . . . . . . . . . . 19
4.6. In-Network Storage Components Mapped to DECADE 5.4. Token-based Authentication and Resource Control . . . . . 21
Architecture . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6.1. Data Access Interface . . . . . . . . . . . . . . . . 20 6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 23
4.6.2. Data Management Operations . . . . . . . . . . . . . . 20 6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 23
4.6.3. Data Search Capability . . . . . . . . . . . . . . . . 21 6.1.1. Controlled Resources . . . . . . . . . . . . . . . . . 23
4.6.4. Access Control Authorization . . . . . . . . . . . . . 21 6.1.2. Access and Resource Control Token . . . . . . . . . . 24
4.6.5. Resource Control Interface . . . . . . . . . . . . . . 21 6.1.3. Status Information . . . . . . . . . . . . . . . . . . 25
4.6.6. Discovery Mechanism . . . . . . . . . . . . . . . . . 21 6.1.4. Object Properties . . . . . . . . . . . . . . . . . . 26
4.6.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . 21 6.2. Standard Data Transport (SDT) . . . . . . . . . . . . . . 26
5. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 21 6.2.1. Writing/Uploading Objects . . . . . . . . . . . . . . 26
5.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 22 6.2.2. Downloading Objects . . . . . . . . . . . . . . . . . 27
5.1.1. Controlled Resources . . . . . . . . . . . . . . . . . 22 7. Server-to-Server Protocols . . . . . . . . . . . . . . . . . . 28
5.1.2. Token-based Authentication and Resource Control . . . 22 7.1. Operational Overview . . . . . . . . . . . . . . . . . . . 29
5.1.3. Status Information . . . . . . . . . . . . . . . . . . 23 8. Potential Optimizations . . . . . . . . . . . . . . . . . . . 29
5.1.4. Object Properties . . . . . . . . . . . . . . . . . . 24 8.1. Pipelining to Avoid Store-and-Forward Delays . . . . . . . 30
5.2. Standard Data Transport (SDT) . . . . . . . . . . . . . . 25 8.2. Deduplication . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1. Writing/Uploading Objects . . . . . . . . . . . . . . 25 8.2.1. Traffic Deduplication . . . . . . . . . . . . . . . . 30
5.2.2. Downloading Objects . . . . . . . . . . . . . . . . . 26 8.2.2. Cross-Server Storage Deduplication . . . . . . . . . . 31
6. Server-to-Server Protocols . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6.1. Operational Overview . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Potential Optimizations . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Pipelining to Avoid Store-and-Forward Delays . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
7.2. Deduplication . . . . . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . . 32
7.2.1. Traffic Deduplication . . . . . . . . . . . . . . . . 29
7.2.2. Cross-Server Storage Deduplication . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10. Informative References . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Appendix: Evaluation of Some Candidate Existing Appendix A. Appendix: Evaluation of Some Candidate Existing
Protocols for DECADE DRP and SDT . . . . . . . . . . 31 Protocols for DECADE DRP and SDT . . . . . . . . . . 33
A.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.1.1. HTTP Support for DECADE Resource Protocol A.1.1. HTTP Support for DECADE Resource Protocol
Primitives . . . . . . . . . . . . . . . . . . . . . . 31 Primitives . . . . . . . . . . . . . . . . . . . . . . 33
A.1.2. HTTP Support for DECADE Standard Transport A.1.2. HTTP Support for DECADE Standard Data Transport
Protocol Primitives . . . . . . . . . . . . . . . . . 32 Protocol Primitives . . . . . . . . . . . . . . . . . 34
A.1.3. Traffic Deduplication Primitives . . . . . . . . . . . 33 A.1.3. Traffic De-duplication Primitives . . . . . . . . . . 35
A.1.4. Other Operations . . . . . . . . . . . . . . . . . . . 33 A.1.4. Other Operations . . . . . . . . . . . . . . . . . . . 35
A.1.5. Conclusions . . . . . . . . . . . . . . . . . . . . . 33 A.1.5. Conclusions . . . . . . . . . . . . . . . . . . . . . 35
A.2. WEBDAV . . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.2. WEBDAV . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2.1. WEBDAV Support for DECADE Resource Protocol A.2.1. WEBDAV Support for DECADE Resource Protocol
Primitives . . . . . . . . . . . . . . . . . . . . . . 34 Primitives . . . . . . . . . . . . . . . . . . . . . . 36
A.2.2. WebDAV Support for DECADE Standard Transport A.2.2. WebDAV Support for DECADE Standard Transport
Protocol Primitives . . . . . . . . . . . . . . . . . 35 Protocol Primitives . . . . . . . . . . . . . . . . . 37
A.2.3. Other Operations . . . . . . . . . . . . . . . . . . . 35 A.2.3. Other Operations . . . . . . . . . . . . . . . . . . . 37
A.2.4. Conclusions . . . . . . . . . . . . . . . . . . . . . 36 A.2.4. Conclusions . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix B. In-Network Storage Components Mapped to DECADE
Architecture . . . . . . . . . . . . . . . . . . . . 39
B.1. Data Access Interface . . . . . . . . . . . . . . . . . . 39
B.2. Data Management Operations . . . . . . . . . . . . . . . . 39
B.3. Data Search Capability . . . . . . . . . . . . . . . . . . 39
B.4. Access Control Authorization . . . . . . . . . . . . . . . 39
B.5. Resource Control Interface . . . . . . . . . . . . . . . . 39
B.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 39
B.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Peer-to-peer (P2P) applications have become widely used on the Content Distribution Applications are widely used on the Internet
Internet today to distribute contents, and they contribute a large today to distribute data, and they contribute a large portion of the
portion of the traffic in many networks. The DECADE Working Group traffic in many networks. The DECADE architecture described in this
has been formed with the goal of developing an architecture to document enables such applications to leverage in-network storage to
introduce in-network storage to be used by such applications, to
achieve more efficient content distribution. Specifically, in many achieve more efficient content distribution. Specifically, in many
subscriber networks, it is typically more expensive to upgrade subscriber networks, it can be expensive to upgrade network equipment
network equipment in the "last-mile", because it can involve in the "last-mile", because it can involve replacing equipment and
replacing equipment and upgrading wiring at individual homes, upgrading wiring at individual homes, businesses, and devices such as
businesses, and devices such as DSLAMs and CMTSs. On the other hand, DSLAMs (Digital Subscriber Line Access Multiplexers) and CMTSs (Cable
it can be cheaper to upgrade the core infrastructure, which involves Modem Termination Systems) in remote locations. Therefore, it can be
fewer components that are shared by many subscribers. See cheaper to upgrade the core infrastructure, which involves fewer
components that are shared by many subscribers. See
[I-D.ietf-decade-problem-statement] for a more complete discussion of [I-D.ietf-decade-problem-statement] for a more complete discussion of
the problem domain and general discussions of the capabilities to be the problem domain and general discussions of the capabilities to be
provided by DECADE. provided by DECADE.
This document presents a potential architecture of providing in- This document presents an architecture for providing in-network
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. In particular, content characteristics and requirements. See [I-D.ietf-decade-reqs] for a
distribution applications that may split data into smaller pieces for definition of the target applications supported by DECADE.
distribution may be able to utilize 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, the protocol of in-network storage. With such core functionalities, the protocol
may be simpler and easier to support by storage providers. If more may be simpler and easier to support by storage providers. If more
complex functionalities are needed by a certain application or class complex functionalities are needed by a certain application or class
of applications, it may be layered on top of the DECADE protocol. of applications, it may be layered on top of the DECADE protocol.
The DECADE protocol will leverage existing transport and application The DECADE protocol will leverage existing data transport and
layer protocols and will be designed to work with a small set of application layer protocols. The design is to work with a small set
alternative IETF protocols. of alternative 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 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 can guide the DECADE design. Next, architectural principles that we use to guide the DECADE design.
given these core principles, this document presents the core Next, given these core principles, this document presents the core
components of the DECADE architecture and identifies usage of components of the DECADE architecture and identifies the usage of
existing protocols and where there is a need for new protocol existing protocols and where there is a need for new protocol
development. development.
This document will be updated to track the progress of the DECADE 2. Functional Entities
survey [I-D.ietf-decade-survey] and requirements
[I-D.ietf-decade-reqs] drafts.
2. Entities This section defines the functional entities involved in a DECADE
system. Functional entities can be classified as follows:
2.1. DECADE Storage Servers o A physical or logical component in the DECADE architecture: DECADE
Client, DECADE Server, Content Distribution Application and
Application End Point;
DECADE storage servers are operated by DECADE storage providers and o Operator of a physical or logical component in the DECADE
provide the DECADE functionality as specified in this document, architecture: DECADE Storage Provider; and
including mechanisms to store, retrieve and manage data. A storage
provider may typically operate multiple storage servers.
2.2. DECADE Storage Provider o Source or sink of content distributed via the DECADE architecture:
DECADE Content Provider, and DECADE Content Consumer.
A DECADE in-network storage provider deploys and/or manages DECADE 2.1. DECADE Server
servers within a network. A storage provider may also own or manage
the network in which the DECADE servers are deployed. A DECADE server stores DECADE data inside the network, and thereafter
manages both the stored data and access to that data. To reinforce
that these servers are responsible for storage of raw data, this
document also refers to them as storage servers.
2.2. DECADE Client
A DECADE client stores and retrieves data at DECADE Servers.
2.3. DECADE Storage Provider
A DECADE storage provider deploys and/or manages DECADE storage
server(s) within a network. A storage provider may also own or
manage the network in which the DECADE servers are deployed, but this
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.3. DECADE Content Providers 2.4. DECADE Content Provider
DECADE content providers access DECADE storage servers (by way of a A DECADE content provider accesses DECADE storage servers (by way of
DECADE client) to upload and manage data. A content provider can a DECADE client) to upload and manage data. A content provider can
access one or more storage servers. A content provider may be a access one or more storage servers. A content provider may be a
single process or a distributed application (e.g., in a P2P single process or a distributed application (e.g., in a P2P
scenario). scenario), and may either be fixed or mobile.
2.4. DECADE Content Consumers 2.5. DECADE Content Consumer
DECADE content consumers access storage servers (by way of a DECADE A DECADE content consumer accesses storage servers (by way of a
client) to download data that has previously been stored by a content DECADE client) to download data that has previously been stored by a
provider. A content consumer can access one or more storage servers. DECADE content provider. A content consumer can access one or more
A content consumer may be a single process or a distributed storage servers. A content consumer may be a single process or a
application (e.g., in a P2P scenario). An instance of a distributed distributed application (e.g., in a P2P scenario), and may either be
application, such as a P2P application, may both provide content to fixed or mobile. An instance of a distributed application, such as a
and consume content from DECADE storage servers. P2P application, may both provide content to and consume content from
DECADE storage servers.
2.5. Content Distribution Application 2.6. Content Distribution Application
A content distribution application is a distributed application A content distribution application (as a target application for
designed for dissemination of possibly-large data to multiple DECADE as described in [I-D.ietf-decade-reqs]) is a distributed
consumers. Content Distribution Applications typically divide application designed for dissemination of a possibly-large data set
content into smaller immutable blocks for dissemination. to multiple consumers. Content Distribution Applications typically
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
particular Content Distribution Application. particular Content Distribution Application.
2.6. Application End-Point 2.6.1. Application End-Point
An Application End-Point is an instance of a Content Distribution An Application End-Point is an instance of a Content Distribution
Application that makes use of DECADE server(s). A particular Application that makes use of DECADE server(s). A particular
Application End-Point may be a DECADE Content Provider, a DECADE Application End-Point may be a DECADE Content Provider, a DECADE
Content Consumer, or both. Content Consumer, or both. For example, an Application End-Point may
be an instance of a video streaming client, or it may be the source
providing the video to a set of clients.
An Application End-Point need not be an active member of a "swarm" to An Application End-Point need not be actively transferring data with
interact with the DECADE storage system. That is, an End-Point may other Application End-Points to interact with the DECADE storage
interact with the DECADE storage servers as an offline activity. system. That is, an End-Point may interact with the DECADE storage
servers as an offline activity.
3. Architectural Principles 3. Protocol Flow
3.1. Overview
The DECADE Architecture uses two protocols, as shown in Figure 1.
First, the DECADE Resource Protocol is responsible for communication
of access control and resource scheduling policies from DECADE Client
to DECADE Server, as well as between DECADE Servers. The DECADE
Architecture includes exactly one DRP for interoperability and a
common format through which these policies can be communicated.
Native Application
.-------------. Protocol(s) .-------------.
| Application | <------------------> | Application |
| End-Point | | End-Point |
| | | |
| .--------. | | .--------. |
| | DECADE | | | | DECADE | |
| | Client | | | | Client | |
| `--------' | | `--------' |
`-------------' `-------------'
| ^ | ^
DECADE | | Standard | |
Resource | | Data DRP | | SDT
Protocol | | Transport | |
(DRP) | | (SDT) | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
v V v V
.=============. DRP .=============.
| DECADE | <------------------> | DECADE |
| Server | <------------------> | Server |
`=============' SDT `============='
Figure 1: Generic Protocol Flow
Second, Standard Data Transport protocols (e.g., WebDAV or NFS or
HTTP/s) are used to transfer data objects to and from a DECADE
Server. The DECADE architecture may be used with multiple standard
data transports.
Decoupling the protocols in this way allows DECADE to directly
utilize existing standard data transports, as well as allowing both
DECADE and DRP to evolve independently from data transports.
It is also important to note that the two protocols do not need to be
separate on the wire. For example, DRP messages may be piggybacked
within some extension fields provided by certain data transport
protocols. In such a scenario, DRP is technically a data structure
(transported by other protocols), but it can still be considered as a
logical protocol that provides the services of configuring DECADE
resource usage. Hence, this document considers SDT and DRP as two
separate, logical functional components for clarity.
3.2. An Example
Before discussing details of the architecture, this section provides
an example data transfer scenario to illustrate how the DECADE
Architecture can be applied.
In this example, we assume that Application End-Point B (the
receiver) is requesting a data object from Application End-Point A
(the sender). Let S(A) denote A's DECADE storage server. There are
multiple usage scenarios (by choice of the Content Distribution
Application). For simplicity of introduction, we design the example
to use only a single DECADE Server; Section 7 details a case when
both A and B wish to employ DECADE Servers.
When an Application End-Point wishes to use its DECADE storage
server, it provides a token (see Section 6.1.2 for details) to the
other Application End-Point. The token is sent using the Content
Distribution Application's native protocol.
The steps of the example are illustrated in Figure 2. First, B
requests a data object from A using their native protocol. Next, A
uses the DECADE Resource Protocol (DRP) to obtain a token from its
DECADE storage server, S(A). A then provides the token to B (again,
using their native protocol). Finally, provides the token to S(B)
via DRP, and requests and downloads the data object via a Standard
Data Transport (SDT).
.----------.
----------> | S(A) | <------
2. Obtain / `----------' \ 4. Request and
Token / \ Download Object
(DRP) / \ (DRP + SDT)
v 1. App request v
.-------------. <--------------------------- .-------------.
| End-Point A | | End-Point B |
`-------------' ---------------------------> `-------------'
3. App response (token)
Figure 2: Download from Storage Server
4. Architectural Principles
We identify the following key principles. We identify the following key principles.
3.1. Decoupled Control/Metadata and Data Planes 4.1. Decoupled Control/Metadata and Data Planes
The DECADE infrastructure is intended to support multiple content The DECADE infrastructure is intended to support multiple content
distribution applications. A complete content distribution distribution applications. A complete content distribution
application implements a set of control and management functions application implements a set of control and management functions
including content search, indexing and collection, access control, ad including content search, indexing and collection, access control, ad
insertion, replication, request routing, and QoS scheduling. A insertion, replication, request routing, and QoS scheduling. An
observation of DECADE is that different content distribution observation of DECADE is that different content distribution
applications can have unique considerations designing the control and applications can have unique considerations designing the control and
signaling functions: signaling functions:
o Metadata Management: Traditional file systems provide a standard o Metadata Management Scheme: Traditional file systems provide a
metadata abstraction: a recursive structure of directories to standard metadata abstraction: a recursive structure of
offer namespace management; each file is an opaque byte stream. directories to offer namespace management; each file is an opaque
In content distribution, applications may use different metadata byte stream. In content distribution, applications may use
management schemes. For example, one application may use a different metadata management schemes. For example, one
sequence of blocks (e.g., for file sharing), while another application may use a sequence of blocks (e.g., for file sharing),
application may use a sequence of frames (with different sizes) while another application may use a sequence of frames (with
indexed by time. For example, Apple Live Streaming uses a dynamic different sizes) indexed by time.
playlist to allow switching of frames encoded at different
encoding rates.
o Resource and Access Control: For example, a major competitive o Resource Scheduling Algorithms: a major competitive advantage of
advantage of many successful P2P systems is their substantial many successful P2P systems is their substantial expertise in
expertise in achieving highly efficient utilization of peer and achieving highly efficient utilization of peer and infrastructural
infrastructural resources. For instance, many live P2P systems resources. For instance, many live P2P systems have their
have their specific algorithms in constructing topologies to specific algorithms in constructing topologies to achieve low-
achieve low-latency, high-bandwidth streaming. They continue to latency, high-bandwidth streaming. They continue to fine-tune
fine-tune such algorithms. such algorithms.
Given the diversity of control-plane functions, in-network storage Given the diversity of control-plane functions, in-network storage
should export basic mechanisms and allow as much flexibility as should export basic mechanisms and allow as much flexibility as
possible to the control planes to implement specific policies. This possible to the control planes to implement specific policies. This
conforms to the end-to-end systems principle and allows innovation conforms to the end-to-end systems principle and allows innovation
and satisfaction of specific business goals. and satisfaction of specific business goals.
Specifically, in the DECADE architecture, the control plane focuses
on the application-specific, complex, and/or processing intensive
functions while the data plane provides storage and data transport
functions.
o Control plane: Signals details of where the data is to be
downloaded from. The control signals may also include the time,
quality of service, and receivers of the download. It also
provides higher layer meta-data management functions such as
defining the sequence of data blocks forming a higher layer
content object. These are behaviors designed and implemented by
the Application. By Application, we mean the broad sense that
includes other control plane protocols.
o Data plane: Stores and transfers basic data objects as instructed
by the Application's Control Plane.
Decoupling control plane and data plane is not new. For example, Decoupling control plane and data plane is not new. For example,
OpenFlow is an implementation of this principle for Internet routing, OpenFlow is an implementation of this principle for Internet routing,
where the computation of the forwarding table and the application of where the computation of the forwarding table and the application of
the forwarding table are separated. Google File System applies the the forwarding table are separated. Google File System applies the
principle to file system design, by utilizing the Master to handle principle to file system design, by utilizing the Master to handle
the meta-data management, and the Chunk Servers to handle the data the meta-data management, and the Chunk Servers to handle the data
plane functions (i.e., read and write of chunks of data). NFS4 also plane functions (i.e., read and write of chunks of data). NFS4 also
implements this principle. implements this principle.
Note that applications may have different Data Plane implementations Note that applications may have different Data Plane implementations
in order to support particular requirements (e.g., low latency). In in order to support particular requirements (e.g., low latency). In
order to provide interoperability, the DECADE architecture does not order to provide interoperability, the DECADE architecture does not
intend to enable arbitrary data transport protocols. However, the intend to enable arbitrary data transport protocols. However, the
architecture may allow for more-than-one data transport protocols to architecture may allow for more-than-one data transport protocols to
be used. be used.
Also note that although an application's existing control plane Also note that although an application's existing control plane
functions remain implemented within the application, the particular functions remain implemented within the application, the particular
implementation may need to be adjusted to support DECADE. implementation may need to be adjusted to support DECADE.
3.2. Immutable Data Objects 4.2. Immutable Data Objects
A property of bulk contents to be broadly distributed is that they A property of bulk contents to be broadly distributed is that they
typically are immutable -- once a piece of content is generated, it typically are immutable -- once a piece of content is generated, it
is typically not modified. It is not common that bulk contents such is typically not modified. It is not common that bulk contents such
as video frames and images need to be modified after distribution. as video frames and images need to be modified after distribution.
Many content distribution applications divide content objects into Many content distribution applications divide content objects into
blocks for two reasons: (1) multipath: different blocks may be blocks for two reasons: (1) multipath: different blocks may be
fetched from different content sources in parallel, and (2) faster fetched from different content sources in parallel, and (2) faster
recovery and verification: individual blocks may be recovered and recovery and verification: individual blocks may be recovered and
verified. Typically, applications use a block size larger than a verified. Typically, applications use a block size larger than a
single packet in order to reduce control overhead. single packet in order to reduce control overhead.
Common applications whose content matches this model include P2P Common applications using the aforementioned data model include P2P
streaming (live and video-on-demand) and P2P file-sharing content. streaming (live and video-on-demand) and P2P file-sharing. However,
However, other additional types of applications may match this model. other additional types of applications may match this model.
DECADE adopts a design in which immutable data objects may be stored DECADE adopts a design in which immutable data objects may be stored
at a storage server. Applications may consider existing blocks as at a storage server. Applications may consider existing blocks as
DECADE data objects, or they may adjust block sizes before storing in DECADE data objects, or they may adjust block sizes before storing in
a DECADE server. a DECADE server.
Focusing on immutable data blocks in the data plane can substantially Focusing on immutable data blocks in the data plane can substantially
simplify the data plane design, since consistency requirements can be simplify the data plane design, since consistency requirements can be
relaxed. It also allows effective reuse of data blocks and de- relaxed. It also allows effective reuse of data blocks and de-
duplication of redundant data. duplication of redundant data.
skipping to change at page 9, line 41 skipping to change at page 12, line 5
are agnostic to the nature of the data objects and do not specify a are agnostic to the nature of the data objects and do not specify a
fixed size for them. fixed size for them.
Note that immutable content may still be deleted. Also note that Note that immutable content may still be deleted. Also note that
immutable data blocks do not imply that contents cannot be modified. immutable data blocks do not imply that contents cannot be modified.
For example, a meta-data management function of the control plane may For example, a meta-data management function of the control plane may
associate a name with a sequence of immutable blocks. If one of the associate a name with a sequence of immutable blocks. If one of the
blocks is modified, the meta-data management function changes the blocks is modified, the meta-data management function changes the
mapping of the name to a new sequence of immutable blocks. mapping of the name to a new sequence of immutable blocks.
3.3. Data Object Identifiers Throughout this document, all the data objects/blocks are referred as
immutable data objects/blocks.
4.3. Data Object Identifiers
Objects that are stored in a DECADE storage server can be accessed by Objects that are stored in a DECADE storage server can be accessed by
DECADE content consumers by a resource identifier that has been DECADE content consumers by a resource identifier that has been
assigned within a certain application context. assigned within a certain application context.
Because a DECADE content consumer can access more than one storage Because a DECADE content consumer can access more than one storage
server within a single application context, a data object that is server within a single application context, a data object that is
replicated across different storage servers managed by a DECADE replicated across different storage servers managed by a DECADE
storage provider, can be accessed by a single identifier. storage provider, can be accessed by a single identifier.
Note that since data objects are immutable, it is possible to support Note that since data objects are immutable, it is possible to support
persistent identifiers for data objects. persistent identifiers for data objects.
3.4. Explicit Control 4.4. Explicit Control
To support the functions of an application's control plane, To support the functions of an application's control plane,
applications must be able to know and control which data is stored at applications must be able to know and control which data is stored at
particular locations. Thus, in contrast with content caches, particular locations. Thus, in contrast with content caches,
applications are given explicit control over the placement (selection applications are given explicit control over the placement (selection
of a DECADE server), deletion (or expiration policy), and access of a DECADE server), deletion (or expiration policy), and access
control for stored data. control for stored data.
Consider deletion/expiration policy as a simple example. An Consider deletion/expiration policy as a simple example. An
application may require that a DECADE server store content for a application may require that a DECADE server store content for a
relatively short period of time (e.g., for live-streaming data). relatively short period of time (e.g., for live-streaming data).
Another application may need to store content for a longer duration Another application may need to store content for a longer duration
(e.g., for video-on-demand). (e.g., for video-on-demand).
3.5. Resource and Data Access Control through User Delegation 4.5. Resource and Data Access Control through User Delegation
DECADE provides a shared infrastructure to be used by multiple DECADE provides a shared infrastructure to be used by multiple
tenants of multiple content distribution applications. Thus, it tenants of multiple content distribution applications. Thus, it
needs to provide both resource and data access control. needs to provide both resource and data access control.
3.5.1. Resource Allocation 4.5.1. Resource Allocation
There are two primary interacting entities in the DECADE There are two primary interacting entities in the DECADE
architecture. First, Storage Providers control where DECADE storage architecture. First, Storage Providers control where DECADE storage
servers are provisioned and their total available resources. Second, servers are provisioned and their total available resources. Second,
Applications control data transfers amongst available DECADE servers Applications control data transfers amongst available DECADE servers
and between DECADE servers and end-points. A form of isolation is and between DECADE servers and end-points. A form of isolation is
required to enable concurrently-running Applications to each required to enable concurrently-running Applications to each
explicitly manage their own content and share of resources at the explicitly manage its own content and share of resources at the
available servers. available servers.
The Storage Provider delegates the management of the resources at a The Storage Provider delegates the management of the resources at a
DECADE server to one or more applications. Applications are able to DECADE server to one or more applications. Applications are able to
explicitly and independently manage their own shares of resources. explicitly and independently manage their own shares of resources.
3.5.2. User Delegations 4.5.2. User Delegations
Storage providers have the ability to explicitly manage the entities Storage providers have the ability to explicitly manage the entities
allowed to utilize the resources at a DECADE server. This capability allowed to utilize the resources at a DECADE server. This capability
is needed for reasons such as capacity-planning and legal is needed for reasons such as capacity-planning and legal
considerations in certain deployment scenarios. considerations in certain deployment scenarios.
To provide a scalable way to manage applications granted resources at To provide a scalable way to manage applications granted resources at
a DECADE server, we consider an architecture that adds a layer of a DECADE server, we consider an architecture that adds a layer of
indirection. Instead of granting resources to an application, the indirection. Instead of granting resources to an application, the
DECADE server grants a share of the resources to a user. The user DECADE server grants a share of the resources to a user. The user
may in turn share the granted resources amongst multiple may in turn share the granted resources amongst multiple
applications. The share of resources granted by a storage provider applications. The share of resources granted by a storage provider
is called a User Delegation. is called a User Delegation.
A User Delegation may be granted to an end-user (e.g., an ISP As a simple example, DECADE Server operated by an ISP may be
subscriber), a Content Provider, or an Application Provider. A configured to grant each ISP Subscriber 1.5 Mbps of bandwidth. The
ISP Subscriber may in turn divide this share of resources amongst a
video streaming application and file-sharing application which are
running concurrently.
In general, a User Delegation may be granted to an end-user (e.g., an
ISP subscriber), a Content Provider, or an Application Provider. A
particular instance of an application may make use of the storage particular instance of an application may make use of the storage
resources: resources:
o granted to the end-user (with the end-user's permission), o granted to the end-user (with the end-user's permission),
o granted to the Content Provider (with the Content Provider's o granted to the Content Provider (with the Content Provider's
permission), and/or permission), and/or
o granted to the Application Provider. o granted to the Application Provider.
4. System Components 5. System Components
The primary focus of the current version of this document is on the
architectural principles. The detailed system components will be
discussed in the next document revision.
This section presents an overview of the components in the DECADE
architecture.
.--------------------------------------------------------------.
| Application End-Point |
| .------------. .-------------------. |
| | App-Layer | ... | App Data Assembly | |
| | Algorithms | | Sequencing | |
| `------------' `-------------------' |
| |
| .----------------------------------------------------------. |
| | DECADE Client | |
| | | |
| | .-------------------------. .--------------------------. | |
| | | Resource Controller | | Data Controller | | |
| | | .--------. .----------. | | .------------. .-------. | | |
Native | | | | Data | | Resource | | | | Data | | Data | | | |
App | | | | Access | | Sharing | | | | Scheduling | | Index | | | |
Protocol(s)| | | | Policy | | Policy | | | | | | | | | |
.--> | | | '--------' `----------' | | `------------' `-------' | | |
| | | `-------------------------' `--------------------------' | |
| | | | ^ | |
| | `------------ | ----------------- | -----------------------' |
| `-------------- | ----------------- | -------------------------'
| | |
v | DECADE | Standard
.-------------. | Resource | Data
| Application | | Protocol (DRP) | Transport (SDT)
| End-Point | | |
`-------------' | | Content Distribution
^ ^ | | Application
= | ===== | ============== | ================= | ==========================
| | | | DECADE Server(s)
| | | |
| | .- | ----------------- | ----------------------.
| | | | v |
| | | | .----------------. |
| | | |----> | Access Control | <--------. |
| DRP | SDT | | `----------------' | |
| | | | ^ | |
| | | | v | |
| | | | .---------------------. | |
| | | `-> | Resource Scheduling | <------| |
v v DRP | `---------------------' | |
.------------. <------> | ^ | |
| DECADE | | v .------------. |
| Server | SDT | .-----------------. | User | |
`------------' <------> | | Data Store | | Delegation | |
| `-----------------' | Management | |
| DECADE Server `------------' |
`----------------------------------------------'
Figure 1: DECADE Architecture Components
A component diagram of the DECADE architecture is displayed in The primary focus of this document is the architectural principals
Figure 1. The diagram illustrates the major components of a Content and the system components that implement them. While certain system
Distribution Application related to DECADE, as well as the functional components might differ amongst implementations, the document details
components of a DECADE Server. the major components and their overall roles in the architecture.
To keep the scope narrow, we only discuss the primary components To keep the scope narrow, we only discuss the primary components
related to protocol development. Particular deployments may require related to protocol development. Particular deployments may require
additional components (e.g., monitoring and accounting at a DECADE additional components (e.g., monitoring and accounting at a DECADE
server), but they are intentionally omitted from the current version server), but they are intentionally omitted from this document.
of this document.
4.1. Content Distribution Application 5.1. Content Distribution Application
Content Distribution Applications have many functional components. Content Distribution Applications have many functional components.
For example, many P2P applications have components to manage overlay For example, many P2P applications have components and algorithms to
topology management, piece selection, etc. In supporting DECADE, it manage overlay topology management, piece selection, etc. In
may be advantageous to consider DECADE within some of these supporting DECADE, it may be advantageous for an application
developer to consider DECADE in the implementation of these
components. However, in this architecture document, we focus on the components. However, in this architecture document, we focus on the
components directly employed to support DECADE. components directly employed to support DECADE.
4.1.1. Data Assembly Figure 3 illustrates the components discussed in this section from
the perspective of a single Application End-Point and their relation
to the DECADE protocols.
Native Protocol(s)
(with other Application End-Points)
.--------------------->
|
|
.----------------------------------------------------------.
| Application End-Point |
| .------------. .-------------------. |
| | App-Layer | ... | App Data Assembly | |
| | Algorithms | | Sequencing | |
| `------------' `-------------------' |
| |
| .------------------------------------------------------. |
| | DECADE Client | |
| | | |
| | .-------------------------. .----------------------. | |
| | | Resource Controller | | Data Controller | | |
| | | .--------. .----------. | | .--------. .-------. | | |
| | | | Data | | Resource | | | | Data | | Data | | | |
| | | | Access | | Sharing | | | | Sched. | | Index | | | |
| | | | Policy | | Policy | | | | | | | | | |
| | | '--------' `----------' | | `--------' `-------' | | |
| | `-------------------------' `----------------------' | |
| | | ^ | |
| `------------ | ----------------- | -------------------' |
`-------------- | ----------------- | ---------------------'
| |
| DECADE | Standard
| Resource | Data
| Protocol | Transport
| (DRP) | (SDT)
v V
Figure 3: Application Components
5.1.1. Data Assembly
DECADE is primarily designed to support applications that can divide DECADE is primarily designed to support applications that can divide
distributed contents into immutable data objects. To accomplish distributed contents into data objects. To accomplish this,
this, applications include a component responsible for creating the applications include a component responsible for creating the
individual data objects before distribution and then re-assembling individual data objects before distribution and then re-assembling
data objects at the Content Consumer. We call this component data objects at the Content Consumer. We call this component
Application Data Assembly. The specific implementation is entirely Application Data Assembly. The specific implementation is entirely
decided by the application. decided by the application.
In producing and assembling the data objects, two important In producing and assembling the data objects, two important
considerations are sequencing and naming. The DECADE architecture considerations are sequencing and naming. The DECADE architecture
assumes that applications implement this functionality themselves. assumes that applications implement this functionality themselves.
For example, a Content Distribution Application might divide a single See Section 5.3 for further discussion.
content (e.g., a finite-length file or a live stream) into multiple
data objects with names of the form "CONTENT_ID:SEQUENCE_NUMBER"
where CONTENT_ID identifies the particular content (e.g., a
particular movie or TV channel distributed by the application), and
SEQUENCE_NUMBER both identifies an individual data object and
determines its order when a client reconstructs individual data
objects into the full content.
4.1.2. Native Protocols 5.1.2. Native Protocols
Applications may still use existing protocols. In particular, an Applications may still use existing protocols. In particular, an
application may reuse existing protocols primarily for control/ application may reuse existing protocols primarily for control/
signaling. However, an application may still retain its existing signaling. However, an application may still retain its existing
data transport protocols, in addition to DECADE as the data transport data transport protocols, in addition to DECADE as the data transport
protocol. This can be important for applications that are designed protocol. This can be important for applications that are designed
to be highly robust (e.g., if DECADE servers are unavailable). to be highly robust (e.g., if DECADE servers are unavailable).
4.1.3. DECADE Client 5.1.3. DECADE Client
An application may be modified to support DECADE. We call the layer An application may be modified to support DECADE. We call the layer
providing the DECADE support to an application the DECADE Client. It providing the DECADE support to an application the DECADE Client. It
is important to note that a DECADE Client need not be embedded into is important to note that a DECADE Client need not be embedded into
an application. It could be implemented alone, or could be an application. It could be implemented alone, or could be
integrated in other entities such as network devices themselves. integrated in other entities such as network devices themselves.
4.1.3.1. Resource Controller 5.1.3.1. Resource Controller
Applications may have different Resource sharing policies and Data Applications may have different Resource Sharing Policies and Data
access policies to control their resource and data in DECADE servers. Access Policies to control their resource and data in DECADE servers.
These policies can be existing policies of applications (e.g., tit- These policies can be existing policies of applications (e.g., tit-
for-tat) or custom policies adapted for DECADE. The specific for-tat) or custom policies adapted for DECADE. The specific
implementation is decided by the application. implementation is decided by the application.
4.1.3.2. Data Controller 5.1.3.2. Data Controller
DECADE is designed to decouple the control and the data transport of DECADE is designed to decouple the control and the data transport of
applications. Data transport between applications and DECADE servers applications. Data transport between applications and DECADE servers
uses standard data transport protocols. It may need to schedule the uses standard data transport protocols. A Data Scheduling component
data being transferred according to network conditions, available schedules data transfers according to network conditions, available
DECADE Servers, and/or available DECADE Server resources. An index DECADE Servers, and/or available DECADE Server resources. The Data
indicates data available at remote DECADE servers. The index (or a Index indicates data available at remote DECADE servers. The Data
subset of it) may be advertised to other Application End-Points. Index (or a subset of it) may be advertised to other Application End-
Points. A common use case for this is to provide the ability to
locate data amongst a distributed set of Application End-Points
(i.e., a data search mechanism).
4.2. DECADE Server 5.2. DECADE Server
DECADE server is an important functional component of DECADE. It A DECADE Server stores data from Application End-Points, and provides
stores data from Application End-Points, and provides control and control and access of those data to Application End-Points. Note
access of those data to Application End-Points. Note that a DECADE that a DECADE Server is not necessarily a single physical machine, it
server is not necessarily a single physical machine, it could also be could also be implemented as a cluster of machines.
implemented as a cluster of machines.
4.2.1. Access Control | |
| DECADE | Standard
| Resource | Data
| Protocol | Transport
| (DRP) | (SDT)
| |
.= | ================= | ======================.
| | v |
| | .----------------. |
| |----> | Access Control | <--------. |
| | `----------------' | |
| | ^ | |
| | | | |
| | v | |
| | .---------------------. | |
| `-> | Resource Scheduling | <------| |
| `---------------------' | |
| ^ | |
| | | |
| v .------------. |
| .-----------------. | User | |
| | Data Store | | Delegation | |
| `-----------------' | Management | |
| DECADE Server `------------' |
`=============================================='
Figure 4: DECADE Server Components
5.2.1. Access Control
An Application End-Point can access its own data or other Application An Application End-Point can access its own data or other Application
End-Point's data (provided sufficient authorization) in DECADE End-Point's data (provided sufficient authorization) in DECADE
servers. Application End-Points may also authorize other End-Points servers. Application End-Points may also authorize other End-Points
to store data. If an access is authorized by an Application End- to store data. If an access is authorized by an Application End-
Point, the DECADE Server will provide access. Point, the DECADE Server will provide access.
Note that even if a request is authorized, it may still fail to Note that even if a request is authorized, it may still fail to
complete due to insufficient resources by either the requesting complete due to insufficient resources by either the requesting
Application End-Point or the providing Application End-Point. Application End-Point, the providing Application End-Point, or the
DECADE Server itself.
4.2.2. Resource Scheduling 5.2.2. Resource Scheduling
Applications may apply their existing resource sharing policies or Applications may apply their existing resource sharing policies or
use a custom policy for DECADE. DECADE servers perform resource use a custom policy for DECADE. DECADE servers perform resource
scheduling according to the resource sharing policies indicated by scheduling according to the resource sharing policies indicated by
Application End-Points as well as configured User Delegations. Application End-Points as well as configured User Delegations.
Access control and resource control are separated in DECADE server. 5.2.3. Data Store
It is possible that an Application End-Point provides only access to
its data without any resources. In order to access this data,
another Application End-Point may use the granted access along with
its own available resources to store or retrieve data from a DECADE
Server.
4.2.3. Data Store
Data from applications may be stored into disks. Data can be deleted
from disks either explicitly or automatically (e.g., after a TTL).
It may be possible to perform optimizations in certain cases, such as
avoiding writing temporary data (e.g., live streaming) to a disk.
4.3. Protocols
The DECADE Architecture uses two protocols. First, the DECADE
Resource Protocol is responsible for communicating access control and
resource scheduling policies to the DECADE Server. Second, standard
data transport protocols (e.g., WebDAV or NFS) are used to transfer
data objects to and from a DECADE Server. The DECADE architecture
will specify a small number of Standard Data Transport instances.
Decoupling the protocols in this way allows DECADE to both directly
utilize existing standard data transports and to evolve
independently.
It is also important to note that the two protocols do not need to be
separate on the wire. For example, the DECADE Resource Protocol
messages may be piggybacked within the extension fields provided by
certain data transport protocols. However, this document considers
them as two separate, logical functional components for clarity.
4.3.1. DECADE Resource Protocol
The DECADE Resource Protocol is responsible for communicating both
access control and resource sharing policies to DECADE Servers used
for data transport.
The DECADE architecture specification will provide exactly one DECADE
Resource Protocol.
4.3.2. Standard Data Transports
Existing data transport protocols are used to read and write data Data from applications may be stored at a DECADE Server. Data can be
from a DECADE Server. Protocols under consideration are WebDAV and deleted from storage either explicitly or automatically (e.g., after
NFS. a TTL expiration). It may be possible to perform optimizations in
certain cases, such as avoiding writing temporary data (e.g., live
streaming) to persistent storage, if appropriate storage hints are
supported by the SDT.
4.4. Data Sequencing and Naming 5.3. Data Sequencing and Naming
In order to provide a simple and generic interface, the DECADE Server In order to provide a simple and generic interface, the DECADE Server
is only responsible for storing and retrieving individual data is only responsible for storing and retrieving individual data
objects. Furthermore, DECADE uses its own simple naming scheme that objects. Furthermore, DECADE uses its own simple naming scheme that
provides uniqueness (with high probability) between data objects, provides uniqueness (with high probability) between data objects,
even across multiple applications. even across multiple applications.
4.4.1. DECADE Data Object Naming Schame 5.3.1. DECADE Data Object Naming Scheme
The name of a data object is derived from the hash over the data The name of a data object is derived from the hash over the data
object's content (the raw bytes), which is made possible by the fact object's content (the raw bytes), which is made possible by the fact
that DECADE objects are immutable. This scheme multiple appealing that DECADE objects are immutable. This scheme multiple appealing
properties: properties:
o Simple integrity verification o Simple integrity verification
o Unique names (with high probability) o Unique names (with high probability)
o Application independent, without a new IANA-maintained registry o Application independent, without a new IANA-maintained registry
The DECADE naming scheme also includes a "type" field, the "type" The DECADE naming scheme also includes a "type" field, the "type"
identifier indicates that the name is the hash of the data object's identifier indicates that the name is the hash of the data object's
content and the particular hashing algorithm used. This allows the content and the particular hashing algorithm used. This allows the
DECADE protocol to evolve by either changing the hashing algorithm DECADE protocol to evolve by either changing the hashing algorithm
(e.g., if security vulernabilities with an existing hashing algorithm (e.g., if security vulnerabilities with an existing hashing algorithm
are discovered), or move to a different naming scheme altogether. are discovered), or move to a different naming scheme altogether.
The specific format of the name (e.g., encoding, hash algorithms, The specific format of the name (e.g., encoding, hash algorithms,
etc) is out of scope of this document, and left for protocol etc) is out of scope of this document, and left for protocol
specification. specification.
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.
4.4.2. Application Usage 5.3.2. Application Usage
Recall from Section 4.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
sequencing used by the Application using a DECADE client. The DECADE sequencing used by the Application using a DECADE client. The DECADE
client is expected to maintain a mapping from its own data objects client is expected to maintain a mapping from its own data objects
and their names to the DECADE data objects and names. Furthermore, and their names to the DECADE data objects and names. Furthermore,
the DECADE naming scheme implies no sequencing or grouping of the DECADE naming scheme implies no sequencing or grouping of
objects, even if this is done at the application layer. objects, even if this is done at the application layer.
Not only does an Application retain its own naming scheme, it may Not only does an Application retain its own naming scheme, it may
also decide the sizes of data objects to be distributed via DECADE. also decide the sizes of data objects to be distributed via DECADE.
This is desirable since sizes of data objects may impact Application This is desirable since sizes of data objects may impact Application
performance (e.g., overhead vs. data distribution delay), and the performance (e.g., overhead vs. data distribution delay), and the
particular tradeoff is application-dependent. particular tradeoff is application-dependent.
4.4.3. Application Usage Example 5.3.3. Application Usage Example
To illustrate these properties, this section presents multiple To illustrate these properties, this section presents multiple
examples. examples.
4.4.3.1. Application with Fixed-Size Chunks 5.3.3.1. Application with Fixed-Size Chunks
Similar to the example in Section 4.1.1, consider an Application in Similar to the example in Section 5.1.1, consider an Application in
which each individual application-layer segment of data is called a which each individual application-layer segment of data is called a
"chunk" and has a name of the form: "CONTENT_ID:SEQUENCE_NUMBER". "chunk" and has a name of the form: "CONTENT_ID:SEQUENCE_NUMBER".
Furthermore, assume that the application's native protocol uses Furthermore, assume that the application's native protocol uses
chunks of size 16KB. chunks of size 16KB.
Now, assume that this application wishes to make use of DECADE, and Now, assume that this application wishes to make use of DECADE, and
assume that it wishes to store data to DECADE servers in data objects assume that it wishes to store data to DECADE servers in data objects
of size 64KB. To accomplish this, it can map a sequence of 4 chunks of size 64KB. To accomplish this, it can map a sequence of 4 chunks
into a single DECADE object, as shown in Figure 2. into a single DECADE object, as shown in Figure 5.
Application Chunks Application Chunks
.---------.---------.---------.---------.---------.---------.---------.-- .---------.---------.---------.---------.---------.---------.--------
| | | | | | | | | | | | | | |
| Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6 | | Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6
| | | | | | | | | | | | | | |
`---------`---------`---------`---------`---------`---------`---------`-- `---------`---------`---------`---------`---------`---------`--------
DECADE Data Objects DECADE Data Objects
.---------------------------------------.-------------------------------- .---------------------------------------.----------------------------
| | | |
| Object_0 | Object_1 | Object_0 | Object_1
| | | |
`---------------------------------------`-------------------------------- `---------------------------------------`----------------------------
Figure 2: Mapping Application Chunks to DECADE Data Objects Figure 5: Mapping Application Chunks to DECADE Data Objects
In this example, the Application might maintain a logical mapping In this example, the Application might maintain a logical mapping
that is able to determine the name of a DECADE data object given the that is able to determine the name of a DECADE data object given the
chunks contained within that data object. The name might be learned chunks contained within that data object. The name might be learned
from either the original source, another endpoint with which the it from either the original source, another endpoint with which the it
is communicating, a tracker, etc. is communicating, a tracker, etc.
It is important to note that as long as the data contained within It is important to note that as long as the data contained within
each sequence of chunks is unique, the corresponding DECADE data each sequence of chunks is unique, the corresponding DECADE data
objects have unique names. This is desired, and happens objects have unique names. This is desired, and happens
automatically if particular Application segments the same stream of automatically if particular Application segments the same stream of
data in a different way, including different chunk size sizes or data in a different way, including different chunk size sizes or
different padding schemes. different padding schemes.
4.4.3.2. Application with Continuous Streaming Data 5.3.3.2. Application with Continuous Streaming Data
Next, consider an Application whose native protocol retrieves a Next, consider an Application whose native protocol retrieves a
continuous data stream (e.g., an MPEG2 stream) instead of downloading continuous data stream (e.g., an MPEG2 stream) instead of downloading
and redistributing chunks of data. Such an application could segment and redistributing chunks of data. Such an application could segment
the continuous data stream to produce either fixed-sized or variable- the continuous data stream to produce either fixed-sized or variable-
sized DECADE data objects. sized DECADE data objects.
Figure 3 shows how a video streaming application might produce Figure 6 shows how a video streaming application might produce
variable-sized DECADE data objects such that each DECADE data object variable-sized DECADE data objects such that each DECADE data object
contains 10 seconds of video data. contains 10 seconds of video data.
Application's Video Stream Application's Video Stream
.------------------------------------------------------------------------ .--------------------------------------------------------------------
| |
| |
| |
`------------------------------------------------------------------------ `--------------------------------------------------------------------
^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | |
0 Seconds 10 Seconds 20 Seconds 30 Seconds 40 Seconds 0 Seconds 10 Seconds 20 Seconds 30 Seconds 40 Seconds
0 B 400 KB 900 KB 1200 KB 1500 KB 0 B 400 KB 900 KB 1200 KB 1500 KB
DECADE Data Objects DECADE Data Objects
.--------------.--------------.--------------.--------------.------------ .--------------.--------------.--------------.--------------.--------
| | | | | | | | | |
| Object_0 | Object_1 | Object_2 | Object_3 | | Object_0 | Object_1 | Object_2 | Object_3 |
| (400 KB) | (500 KB) | (300 KB) | (300 KB) | | (400 KB) | (500 KB) | (300 KB) | (300 KB) |
`--------------`--------------`--------------`--------------`------------ `--------------`--------------`--------------`--------------`--------
Figure 3: Mapping a Continuous Data Stream to DECADE Data Objects Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects
Similar to the previous example, the Application might maintain a Similar to the previous example, the Application might maintain a
mapping that is able to determine the name of a DECADE data object mapping that is able to determine the name of a DECADE data object
given the time offset of the video chunk. given the time offset of the video chunk.
4.5. Token-based Authentication and Resource Control 5.4. Token-based Authentication and Resource Control
A primary use case for DECADE is a DECADE Client authorizing other A primary use case for DECADE is a DECADE Client authorizing other
DECADE Clients to store or retrieve data objects from its DECADE DECADE Clients to store or retrieve data objects from its DECADE
storage. To support this, DECADE uses a token-based authentication storage. To support this, DECADE uses a token-based authentication
scheme. scheme.
In particular, an entity trusted by a DECADE Client generates a In particular, an entity trusted by a DECADE Client generates a
digitally-signed token with particular properties (see Section 5.1.2 digitally-signed token with particular properties (see Section 6.1.2
for details). The DECADE Client distributes this token to other for details). The DECADE Client distributes this token to other
DECADE Clients which then use the token when sending requests to the DECADE Clients which then use the token when sending requests to the
DECADE Server. Upon receiving a token, the DECADE Server validates DECADE Server. Upon receiving a token, the DECADE Server validates
the signature and the operation being performed. the signature and the operation being performed.
This is a simple scheme, but has multiple important advantages over This is a simple scheme, but has multiple important advantages over
an alternate approach in which a DECADE Client explicitly manipulates an alternate approach in which a DECADE Client explicitly manipulates
an Access Control List (ACL) associated with each DECADE data object. an Access Control List (ACL) associated with each DECADE data object.
In particular, it has the following advantages when applied to In particular, it has the following advantages when applied to
DECADE's target applications: DECADE's target applications:
o Authorization policies are implemented within the Application; an o Authorization policies are implemented within the Application; an
Application explicitly controls when tokens are generated and to Application explicitly controls when tokens are generated and to
whom they are distributed. whom they are distributed.
o Fine-grained access and resource control can be applied to data o Fine-grained access and resource control can be applied to data
objects; see Section 5.1.2 for the list of restrictions that can objects; see Section 6.1.2 for the list of restrictions that can
be enforced with a token. be enforced with a token.
o There is no messaging between a DECADE Client and DECADE Server to o There is no messaging between a DECADE Client and DECADE Server to
manipulate data object permissions. This can simplify, in manipulate data object permissions. This can simplify, in
particular, Applications which share data objects with many particular, Applications which share data objects with many
dynamic peers and need to frequently adjust access control dynamic peers and need to frequently adjust access control
policies attached to DECADE data objects. policies attached to DECADE data objects.
o Tokens can provide anonymous access, in which a DECADE Server does o Tokens can provide anonymous access, in which a DECADE Server does
not need to know the identity of each DECADE Client that accesses not need to know the identity of each DECADE Client that accesses
skipping to change at page 20, line 29 skipping to change at page 22, line 29
in other administrative or security domains, and allow them to in other administrative or security domains, and allow them to
read or write data objects from its DECADE storage. read or write data objects from its DECADE storage.
It is important to note that, in addition to DECADE Clients applying It is important to note that, in addition to DECADE Clients applying
access control policies to DECADE data objects, the DECADE Server may access control policies to DECADE data objects, the DECADE Server may
be configured to apply additional policies based on user, object, be configured to apply additional policies based on user, object,
geographic location, etc. Defining such policies is out of scope of geographic location, etc. Defining such policies is out of scope of
the DECADE Working Group, but in such a case, a DECADE Client may be the DECADE Working Group, but in such a case, a DECADE Client may be
denied access even though it possess a valid token. denied access even though it possess a valid token.
4.6. In-Network Storage Components Mapped to DECADE Architecture 5.5. Discovery
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]
map into the DECADE architecture.
It is important to note that complex and/or application-specific
behavior is delegated to applications instead of tuning the storage
system wherever possible.
4.6.1. Data Access Interface
Users can read and write objects of arbitrary size through the DECADE
Client's Data Controller, making use of a standard data transport.
4.6.2. Data Management Operations
Users can move or delete previously stored objects via the DECADE
Client's Data Controller, making use of a standard data transport.
4.6.3. Data Search Capability
Users can enumerate or search contents of DECADE servers to find
objects matching desired criteria through services provided by the
Content Distribution Application (e.g., buffer-map exchanges, a DHT,
or peer-exchange). In doing so, End-Points may consult their local
data index in the DECADE Client's Data Controller.
4.6.4. Access Control Authorization
All methods of access control are supported: public-unrestricted,
public-restricted and private. Access Control Policies are generated
by a Content Distribution Application and provided to the DECADE
Client's Resource Controller. The DECADE Server is responsible for
implementing the access control checks.
4.6.5. Resource Control Interface
Users can manage the resources (e.g. bandwidth) on the DECADE server
that can be used by other Application End-Points. Resource Sharing
Policies are generated by a Content Distribution Application and
provided to the DECADE Client's Resource Controller. The DECADE
Server is responsible for implementing the resource sharing policies.
4.6.6. Discovery Mechanism DECADE includes a discovery mechanism through which DECADE clients
locate an appropriate DECADE Server. [I-D.ietf-decade-reqs] details
specific requirements of the discovery mechanism; this section
discusses how they relate to other principles outlined in this
document.
This is outside the scope of the DECADE architecture. However, it is A discovery mechanism allows a DECADE client to determine an IP
expected that DNS or some other well known protocol will be used for address or some other identifier that can be resolved to locate the
the users to discover the DECADE servers. server for which the client will be authorized to generate tokens
(via DRP). (Note that the discovery mechanism may also result in an
error if no such DECADE servers can be located.) After discovering
one or more DECADE servers, a DECADE client may distribute load and
requests across them (subject to resource limitations and policies of
the DECADE servers themselves) according to the policies of the
Application End-Point in which it is embedded.
4.6.7. Storage Mode The particular protocol used for discovery is out of scope of this
document, but any specification will re-use standard protocols
wherever possible.
DECADE Servers provide an object-based storage mode. Immutable data It is important to note that the discovery mechanism outlined here
objects may be stored at a DECADE server. Applications may consider does not provide the ability to locate arbitrary DECADE servers to
existing blocks as DECADE data objects, or they may adjust block which a DECADE client might obtain tokens from others. To do so
sizes before storing in a DECADE server. requires application-level knowledge, and it is assumed that this
functionality is implemented in the Content Distribution Application,
or if desired and needed, as an extension to this DECADE
architecture.
5. DECADE Protocols 6. DECADE Protocols
This section specifies the DECADE Resource Protocol (DRP) and the This section specifies the DECADE Resource Protocol (DRP) and the
Standard Data Transport (SDT) in terms of abstract protocol Standard Data Transport (SDT) in terms of abstract protocol
interactions that are intended to mapped to specific protocols. Note interactions that are intended to mapped to specific protocols. Note
that while the protocols are logically separate, DRP is specified as that while the protocols are logically separate, DRP is specified as
being carried through extension fields within an SDT (e.g., HTTP being carried through extension fields within an SDT (e.g., HTTP
headers). headers).
The DRP is the protocol used by a DECADE client to configure the The DRP is the protocol used by a DECADE client to configure the
resources and authorization used to satisfy requests (reading, resources and authorization used to satisfy requests (reading,
writing, and management operations concerning DECADE objects) at a writing, and management operations concerning DECADE objects) at a
DECADE server. The SDT is used to send the operations to the DECADE DECADE server. The SDT is used to send the operations to the DECADE
server. Necessary DRP metadata is supplied using mechanisms in the server. Necessary DRP metadata is supplied using mechanisms in the
SDT that are provided for extensibility (e.g., additional request SDT that are provided for extensibility (e.g., additional request
parameters or extension headers). parameters or extension headers).
5.1. DECADE Resource Protocol (DRP) 6.1. DECADE Resource Protocol (DRP)
DRP provides configuration of access control and resource sharing DRP provides configuration of access control and resource sharing
policies on DECADE servers. A content distribution application, policies on DECADE servers. A content distribution application,
e.g., a live P2P streaming session, MAY employ several DECADE e.g., a live P2P streaming session, MAY employ several DECADE
servers, for instance, servers in different operator domains, and DRP servers, for instance, servers in different operator domains, and DRP
allows one instance of such an application, e.g., an application allows one instance of such an application, e.g., an application
endpoint, to configure access control and resource sharing policies endpoint, to apply access control and resource sharing policies on
on a set of servers. each of them.
5.1.1. Controlled Resources 6.1.1. Controlled Resources
On a single DECADE server, the following resources may be managed: On a single DECADE server, the following resources may be managed:
communication resources: DECADE servers have limited communication communication resources: DECADE servers have limited communication
resources in terms of bandwidth (upload/download) but also in resources in terms of bandwidth (upload/download) but also in
terms of number of connected clients (connections) at a time. terms of number of connected clients (connections) at a time.
storage resources: DECADE servers have limited storage resources. storage resources: DECADE servers have limited storage resources.
5.1.2. Token-based Authentication and Resource Control 6.1.2. Access and Resource Control Token
DECADE uses a token-based scheme that allows a DECADE Client to A token includes the following fields:
authorize other DECADE Clients to perform certain actions (e.g., read
or write data objects) on the client's DECADE Server. The token
includes the following fields:
Permitted operations (e.g., read, write) Permitted operations (e.g., read, write)
Permitted objects (e.g., names of data objects that may be read or Permitted objects (e.g., names of data objects that may be read or
written) written)
Permitted clients (e.g., as indicated by IP address or other Permitted clients (e.g., as indicated by IP address or other
identifier) that may use the token identifier) that may use the token
Expiration time Expiration time
Priority for bandwidth given to requested operation Priority for bandwidth given to requested operation (e.g., a
weight used in a weighted bandwidth sharing scheme)
Amount of data that may be read or written Amount of data that may be read or written
The particular format for the token is out of scope of this document. The particular format for the token is out of scope of this document.
The tokens are generated by a trusted entity at the request of a The tokens are generated by a trusted entity at the request of a
DECADE Client. It is out of scope of this document to identify which DECADE Client. It is out of scope of this document to identify which
entity serves this purpose, but examples include the DECADE Client entity serves this purpose, but examples include the DECADE Client
itself, a DECADE Server trusted by the DECADE Client, or another itself, a DECADE Server trusted by the DECADE Client, or another
server managed by a Storage Provider trusted by the DECADE Client. server managed by a Storage Provider trusted by the DECADE Client.
skipping to change at page 23, line 28 skipping to change at page 24, line 47
Server validates the token to identify the DECADE Client that issued Server validates the token to identify the DECADE Client that issued
it and whether the requested operation is permitted by the contents it and whether the requested operation is permitted by the contents
of the token. If the token is successfully validated, the DECADE of the token. If the token is successfully validated, the DECADE
Server applies the resource control policies indicated in the token Server applies the resource control policies indicated in the token
while performing the operation. while performing the operation.
It is possible for DRP to allow tokens to apply to a batch of It is possible for DRP to allow tokens to apply to a batch of
operations to reduce communication overhead required between DECADE operations to reduce communication overhead required between DECADE
Clients. Clients.
DRP may also define tokens to include a unique identifer to allow a DRP may also define tokens to include a unique identifier to allow a
DECADE Server to detect when a token is used multiple times. DECADE Server to detect when a token is used multiple times.
5.1.3. Status Information 6.1.3. Status Information
DRP provides a request service for status information that DECADE DRP provides a request service for status information that DECADE
clients can use to request information from a DECADE server. clients can use to request information from a DECADE server.
status information per application context on a specific server: status information per application context on a specific server:
Access to such status information requires client authorization, Access to such status information requires client authorization,
i.e., DECADE clients need to be authorized to access status i.e., DECADE clients need to be authorized to access status
information for a specific application context. This information for a specific application context. This
authorization (and the mapping to application contexts) is based authorization (and the mapping to application contexts) is based
on the user delegation concept as described in Section 3.5. The on the user delegation concept as described in Section 4.5. The
following status information elements can be obtained: following status information elements can be obtained:
* list of associated objects (with properties) * list of associated objects (with properties)
* resources used/available * resources used/available
* list of servers to which objects have been distributed (in a * list of servers to which objects have been distributed (in a
certain time-frame) certain time-frame)
* list of clients to which objects have been distributed (in a * list of clients to which objects have been distributed (in a
skipping to change at page 24, line 18 skipping to change at page 25, line 41
time frame in the response to such requests. Some of this time frame in the response to such requests. Some of this
information can be used for accounting purposes, e.g., the list of information can be used for accounting purposes, e.g., the list of
clients to which objects have been distributed. clients to which objects have been distributed.
access information per application context on a specific server: access information per application context on a specific server:
Access information can be provided for accounting purposes, for Access information can be provided for accounting purposes, for
example, when application service providers are interested to example, when application service providers are interested to
maintain access statistics for resources and/or to perform maintain access statistics for resources and/or to perform
accounting per user. Again, access to such information requires accounting per user. Again, access to such information requires
client authorization based on the user delegation concept as client authorization based on the user delegation concept as
described in Section 3.5. The following access information described in Section 4.5. The following access information
elements can be requested: elements can be requested:
* what objects have been accessed how many times * what objects have been accessed how many times
* access tokens that a server as seen for a given object * access tokens that a server as seen for a given object
The DECADE server can decide on time bounds for which this The DECADE server can decide on time bounds for which this
information is stored and specify the corresponding time frame in information is stored and specify the corresponding time frame in
the response to such requests. the response to such requests.
5.1.4. Object Properties 6.1.4. Object Properties
Objects that are stored on a DECADE server can provide properties (in Objects that are stored on a DECADE server can provide properties (in
addition to the object identifier and the actual content). Depending addition to the object identifier and the actual content). Depending
on authorization, DECADE clients may get or set such properties. on authorization, DECADE clients may get or set such properties.
This authorization (and the mapping to application contexts) is based This authorization (and the mapping to application contexts) is based
on the user delegation concept as described in Section 3.5. The on the user delegation concept as described in Section 4.5. The
DECADE architecture does not limit the set of permissible properties, DECADE architecture does not limit the set of permissible properties,
but rather specifies a set of baseline properties that SHOULD be but rather specifies a set of baseline properties that SHOULD be
supported by implementations. supported by implementations.
TTL: TTL of the object as an absolute time value TTL: TTL of the object as an absolute time value
object size: in bytes object size: in bytes
MIME type MIME type
access statistics: how often the object has been accessed (and what access statistics: how often the object has been accessed (and what
tokens have been used) tokens have been used)
5.2. Standard Data Transport (SDT) 6.2. Standard Data Transport (SDT)
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.
5.2.1. Writing/Uploading Objects An SDT used in DECADE SHOULD offer a transport mode that provides
confidentiality and integrity.
6.2.1. Writing/Uploading Objects
For writing objects, a client uploads an object to a DECADE server. For writing objects, a client uploads an object to a DECADE server.
The object on the server will be named (associated to an identifier), The object on the server will be named (associated to an identifier),
and this name can be used to access (download) the object later, and this name can be used to access (download) the object later,
e.g., the client can pass the name as a reference to other client e.g., the client can pass the name as a reference to other client
that can then refer to the object. 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 MUST 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 4.4. 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.
In the following we provide an abstract specification of the upload In the following we provide an abstract specification of the upload
operation that we name 'PUT METHOD'. See Appendix A.1 for an example operation that we name 'PUT METHOD'. See Appendix A.1 for an example
how this could be mapped to HTTP. how this could be mapped to HTTP.
Method PUT: Method PUT:
Parameters: Parameters:
NAME: The naming of the object according to Section 4.4 NAME: The naming of the object according to Section 5.3
OBJECT: The object itself. The protocol MUST provide transparent OBJECT: The object itself. The protocol MUST provide transparent
binary object transport. binary object transport.
Description: The PUT method is used by a DECADE client to upload an Description: The PUT method is used by a DECADE client to upload an
object with an associated name 'NAME' to a DECADE server. object with an associated name 'NAME' to a DECADE server.
RESPONSES: The DECADE server MUST respond with one the following RESPONSES: The DECADE server MUST respond with one the following
response messages: response messages:
OK: The object has been uploaded successfully and has replaced an
existing object with the same name.
CREATED: The object has been uploaded successfully and is now CREATED: The object has been uploaded successfully and is now
available under the specified name. available under the specified name.
ERRORs: possible error codes later will be specified in a later ERRORs: There was an error uploading the content
version of this document
5.2.2. Downloading Objects 6.2.2. Downloading Objects
A DECADE client can request named objects from a DECADE server. In A DECADE client can request named objects from a DECADE server. In
the following, we provide an abstract specification of the download the following, we provide an abstract specification of the download
operation that we name 'GET METHOD'. See Section 4.4 for an example operation that we name 'GET METHOD'. See Section 5.3 for an example
how this could be mapped to HTTP. how this could be mapped to HTTP.
Method GET: Method GET:
Parameters: Parameters:
NAME: The naming of the object according to Section 4.4. NAME: The naming of the object according to Section 5.3.
Description: The GET method is used by a DECADE client to download Description: The GET method is used by a DECADE client to download
an object with an associated name 'NAME' from a DECADE server. an object with an associated name 'NAME' from a DECADE server.
RESPONSES: The DECADE server MUST respond with one the following RESPONSES: The DECADE server MUST respond with one the following
response messages: response messages:
OK: The request has succeeded, and an entity corresponding to the OK: The request has succeeded, and an entity corresponding to the
requested resource is sent in the response. requested resource is sent in the response.
ERRORs: ERRORs:
NOTFOUND: The DECADE server has not found anything matching NOTFOUND: The DECADE server has not found anything matching
the request object name. the request object name.
Other Errors: TBD in a future version of this document Other Errors: TBD in a future version of this document
6. 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 data objects from another DECADE server.
This capability allows Applications to directly replicate data This capability allows Applications to directly replicate data
objects between servers without requiring end-hosts to use uplink objects between servers without requiring end-hosts to use uplink
capacity to upload data objects to a different DECADE server. capacity to upload data objects to a different DECADE server.
Similar to other operations in DRP and SDT, replicating data objects Similar to other operations in DRP and SDT, replicating data objects
between DECADE servers is an explicit operation. between DECADE servers is an explicit operation.
To support this functionality, DECADE re-uses the already-specified To support this functionality, DECADE re-uses the already-specified
skipping to change at page 27, line 32 skipping to change at page 28, line 48
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 (PUT or 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 is also a DECADE client, and requests
may instantiate requests via that client. The operations are may instantiate requests via that client. The operations are
performed as if the original requestor had its own DECADE client co- performed as if the original requester had its own DECADE client co-
located with the DECADE server. It is this mode of operation that located with the DECADE server. It is this mode of operation that
provides substantial savings in uplink capacity. provides substantial savings in uplink capacity.
6.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.
REMOTE_USER: The account at the remote server from which to retrieve REMOTE_USER: The account at the remote server from which to retrieve
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
skipping to change at page 28, line 25 skipping to change at page 29, line 43
time). 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 return the object
to the client. In the case of a PUT operation, the DECADE server is to the client. In the case of a PUT operation, the DECADE server is
to store the object from the client, and then store the object to the to store the object from the client, and then store the object to the
remote server using the specified credentials (via a PUT request to remote server using the specified credentials (via a PUT request to
the remote server). the remote server).
7. 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.
7.1. Pipelining to Avoid Store-and-Forward Delays 8.1. Pipelining to Avoid Store-and-Forward Delays
DECADE server may choose to not fully store an object before A DECADE server may choose to not fully store an object before
beginning to serve it. For example, in the case of a GET request, a beginning to serve it. For example, when serving a GET request,
DECADE server may begin to receive a data object from a remote server instead of waiting for the complete data to arrive from a remote
or DECADE Client, and immediately begin returning it to the DECADE server or DECADE client, a DECADE server may forward received data
client. This pipelining mode avoids store-and-forward delays, which bytes as they come in. This pipelining mode reduces store-and-
could be substantial for large objects. A similar behavior could be forward delays, which could be substantial for large objects. A
used for PUT. similar behavior could be used for PUT.
7.2. Deduplication 8.2. Deduplication
A common concern amongst Storage Providers is the total volume of A common concern amongst Storage Providers is the total volume of
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 techniques which attempt existing storage systems is de-duplication, which attempts to avoid
to avoid storing identical data multiple times. DECADE Server storing identical data multiple times. A DECADE Server
implementations may internally perform de-duplication of data on implementation may internally perform de-duplication of data on disk.
disk, but the DECADE architecture enables other forms of de- The DECADE architecture enables additional forms of de-duplication.
duplication.
Note that these techniques may impact protocol design. Discussion of Note that these techniques may impact protocol design. Discussions
whether or not they should be adopted is out of scope of this of whether or not they should be adopted is out of the scope of this
document. document.
7.2.1. Traffic Deduplication 8.2.1. Traffic Deduplication
7.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 Deduplication. This means that S does
not download the object from R, which saves network traffic. not download the object from R, in order to save network traffic. In
Instead, it performs a challenge to make sure that the remote entity particular, S performs a challenge to make sure that the remote
R actually has the object and then replies with its local object copy entity R actually has the object and then replies with its local
directly. object copy directly.
7.2.1.2. Example 8.2.1.2. An Example
As shown in Figure 4 , without Traffic Deduplication, redundant As shown in Figure 7, without Traffic Deduplication, unnecessary
traffic flows between S and R will be issued if the server 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 Deduplication is enabled, S
only needs to challenge R to verify that it does have the data to 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 Deduplication
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 Deduplication
Figure 4 Figure 7
7.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 deduplication with HTTP is shown in
Appendix A.1.3. Appendix A.1.3.
7.2.2. Cross-Server Storage Deduplication 8.2.2. Cross-Server Storage Deduplication
The same object might be uploaded for multiple times to different The same object might be uploaded multiple times to different DECADE
DECADE servers. For storage efficiency, storage providers may desire servers. For storage efficiency, storage providers may desire that a
a single object to be stored on one or a few servers. They might single object be stored on one or a few servers. They might
design internal system architecture to achieve that, or simply implement an internal mechanism to achieve the goal, for example, by
redirect the requests to proper servers. DECADE protocol support redirecting requests to proper servers. The DECADE protocol supports
redirections of DECADE client request to support further cross-server the redirection of DECADE client requests to support further cross-
storage deduplication. server storage deduplication.
8. Security Considerations 9. Security Considerations
This document currently does not contain any security considerations In general, the security considerations mentioned in
beyond those mentioned in [I-D.ietf-decade-problem-statement]. [I-D.ietf-decade-problem-statement] apply to this document as well.
9. IANA Considerations In addition, it should be noted that the token-based approach
Section 5.4 provides authorization through token delegation. The
strength of this authorization depends on several factors:
1. the uniqueness of tokens: tokens should be constructed in a way
that minimize the possibilities for collisions;
2. validity of tokens: applications/users should not re-use tokens;
and
3. secrecy of tokens: if tokens are compromised to unauthorized
entities, access control for the associated resources cannot be
provided.
Depending on the specific application, DECADE can be used to access
confidential information. Hence DECADE implementations SHOULD
provide a secure transport mode that allows for encryption.
10. IANA Considerations
This document does not have any IANA considerations. This document does not have any IANA considerations.
10. Informative References 11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.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 31, line 23 skipping to change at page 33, line 21
progress), May 2011. progress), May 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>.
Appendix A. Appendix: Evaluation of Some Candidate Existing Protocols Appendix A. Appendix: Evaluation of Some Candidate Existing Protocols
for DECADE DRP and SDT for DECADE DRP and SDT
In this section we evaluate how well the abstract protocol In this section we evaluate how well the abstract protocol
interactions specified in Section 5 for DECADE DRP and SDT can be interactions specified in Section 6 for DECADE DRP and SDT can be
fulfilled by existing protocols such as HTTP and WEBDAV. fulfilled by existing protocols such as HTTP and WEBDAV.
A.1. HTTP A.1. HTTP
HTTP [RFC2616] is a key protocol for the Internet in general and HTTP [RFC2616] is a key protocol for the Internet in general and
especially for the World Wide Web. HTTP is a request-response especially for the World Wide Web. HTTP is a request-response
protocol. A typical transaction involves a client (e.g. web browser) protocol. A typical transaction involves a client (e.g. web browser)
requesting content (resources) from a web server. Another example is requesting content (resources) from a web server. Another example is
when a client stores or deletes content from a server. when a client stores or deletes content from a server.
skipping to change at page 32, line 15 skipping to change at page 34, line 15
A.1.1.2. Communication Resource Controls Primitives A.1.1.2. Communication Resource Controls Primitives
Communications resources include bandwidth (upload/download) and Communications resources include bandwidth (upload/download) and
number of simultaneous connected clients (connections). HTTP number of simultaneous connected clients (connections). HTTP
supports bandwidth control indirectly through "persistent" HTTP supports bandwidth control indirectly through "persistent" HTTP
connections. Persistent HTTP connections allows a client to keep connections. Persistent HTTP connections allows a client to keep
open the underlying TCP connection to the server to allow streaming open the underlying TCP connection to the server to allow streaming
and pipelining (multiple simultaneous requests for a given client). and pipelining (multiple simultaneous requests for a given client).
HTTP does not define protocol operation to allow limiting the HTTP does not define protocol operation to allow limiting the
communciation resources to a client. However servers typically communication resources to a client. However servers typically
perform this function via implementation algorithms. perform this function via implementation algorithms.
A.1.1.3. Storage Resource Control Primitives A.1.1.3. Storage Resource Control Primitives
Storage resources include amount of memory and lifetime of storage. Storage resources include amount of memory and lifetime of storage.
HTTP does not allow direct control of storage at the server end HTTP does not allow direct control of storage at the server end
point. However HTTP supports caching at intermediate points such as point. However HTTP supports caching at intermediate points such as
a web proxy. For this purpose, HTTP defines cache control mechanisms a web proxy. For this purpose, HTTP defines cache control mechanisms
that define how long and in what situations the intermediate point that define how long and in what situations the intermediate point
may store and use the content. may store and use the content.
A.1.2. HTTP Support for DECADE Standard Transport Protocol Primitives A.1.2. HTTP Support for DECADE Standard Data Transport Protocol
Primitives
SDT is used to write objects and read (download) objects from a SDT is used to write objects and read (download) objects from a
DECADE server. The object can be either a self-contained object such DECADE server. The object can be either a self-contained object such
as a multimedia file or a chunk from a P2P system. as a multimedia file or a chunk from a P2P system.
A.1.2.1. Writing Primitives A.1.2.1. Writing Primitives
Writing involves uploading objects to the server. HTTP supports two Writing involves uploading objects to the server. HTTP supports two
methods of writing called PUT and POST. In HTTP the object is called methods of writing called PUT and POST. In HTTP the object is called
a resource and is identified by a URI. PUT uploads a resource to a a resource and is identified by a URI. PUT uploads a resource to a
skipping to change at page 32, line 52 skipping to change at page 35, line 4
For DECADE, the choice of whether to use PUT or POST will be For DECADE, the choice of whether to use PUT or POST will be
influenced by which entity is responsible for the naming. If the influenced by which entity is responsible for the naming. If the
client performs the naming, then PUT is appropriate. If the server client performs the naming, then PUT is appropriate. If the server
performs the naming, then POST should be used (to allow the server to performs the naming, then POST should be used (to allow the server to
define the URI). define the URI).
A.1.2.2. Downloading Primitives A.1.2.2. Downloading Primitives
Downloading involves fetching of an object from the server. HTTP Downloading involves fetching of an object from the server. HTTP
supports downloading through the GET and HEAD methods. GET fetches a supports downloading through the GET and HEAD methods. GET fetches a
specific resource as identified by the URL. HEAD is similiar but specific resource as identified by the URL. HEAD is similar but only
only fetches the metadata ("header") associated with the resource but fetches the metadata ("header") associated with the resource but not
not the resource itself. the resource itself.
A.1.3. Traffic Deduplication Primitives A.1.3. Traffic De-duplication Primitives
To challenge a remote entity for an object, the DECADE server should To challenge a remote entity for an object, the DECADE server should
provide a seed number, which is generated by the server randomly, and provide a seed number, which is generated by the server randomly, and
ask the remote entity to return a hash calculated from the seed ask the remote entity to return a hash calculated from the seed
number and the content of the object. The server MAY also specify number and the content of the object. The server MAY also specify
the hash function which the remote entity should use. HTTP supports the hash function which the remote entity should use. HTTP supports
the challenge message through the GET methods. The message type the challenge message through the GET methods. The message type
("challenge"), the seed number and the hash funtion name are put in ("challenge"), the seed number and the hash function name are put in
URL. In the reply, the hash is sent in an ETAG header. URL. In the reply, the hash is sent in an ETAG header.
A.1.4. Other Operations A.1.4. Other Operations
HTTP supports deleting of content on the server through the DELETE HTTP supports deleting of content on the server through the DELETE
method. method.
A.1.5. Conclusions A.1.5. Conclusions
HTTP can provide a rudimentary DRP and SDT for some aspects of HTTP can provide a rudimentary DRP and SDT for some aspects of
skipping to change at page 36, line 5 skipping to change at page 38, line 5
WebDAV supports COPY and MOVE methods. The COPY operation creates a WebDAV supports COPY and MOVE methods. The COPY operation creates a
duplicate of the source resource identified by the Request-URI, in duplicate of the source resource identified by the Request-URI, in
the destination resource identified by the URI in the Destination the destination resource identified by the URI in the Destination
header. header.
The MOVE operation on a resource is the logical equivalent of a COPY, The MOVE operation on a resource is the logical equivalent of a COPY,
followed by consistency maintenance processing, followed by a delete followed by consistency maintenance processing, followed by a delete
of the source, where all three actions are performed in a single of the source, where all three actions are performed in a single
operation. The consistency maintenance step allows the server to operation. The consistency maintenance step allows the server to
perform updates caused by the move, such as updating all URLs, other perform updates caused by the move, such as updating all URLs, other
than the Request-URI that identifiesthe source resource, to point to than the Request-URI that identifies the source resource, to point to
the new destination resource. the new destination resource.
WebDAV also supports the concept of "collections" of resources to WebDAV also supports the concept of "collections" of resources to
support joint operations on related objects (e.g. file system support joint operations on related objects (e.g. file system
directories) within a server's namespace. For example, GET and HEAD directories) within a server's namespace. For example, GET and HEAD
may be done on a single resource (as in HTTP) or on a collection. may be done on a single resource (as in HTTP) or on a collection.
The MKCOL operation is used to create a new collection. DECADE may The MKCOL operation is used to create a new collection. DECADE may
find the concept of collections to be useful if there is a need to find the concept of collections to be useful if there is a need to
support directory like structures in DECADE. support directory like structures in DECADE.
WebDAV servers can be interfaced from an HTML-based user interface in WebDAV servers can be interfaced from an HTML-based user interface in
a web browser. However, it is frequently desirable to be able to a web browser. However, it is frequently desirable to be able to
switch from an HTML-based view to a persentation provided by a native switch from an HTML-based view to a presentation provided by a native
WebDAV client, directly supporting WebDAV features. The method to WebDAV client, directly supporting WebDAV features. The method to
perform this in a platform-neutral mechanism is specified in the perform this in a platform-neutral mechanism is specified in the
WebDAV protocol for "mounting WebDAV servers" [RFC4709]. This type WebDAV protocol for "mounting WebDAV servers" [RFC4709]. This type
of feature may also be attractive for DECADE clients. of feature may also be attractive for DECADE clients.
A.2.4. Conclusions A.2.4. Conclusions
WebDAV has a rich array of features that can provide a good base for WebDAV has a rich array of features that can provide a good base for
DRP and SDT for DECADE. An initial analysis finds that the following DRP and SDT for DECADE. An initial analysis finds that the following
WebDAV features will be useful for DECADE: WebDAV features will be useful for DECADE:
skipping to change at page 37, line 5 skipping to change at page 39, line 5
DECADE: DECADE:
- LOCK/UNLOCK - LOCK/UNLOCK
Finally, some extensions to WebDAV may still be required to meet all Finally, some extensions to WebDAV may still be required to meet all
DECADE requirements. For example, defining a new WebDAV "time-to- DECADE requirements. For example, defining a new WebDAV "time-to-
live" property may be useful for DECADE. Further analysis is live" property may be useful for DECADE. Further analysis is
required to fully define the potential extensions to WebDAV to meet required to fully define the potential extensions to WebDAV to meet
all DECADE requirements. all DECADE requirements.
Appendix B. In-Network Storage Components Mapped to DECADE Architecture
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]
map into the DECADE architecture.
It is important to note that complex and/or application-specific
behavior is delegated to applications instead of tuning the storage
system wherever possible.
B.1. Data Access Interface
Users can read and write objects of arbitrary size through the DECADE
Client's Data Controller, making use of a standard data transport.
B.2. Data Management Operations
Users can move or delete previously stored objects via the DECADE
Client's Data Controller, making use of a standard data transport.
B.3. Data Search Capability
Users can enumerate or search contents of DECADE servers to find
objects matching desired criteria through services provided by the
Content Distribution Application (e.g., buffer-map exchanges, a DHT,
or peer-exchange). In doing so, End-Points may consult their local
Data Index in the DECADE Client's Data Controller.
B.4. Access Control Authorization
All methods of access control are supported: public-unrestricted,
public-restricted and private. Access Control Policies are generated
by a Content Distribution Application and provided to the DECADE
Client's Resource Controller. The DECADE Server is responsible for
implementing the access control checks.
B.5. Resource Control Interface
Users can manage the resources (e.g. bandwidth) on the DECADE server
that can be used by other Application End-Points. Resource Sharing
Policies are generated by a Content Distribution Application and
provided to the DECADE Client's Resource Controller. The DECADE
Server is responsible for implementing the resource sharing policies.
B.6. Discovery Mechanism
The particular protocol used for discovery is outside the scope of
this document. However, options and considerations have been
discussed in Section 5.5.
B.7. Storage Mode
DECADE Servers provide an object-based storage mode. Immutable data
objects may be stored at a DECADE server. Applications may consider
existing blocks as DECADE data objects, or they may adjust block
sizes before storing in a DECADE server.
Authors' Addresses Authors' Addresses
Richard Alimi Richard Alimi
Google Google
Email: ralimi@google.com Email: ralimi@google.com
Y. Richard Yang Y. Richard Yang
Yale University Yale University
 End of changes. 148 change blocks. 
521 lines changed or deleted 657 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/