draft-ietf-decade-arch-07.txt   draft-ietf-decade-arch-08.txt 
DECADE R. Alimi DECADE R. Alimi
Internet-Draft Google Internet-Draft Google
Intended status: Informational A. Rahman Intended status: Informational A. Rahman
Expires: December 16, 2012 InterDigital Communications, LLC Expires: January 14, 2013 InterDigital Communications, LLC
D. Kutscher D. Kutscher
NEC NEC
Y. Yang Y. Yang
Yale University Yale University
June 14, 2012 July 13, 2012
DECADE Architecture DECADE Architecture
draft-ietf-decade-arch-07 draft-ietf-decade-arch-08
Abstract Abstract
Content Distribution Applications (e.g., Peer-to-Peer applications) Content Distribution Applications (e.g., P2P applications) are widely
are widely used on the Internet and make up a large portion of the used on the Internet and make up a large portion of the traffic in
traffic in many networks. One technique to improve the network many networks. One technique to improve the network efficiency of
efficiency of these applications is to introduce storage capabilities these applications is to introduce storage capabilities within the
within the networks; this is the capability provided by a DECADE networks; this is the capability provided by a DECADE (DECoupled
(DECoupled Application Data Enroute) compatible system. This Application Data Enroute) compatible system. This document presents
document presents an architecture, discusses the underlying an architecture, discusses the underlying principles, and identifies
principles, and identifies key functionalities required for key functionalities in the architecture for introducing a DECADE-
introducing a DECADE-compatible in-network storage system. In compatible in-network storage system. In addition, some examples are
addition, some examples are given to illustrate these concepts. given to illustrate these concepts.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 4 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 16, 2012. This Internet-Draft will expire on January 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with 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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 5 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Content Provider . . . . . . . . . . . . . . . . . . . . . 6 3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Content Consumer . . . . . . . . . . . . . . . . . . . . . 6 4. Architectural Principles . . . . . . . . . . . . . . . . . . . 6
2.5. Storage Provider . . . . . . . . . . . . . . . . . . . . . 6 4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 6
2.6. Content Distribution Application . . . . . . . . . . . . . 6 4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 7
2.7. Application End-Point . . . . . . . . . . . . . . . . . . 6 4.3. Data Objects With Identifiers . . . . . . . . . . . . . . 8
2.8. Data Object . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . . 10
3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Resource and Data Access Control through Delegation . . . 10
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. System Components . . . . . . . . . . . . . . . . . . . . . . 11
3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Content Distribution Application . . . . . . . . . . . . . 11
4. Architectural Principles . . . . . . . . . . . . . . . . . . . 9 5.2. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 9 5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 15
4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 10 5.4. Token-based Authorization and Resource Control . . . . . . 17
4.3. Data Objects With Identifiers . . . . . . . . . . . . . . 11 5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. Data Object Naming Scheme . . . . . . . . . . . . . . . . 11 6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Explicit Control . . . . . . . . . . . . . . . . . . . . . 13 6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 19
4.6. Resource and Data Access Control . . . . . . . . . . . . . 13 6.2. Standard Data Transfer (SDT) Protocol . . . . . . . . . . 22
5. System Components . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Server-to-Server Protocols . . . . . . . . . . . . . . . . 23
5.1. Content Distribution Application . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Threat: System Denial of Service Attacks . . . . . . . . . 25
5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 18 7.2. Threat: Protocol Security . . . . . . . . . . . . . . . . 25
5.4. Token-based Authentication and Resource Control . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
6.2. Standard Data Transfer (SDT) Protocol . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 28
6.3. Server-to-Server Protocols . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Threat: System Denial of Service Attacks . . . . . . . . . 28
7.2. Threat: Protocol Security . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. In-Network Storage Components Mapped to DECADE Appendix A. In-Network Storage Components Mapped to DECADE
Architecture . . . . . . . . . . . . . . . . . . . . 31 Architecture . . . . . . . . . . . . . . . . . . . . 28
A.1. Data Access Interface . . . . . . . . . . . . . . . . . . 32 A.1. Data Access Interface . . . . . . . . . . . . . . . . . . 28
A.2. Data Management Operations . . . . . . . . . . . . . . . . 32 A.2. Data Management Operations . . . . . . . . . . . . . . . . 29
A.3. Data Search Capability . . . . . . . . . . . . . . . . . . 32 A.3. Data Search Capability . . . . . . . . . . . . . . . . . . 29
A.4. Access Control Authorization . . . . . . . . . . . . . . . 32 A.4. Access Control Authorization . . . . . . . . . . . . . . . 29
A.5. Resource Control Interface . . . . . . . . . . . . . . . . 32 A.5. Resource Control Interface . . . . . . . . . . . . . . . . 29
A.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 32 A.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 29
A.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 32 A.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Content Distribution Applications, such as Peer-to-Peer (P2P) Content Distribution Applications, such as Peer-to-Peer (P2P)
applications, are widely used on the Internet to distribute data, and applications, are widely used on the Internet to distribute data, and
they contribute a large portion of the traffic in many networks. The they contribute a large portion of the traffic in many networks. The
DECADE-compatible architecture described in this document enables architecture described in this document enables such applications to
such applications to leverage in-network storage to achieve more leverage in-network storage to achieve more efficient content
efficient content distribution. Specifically, in many subscriber distribution (i.e. DECADE-compatible system). Specifically, in many
networks, it can be expensive to upgrade network equipment in the subscriber networks, it can be expensive to upgrade network equipment
"last-mile", because it can involve replacing equipment and upgrading in the "last-mile", because it can involve replacing equipment and
wiring at individual homes, businesses, and devices such as DSLAMs upgrading wiring at individual homes, businesses, and devices such as
(Digital Subscriber Line Access Multiplexers) and CMTSs (Cable Modem DSLAMs (Digital Subscriber Line Access Multiplexers) and CMTSs (Cable
Termination Systems) in remote locations. Therefore, it may be Modem Termination Systems) in remote locations. Therefore, it may be
cheaper to upgrade the core infrastructure, which involves fewer cheaper to upgrade the core infrastructure, which involves fewer
components that are shared by many subscribers. See components that are shared by many subscribers. See [RFC6646] for a
[I-D.ietf-decade-problem-statement] for a more complete discussion of more complete discussion of the problem domain and general
the problem domain and general discussions of the capabilities to be discussions of the capabilities to be provided by a DECADE-compatible
provided by a DECADE-compatible system. system.
This document presents an architecture for providing in-network This document presents an architecture for providing in-network
storage that can be integrated into Content Distribution storage that can be integrated into Content Distribution
Applications. The primary focus is P2P-based content distribution, Applications. The primary focus is P2P-based content distribution,
but the architecture may be useful to other applications with similar but the architecture may be useful to other applications with similar
characteristics and requirements. See [I-D.ietf-decade-reqs] for a characteristics and requirements. See [I-D.ietf-decade-reqs] for a
definition of the target applications supported by a DECADE- definition of the target applications as well as the requirements for
compatible system. a DECADE-compatible system.
The approach of this document is to define the core functionalities The approach of this document is to define the core functionalities
and protocol behaviour that are needed to support in-network storage and protocol functions that are needed to support a DECADE-compatible
in a DECADE-compatible system. The protocol themselves are not system. The specific protocols are not selected or designed in this
selected or designed in this document. Some illustrative examples document. Some illustrative examples are given to help the reader
are given to help the reader understand certain concepts. These understand certain concepts. These examples are purely informational
examples are purely informational and are not meant to constrain and are not meant to constrain future protocol design or selection.
future protocol design or selection.
2. Terminology 2. Terminology
This document assumes readers are familiar with the terms and This document assumes readers are familiar with the terms and
concepts that are used in [I-D.ietf-decade-problem-statement]. In concepts that are used in [RFC6646] and [I-D.ietf-decade-reqs].
addition, this document defines the following terminology.
2.1. DECADE-compatible Client
A DECADE-compatible client uploads and/or retrieves data from DECADE-
compatible servers. We simply use the term "client" if there is no
ambiguity.
2.2. DECADE-compatible Server
A DECADE-compatible server stores data inside the network, and
thereafter manages both the stored data and access to that data. We
simply use the term "server" if there is no ambiguity.
2.3. Content Provider
A client which owns (i.e. uploads and manages) storage at a DECADE-
compatible server.
2.4. Content Consumer
A client which has been granted permission to retrieve data from a
DECADE-compatible server by a Content Provider.
2.5. Storage Provider
A Storage Provider deploys and/or manages DECADE-compatible server(s)
within a network.
2.6. Content Distribution Application
A Content Distribution Application is an application (e.g., P2P)
designed for dissemination of a large amounts of data to multiple
consumers. Content Distribution Applications typically divide
content into smaller blocks for dissemination.
We consider Content Distribution Applications that include a DECADE-
compatible client along with other application functionality (e.g.,
P2P video streaming client).
2.7. Application End-Point
An Application End-Point is an instance of a Content Distribution
Application. A particular Application End-Point might be a Content
Provider, a Content Consumer, or both. For example, an Application
End-Point might be an instance of a video streaming client, or it
might be the source providing the video to a set of clients.
2.8. Data Object
A data object is the unit of data stored and retrieved from a DECADE-
compatible server. The data object is a string of raw bytes. The
server maintains metadata associated with each data object, but the
metadata is not included in the data object.
3. Protocol Flow 3. Protocol Flow
3.1. Overview 3.1. Overview
A DECADE-compatible system will support two logical protocols, as Following[I-D.ietf-decade-reqs], the architecture consists of two
shown in Figure 1. First, the DECADE Resource Protocol (DRP) is protocols: the DECADE Resource Protocol (DRP) that is responsible for
responsible for communication of access control and resource communication of access control and resource scheduling policies from
scheduling policies between a client and a server, as well as between a client to a server, as well as between servers; and Standard Data
servers. A DECADE-compatible system will include exactly one DRP for Transfer (SDT) protocol(s) that will be used to transfer data objects
interoperability and a common format through which these policies can to and from a server. We show the protocol components figure below:
be communicated.
Native Application Native Application
.-------------. Protocol(s) .-------------. .-------------. Protocol(s) .-------------.
| Application | <------------------> | Application | | Application | <------------------> | Application |
| End-Point | | End-Point | | End-Point | | End-Point |
| | | | | | | |
| .--------. | | .--------. | | .--------. | | .--------. |
| | DECADE | | | | DECADE | | | | DECADE | | | | DECADE | |
| | Client | | | | Client | | | | Client | | | | Client | |
| `--------' | | `--------' | | `--------' | | `--------' |
skipping to change at page 7, line 46 skipping to change at page 5, line 37
| | | | | | | |
| | | | | | | |
v V v V v V v V
.=============. DRP .=============. .=============. DRP .=============.
| DECADE | <------------------> | DECADE | | DECADE | <------------------> | DECADE |
| Server | <------------------> | Server | | Server | <------------------> | Server |
`=============' SDT `=============' `=============' SDT `============='
Figure 1: Generic Protocol Flow Figure 1: Generic Protocol Flow
Second, a Standard Data Transfer (SDT) protocol will be used to
transfer data objects to and from a server. A DECADE-compatible
system may support multiple SDT's. If there are multiple SDT's, a
negotiation mechanism will be used to determine a suitable SDT
between the client and server.
The two protocols (DRP and SDT) will be either separate or combined
on the wire. If they are combined, DRP messages can be piggy-backed
within some extension fields provided by certain SDT 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-compatible
resource usage. If the protocols are physically separate on the
wire, DRP can take the form of a separate control connection open
between the a DECADE-compatible client and server. Hence, this
document considers SDT and DRP as two separate, logical functional
components for clarity. The abstract properties of the SDT and DRP
are outlined below but the final selection of these protocols is
outside the scope of this document.
3.2. An Example 3.2. An Example
This section provides an example of steps in a data transfer scenario This section provides an example showing the steps in the
involving an in-network storage system. We assume that Application architecture for a data transfer scenario involving an in-network
End-Point B (the receiver) is requesting a data object from storage system. We assume that Application End-Point B (the
Application End-Point A (the sender). Let S(A) denote the DECADE- receiver) is requesting a data object from Application End-Point A
compatible storage server to which A has access. There are multiple (the sender). Let S(A) denote the DECADE-compatible storage server
usage scenarios (by choice of the Content Distribution Application). to which A has access. There are multiple usage scenarios (by choice
For simplicity of introduction, we design this example to use only a of the Content Distribution Application). For simplicity of
single DECADE-compatible server. introduction, we design this example to use only a single DECADE-
compatible server.
The steps of the example are illustrated in Figure 2. First, B The steps of the example are illustrated in Figure 2. First, B
requests a data object from A using their native application protocol requests a data object from A using their native application protocol
(see Section 5.1.2). Next, A uses the DRP to obtain a token. There (see Section 5.1.2). Next, A uses the DRP to obtain a token. There
are multiple ways for A to obtain the token: compute locally, or are multiple ways for A to obtain the token: compute locally, or
request from its DECADE-compatible storage server, S(A). See request from its DECADE-compatible storage server, S(A). See
Section 6.1.2 for details. A then provides the token to B (again, Section 6.1.2 for details. A then provides the token to B (again,
using their native application protocol). Finally, B provides the using their native application protocol). Finally, B provides the
token to S(A) via DRP, and requests and downloads the data object via token to S(A) via DRP, and requests and downloads the data object via
a SDT. a SDT.
.----------. .----------.
2. Obtain --------> | S(A) | <------ 2. Obtain --------> | S(A) | <------
Token / `----------' \ 4. Request and Token / `----------' \ 4. Request and
(DRP) / \ Download Object (DRP) / \ Download Data
Locally / \ (DRP + SDT) Locally / \ Object
or From / \ or From / \ (DRP + SDT)
S(A) v 1. App Request v S(A) v 1. App Request v
.-------------. <--------------------------- .-------------. .-------------. <--------------------------- .-------------.
| Application | | Application | | Application | | Application |
| End-Point A | | End-Point B | | End-Point A | | End-Point B |
`-------------' ---------------------------> `-------------' `-------------' ---------------------------> `-------------'
3. App Response (token) 3. App Response (token)
Figure 2: Download from Storage Server Figure 2: Download from Storage Server
4. Architectural Principles 4. Architectural Principles
We identify the following key principles that will be followed in any We identify the following key principles that will be followed in any
DECADE-compatible system: DECADE-compatible system:
4.1. Decoupled Control/Metadata and Data Planes 4.1. Decoupled Control/Metadata and Data Planes
A DECADE-compatible system SHOULD be able to support multiple Content A DECADE-compatible system SHOULD be able to support multiple Content
Distribution Applications. A complete Content Distribution Distribution Applications. A complete Content Distribution
Application implements a set of "control plane" functions including Application implements a set of "control plane" functions including
content search, indexing and collection, access control, ad content search, indexing and collection, access control, replication,
insertion, replication, request routing, and QoS scheduling. request routing, and QoS scheduling. Different Content Distribution
Different Content Distribution Applications will have unique Applications will have unique considerations designing the control
considerations designing the control plane functions: plane functions:
o Metadata Management Scheme: Traditional file systems provide a o Metadata Management Scheme: Traditional file systems provide a
standard metadata abstraction: a recursive structure of standard metadata abstraction: a recursive structure of
directories to offer namespace management; each file is an opaque directories to offer namespace management; each file is an opaque
byte stream. Content Distribution Applications may use different byte stream. Content Distribution Applications may use different
metadata management schemes. For example, one application might metadata management schemes. For example, one application might
use a sequence of blocks (e.g., for file sharing), while another use a sequence of blocks (e.g., for file sharing), while another
application might use a sequence of frames (with different sizes) application might use a sequence of frames (with different sizes)
indexed by time. indexed by time.
skipping to change at page 10, line 23 skipping to change at page 7, line 45
Focusing on immutable data in the data plane can substantially Focusing on immutable data 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 simplifies reuse of data and implementation of de- relaxed. It also simplifies reuse of data and implementation of de-
duplication. duplication.
Depending on its specific requirements, an application may store Depending on its specific requirements, an application may store
immutable data objects in DECADE-compatible servers such that each immutable data objects in DECADE-compatible servers such that each
data object is completely self-contained (e.g., a complete, data object is completely self-contained (e.g., a complete,
independently decodable video segment). An application may also independently decodable video segment). An application may also
divide data into blocks that require application level assembly. divide data into data objects that require application level
Many Content Distribution Applications divide bulk content into assembly. Many Content Distribution Applications divide bulk content
blocks for multiple reasons, including (1) multipath: different into data objects for multiple reasons, including (1) fetching
blocks might be fetched from different sources in parallel; and (2) different data objects from different sources in parallel; and (2)
faster recovery and verification: individual blocks might be faster recovery and verification: individual data objects might be
recovered and verified. Typically, applications use a block size recovered and verified. Typically, applications use a data object
larger than a single packet in order to reduce control overhead. size larger than a single packet in order to reduce control overhead.
A DECADE-compatible system SHOULD be agnostic to the nature of the A DECADE-compatible system SHOULD be agnostic to the nature of the
data objects and SHOULD NOT specify a fixed size for them. Though a data objects and SHOULD NOT specify a fixed size for them. A
protocol specification based on this architecture MAY prescribe protocol specification based on this architecture MAY prescribe
requirements on minimum and maximum sizes by compliant requirements on minimum and maximum sizes by compliant
implementations. Applications may consider existing blocks as data implementations.
objects, or they may adjust block sizes before storing in the DECADE-
compatible server.
Immutable data objects can still be deleted. Applications may Immutable data objects can still be deleted. Applications may
support modification of existing data stored at a DECADE-compatible support modification of existing data stored at a DECADE-compatible
server through a combination of storing new data objects and deleting server through a combination of storing new data objects and deleting
existing data objects. For example, a meta-data management function existing data objects. For example, a meta-data management function
of the control plane might associate a name with a sequence of of the control plane might associate a name with a sequence of
immutable blocks. If one of the blocks is modified, the meta-data immutable data objects. If one of the data objects is modified, the
management function changes the mapping of the name to a new sequence meta-data management function changes the mapping of the name to a
of immutable blocks. new sequence of immutable data objects.
Throughout this document, all data objects/blocks are assumed to be Throughout this document, all data objects are assumed to be
immutable. immutable.
4.3. Data Objects With Identifiers 4.3. Data Objects With Identifiers
An object that is stored in a DECADE-compatible storage server SHOULD An object that is stored in a DECADE-compatible storage server SHALL
be accessed by Content Consumers via a data object identifier. be accessed by Content Consumers via a data object identifier.
A Content Consumer may be able to access more than one storage A Content Consumer may be able to access more than one storage
server. A data object that is replicated across different storage server. A data object that is replicated across different storage
servers managed by a DECADE-compatible Storage Provider MAY still be servers managed by a DECADE-compatible Storage Provider MAY still be
accessed by a single identifier. accessed by a single identifier.
Since data objects are immutable, it SHALL be possible to support Since data objects are immutable, it SHALL be possible to support
persistent identifiers for data objects. persistent identifiers for data objects.
Data object identifiers for data objects SHOULD be created by Content Data object identifiers for data objects SHOULD be created by Content
Providers that upload the objects to servers. Providers that upload the objects to servers. We refer to a scheme
for the assignment/derivation of the data object identifier to a data
4.4. Data Object Naming Scheme object depends as the data object naming scheme. The details of data
naming schemes will be provided by future DECADE-compatible protocol/
The DECADE architecture is based on data object identifiers as naming specifications. This document describes naming schemes on a
described above, and the assignment/derivation of the data object semantic level and specific SDTs and DRPs SHOULD use specific
identifier to a data object depends on the data object naming scheme. representations.
The details of data naming schemes will be provided by future DECADE-
compatible protocol/naming specifications. This document describes
naming schemes on a semantic level and specific SDTs and DRPs SHOULD
use specific representations.
In particular, for some applications it is important that clients and In particular, for some applications it is important that clients and
servers SHOULD be able to validate the name-object binding for a data servers SHOULD be able to validate the name-object binding for a data
object, i.e., by verifying that a received object really corresponds object, i.e., by verifying that a received object really corresponds
to the name (identifier) that was used for requesting it (or that was to the name (identifier) that was used for requesting it (or that was
provided by a sender). Data object identifiers can support name- provided by a sender). Data object identifiers can support name-
object binding validation by providing message digests or so-called object binding validation by providing message digests or so-called
self-certifying naming information -- if a specific application has self-certifying naming information -- if a specific application has
this requirement. this requirement.
skipping to change at page 12, line 12 skipping to change at page 9, line 26
o Applications MAY be able to construct unique names (with high o Applications MAY be able to construct unique names (with high
probability) without requiring a registry or other forms of probability) without requiring a registry or other forms of
coordination; and coordination; and
o Names MAY be self-describing so that a receiving entity (Content o Names MAY be self-describing so that a receiving entity (Content
Consumer) knows what hash function (for example) to use for Consumer) knows what hash function (for example) to use for
validating name-object binding. validating name-object binding.
Some Content Distribution Applications will derive the name of a data Some Content Distribution Applications will derive the name of a data
object from the hash over the data object, which is made possible by object from the hash over the data object, which is made possible by
the fact that DECADE-compatible objects are immutable. But there the fact that DECADE-compatible objects are immutable. But there may
maybe other applications such as live streaming where object/chunk be other applications such as live streaming where object names will
names will not based on hashes but rather on an enumeration scheme. not based on hashes but rather on an enumeration scheme. The naming
The naming scheme will also enable those applications to construct scheme will also enable those applications to construct unique names.
unique names.
In order to enable the uniqueness, flexibility and self-describing In order to enable the uniqueness, flexibility and self-describing
properties, the naming scheme SHOULD provide the following name properties, the naming scheme SHOULD provide the following name
elements: elements:
o A "type" field that indicates the name-object validation function o A "type" field that indicates the name-object validation function
type (for example, "sha-256"); type (for example, "sha-256");
o Cryptographic data (such as an object hash) that corresponds to o Cryptographic data (such as an object hash) that corresponds to
the type information; and the type information; and
The naming scheme MAY additionally provide the following name The naming scheme MAY additionally provide the following name
elements: elements:
o Application or publisher information. o Application or publisher information.
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 is left for protocol etc) is out of scope of this document, and is left for protocol
specification. specification.
The DECADE-compatible naming scheme SHOULD be used in scenarios where 4.4. Explicit Control
a client knows the name of a data object before it is completely
stored at the server. This allows for particular optimizations, such
as advertising data object while the data object is being stored,
removing store-and-forward delays. For example, a client A might
simultaneously begin storing an object to a server, and advertise
that the object is available to client B. If it is supported by the
server, client B might begin downloading the object before A is
finished storing the object.
If object names are not based on hashes of the data objects
themselves, names can also be used in scenarios where a client knows
the name of a data object before it is locally created.
4.5. Explicit Control
To support the functions of an application's control plane, To support the functions of an application's control plane,
applications SHOULD be able to know and coordinate which data is applications SHOULD be able to know and coordinate which data is
stored at particular servers. Applications are given explicit stored at particular servers. Thus, in contrast with traditional
control over the placement (selection of a DECADE-compatible server), caches, applications are given explicit control over the placement
deletion (or expiration policy), and access control for stored data. (selection of a DECADE-compatible server), deletion (or expiration
policy), and access control for stored data.
Consider deletion/expiration policy as a simple example. An Consider deletion/expiration policy as a simple example. An
application might require that a server store data objects for a application might require that a server stores data objects 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 might need to store data objects for a longer Another application might need to store data objects for a longer
duration (e.g., for video-on-demand). duration (e.g., for video-on-demand).
4.6. Resource and Data Access Control 4.5. Resource and Data Access Control through Delegation
A DECADE-compatible system will provide a shared infrastructure to be A DECADE-compatible system will provide a shared infrastructure to be
used by multiple Content Consumers and Content Providers spanning used by multiple Content Consumers and Content Providers spanning
multiple Content Distribution Applications. Thus, it needs to multiple Content Distribution Applications. Thus, it needs to
provide both resource and data access control. provide both resource and data access control.
4.6.1. Resource Allocation 4.5.1. Resource Allocation
There are two primary interacting entities in a DECADE-compatible There are two primary interacting entities in a DECADE-compatible
system. First, Storage Providers SHOULD coordinate where storage system. First, Storage Providers SHOULD coordinate where storage
servers are provisioned and their total available resources. Second, servers are provisioned and their total available resources
Applications will coordinate data transfers amongst available servers Section 6.1.1. Second, Applications will coordinate data transfers
and between servers and clients. A form of isolation is required to amongst available servers and between servers and clients. A form of
enable concurrently-running Applications to each explicitly manage isolation is required to enable concurrently-running Applications to
its own data objects and share of resources at the available servers. each explicitly manage its own data objects and share of resources at
the available servers.
The Storage Provider SHOULD delegate the management of the resources The Storage Provider SHOULD delegate the management of the resources
on a server to DECADE Content Providers. This means that Content on a server to Content Providers. This means that Content Providers
Providers are able to explicitly and independently manage their own are able to explicitly and independently manage their own shares of
shares of resources on a server. resources on a server.
4.6.2. User Delegations 4.5.2. User Delegations
Storage Providers will have the ability to explicitly manage the Storage Providers will have the ability to explicitly manage the
entities allowed to utilize the resources at a DECADE-compatible entities allowed to utilize the resources at a DECADE-compatible
server. This capability is needed for reasons such as capacity- server. This capability is needed for reasons such as capacity-
planning and legal considerations in certain deployment scenarios. planning and legal considerations in certain deployment scenarios.
The server SHOULD grant a share of the resources to a Content The server SHOULD grant a share of the resources to a Content
Provider or Content Consumer. The client can in turn share the Provider or Content Consumer. The client can in turn share the
granted resources amongst its multiple applications. The share of granted resources amongst its multiple applications. The share of
resources granted by a server is called a User Delegation. resources granted by a server is called a User Delegation.
skipping to change at page 15, line 43 skipping to change at page 12, line 43
| Resource | Data | Resource | Data
| Protocol | Transfer | Protocol | Transfer
| (DRP) | (SDT) | (DRP) | (SDT)
v V v V
Figure 3: Application Components Figure 3: Application Components
5.1.1. Data Assembly 5.1.1. Data Assembly
A DECADE-compatible system is geared towards supporting applications A DECADE-compatible system is geared towards supporting applications
that can divide distributed content into data objects. To accomplish that can distribute content using data objects. To accomplish this,
this, applications can include a component responsible for creating applications can include a component responsible for creating the
the individual data objects before distribution and then re- individual data objects before distribution and then re-assembling
assembling data objects at the Content Consumer. We call this data objects at the Content Consumer. We call this component the
component the Application Data Assembly. Application Data Assembly.
In producing and assembling the data objects, two important In producing and assembling the data objects, two important
considerations are sequencing and naming. A DECADE-compatible system considerations are sequencing and naming. A DECADE-compatible system
assumes that applications implement this functionality themselves. assumes that applications implement this functionality themselves.
See Section 5.3 for further discussion. See Section 5.3 for further discussion.
5.1.2. Native Application Protocols 5.1.2. Native Application Protocols
In addition to the DECADE-compatible DRP/SDT, applications will also In addition to the DECADE-compatible DRP/SDT, applications can also
support their existing native application protocols (e.g., P2P support existing native application protocols (e.g., P2P control and
control and data transfer protocols). data transfer protocols).
5.1.3. DECADE Client 5.1.3. DECADE Client
An application needs to be modified to support a DECADE-compatible The client provides the local support to an application, and can be
system. The client provides the local support to an application, and implemented standalone, embedded into the application, or integrated
can standalone, embedded into the application, or integrated in other in other entities such as network devices themselves.
entities such as network devices themselves.
5.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- Access Policies to control their resource and data in DECADE-
compatible servers. These policies may be existing policies of compatible servers. These policies may be existing policies of
applications or custom policies. The specific implementation is applications or custom policies. The specific implementation is
decided by the application. decided by the application.
5.1.3.2. Data Controller 5.1.3.2. Data Controller
skipping to change at page 16, line 38 skipping to change at page 13, line 37
A DECADE-compatible system decouples the control and the data A DECADE-compatible system decouples the control and the data
transfer of applications. A Data Scheduling component schedules data transfer of applications. A Data Scheduling component schedules data
transfers according to network conditions, available servers, and/or transfers according to network conditions, available servers, and/or
available server resources. The Data Index indicates data available available server resources. The Data Index indicates data available
at remote servers. The Data Index (or a subset of it) can be at remote servers. The Data Index (or a subset of it) can be
advertised to other clients. A common use case for this is to advertised to other clients. A common use case for this is to
provide the ability to locate data amongst distributed Application provide the ability to locate data amongst distributed Application
End-Points (i.e., a data search mechanism such as a Distributed Hash End-Points (i.e., a data search mechanism such as a Distributed Hash
Table). Table).
5.2. Server 5.2. DECADE Server
Figure 4 illustrates the components discussed in a DECADE-compatible Figure 4 illustrates the components discussed in a DECADE-compatible
server. A server is not necessarily a single physical machine, it server. A server is not necessarily a single physical machine, it
can also be implemented as a cluster of machines. can also be implemented as a cluster of machines.
| | | |
| DECADE | Standard | DECADE | Standard
| Resource | Data | Resource | Data
| Protocol | Transfer | Protocol | Transfer
| (DRP) | (SDT) | (DRP) | (SDT)
skipping to change at page 17, line 37 skipping to change at page 14, line 37
| `-----------------' | Management | | | `-----------------' | Management | |
| DECADE Server `------------' | | DECADE Server `------------' |
`==============================================' `=============================================='
Figure 4: DECADE Server Components Figure 4: DECADE Server Components
5.2.1. Access Control 5.2.1. Access Control
A client SHALL be able to access its own data or other client's data A client SHALL be able to access its own data or other client's data
(provided sufficient authorization) in DECADE-compatible servers. (provided sufficient authorization) in DECADE-compatible servers.
Clients MAY also authorize other Clients to store data. If an access Clients MAY also authorize other clients to store data. If an access
is authorized by a Client, the server SHOULD provide access. Even if is authorized by a client, the server SHOULD provide access. Even if
a request is authorized, it MAY still fail to complete due to a request is authorized, it MAY still fail to complete due to
insufficient resources at the server. insufficient resources at the server.
5.2.2. Resource Scheduling 5.2.2. Resource Scheduling
Applications will apply resource sharing policies or use a custom Applications will apply resource sharing policies or use a custom
policy. Servers perform resource scheduling according to the policy. Servers perform resource scheduling according to the
resource sharing policies indicated by Clients as well as configured resource sharing policies indicated by clients as well as configured
User Delegations. User Delegations.
5.2.3. Data Store 5.2.3. Data Store
Data from applications will be stored at a DECADE-compatible server. Data from applications will be stored at a DECADE-compatible server.
Data SHOULD be deleted from storage either explicitly or Data may be deleted from storage either explicitly or automatically
automatically (e.g., after a TTL expiration). It SHOULD be possible (e.g., after a TTL expiration).
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.
5.3. Data Sequencing and Naming 5.3. Data Sequencing and Naming
In order to provide a simple and generic interface, the DECADE- In order to provide a simple and generic interface, the DECADE-
compatible server will only be responsible for storing and retrieving compatible server will be responsible only for storing and retrieving
individual data objects. Furthermore, a DECADE-compatible system individual data objects. Furthermore, a DECADE-compatible system
will use its own naming scheme that provides uniqueness (with high will use its own naming scheme that provides uniqueness (with high
probability) between data objects, even across multiple applications. probability) between data objects, even across multiple applications.
5.3.1. Data Object Naming Scheme 5.3.1. Data Object Naming Scheme
Details of the naming scheme are discussed in Section 4.4. Details of the naming scheme are discussed in Section 5.3.
5.3.2. Application Usage 5.3.2. Application Usage
Recall from Section 5.1.1 that an Application typically includes its Recall from Section 5.1.1 that an Application typically includes its
own naming and sequencing scheme. The DECADE-compatible naming own naming and sequencing scheme. The DECADE-compatible naming
format SHOULD NOT attempt to replace any naming or sequencing of data format SHOULD NOT attempt to replace any naming or sequencing of data
objects already performed by an Application; instead, the naming is objects already performed by an Application; instead, the naming is
intended to apply only to data objects referenced by DECADE-specific intended to apply only to data objects referenced by DECADE-specific
purposes. purposes.
An Application using a DECADE-compatible client may use a naming and An Application using a DECADE-compatible client may use a naming and
sequencing scheme independent of DECADE-compatible names. The sequencing scheme independent of DECADE-compatible names. The
DECADE-compatible client SHOULD maintain a mapping from its own data DECADE-compatible client SHOULD maintain a mapping from its own data
objects and their names to the DECADE-specific data objects and objects and their names to the DECADE-specific data objects and
names. names. Furthermore, the DECADE-compatible naming scheme implies no
sequencing or grouping of objects, even if this is done at the
application layer.
5.3.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.
5.3.3.1. Application with Fixed-Size Chunks 5.3.3.1. Application with Fixed-Size Chunks
Similar to the example in Section 5.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 16 KiloByte (KB). chunks of size 16 KiB.
Now, assume that this application wishes to store data in DECADE- Now, assume that this application wishes to store data in DECADE-
compatible servers in data objects of size 64 KB. To accomplish compatible servers in data objects of size 64 KiB. To accomplish
this, it can map a sequence of 4 chunks into a single object, as this, it can map a sequence of 4 chunks into a single data object, as
shown in Figure 5. 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 5: 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 maintains a logical mapping that is
that is able to determine the name of a DECADE-compatible data object able to determine the name of a DECADE-compatible data object given
given the chunks contained within that data object. The name might the chunks contained within that data object. The name may be
be learned from either the original source, another End-Point with learned from either the original Content Provider, another End-Point
which the Application is communicating, a tracker, etc. with which the Application is communicating, etc. As long as the
data contained within each sequence of chunks is globally unique, the
As long as the data contained within each sequence of chunks is corresponding data objects have globally unique names.
globally unique, the corresponding data objects have globally unique
names. This is desired, and happens automatically if particular
Application segments the same stream of data in a different way,
including different chunk sizes or different padding schemes.
5.3.3.2. Application with Continuous Streaming Data 5.3.3.2. Application with Continuous Streaming Data
Consider an Application whose native protocol retrieves a continuous Consider an Application whose native protocol retrieves a continuous
data stream (e.g., an MPEG2 stream) instead of downloading and data stream (e.g., an MPEG2 stream) instead of downloading and
redistributing chunks of data. Such an application could segment the redistributing chunks of data. Such an application could segment the
continuous data stream to produce either fixed-sized or variable- continuous data stream to produce either fixed-sized or variable-
sized data objects. sized data objects.
Figure 6 shows how a video streaming application might produce Figure 6 shows how a video streaming application might produce
skipping to change at page 20, line 14 skipping to change at page 17, line 14
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 KiB 900 KiB 1200 KiB 1500 KiB
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 KiB) | (500 KiB) | (300 KiB) | (300 KiB) |
`--------------`--------------`--------------`--------------`-------- `--------------`--------------`--------------`--------------`--------
Figure 6: 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 data object given the mapping that is able to determine the name of a data object given the
time offset of the video chunk. time offset of the video chunk.
5.4. Token-based Authentication and Resource Control 5.4. Token-based Authorization and Resource Control
A key feature of a DECADE-compatible system is that a client can A key feature of a DECADE-compatible system is that a client can
authorize other Clients to store or retrieve data objects from the authorize other clients to store or retrieve data objects from the
in-network storage. A token-based authentication scheme is used to in-network storage. A token-based authorization scheme is used to
accomplish this. accomplish this.
Specifically, an entity trusted by a client generates a signed token Specifically, an entity trusted by a client generates a signed token
with particular properties (see Section 6.1.2 for details). The with particular properties (see Section 6.1.2 for details). The
client then distributes this token to other Clients which then use client then distributes this token to other clients which then use
the token when sending requests to the DECADE-compatible server. the token when sending requests to the DECADE-compatible server.
Upon receiving a token, the server validates the signature and the Upon receiving a token, the server validates the signature and the
operation being performed (e.g. PUT, GET). operation being performed.
This is a simple scheme, but has some important advantages over an This is a simple scheme, but has some important advantages over an
alternate approach in which a client explicitly manipulates an Access alternative approach in which a client explicitly manipulates an
Control List (ACL) associated with each data object. In particular, Access Control List (ACL) associated with each data object. In
it has the following advantages when applied to DECADE-compatible particular, it has the following advantages when applied to DECADE-
target applications: compatible 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 and for how long they will be valid.
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 6.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 client and server to manipulate o There is no messaging between a client and server to manipulate
data object permissions. This can simplify, in particular, data object permissions. This can simplify, in particular,
Applications which share data objects with many dynamic clients Applications which share data objects with many dynamic peers and
and need to frequently adjust access control policies attached to need to frequently adjust access control policies attached to data
data objects. objects.
o Tokens can provide anonymous access, in which a server does not o Tokens can provide anonymous access, in which a server does not
need to know the identity of each client that accesses it. This need to know the identity of each client that accesses it. This
enables a client to send tokens to clients in other administrative enables a client to send tokens to clients belonging to other
or security domains, and allow them to read or write data objects Storage Providers, and allow them to read or write data objects
from its storage. from the storage of its own Storage Provider.
In addition to clients applying access control policies to data In addition to clients applying access control policies to data
objects, the server MAY be configured to apply additional policies objects, the server MAY be configured to apply additional policies
based on user, object, geographic location, etc. A client might thus based on user, object, geographic location, etc. A client might thus
be denied access even though it possess a valid token. be denied access even though it possesses a valid token.
Existing protocols (e.g., OAuth [RFC5849]) implement similar referral There are existing protocols (e.g., OAuth [RFC5849]) that implement
mechanisms using tokens. A protocol specification of this similar referral mechanisms using tokens. A protocol specification
architecture SHOULD endeavor to use existing mechanisms wherever of this architecture SHOULD endeavor to use existing mechanisms
possible. wherever possible.
5.5. Discovery 5.5. Discovery
A DECADE-compatible system SHOULD include a discovery mechanism A DECADE-compatible system SHOULD include a discovery mechanism
through which clients locate an appropriate server. through which clients locate an appropriate server.
[I-D.ietf-decade-reqs] details specific requirements of the discovery [I-D.ietf-decade-reqs] details specific requirements of the discovery
mechanism; this section discusses how they relate to other principles mechanism; this section discusses how they relate to other principles
outlined in this document. outlined in this document.
A discovery mechanism SHOULD allow a client to determine an IP A discovery mechanism SHOULD allow a client to determine an IP
skipping to change at page 22, line 8 skipping to change at page 19, line 8
(subject to resource limitations and policies of the servers (subject to resource limitations and policies of the servers
themselves) according to the policies of the Application End-Point in themselves) according to the policies of the Application End-Point in
which it is embedded. which it is embedded.
The particular protocol used for discovery is out of scope of this The particular protocol used for discovery is out of scope of this
document, but any specification SHOULD re-use standard protocols document, but any specification SHOULD re-use standard protocols
wherever possible. wherever possible.
The discovery mechanism outlined here does not provide the ability to The discovery mechanism outlined here does not provide the ability to
locate arbitrary DECADE-compatible servers to which a client might locate arbitrary DECADE-compatible servers to which a client might
obtain tokens from others. To do so requires application-level obtain tokens from others. To do so will require application-level
knowledge, and it is assumed that this functionality is implemented knowledge, and it is assumed that this functionality is implemented
in the Content Distribution Application. in the Content Distribution Application.
6. DECADE Protocols 6. DECADE Protocols
This section presents the DRP and the SDT protocol in terms of This section presents the DRP and the SDT protocol in terms of
abstract protocol interactions that are intended to be mapped to abstract protocol interactions that are intended to be mapped to
specific protocols. In general, the DRP/SDT functionality between a specific protocols. In general, the DRP/SDT functionality between a
DECADE-compatible client-server are very similar to the DRP/SDT DECADE-compatible client-server are very similar to the DRP/SDT
functionality between running between server-server. Any differences functionality between server-server. Any differences are highlighted
are highlighted below. below.
The DRP will be the protocol used by a DECADE-compatible client to DRP will be the protocol used by a DECADE-compatible client to
configure the resources and authorization used to satisfy requests configure the resources and authorization used to satisfy requests
(reading, writing, and management operations concerning objects) at a (reading, writing, and management operations concerning data objects)
server. The SDT will be used to send the data to the server. at a server. SDT will be used to transport data between a client and
a server.
6.1. DECADE Resource Protocol (DRP) 6.1. DECADE Resource Protocol (DRP)
DRP will provide configuration of access control and resource sharing DRP will provide configuration of access control and resource sharing
policies on DECADE-compatible servers. A Content Distribution policies on DECADE-compatible servers. A Content Distribution
Application, e.g., a live P2P streaming session, can have permission Application, e.g., a live P2P streaming session, can have permission
to manage data at several servers, for instance, servers in different to manage data at several servers, for instance, servers belonging to
operator domains, and DRP allows one instance of such an application, different Storage Providers, and DRP allows one instance of such an
e.g., an Application End-Point, to apply access control and resource application, e.g., an Application End-Point, to apply access control
sharing policies on each of them. and resource sharing policies on each of them.
6.1.1. Controlled Resources 6.1.1. Controlled Resources
On a single DECADE-compatible server, the following resources SHOULD On a single DECADE-compatible server, the following resources SHOULD
be managed: be managed:
o Communication resources in terms of bandwidth (upload/download) o Communication resources in terms of bandwidth (upload/download)
and also in terms of number of connected clients (connections) at and also in terms of number of active clients (simultaneous
a time. connections).
o Storage resources. o Storage resources.
6.1.2. Access and Resource Control Token 6.1.2. Access and Resource Control Token
A token SHOULD include the following information: A token SHOULD include the following information:
o Permitted operations (e.g., read, write) o Server providing the service;
o Permitted operations (e.g., read, write);
o Permitted objects (e.g., names of data objects that might be read o Permitted objects (e.g., names of data objects that might be read
or written) or written);
o Expiration time o Expiration time;
o Priority for bandwidth given to requested operation (e.g., a o Priority for bandwidth given to requested operation (e.g., a
weight used in a weighted bandwidth sharing scheme) weight used in a weighted bandwidth sharing scheme);
o Amount of data that might be read or written o Amount of data that might be read or written.
The tokens SHOULD be generated by an entity trusted by both the The tokens SHOULD be generated by an entity trusted by both the
DECADE-compatible client and server at the request of a DECADE- DECADE-compatible client and server at the request of a DECADE-
compatible client. For example this entity could be the client, a compatible client. For example this entity could be the client, a
server trusted by the client, or another server managed by a Storage server trusted by the client, or another server managed by a Storage
Provider trusted by the client. It is important for a server to Provider and trusted by the client. It is important for a server to
trust the entity generating the tokens since each token may incur a trust the entity generating the tokens since each token may incur a
resource cost on the server when used. Likewise, it is important for resource cost on the server when used. Likewise, it is important for
a client to trust the entity generating the tokens since the tokens a client to trust the entity generating the tokens since the tokens
grant access to the data stored at the server. grant access to the data stored at the server.
Upon generating a token, a client MAY distribute it to another client Upon generating a token, a client MAY distribute it to another client
(e.g., via their native application protocol). The receiving client (e.g., via their native application protocol). The receiving client
MAY then connect to the sending client's server and perform any MAY then connect to the server specified in the token and perform any
operation permitted by the token. The token SHOULD be sent along operation permitted by the token. The token SHOULD be sent along
with the operation. The server SHOULD validate the token to identify with the operation. The server SHOULD validate the token to identify
the client that issued it and whether the requested operation is the client that issued it and whether the requested operation is
permitted by the contents of the token. If the token is successfully permitted by the contents of the token. If the token is successfully
validated, the server SHOULD apply the resource control policies validated, the server SHOULD apply the resource control policies
indicated in the token while performing the operation. indicated in the token while performing the operation.
Tokens SHOULD include a unique identifier to allow a server to detect Tokens SHOULD include a unique identifier to allow a server to detect
when a token is used multiple times and reject the additional usage when a token is used multiple times and reject the additional usage
attempts. Since usage of a token incurs resource costs to a server attempts. Since usage of a token incurs resource costs to a server
(e.g., bandwidth and storage) and a Content Provider may have a (e.g., bandwidth and storage) and a Content Provider may have a
limited budget (see Section 4.6), the a Content Provider should be limited budget (see Section 4.5), the Content Provider should be able
able to indicate if a token may be used multiple times. to indicate if a token may be used multiple times.
It SHOULD be possible for DRP to allow tokens to apply to a batch of
operations to reduce communication overhead required between clients.
A request sent in this way explicitly denotes the objects to which it
applies.
It SHOULD be possible to revoke tokens after they are generated. It SHOULD be possible to revoke tokens after they are generated.
This could be accomplished by supplying the server the unique This could be accomplished by supplying the server the unique
identifiers of the tokens which are to be revoked. identifiers of the tokens which are to be revoked.
6.1.3. Status Information 6.1.3. Status Information
DRP SHOULD provide a request service for status information that DRP SHOULD provide a status request service that clients can use to
clients can use to request information from a server. request status information of a server.
Status information on a specific server: Access to such status 6.1.3.1. Status Information on a specific server
information SHOULD require client authorization, i.e., clients
need to be authorized to access the requested status information.
This authorization is based on the user delegation concept as
described in Section 4.6. The following status information
elements SHOULD be obtained:
* List of associated objects (with properties) Access to such status information SHOULD require client
authorization; that is, clients need to be authorized to access the
requested status information. This authorization is based on the
user delegation concept as described in Section 4.5. The following
status information elements SHOULD be obtained:
* Resources used/available o List of associated data objects (with properties);
The following information elements MAY additionally be available: o Resources used/available.
* List of servers to which objects have been distributed (in a The following information elements MAY additionally be available:
certain time-frame)
* List of clients to which objects have been distributed (in a o List of servers to which data objects have been distributed (in a
certain time-frame) certain time-frame);
For the list of servers/clients to which objects have been o List of clients to which data objects have been distributed (in a
distributed to, the server SHOULD be able to decide on time bounds certain time-frame).
for which this information is stored and specify the corresponding
time frame in the response to such requests. Some of this
information may be used for accounting purposes, e.g., the list of
clients to which objects have been distributed.
Access information on a specific server: Access information MAY be For the list of servers/clients to which data objects have been
provided for accounting purposes, for example, when Content distributed to, the server SHOULD be able to decide on time bounds
Providers are interested in access statistics for resources and/or for which this information is stored and specify the corresponding
to perform accounting per user. Again, access to such information time frame in the response to such requests. Some of this
requires client authorization SHOULD based on the delegation information may be used for accounting purposes, e.g., the list of
concept as described in Section 4.6. The following type of access clients to which data objects have been distributed.
information elements MAY be requested:
* What objects have been accessed how many times 6.1.3.2. Access information on a specific server
* Access tokens that a server as seen for a given object Access information MAY be provided for accounting purposes, for
example, when Content Providers are interested in access statistics
for resources and/or to perform accounting per user. Again, access
to such information requires client authorization and SHOULD based on
the delegation concept as described in Section 4.5. The following
type of access information elements MAY be requested:
The server SHOULD decide on time bounds for which this information o What data objects have been accessed by whom and for how many
is stored and specify the corresponding time frame in the response times;
to such requests.
6.1.4. Object Attributes o Access tokens that a server as seen for a given data object.
Objects that are stored on a DECADE-compatible server SHOULD have The server SHOULD decide on time bounds for which this information is
associated attributes (in addition to the object identifier and data stored and specify the corresponding time frame in the response to
object) that relate to the data storage and its management. These such requests.
attributes may be used by the server (and possibly the underlying
storage system) to perform specialized processing or handling for the 6.1.4. Data Object Attributes
data object, or to attach related server or storage-layer properties
to the data object. These attributes have a scope local to a server. Data Objects that are stored on a DECADE-compatible server SHOULD
In particular, these attributes SHOULD NOT be applied to a server or have associated attributes (in addition to the object identifier and
client to which a data object is copied. data object) that relate to the data storage and its management.
These attributes may be used by the server (and possibly the
underlying storage system) to perform specialized processing or
handling for the data object, or to attach related server or storage-
layer properties to the data object. These attributes have a scope
local to a server. In particular, these attributes SHOULD NOT be
applied to a server or client to which a data object is copied.
Depending on authorization, clients SHOULD be permitted to get or set Depending on authorization, clients SHOULD be permitted to get or set
such attributes. This authorization is based on the delegation such attributes. This authorization is based on the delegation
concept as described in Section 4.6. The architecture does not limit concept as described in Section 4.5. The architecture does not limit
the set of permissible attributes, but rather specifies a set of the set of permissible attributes, but rather specifies a set of
baseline attributes that SHOULD be supported: baseline attributes that SHOULD be supported:
Expiration Time: Time at which the object might be deleted Expiration Time: Time at which the data object can be deleted;
Object size: In bytes Data Object size: In bytes;
Media type Labelling of type as per [RFC4288] Media type Labelling of type as per [RFC4288];
Access statistics: How often the object has been accessed (and what Access statistics: How often the data object has been accessed (and
tokens have been used) what tokens have been used).
The Object Attributes defined here are distinct from application The data object attributes defined here are distinct from application
metadata (see Section 4.1). Application metadata is custom metadata (see Section 4.1). Application metadata is custom
information that an application might wish to associate with a data information that an application might wish to associate with a data
object to understand its semantic meaning (e.g., whether it is video object to understand its semantic meaning (e.g., whether it is video
and/or audio, its playback length in time, or its index in a stream). and/or audio, its playback length in time, or its index in a stream).
If an application wishes to store such metadata persistently, it can If an application wishes to store such metadata persistently, it can
be stored within data objects themselves. be stored within data objects themselves.
6.2. Standard Data Transfer (SDT) Protocol 6.2. Standard Data Transfer (SDT) Protocol
A DECADE-compatible server will provide a data access interface, and A DECADE-compatible server will provide a data access interface, and
the SDT will be used to write objects to a server and to read the SDT will be used to write data objects to a server and to read
(download) objects from a server. Semantically, SDT is a client- (download) data objects from a server. Semantically, SDT is a
server protocol, i.e., the server always responds to client requests. client-server protocol; that is, the server always responds to client
requests.
6.2.1. Writing/Uploading Objects 6.2.1. Writing/Uploading Objects
To write an object, a client first generates the object's name (see To write a data object, a client first generates the object's name
Section 5.3), and then uploads the object to a server and supplies (see Section 5.3), and then uploads the object to a server and
the generated name. The name can be used to access (download) the supplies the generated name. The name can be used to access
object later, e.g., the client can pass the name as a reference to (download) the object later; for example, the client can pass the
other client that can then refer to the object. name as a reference to other client that can then refer to the
object.
Objects can be self-contained objects such as multimedia resources,
files etc., but also chunks, such as chunks of a P2P distribution
protocol that can be part of a containing object or a stream.
If supported, a server can accept download requests for an object Data objects can be self-contained objects such as multimedia
that is still being uploaded. resources, files etc., but also chunks, such as chunks of a P2P
distribution protocol that can be part of a containing object or a
stream.
The application that originates the objects generates DECADE- The application that originates the data objects generates DECADE-
compatible object names according to the naming specification in compatible object names according to the naming specification in
Section 5.3. Clients (as parts of application entities) upload a Section 5.3. Clients (as parts of application entities) upload a
named object to a server. If supported, a server can verify the named object to a server. If supported, a server can verify the
integrity and other security properties of uploaded objects. integrity and other security properties of uploaded objects.
6.2.2. Downloading Objects 6.2.2. Downloading Data Objects
A client can request named objects from a server. In a corresponding A client can request named data objects from a server. In a
request message, a client specifies the object name and a suitable corresponding request message, a client specifies the object name and
access and resource control token. The server checks the validity of a suitable access and resource control token. The server checks the
the received token and its associated resource usage-related validity of the received token and its associated resource usage-
properties. related properties.
If the named object exists on the server and then token has been If the named data object exists on the server and the token can be
validated, the server delivers the requested object in a response validated, the server delivers the requested object in a response
message. message.
If the object cannot be delivered the server provides an If the data object cannot be delivered the server provides an
corresponding status/reason information in a response message. corresponding status/reason information in a response message.
Specifics regarding error handling, including additional error Specifics regarding error handling, including additional error
conditions (e.g. overload), precedence for returned errors and its conditions (e.g., overload), precedence for returned errors and its
relation with server policy, are deferred to eventual protocol relation with server policy, are deferred to eventual protocol
specification. specification.
6.3. Server-to-Server Protocols 6.3. Server-to-Server Protocols
An important feature of a DECADE-compatible system is the capability An important feature of a DECADE-compatible system is the capability
for one server to directly download objects from another server. for one server to directly download data objects from another server.
This capability allows Applications to directly replicate data This capability allows Applications to directly replicate data
objects between servers without requiring clients to use uplink objects between servers without requiring end-hosts to use uplink
capacity to upload data objects to a different server. capacity to upload data objects to a different server.
DRP and SDT will support operations directly between servers. DRP and SDT will support operations directly between servers.
Servers are not assumed to trust each other nor are configured to do Servers are not assumed to trust each other nor are configured to do
so. All data operations are performed on behalf of clients via so. All data operations are performed on behalf of clients via
explicit instruction. However, the objects being processed do not explicit instruction. However, the objects being processed do not
necessarily have to originate or terminate at the client (i.e. the necessarily have to originate or terminate at the client (i.e., the
object might be limited to being exchanged between servers even if data object might be limited to being exchanged between servers even
the instruction is triggered by the client). Clients thus will be if the instruction is triggered by the client). Clients thus will be
able to indicate to a server the following additional parameters: able to indicate to a server the following additional parameters:
o Which remote server(s) to access; o Which remote server(s) to access;
o The operation to be performed (e.g. PUT, GET); and o The operation to be performed;
o The Content Provider at the remote server from which to retrieve o The Content Provider at the remote server from which to retrieve
the object (for a GET), or in which the object is to be stored the data object, or in which the object is to be stored; and
(for a PUT).
o Credentials indicating permission to perform the operation at the o Credentials indicating access and resource control to perform the
remote server. operation at the remote server.
Server-to-server support is focused on reading and writing data Server-to-server support is focused on reading and writing data
objects between servers. The data object referred to at the remote objects between servers. The data object referred to at the remote
server is the same as the original request. Object attributes (see server is the same as the original data object requested by the
Section 6.1.4) might also be specified in the request to the remote client. Object attributes (see Section 6.1.4) might also be
server. specified in the request to the remote server.
In this way, a server acts as a proxy for a client, and a client can In this way, a server acts as a proxy for a client, and a client can
instantiate requests via that proxy. The operations will be instantiate requests via that proxy. The operations will be
performed as if the original requester had its own client co-located performed as if the original requester had its own client co-located
with the server. It is this mode of operation that provides with the server.
substantial savings in uplink capacity. This mode of operation can
also be triggered by an administrative/management application outside
the architecture.
When a client sends a request to a server with these additional When a client sends a request to a server with these additional
parameters, it is giving the server permission to act (proxy) on its parameters, it is giving the server permission to act (proxy) on its
behalf. Thus, it would be prudent for the supplied token to have behalf. Thus, it would be prudent for the supplied token to have
narrow privileges (e.g., limited to only the necessary data objects) narrow privileges (e.g., limited to only the necessary data objects)
or validity time (e.g., a small expiration time). or validity time (e.g., a small expiration time).
In the case of a GET operation, the server is to retrieve the data In the case of a retrieval operation, the server is to retrieve the
object from the remote server using the specified credentials (via a data object from the remote server using the specified credentials,
GET request to the remote server), and then optionally return the and then optionally return the object to a client. In the case of a
object to a client. In the case of a PUT operation, the server is to storage operation, the server is to store the object to the remote
store the object to the remote server using the specified credentials server using the specified credentials. The object might optionally
(via a PUT request to the remote server). The object might be uploaded from the client or might already exist at the proxy
optionally be uploaded from the client or might already exist at the server.
proxy server.
7. Security Considerations 7. Security Considerations
In general, the security considerations mentioned in In general, the security considerations mentioned in [RFC6646] apply
[I-D.ietf-decade-problem-statement] apply to this document as well. to this document as well.
A DECADE-compatible system provides a distributed storage service for A DECADE-compatible system provides a distributed storage service for
content distribution and similar applications. The system consists content distribution and similar applications. The system consists
of servers and clients that use these servers to upload data objects, of servers and clients that use these servers to upload data objects,
to request distribution of data objects, and to download data to request distribution of data objects, and to download data
objects. Such a system is employed in an overall application context objects. Such a system is employed in an overall application context
-- for example in a P2P Content Distribution Application, and it is -- for example in a P2P Content Distribution Application, and it is
expected that DECADE-compatible clients take part in application- expected that DECADE-compatible clients take part in application-
specific communication sessions. specific communication sessions.
The security considerations here focus on threats related to the The security considerations here focus on threats related to the
DECADE-compatible system and its communication services, i.e., the DECADE-compatible system and its communication services, i.e., the
DRP/SDT protocols that have been described in an abstract fashion in DRP/SDT protocols that have been described in an abstract fashion in
this document. this document.
7.1. Threat: System Denial of Service Attacks 7.1. Threat: System Denial of Service Attacks
A DECADE-compatible network of servers might be used to distribute A DECADE-compatible network might be used to distribute data objects
data objects from one client to a set of servers using the server-to- from one client to a set of servers using the server-to-server
server communication feature that a client can request when uploading communication feature that a client can request when uploading an
an object. Multiple clients uploading many objects at different object. Multiple clients uploading many objects at different servers
servers at the same time and requesting server-to-server distribution at the same time and requesting server-to-server distribution for
for them could thus mount massive distributed denial of service them could thus mount massive distributed denial of service (DDOS)
(DDOS) attacks, overloading a network of servers. attacks, overloading a network of servers.
This threat is addressed by its access control and resource control This threat is addressed by the server's access control and resource
framework. Servers can require Application End-Points to be control framework. Servers can require Application End-Points to be
authorized to store and to download objects, and Application End- authorized to store and to download objects, and Application End-
Points can delegate authorization to other Application End-Points Points can delegate authorization to other Application End-Points
using the token mechanism. using the token mechanism.
Of course the effective security of this approach depends on the Of course the effective security of this approach depends on the
strength of the token mechanism. See below for a discussion of this strength of the token mechanism. See below for a discussion of this
and related communication security threats. and related communication security threats.
Denial of Service Attacks against a single server (directing many Denial of Service Attacks against a single server (directing many
requests to that server) might still lead to considerable load for requests to that server) might still lead to considerable load for
processing requests and invalidating tokens. A SDT therefore MUST processing requests and invalidating tokens. SDT therefore MUST
provide a redirection mechanism as described as a requirement in provide a redirection mechanism as described as a requirement in
[I-D.ietf-decade-reqs]. [I-D.ietf-decade-reqs].
7.2. Threat: Protocol Security 7.2. Threat: Protocol Security
7.2.1. Threat: Authorization Mechanisms Compromised 7.2.1. Threat: Authorization Mechanisms Compromised
A DECADE-compatible system does not require Application End-Points to A DECADE-compatible system does not require Application End-Points to
authenticate in order to access a server for downloading objects, authenticate in order to access a server for downloading objects,
since authorization is not based on End-Point or user identities but since authorization is not based on End-Point or user identities but
skipping to change at page 29, line 31 skipping to change at page 26, line 24
servers is compromised. servers is compromised.
This is a general security threat that applies to authorization This is a general security threat that applies to authorization
delegation schemes. Specifications of existing delegation schemes delegation schemes. Specifications of existing delegation schemes
such as OAuth [RFC5849] discuss these general threats in detail. We such as OAuth [RFC5849] discuss these general threats in detail. We
can say that the DRP has to specify appropriate algorithms for token can say that the DRP has to specify appropriate algorithms for token
generation. Moreover, authorization tokens should have a limited generation. Moreover, authorization tokens should have a limited
validity period that should be specified by the application. Token validity period that should be specified by the application. Token
confidentiality should be provided by application protocols that confidentiality should be provided by application protocols that
carry tokens, and the SDT and DRP should provide secure carry tokens, and the SDT and DRP should provide secure
(confidential) communication. (confidential) communication modes.
7.2.2. Threat: Object Spoofing 7.2.2. Threat: Data Object Spoofing
In a DECADE-compatible system, an Application End-Point is referring In a DECADE-compatible system, an Application End-Point is referring
other Application End-Points to servers to download a specified data other Application End-Points to servers to download a specified data
objects. An attacker could "inject" a faked version of the object objects. An attacker could "inject" a faked version of the object
into this process, so that the downloading End-Point effectively into this process, so that the downloading End-Point effectively
receives a different object (compared to what the uploading End-Point receives a different object (compared to what the uploading End-Point
provided). As result, the downloading End-Point believes that is has provided). As result, the downloading End-Point believes that is has
received an object that corresponds to the name it was provided received an object that corresponds to the name it was provided
earlier, whereas in fact it is a faked object. Corresponding attacks earlier, whereas in fact it is a faked object. Corresponding attacks
could be mounted against the application protocol (that is used for could be mounted against the application protocol (that is used for
skipping to change at page 30, line 16 skipping to change at page 27, line 10
those application scenarios where hashes of data objects are not those application scenarios where hashes of data objects are not
applicable (for example live-streaming) other forms of name-object applicable (for example live-streaming) other forms of name-object
binding can be used (see Section 5.3). This flexibility also binding can be used (see Section 5.3). This flexibility also
addresses cryptographic algorithm evolvability: hash functions might addresses cryptographic algorithm evolvability: hash functions might
get deprecated, better alternatives might be invented etc., so that get deprecated, better alternatives might be invented etc., so that
applications can choose appropriate mechanisms meeting their security applications can choose appropriate mechanisms meeting their security
requirements. requirements.
DECADE-compatible servers MAY perform name-object binding validation DECADE-compatible servers MAY perform name-object binding validation
on stored objects, but Application End-Points MUST NOT rely on that. on stored objects, but Application End-Points MUST NOT rely on that.
In other forms: Application End-Points SHOULD perform name-object In other words, Application End-Points SHOULD perform name-object
binding validation on received objects. binding validation on received objects.
8. IANA Considerations 8. IANA Considerations
This document does not have any IANA considerations. This document does not have any IANA considerations.
9. Acknowledgments 9. Acknowledgments
We thank the following people for their contributions to this We thank the following people for their contributions to this
document: document:
Carsten Bormann
David Bryan David Bryan
Dave Crocker Dave Crocker
David Harrington
Yingjie Gu Yingjie Gu
Hongqiang (Harry) Liu Hongqiang (Harry) Liu
David McDysan David McDysan
Borje Ohlman Borje Ohlman
Konstantinos Pentikousis
Haibin Song Haibin Song
Martin Stiemerling Martin Stiemerling
Richard Woundy Richard Woundy
Ning Zong Ning Zong
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 10.2. Informative References
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
skipping to change at page 31, line 28 skipping to change at page 28, line 24
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010. RFC 5661, January 2010.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010. April 2010.
[RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- [RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
Network Storage Systems", RFC 6392, October 2011. Network Storage Systems", RFC 6392, October 2011.
[I-D.ietf-decade-problem-statement] [RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement", Application Data Enroute (DECADE) Problem Statement",
draft-ietf-decade-problem-statement-06 (work in progress), RFC 6646, July 2012.
May 2012.
[I-D.ietf-decade-reqs] [I-D.ietf-decade-reqs]
Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE
Requirements", draft-ietf-decade-reqs-06 (work in Requirements", draft-ietf-decade-reqs-06 (work in
progress), March 2012. progress), March 2012.
[OpenFlow] [OpenFlow]
"OpenFlow Organization", <http://www.openflow.org/>. "OpenFlow Organization", <http://www.openflow.org/>.
[GoogleFileSystem] [GoogleFileSystem]
skipping to change at page 32, line 34 skipping to change at page 29, line 28
A.4. Access Control Authorization A.4. Access Control Authorization
All methods of access control are supported: public-unrestricted, All methods of access control are supported: public-unrestricted,
public-restricted and private. Access Control Policies are generated public-restricted and private. Access Control Policies are generated
by a Content Distribution Application and provided to the client's by a Content Distribution Application and provided to the client's
Resource Controller. The server is responsible for implementing the Resource Controller. The server is responsible for implementing the
access control checks. access control checks.
A.5. Resource Control Interface A.5. Resource Control Interface
Clients can manage the resources (e.g. bandwidth) on the DECADE Clients can manage the resources (e.g., bandwidth) on the DECADE
server that can be used by other Application End-Points. Resource server that can be used by other Application End-Points. Resource
Sharing Policies are generated by a Content Distribution Application Sharing Policies are generated by a Content Distribution Application
and provided to the client's Resource Controller. The server is and provided to the client's Resource Controller. The server is
responsible for implementing the resource sharing policies. responsible for implementing the resource sharing policies.
A.6. Discovery Mechanism A.6. Discovery Mechanism
The particular protocol used for discovery is outside the scope of The particular protocol used for discovery is outside the scope of
this document. However, options and considerations have been this document. However, options and considerations have been
discussed in Section 5.5. discussed in Section 5.5.
 End of changes. 125 change blocks. 
451 lines changed or deleted 334 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/