GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7069

Independent Submission R. Alimi Request for Comments: 7069 Google Category: Informational A. Rahman ISSN: 2070-1721 InterDigital Communications, LLC

                                                           D. Kutscher
                                                                   NEC
                                                               Y. Yang
                                                       Yale University
                                                               H. Song
                                                   Huawei Technologies
                                                        K. Pentikousis
                                                                  EICT
                                                         November 2013
            DECoupled Application Data Enroute (DECADE)

Abstract

 Content distribution applications, such as those employing peer-to-
 peer (P2P) technologies, are widely used on the Internet and make up
 a large portion of the traffic in many networks.  Often, however,
 content distribution applications use network resources
 inefficiently.  One way to improve efficiency is to introduce storage
 capabilities within the network and enable cooperation between end-
 host and in-network content distribution mechanisms.  This is the
 capability provided by a DECoupled Application Data Enroute (DECADE)
 system, which is introduced in this document.  DECADE enables
 applications to take advantage of in-network storage when
 distributing data objects as opposed to using solely end-to-end
 resources.  This document presents the underlying principles and key
 functionalities of such a system and illustrates operation through a
 set of examples.

Alimi, et al. Informational [Page 1] RFC 7069 DECADE November 2013

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7069.

Copyright Notice

 Copyright (c) 2013 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Alimi, et al. Informational [Page 2] RFC 7069 DECADE November 2013

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
 2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
 3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
 4.  Architectural Principles  . . . . . . . . . . . . . . . . . .   8
   4.1.  Data- and Control-Plane Decoupling  . . . . . . . . . . .   8
   4.2.  Immutable Data Objects  . . . . . . . . . . . . . . . . .   9
   4.3.  Data Object Identifiers . . . . . . . . . . . . . . . . .  10
   4.4.  Explicit Control  . . . . . . . . . . . . . . . . . . . .  11
   4.5.  Resource and Data Access Control through Delegation . . .  11
 5.  System Components . . . . . . . . . . . . . . . . . . . . . .  12
   5.1.  Application Endpoint  . . . . . . . . . . . . . . . . . .  13
   5.2.  DECADE Client . . . . . . . . . . . . . . . . . . . . . .  14
   5.3.  DECADE Server . . . . . . . . . . . . . . . . . . . . . .  14
   5.4.  Data Sequencing and Naming  . . . . . . . . . . . . . . .  15
   5.5.  Token-Based Authorization and Resource Control  . . . . .  17
   5.6.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .  18
 6.  DECADE Protocol Considerations  . . . . . . . . . . . . . . .  19
   6.1.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.2.  Resource Protocol . . . . . . . . . . . . . . . . . . . .  19
   6.3.  Data Transfer . . . . . . . . . . . . . . . . . . . . . .  22
   6.4.  Server-Server Protocols . . . . . . . . . . . . . . . . .  23
   6.5.  Potential DRP/SDT Candidates  . . . . . . . . . . . . . .  23
 7.  How In-Network Storage Components Map to DECADE . . . . . . .  24
 8.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
   8.1.  Threat: System Denial-of-Service Attacks  . . . . . . . .  25
   8.2.  Threat: Authorization Mechanisms Compromised  . . . . . .  25
   8.3.  Threat: Spoofing of Data Objects  . . . . . . . . . . . .  26
 9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  27
 10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
   10.1.  Normative References . . . . . . . . . . . . . . . . . .  27
   10.2.  Informative References . . . . . . . . . . . . . . . . .  27
 Appendix A.  Evaluation of Candidate Protocols for DECADE DRP/SDT  29
   A.1.  HTTP  . . . . . . . . . . . . . . . . . . . . . . . . . .  29
   A.2.  CDMI  . . . . . . . . . . . . . . . . . . . . . . . . . .  31
   A.3.  OAuth . . . . . . . . . . . . . . . . . . . . . . . . . .  34

Alimi, et al. Informational [Page 3] RFC 7069 DECADE November 2013

1. Introduction

 Content distribution applications, such as peer-to-peer (P2P)
 applications, are widely used on the Internet to distribute data
 objects and make up a large portion of the traffic in many networks.
 Said applications can often introduce performance bottlenecks in
 otherwise well-provisioned networks.  In some cases, operators are
 forced to invest substantially in infrastructure to accommodate the
 use of such applications.  For instance, in many subscriber networks,
 it can be expensive to upgrade network equipment in the "last mile",
 because it can involve replacing equipment and upgrading wiring and
 devices at individual homes, businesses, DSLAMs (Digital Subscriber
 Line Access Multiplexers), and CMTSs (Cable Modem Termination
 Systems) in remote locations.  It may be more practical and
 economical to upgrade the core infrastructure, instead of the "last
 mile" of the network, as this involves fewer components that are
 shared by many subscribers.  See [RFC6646] and [RFC6392] for a more
 complete discussion of the problem domain and general discussions of
 the capabilities envisioned for a DECADE system.  As a historical
 point, it should be noted that [RFC6646] and [RFC6392] came out of
 the now closed DECADE Working Group.  This document aims to advance
 some of the valuable concepts from that now closed Working Group.
 This document presents mechanisms for providing in-network storage
 that can be integrated into content distribution applications.  The
 primary focus is P2P-based content distribution, but DECADE may be
 useful to other applications with similar characteristics and
 requirements (e.g., Content Distribution Networks (CDNs) or hybrid
 P2P/CDNs).  The approach we adopt in this document is to define the
 core functionalities and protocol functions that are needed to
 support a DECADE system.  This document provides illustrative
 examples so that implementers can understand the main concepts in
 DECADE, but it is generally assumed that readers are also familiar
 with the terms and concepts used in [RFC6646] and [RFC6392].

1.1. Requirements Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

Alimi, et al. Informational [Page 4] RFC 7069 DECADE November 2013

2. Terminology

 This document uses the following terminology.
 Application Endpoint
    A host that includes a DECADE client along with other application
    functionalities (e.g., peer-to-peer (P2P) client, video streaming
    client).
 Content Distribution Application
    A specific type of application that may exist in an Application
    Endpoint.  A content distribution application is an application
    (e.g., P2P) designed for dissemination of large amounts of content
    (e.g., files or video streams) to multiple peers.  Content
    distribution applications may divide content into smaller blocks
    for dissemination.
 Data Object
    A data object is the unit of data stored and retrieved from a
    DECADE server.  The data object is a sequence of raw bytes.  The
    server maintains metadata associated with each data object, but
    the metadata is physically and logically separate from the data
    object.
 DECADE Client
    A DECADE client uploads and/or retrieves data from a DECADE
    server.
 DECADE Resource Protocol (DRP)
    A logical protocol for communication of access control and
    resource-scheduling policies from a DECADE client to a DECADE
    server, or between DECADE servers.  In practice, the functionality
    of the DRP may be distributed over one or more actual protocols.
 DECADE Server
    A DECADE server stores data inside the network for a DECADE client
    or another DECADE server, and thereafter it manages both the
    stored data and access to that data by other DECADE clients.
 DECADE Storage Provider
    A DECADE storage provider deploys and/or manages DECADE servers
    within a network.
 DECADE System
    An in-network storage system that is composed of DECADE clients
    and DECADE servers.  The DECADE servers may be deployed by one or
    more DECADE storage providers.

Alimi, et al. Informational [Page 5] RFC 7069 DECADE November 2013

 In-Network Storage
    A service inside a network that provides storage to applications.
    In-network storage may reduce upload/transit/backbone traffic and
    improve application performance.  In-network storage may, for
    example, be co-located with the border router (network-attached
    storage) or inside a data center.  A DECADE system is an example
    of an in-network storage system.
 Standard Data Transfer (SDT) Protocol
    A logical protocol used to transfer data objects between a DECADE
    client and DECADE server, or between DECADE servers.  The intent
    is that in practice the SDT should map to an existing, well-known
    protocol already in use over the Internet for transporting data.

3. Overview

 A DECADE system provides a distributed storage service for content
 distribution applications (e.g., P2P).  The system consists of
 clients and servers.  A client first uploads data objects to one or
 more selected servers and optionally requests distribution of these
 data objects to other servers.  The client then selectively
 authorizes other clients to download these data objects.  Such a
 system is employed in an overall application context (e.g., P2P file
 sharing), and it is expected that DECADE clients take part in
 application-specific communication sessions.
 Figure 1 is a schematic of a simple DECADE system with two DECADE
 clients and two DECADE servers.  As illustrated, a DECADE client,
 which is part of an Application Endpoint, uses the DECADE Resource
 Protocol (DRP) to convey to a server information related to access
 control and resource-scheduling policies.  DRP can also be used
 between servers for exchanging this type of information.  A DECADE
 system employs the Standard Data Transfer (SDT) protocol to transfer
 data objects to and from a server, as we will explain later.

Alimi, et al. Informational [Page 6] RFC 7069 DECADE November 2013

                       Native Application
                        Protocol(s)
       .-------------.   (e.g., P2P)        .-------------.
       | Application | <------------------> | Application |
       |  Endpoint   |                      |  Endpoint   |
       |             |                      |             |
       | .--------.  |                      | .--------.  |
       | | DECADE |  |                      | | DECADE |  |
       | | Client |  |                      | | Client |  |
       | `--------'  |                      | `--------'  |
       `-------------'                      `-------------'
           |     ^                              |     ^
   DECADE  |     | Standard                     |     |
  Resource |     |   Data                   DRP |     | SDT
  Protocol |     | Transfer                     |     |
   (DRP)   |     |   (SDT)                      |     |
           |     |                              |     |
           |     |                              |     |
           |     |                              |     |
           |     |                              |     |
           |     |                              |     |
           |     |                              |     |
           v     v                              v     v
       .=============.         DRP          .=============.
       |   DECADE    | <------------------> |   DECADE    |
       |   Server    | <------------------> |   Server    |
       `============='         SDT          `============='
                       Figure 1: DECADE Overview
 With Figure 1 at hand, assume that Application Endpoint B requests a
 data object from Application Endpoint A using their native
 application protocols (e.g., P2P protocol) as in Figure 2.  In this
 case, Endpoint A will act as the sender, and Endpoint B as the
 receiver for said data object.  S(A) is the DECADE storage server
 which is access controlled.  This means, first, that Endpoint A has a
 right to store the data object in S(A).  Secondly, Endpoint B needs
 to obtain authorization before being able to retrieve the data object
 from S(A).
 The four steps involved in a DECADE session are illustrated in
 Figure 2.  The sequence starts with the initial contact between
 Endpoint B and Endpoint A, where Endpoint B requests a data object
 using their native application protocol (e.g., P2P).  Next, Endpoint
 A uses DRP to obtain a token corresponding to the data object that
 was requested by Endpoint B.  There may be several ways for Endpoint
 A to obtain such a token, e.g., compute it locally or request one
 from its DECADE storage server, S(A).  Once obtained, Endpoint A then

Alimi, et al. Informational [Page 7] RFC 7069 DECADE November 2013

 provides the token to Endpoint B (again, using their native
 application protocol).  Finally, Endpoint B provides the received
 token to S(A) via DRP, and subsequently requests and downloads the
 data object via SDT.  Again, it is assumed that DECADE is employed in
 an overall application context (e.g., P2P file-sharing session).
 For completeness, note that there is an important prerequisite step
 (not shown) to Figure 2, where Endpoint A first discovers and then
 stores the data object(s) of interest in S(A).
                             .----------.
    2. Obtain      --------> |   S(A)   | <------
       Token      /          `----------'        \   4. Request and
       (DRP)     /                                \     Download
       Locally  /                                  \    Data Object
       or From /                                    \   (DRP + SDT)
       S(A)   v          1. App Request              v
     .-------------. <--------------------------- .-------------.
     | Application |                              | Application |
     | Endpoint A  |                              | Endpoint B  |
     `-------------' ---------------------------> `-------------'
                        3. App Response (token)
                Figure 2: Download from Storage Server

4. Architectural Principles

 This section presents the key principles followed by any DECADE
 system.

4.1. Data- and Control-Plane Decoupling

 DECADE SDT and DRP can be classified as belonging to data-plane
 functionality.  The algorithms and signaling for a P2P application,
 for example, would belong to control-plane functionality.
 A DECADE system aims to be application independent and should support
 multiple content distribution applications.  Typically, a complete
 content distribution application implements a set of control-plane
 functions including content search, indexing and collection, access
 control, replication, request routing, and QoS scheduling.
 Implementers of different content distribution applications may have
 unique considerations when designing the control-plane functions.
 For example, with respect to the metadata management scheme,
 traditional file systems provide a standard metadata abstraction: a
 recursive structure of directories to offer namespace management
 where each file is an opaque byte stream.  Content distribution
 applications may use different metadata management schemes.  For

Alimi, et al. Informational [Page 8] RFC 7069 DECADE November 2013

 instance, one application might use a sequence of blocks (e.g., for
 file sharing), while another application might use a sequence of
 frames (with different sizes) indexed by time.
 With respect to resource-scheduling algorithms, a major advantage of
 many successful P2P systems is their substantial expertise in
 achieving efficient utilization of peer resources.  For instance,
 many streaming P2P systems include optimization algorithms for
 constructing overlay topologies that can support low-latency, high-
 bandwidth streaming.  The research community as well as implementers
 of such systems continuously fine-tune existing algorithms and invent
 new ones.  A DECADE system should be able to accommodate and benefit
 from all new developments.
 In short, given the diversity of control-plane functions, a DECADE
 system should allow for as much flexibility as possible to the
 control plane to implement specific policies (and be decoupled from
 data-plane DRP/SDT).  Decoupling the control plane from the data
 plane is not new, of course.  For example, OpenFlow [OpenFlow] is an
 implementation of this principle for Internet routing, where the
 computation of the forwarding table and the application of the
 forwarding table are separated.  The Google File System
 [GoogleFileSystem] applies the same principle to file system design
 by utilizing a Master to handle metadata management and several Chunk
 servers to handle data-plane functions (i.e., read and write of
 chunks of data).  Finally, NFSv4.1's parallel NFS (pNFS) extension
 [RFC5661] also adheres to this principle.

4.2. Immutable Data Objects

 A common property of bulk content to be broadly distributed is that
 it is immutable -- once content is generated, it is typically not
 modified.  For example, once a movie has been edited and released for
 distribution, it is very uncommon that the corresponding video frames
 and images need to be modified.  The same applies to document
 distribution, such as RFCs; audio files, such as podcasts; and
 program patches.  Focusing on immutable data can substantially
 simplify data-plane design, since consistency requirements can be
 relaxed.  It also simplifies data reuse and the removal of
 duplicates.
 Depending on its specific requirements, an application may store
 immutable data objects in DECADE servers such that each data object
 is completely self-contained (e.g., a complete, independently
 decodable video segment).  An application may also divide data into
 data objects that require application-level assembly.  Many content
 distribution applications divide bulk content into data objects for
 multiple reasons, including (a) fetching different data objects from

Alimi, et al. Informational [Page 9] RFC 7069 DECADE November 2013

 different sources in parallel and (b) faster recovery and
 verification as individual data objects might be recovered and
 verified.  Typically, applications use a data object size larger than
 a single packet in order to reduce control overhead.
 A DECADE system should be agnostic to the nature of the data objects
 and should not specify a fixed size for them.  A protocol
 specification based on this architecture may prescribe requirements
 on minimum and maximum sizes for compliant implementations.
 Note that immutable data objects can still be deleted.  Applications
 can support modification of existing data stored at a DECADE server
 through a combination of storing new data objects and deleting
 existing data objects.  For example, a metadata management function
 of the control plane might associate a name with a sequence of
 immutable data objects.  If one of the data objects is modified, the
 meta-data management function changes the mapping of the name to a
 new sequence of immutable data objects.

4.3. Data Object Identifiers

 A data object stored in a DECADE server shall be accessed by DECADE
 clients via a data object identifier.  Each DECADE client may be able
 to access more than one storage server.  A data object that is
 replicated across different storage servers managed by a storage
 provider may be accessed through a single identifier.  Since data
 objects are immutable, it shall be possible to support persistent
 identifiers for data objects.
 Data object identifiers should be created by DECADE clients when
 uploading the corresponding objects to a DECADE server.  The scheme
 for the assignment/derivation of the data object identifier to a data
 object depends as the data object naming scheme and is out of scope
 of this document.  One possibility is to name data objects using
 hashes as described in [RFC6920].  Note that [RFC6920] describes
 naming schemes on a semantic level only, but specific SDTs and DRPs
 use specific representations.
 In particular, for some applications, it is important that clients
 and servers be able to validate the name-object binding, i.e., by
 verifying that a received object really corresponds to the name
 (identifier) that was used for requesting it (or that was provided by
 a sender).  If a specific application requires name-object binding
 validation, the data object identifiers can support it by providing
 message digests or so-called self-certifying naming information.

Alimi, et al. Informational [Page 10] RFC 7069 DECADE November 2013

 Different name-object binding validation mechanisms may be supported
 in a single DECADE system.  Content distribution applications can
 decide what mechanism to use, or to not provide name-object
 validation (e.g., if authenticity and integrity can by ascertained by
 alternative means).  We expect that applications may be able to
 construct unique names (with high probability) without requiring a
 registry or other forms of coordination.  Names may be self-
 describing so that a receiving DECADE client understands, for
 example, which hash function to use for validating name-object
 binding.
 Some content distribution applications will derive the name of a data
 object from the hash over the data object; this is made possible by
 the fact that DECADE objects are immutable.  But there may be other
 applications such as live streaming where object names will not based
 on hashes but rather on an enumeration scheme.  The naming scheme
 will also enable those applications to construct unique names.
 In order to enable the uniqueness, flexibility and self-describing
 properties, the naming scheme used in a DECADE system should provide
 a "type" field that indicates the name-object validation function
 type (for example, "sha-256" [RFC5754]) and the cryptographic data
 (such as an object hash) that corresponds to the type information.
 Moreover, the naming scheme may additionally provide application or
 publisher information.

4.4. Explicit Control

 To support the functions of an application's control plane,
 applications should be able to keep track and coordinate which data
 is stored at particular servers.  Thus, in contrast with traditional
 caches, applications are given explicit control over the placement
 (selection of a DECADE server), deletion (or expiration policy), and
 access control for stored data objects.  Consider deletion/expiration
 policy as a simple example.  An application might require that a
 DECADE server stores data objects for a relatively short period of
 time (e.g., for live-streaming data).  Another application might need
 to store data objects for a longer duration (e.g., for video on
 demand), and so on.

4.5. Resource and Data Access Control through Delegation

 A DECADE system provides a shared infrastructure to be used by
 multiple Application Endpoints.  Thus, it needs to provide both
 resource and data access control, as discussed in the following
 subsections.

Alimi, et al. Informational [Page 11] RFC 7069 DECADE November 2013

4.5.1. Resource Allocation

 There are two primary interacting entities in a DECADE system.
 First, storage providers coordinate DECADE server provisioning,
 including their total available resources.  Second, applications
 coordinate data transfers amongst available DECADE servers and
 between servers and clients.  A form of isolation is required to
 enable each of the concurrently running applications to explicitly
 manage its own data objects and share of resources at the available
 servers.  Therefore, a storage provider should delegate resource
 management on a DECADE server to uploading DECADE clients, enabling
 them to explicitly and independently manage their own share of
 resources on a server.

4.5.2. User Delegation

 DECADE storage providers will have the ability to explicitly manage
 the entities allowed to utilize the resources available on a DECADE
 server.  This is needed for reasons such as capacity-planning and
 legal considerations in certain deployment scenarios.  The DECADE
 server should grant a share of the resources to a DECADE client.  The
 client can in turn share the granted resources amongst its (possibly)
 multiple applications.  The share of resources granted by a server is
 called a User Delegation.  As a simple example, a DECADE server
 operated by an ISP might be configured to grant each ISP subscriber
 1.5 Mbit/s of network capacity and 1 GB of memory.  The ISP
 subscriber might in turn divide this share of resources amongst a
 video-streaming application and file-sharing application that are
 running concurrently.

5. System Components

 As noted earlier, the primary focus of this document is the
 architectural principles and the system components that implement
 them.  While specific system components might differ between
 implementations, this document details the major components and their
 overall roles in the architecture.  To keep the scope narrow, we only
 discuss the primary components related to protocol development.
 Particular deployments will require additional components (e.g.,
 monitoring and accounting at a server), but they are intentionally
 omitted from this document.

Alimi, et al. Informational [Page 12] RFC 7069 DECADE November 2013

5.1. Application Endpoint

 Content distribution applications have many functional components.
 For example, many P2P applications have components and algorithms to
 manage overlay topology, rate allocation, piece selection, and so on.
 In this document, we focus on the components directly engaged in a
 DECADE system.  Figure 3 illustrates the components discussed in this
 section from the perspective of a single Application Endpoint.
                             Native Application Protocol(s)
                          (with other Application Endpoints)
                                  .--------------------->
                                  |
                                  V
 .----------------------------------------------------------------.
 | Application Endpoint                                           |
 | .-------------------.          .-------------------.           |
 | | Application-Layer |   ...    | App Data Assembly |           |
 | |    Algorithms     |          |    Sequencing     |           |
 | `-------------------'          `-------------------'           |
 |                                                                |
 |  .==========================================================.  |
 |  | DECADE Client                                            |  |
 |  | .-------------------------. .--------------------------. |  |
 |  | | Resource Controller     | | Data Controller          | |  |
 |  | | .--------. .----------. | | .------------. .-------. | |  |
 |  | | |  Data  | | Resource-| | | |    Data    | | Data  | | |  |
 |  | | | Access | | Sharing  | | | | Scheduling | | Index | | |  |
 |  | | | Policy | |  Policy  | | | |            | |       | | |  |
 |  | | `--------' `----------' | | `------------' `-------' | |  |
 |  | `-------------------------' `--------------------------' |  |
 |  |   |                                ^                     |  |
 |  `== | ============================== | ===================='  |
 `----- | ------------------------------ | -----------------------'
        |                                |
        | DECADE Resource Protocol       | Standard Data Transfer
        |    (DRP)                       |    (SDT)
        v                                V
          Figure 3: Application and DECADE Client Components
 A DECADE system is geared towards supporting applications that can
 distribute content using data objects (e.g., P2P).  To accomplish
 this, applications can include a component responsible for creating
 the individual data objects before distribution and for reassembling
 them later.  We call this component Application Data Assembly.  In
 producing and assembling data objects, two important considerations
 are sequencing and naming.  A DECADE system assumes that applications

Alimi, et al. Informational [Page 13] RFC 7069 DECADE November 2013

 implement this functionality themselves.  In addition to DECADE
 DRP/SDT, applications will most likely also support other, native
 application protocols (e.g., P2P control and data transfer
 protocols).

5.2. DECADE Client

 The DECADE client provides the local support to an application, and
 it can be implemented standalone, embedded into the application, or
 integrated in other software entities within network devices (i.e.,
 hosts).  In general, applications may have different resource-sharing
 policies and data access policies with regard to DECADE servers.
 These policies may be existing policies of applications or custom
 policies.  The specific implementation is decided by the application.
 Recall that DECADE decouples the control and the data transfer of
 applications.  A data-scheduling component schedules data transfers
 according to network conditions, available servers, and/or available
 server resources.  The Data Index indicates data available 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 provide the ability
 to locate data amongst distributed Application Endpoints (i.e., a
 data search mechanism such as a Distributed Hash Table (DHT)).

5.3. DECADE Server

 Figure 4 illustrates the primary components of a DECADE server.  Note
 that the description below does not assume a single-host or
 centralized implementation -- a DECADE server is not necessarily a
 single physical machine; it can also be implemented in a distributed
 manner on a cluster of machines.

Alimi, et al. Informational [Page 14] RFC 7069 DECADE November 2013

        | DECADE Resource   | Standard Data
        | Protocol (DRP)    | Transfer (SDT)
        |                   |
     .= | ================= | ===========================.
     |  |                   v              DECADE Server |
     |  |      .----------------.                        |
     |  |----> | Access Control | <--------.             |
     |  |      `----------------'          |             |
     |  |                   ^              |             |
     |  |                   |              |             |
     |  |                   v              |             |
     |  |   .---------------------.        |             |
     |  `-> | Resource Scheduling | <------|             |
     |      `---------------------'        |             |
     |                      ^              |             |
     |                      |              |             |
     |                      v        .-----------------. |
     |        .-----------------.    | User Delegation | |
     |        |    Data Store   |    |   Management    | |
     |        `-----------------'    `-----------------' |
     `==================================================='
                  Figure 4: DECADE Server Components
 Provided sufficient authorization, a client shall be able to access
 its own data or other client's data in a DECADE server.  Clients may
 also authorize other clients to store data.  If access is authorized
 by a client, the server should provide access.  Applications may
 apply resource-sharing policies or use a custom policy.  DECADE
 servers will then perform resource scheduling according to the
 resource-sharing policies indicated by the client as well as any
 other previously configured User Delegations.  Data from applications
 will be stored at a DECADE server.  Data may be deleted from storage
 either explicitly or automatically (e.g., after a Time To Live (TTL)
 expiration).

5.4. Data Sequencing and Naming

 The DECADE naming scheme implies no sequencing or grouping of
 objects, even if this is done at the application layer.  To
 illustrate these properties, this section presents several examples
 of use.

Alimi, et al. Informational [Page 15] RFC 7069 DECADE November 2013

5.4.1. Application with Fixed-Size Chunks

 Consider an application in which each individual application-layer
 segment of data is called a "chunk" and has a name of the form:
 "CONTENT_ID:SEQUENCE_NUMBER".  Furthermore, assume that the
 application's native protocol uses chunks of size 16 KB.  Now, assume
 that this application wishes to store data in a DECADE server in data
 objects of size 64 KB.  To accomplish this, it can map a sequence of
 4 chunks into a single data object, as shown in Figure 5.
   Application Chunks
 .---------.---------.---------.---------.---------.---------.--------
 |         |         |         |         |         |         |
 | Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6
 |         |         |         |         |         |         |
 `---------`---------`---------`---------`---------`---------`--------
   DECADE Data Objects
 .---------------------------------------.----------------------------
 |                                       |
 |               Object_0                |               Object_1
 |                                       |
 `---------------------------------------`----------------------------
      Figure 5: Mapping Application Chunks to DECADE Data Objects
 In this example, the application maintains a logical mapping that is
 able to determine the name of a DECADE data object given the chunks
 contained within that data object.  The name may be conveyed from
 either the original uploading DECADE client, another Endpoint with
 which the application is communicating, etc.  As long as the data
 contained within each sequence of chunks is globally unique, the
 corresponding data objects have globally unique names.

5.4.2. Application with Continuous Streaming Data

 Consider an application whose native protocol retrieves a continuous
 data stream (e.g., an MPEG2 stream) instead of downloading and
 redistributing chunks of data.  Such an application could segment the
 continuous data stream to produce either fixed-sized or variable-
 sized data objects.  Figure 6 depicts how a video streaming
 application might produce variable-sized data objects such that each
 data object contains 10 seconds of video data.  In a manner similar
 to the previous example, the application may maintain a mapping that
 is able to determine the name of a data object given the time offset
 of the video chunk.

Alimi, et al. Informational [Page 16] RFC 7069 DECADE November 2013

   Application's Video Stream
 .--------------------------------------------------------------------
 |
 |
 |
 `--------------------------------------------------------------------
 ^              ^              ^              ^              ^
 |              |              |              |              |
 0 seconds     10 seconds     20 seconds     30 seconds     40 seconds
 0 B          400 KB         900 KB        1200 KB        1500 KB
   DECADE Data Objects
 .--------------.--------------.--------------.--------------.--------
 |              |              |              |              |
 |   Object_0   |   Object_1   |   Object_2   |   Object_3   |
 |   (400 KB)   |   (500 KB)   |   (300 KB)   |   (300 KB)   |
 `--------------`--------------`--------------`--------------`--------
   Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects

5.5. Token-Based Authorization and Resource Control

 A key feature of a DECADE system is that an Application Endpoint can
 authorize other Application Endpoints to store or retrieve data
 objects from its in-network storage via tokens.  The peer client then
 uses the token when sending requests to the DECADE server.  Upon
 receiving a token, the server validates the signature and the
 operation being performed.
 This is a simple scheme, but has some important advantages over an
 alternative approach, for example, in which a client explicitly
 manipulates an Access Control List (ACL) associated with each data
 object.  In particular, it has the following advantages when applied
 to DECADE systems.  First, authorization policies are implemented
 within the application, thus the Application Endpoint explicitly
 controls when tokens are generated, to whom they are distributed, and
 for how long they will be valid.  Second, fine-grained access and
 resource control can be applied to data objects.  Third, there is no
 messaging between a client and server to manipulate data object
 permissions.  This can simplify, in particular, applications that
 share data objects with many dynamic peers and need to frequently
 adjust access control policies attached to data objects.  Finally,
 tokens can provide anonymous access, in which a server does not need
 to know the identity of each client that accesses it.  This enables a
 client to send tokens to clients belonging to other storage
 providers, and to allow them to read or write data objects from the
 storage of its own storage provider.  In addition to clients' ability
 to apply access control policies to data objects, the server may be

Alimi, et al. Informational [Page 17] RFC 7069 DECADE November 2013

 configured to apply additional policies based on user, object
 properties, geographic location, etc.  A client might thus be denied
 access even though it possesses a valid token.

5.6. Discovery

 A DECADE system should include a discovery mechanism through which
 DECADE clients locate an appropriate DECADE server.  A discovery
 mechanism should allow a client to determine an IP address or some
 other identifier that can be resolved to locate the server for which
 the client will be authorized to generate tokens (via DRP).  (The
 discovery mechanism might also result in an error if no such servers
 can be located.)  After discovering one or more servers, a DECADE
 client can distribute load and requests across them (subject to
 resource limitations and policies of the servers themselves)
 according to the policies of the Application Endpoint in which it is
 embedded.  The discovery mechanism outlined here does not provide the
 ability to locate arbitrary DECADE servers to which a client might
 obtain tokens from others.  To do so will require application-level
 knowledge, and it is assumed that this functionality is implemented
 in the content distribution application.
 As noted above, the discovered DECADE server should be authorized to
 allow the client to store data objects and then generate tokens to
 allow other clients to retrieve these data objects.  This
 authorization may be:
  1. a result of off-line administrative procedures;
  1. access network dependent (e.g., all the subscribers to a

particular ISP may be allowed by the ISP);

  1. due to a prior subscription;
  1. etc.
 The particular protocol used for discovery is out of scope of this
 document, but any specification should reuse well-known protocols
 wherever possible.

Alimi, et al. Informational [Page 18] RFC 7069 DECADE November 2013

6. DECADE Protocol Considerations

 This section presents the DRP and the SDT protocol in terms of
 abstract protocol interactions that are intended to be mapped to
 specific protocols in an implementation.  In general, the DRP/SDT
 functionality for DECADE client-server interaction is very similar to
 that for server-server interaction.  Any differences are highlighted
 below.  DRP is used by a DECADE client to configure the resources and
 authorization used to satisfy requests (reading, writing, and
 management operations concerning data objects) at a server.  SDT will
 be used to transport data between a client and a server, as
 illustrated in Figure 1.

6.1. Naming

 A DECADE system SHOULD use [RFC6920] as the recommended and default
 naming scheme.  Other naming schemes that meet the guidelines in
 Section 4.3 MAY alternatively be used.  In order to provide a simple
 and generic interface, the DECADE server will be responsible only for
 storing and retrieving individual data objects.
 The DECADE naming format SHOULD NOT attempt to replace any naming or
 sequencing of data objects already performed by an application.
 Instead, naming is intended to apply only to data objects referenced
 by DECADE-specific purposes.  An application using a DECADE client
 may use a naming and sequencing scheme independent of DECADE names.
 The DECADE client SHOULD maintain a mapping from its own data objects
 and their names to the DECADE-specific data objects and names.
 Furthermore, the DECADE naming scheme implies no sequencing or
 grouping of objects, even if this is done at the application layer.

6.2. Resource Protocol

 DRP will provide configuration of access control and resource-sharing
 policies on DECADE servers.  A content distribution application
 (e.g., a live P2P streaming session) can have permission to manage
 data at several servers, for instance, servers belonging to different
 storage providers.  DRP allows one instance of such an application,
 i.e., an Application Endpoint, to apply access control and resource-
 sharing policies on each of them.
 On a single DECADE server, the following resources SHOULD be managed:
 a) communication resources in terms of bandwidth (upload/download)
 and also in terms of number of active clients (simultaneous
 connections); and b) storage resources.

Alimi, et al. Informational [Page 19] RFC 7069 DECADE November 2013

6.2.1. Access and Resource Control Token

 The tokens SHOULD be generated by an entity trusted by both the
 DECADE client and the server at the request of a DECADE client.  For
 example, this entity could be the client, a server trusted by the
 client, or another server managed by a storage 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 resource cost on
 the server when used.  Likewise, it is important for a client to
 trust the entity generating the tokens since the tokens grant access
 to the data stored at the server.
 The token does not normally include information about the identity of
 the authorized client (i.e., it is typically an anonymous token).
 However, it is not prohibited to have a binding of the token to an
 identity if desired (e.g., binding of the token to the IP address of
 the authorized party).
 Upon generating a token, a DECADE client can distribute it to another
 client.  Token confidentiality SHOULD be provided by whatever
 protocol it is carried in (i.e., Application Protocol, DRP, or SDT).
 The receiving client can then connect to the server specified in the
 token and perform any operation permitted by the token.  The token
 SHOULD be sent along with the operation.  The server SHOULD validate
 the token to identify the client that issued it and whether the
 requested operation is permitted by the contents of the token.  If
 the token is successfully validated, the server SHOULD apply the
 resource control policies indicated in the token while performing the
 operation.
 Tokens SHOULD include a unique identifier to allow a server to detect
 when a token is used multiple times and reject the additional usage
 attempts.  Since usage of a token incurs resource costs to a server
 (e.g., bandwidth and storage) and an uploading DECADE client may have
 a limited budget, the uploading DECADE client should be able to
 indicate if a token may be used multiple times.
 It SHOULD be possible to revoke tokens after they are generated.
 This could be accomplished by supplying the server the unique
 identifiers of the tokens that are to be revoked.

6.2.2. Status Information

 DRP SHOULD provide a status request service that clients can use to
 request status information of a server.  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

Alimi, et al. Informational [Page 20] RFC 7069 DECADE November 2013

 described in Section 4.5.  The following status information elements
 SHOULD be obtained: a) list of associated data objects (with
 properties); and b) resources used/available.  In addition, the
 following information elements MAY be available: c) list of servers
 to which data objects have been distributed (in a certain time
 frame); and d) list of clients to which data objects have been
 distributed (in a certain time frame).
 For the list of servers/clients to which data objects have been
 distributed to, the server SHOULD be able to decide on time bounds
 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 data objects have been distributed.
 Access information MAY be provided for accounting purposes, for
 example, when uploading DECADE clients are interested in access
 statistics for resources and/or to perform accounting per user.
 Again, access to such information requires client authorization and
 SHOULD be based on the delegation concept as described in
 Section 4.5.  The following type of access information elements MAY
 be requested: a) what data objects have been accessed by whom and how
 many times; and b) access tokens that a server has seen for a given
 data object.
 The server SHOULD decide on time bounds for which this information is
 stored and specify the corresponding time frame in the response to
 such requests.

6.2.3. Data Object Attributes

 Data objects that are stored on a DECADE server SHOULD have
 associated attributes (in addition to the object identifier) 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
 such attributes.  This authorization is based on the delegation as
 per Section 4.5.  DECADE does not limit the set of permissible
 attributes, but rather specifies a set of baseline attributes that
 SHOULD be supported:

Alimi, et al. Informational [Page 21] RFC 7069 DECADE November 2013

 Expiration Time:  time at which the data object can be deleted
 Data Object size:  in bytes
 Media type:  labeling of type as per [RFC6838]
 Access statistics:  how often the data object has been accessed (and
    what tokens have been used)
 The data object attributes defined here are distinct from application
 metadata.  Application metadata is custom information that an
 application might wish to associate with a data 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).  If an
 application wishes to store such metadata persistently, it can be
 stored within data objects themselves.

6.3. Data Transfer

 A DECADE server will provide a data access interface, and SDT will be
 used to write data objects to a server and to read (download) data
 objects from a server.  Semantically, SDT is a client-server
 protocol; that is, the server always responds to client requests.
 To write a data object, a client first generates the object's name
 (see Section 6.1), and then uploads the object to a server and
 supplies the generated name.  The name can be used to access
 (download) the object later; for example, the client can pass the
 name as a reference to other clients that can then refer to the
 object.  Data 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 verify the integrity and
 other security properties of uploaded objects.
 A client can request named data objects from a server.  In a
 corresponding request message, a client specifies the object name and
 a suitable access and resource control token.  The server checks the
 validity of the received token and its associated properties related
 to resource usage.  If the named data object exists on the server and
 the token can be validated, the server delivers the requested object
 in a response message.  If the data object cannot be delivered, the
 server provides a corresponding status/reason information in a
 response message.  Specifics regarding error handling, including
 additional error conditions (e.g., overload), precedence for returned
 errors and its relation with server policy, are deferred to eventual
 protocol specification.

Alimi, et al. Informational [Page 22] RFC 7069 DECADE November 2013

6.4. Server-Server Protocols

 An important feature of a DECADE system is the capability for one
 server to directly download data objects from another server.  This
 capability allows applications to directly replicate data objects
 between servers without requiring end-hosts to use uplink capacity to
 upload data objects to a different server.
 DRP and SDT SHOULD support operations directly between servers.
 Servers are not assumed to trust each other nor are they configured
 to do so.  All data operations are performed on behalf of clients via
 explicit instruction.  However, the objects being processed do not
 necessarily have to originate or terminate at the client (i.e., the
 data object might be limited to being exchanged between servers even
 if the instruction is triggered by the client).  Clients thus will be
 able to indicate to a server which remote server(s) to access, what
 operation is to be performed, or in which server the object is to be
 stored, and the credentials indicating access and resource control to
 perform the operation at the remote server.
 Server-server support is focused on reading and writing data objects
 between servers.  The data object referred to at the remote server is
 the same as the original data object requested by the client.  Object
 attributes might also be specified in the request to the remote
 server.  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 performed as if the original requester had its own client co-
 located with the server.  When a client sends a request to a server
 with these additional parameters, it is giving the server permission
 to act (proxy) on its behalf.  Thus, it would be prudent for the
 supplied token to have narrow privileges (e.g., limited to only the
 necessary data objects) or validity time (e.g., a small expiration
 time).
 In the case of a retrieval operation, the server is to retrieve the
 data object from the remote server using the specified credentials,
 and then optionally return the object to a client.  In the case of a
 storage operation, the server is to store the object to the remote
 server using the specified credentials.  The object might optionally
 be uploaded from the client or might already exist at the server.

6.5. Potential DRP/SDT Candidates

 Having covered the key DRP/SDT functionalities above, it is useful to
 consider some potential DRP/SDT candidates as guidance for future
 DECADE protocol implementations.  To recap, the DRP is a protocol for
 communication of access control and resource-scheduling policies from
 a DECADE client to a DECADE server, or between DECADE servers.  The

Alimi, et al. Informational [Page 23] RFC 7069 DECADE November 2013

 SDT is a protocol used to transfer data objects between a DECADE
 client and DECADE server, or between DECADE servers.  An evaluation
 of existing protocols for their suitability for DRP and SDT is given
 in Appendix A.  Also, [INTEGRATION-EX] provides some experimental
 examples of how to integrate DECADE-like in-network storage
 infrastructure into P2P applications.

7. How In-Network Storage Components Map to DECADE

 This section evaluates how the basic components of an in-network
 storage system (see Section 3 of [RFC6392]) map into a DECADE system.
 With respect to the data access interface, DECADE clients can read
 and write objects of arbitrary size through the client's Data
 Controller, making use of standard data transfer (SDT).  With respect
 to data management operations, clients can move or delete previously
 stored objects via the client's Data Controller, making use of SDT.
 Clients can enumerate or search contents of servers to find objects
 matching desired criteria through services provided by the content
 distribution application (e.g., buffer-map exchanges, a DHT, or peer
 exchange).  In doing so, Application Endpoints might consult their
 local Data Index in the client's Data Controller (Data Search
 Capability).
 With respect to access control authorization, all methods of access
 control are supported: public-unrestricted, public-restricted, and
 private.  Access control policies are generated by a content
 distribution application and provided to the client's Resource
 Controller.  The server is responsible for implementing the access
 control checks.  Clients can manage the resources (e.g., bandwidth)
 on the DECADE server that can be used by other Application Endpoints
 (Resource Control Interface).  Resource-sharing policies are
 generated by a content distribution application and provided to the
 client's Resource Controller.  The server is responsible for
 implementing the resource-sharing policies.
 Although the particular protocol used for discovery is outside the
 scope of this document, different options and considerations have
 been discussed in Section 5.6.  Finally, with respect to the storage
 mode, DECADE servers provide an object-based storage mode.  Immutable
 data objects might be stored at a server.  Applications might
 consider existing blocks as data objects, or they might adjust block
 sizes before storing in a server.

Alimi, et al. Informational [Page 24] RFC 7069 DECADE November 2013

8. Security Considerations

 In general, the security considerations mentioned in [RFC6646] apply
 to this document as well.  A DECADE system provides a distributed
 storage service for content distribution and similar applications.
 The system consists of servers and clients that use these servers to
 upload data objects, to request distribution of data objects, and to
 download data objects.  Such a system is employed in an overall
 application context (for example, in a P2P application), and it is
 expected that DECADE clients take part in application-specific
 communication sessions.  The security considerations here focus on
 threats related to the DECADE system and its communication services,
 i.e., the DRP/SDT protocols that have been described in an abstract
 fashion in this document.

8.1. Threat: System Denial-of-Service Attacks

 A DECADE network might be used to distribute data objects from one
 client to a set of servers using the server-server communication
 feature that a client can request when uploading an object.  Multiple
 clients uploading many objects at different servers at the same time
 and requesting server-server distribution for them could thus mount
 massive distributed denial-of-service (DDOS) attacks, overloading a
 network of servers.  This threat is addressed by the server's access
 control and resource control framework.  Servers can require
 Application Endpoints to be authorized to store and to download
 objects, and Application Endpoints can delegate authorization to
 other Application Endpoints using the token mechanism.  Of course the
 effective security of this approach depends on the strength of the
 token mechanism.  See below for a discussion of this and related
 communication security threats.
 Denial-of-service attacks against a single server (directing many
 requests to that server) might still lead to considerable load for
 processing requests and invalidating tokens.  SDT therefore MUST
 provide a redirection mechanism to allow requests to other servers.
 Analogous to how an HTTP reverse proxy can redirect and load balance
 across multiple HTTP origin servers [RFC2616].

8.2. Threat: Authorization Mechanisms Compromised

 A DECADE system does not require Application Endpoints to
 authenticate in order to access a server for downloading objects,
 since authorization is not based on Endpoint or user identities but
 on a delegation-based authorization mechanism.  Hence, most protocol
 security threats are related to the authorization scheme.  The
 security of the token mechanism depends on the strength of the token
 mechanism and on the secrecy of the tokens.  A token can represent

Alimi, et al. Informational [Page 25] RFC 7069 DECADE November 2013

 authorization to store a certain amount of data, to download certain
 objects, to download a certain amount of data per time, etc.  If it
 is possible for an attacker to guess, construct, or simply obtain
 tokens, the integrity of the data maintained by the servers is
 compromised.
 This is a general security threat that applies to authorization
 delegation schemes.  Specifications of existing delegation schemes
 such as [RFC6749] discuss these general threats in detail.  We can
 say that the DRP has to specify appropriate algorithms for token
 generation.  Moreover, authorization tokens should have a limited
 validity period that should be specified by the application.  Token
 confidentiality should be provided by application protocols that
 carry tokens, and the SDT and DRP should provide secure
 (confidential) communication modes.

8.3. Threat: Spoofing of Data Objects

 In a DECADE system, an Application Endpoint is referring other
 Application Endpoints to servers to download a specified data object.
 An attacker could "inject" a faked version of the object into this
 process, so that the downloading Endpoint effectively receives a
 different object (compared to what the uploading Endpoint provided).
 As a result, the downloading Endpoint believes that is has received
 an object that corresponds to the name it was provided earlier,
 whereas in fact it is a faked object.  Corresponding attacks could be
 mounted against the application protocol (that is used for referring
 other Endpoints to servers), servers themselves (and their storage
 subsystems), and the SDT by which the object is uploaded,
 distributed, and downloaded.
 A DECADE systems fundamental mechanism against object spoofing is
 name-object binding validation, i.e., the ability of a receiver to
 check whether the name it was provided and that it used to request an
 object actually corresponds to the bits it received.  As described
 above, this allows for different forms of name-object binding, for
 example, using hashes of data objects, with different hash functions
 (different algorithms, different digest lengths).  For those
 application scenarios where hashes of data objects are not applicable
 (for example, live streaming), other forms of name-object binding can
 be used.  This flexibility also addresses cryptographic algorithm
 evolution: hash functions might get deprecated, better alternatives
 might be invented, etc., so that applications can choose appropriate
 mechanisms that meet their security requirements.

Alimi, et al. Informational [Page 26] RFC 7069 DECADE November 2013

 DECADE servers MAY perform name-object binding validation on stored
 objects, but Application Endpoints MUST NOT rely on that.  In other
 words, Application Endpoints SHOULD perform name-object binding
 validation on received objects.

9. Acknowledgments

 We thank the following people for their contributions to and/or
 detailed reviews of this document or earlier drafts of this document:
 Carlos Bernardos, Carsten Bormann, David Bryan, Dave Crocker, Yingjie
 Gu, David Harrington, Hongqiang (Harry) Liu, David McDysan, Borje
 Ohlman, Martin Stiemerling, Richard Woundy, and Ning Zong.

10. References

10.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2. Informative References

 [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
            Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
            Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 [RFC5661]  Shepler, S., Eisler, M., and D. Noveck, "Network File
            System (NFS) Version 4 Minor Version 1 Protocol", RFC
            5661, January 2010.
 [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
            Message Syntax", RFC 5754, January 2010.
 [RFC6392]  Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
            Network Storage Systems", RFC 6392, October 2011.
 [RFC6646]  Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
            Application Data Enroute (DECADE) Problem Statement", RFC
            6646, July 2012.
 [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
            6749, October 2012.
 [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
            Specifications and Registration Procedures", BCP 13, RFC
            6838, January 2013.

Alimi, et al. Informational [Page 27] RFC 7069 DECADE November 2013

 [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
            Keranen, A., and P. Hallam-Baker, "Naming Things with
            Hashes", RFC 6920, April 2013.
 [INTEGRATION-EX]
            Zong, N., Ed., Chen, X., Huang, Z., Chen, L., and H. Liu,
            "Integration Examples of DECADE System", Work in Progress,
            August 2013.
 [GoogleFileSystem]
            Ghemawat, S., Gobioff, H., and S. Leung, "The Google File
            System", SOSP '03, Proceedings of the 19th ACM Symposium
            on Operating Systems Principles, October 2003.
 [GoogleStorageDevGuide]
            Google, "Google Cloud Storage - Developer's Guide",
            <https://developers.google.com/storage/docs/
            concepts-techniques>.
 [OpenFlow]
            Open Networking Foundation, "Software-Defined Networking:
            The New Norm for Networks", April 2013,
            <https://www.opennetworking.org/images/stories/downloads/
            sdn-resources/white-papers/wp-sdn-newnorm.pdf>.
 [CDMI]     Storage Networking Industry Association (SNIA), "Cloud
            Data Management Interface (CDMI (TM)), Version 1.0.2",
            June 2012,
            <http://snia.org/sites/default/files/CDMI%20v1.0.2.pdf>.

Alimi, et al. Informational [Page 28] RFC 7069 DECADE November 2013

Appendix A. Evaluation of Candidate Protocols for DECADE DRP/SDT

 In this section we evaluate how well the abstract protocol
 interactions specified in this document for DECADE DRP and SDT can be
 fulfilled by the existing protocols of HTTP, CDMI, and OAuth.

A.1. HTTP

 HTTP [RFC2616] is a key protocol for the Internet in general and
 especially for the World Wide Web.  HTTP is a request-response
 protocol.  A typical transaction involves a client (e.g., web
 browser) requesting content (resources) from a web server.  Another
 example is when a client stores or deletes content from a server.

A.1.1. HTTP Support for DRP Primitives

 DRP provides configuration of access control and resource-sharing
 policies on DECADE servers.

A.1.1.1. Access Control Primitives

 Access control requires mechanisms for defining the access policies
 for the server and then checking the authorization of a user before
 it stores or retrieves content.  HTTP supports a rudimentary access
 control via "HTTP Secure" (HTTPS).  HTTPS is a combination of HTTP
 with SSL/TLS.  The main use of HTTPS is to authenticate the server
 and encrypt all traffic between the client and the server.  There is
 also a mode to support client authentication, though this is less
 frequently used.

A.1.1.2. Resource Control Primitives for Communication

 Communication resources include bandwidth (upload/download) and the
 number of simultaneously connected clients (connections).  HTTP
 supports bandwidth control indirectly through "persistent" HTTP
 connections.  Persistent HTTP connections allows a client to keep
 open the underlying TCP connection to the server to allow streaming
 and pipelining (multiple simultaneous requests for a given client).
 HTTP does not have direct support for controlling the communication
 resources for a given client.  However, servers typically perform
 this function via implementation algorithms.

Alimi, et al. Informational [Page 29] RFC 7069 DECADE November 2013

A.1.1.3. Resource Control Primitives for Storage

 Storage resources include the amount of memory and lifetime of
 storage.  HTTP does not allow direct control of storage at the server
 endpoint.  However, HTTP supports caching at intermediate points such
 as a web proxy.  For this purpose, HTTP defines cache control
 mechanisms that define how long and in what situations the
 intermediate point may store and use the content.

A.1.2. HTTP Support for SDT Primitives

 SDT is used to write objects and read (download) objects from a
 DECADE server.  The object can be either a self-contained object such
 as a multimedia file or a chunk from a P2P system.

A.1.2.1. Writing Primitives

 Writing involves uploading objects to the server.  HTTP supports two
 methods of writing called PUT and POST.  In HTTP, the object is
 called a resource and is identified by a URI.  PUT uploads a resource
 to a specific location on the server.  POST, on the other hand,
 submits the object to the server, and the server decides whether to
 update an existing resource or to create a new resource.
 For DECADE, the choice of whether to use PUT or POST will be
 influenced by which entity is responsible for the naming.  If the
 client performs the naming, then PUT is appropriate.  If the server
 performs the naming, then POST should be used (to allow the server to
 define the URI).

A.1.2.2. Downloading Primitives

 Downloading involves fetching of an object from the server.  HTTP
 supports downloading through the GET and HEAD methods.  GET fetches a
 specific resource as identified by the URL.  HEAD is similar but only
 fetches the metadata ("header") associated with the resource, not the
 resource itself.

A.1.3. Primitives for Removing Duplicate Traffic

 To challenge a remote entity for an object, the DECADE server should
 provide a seed number, which is generated by the server randomly, and
 ask the remote entity to return a hash calculated from the seed
 number and the content of the object.  The server may also specify
 the hash function that the remote entity should use.  HTTP supports
 the challenge message through the GET methods.  The message type

Alimi, et al. Informational [Page 30] RFC 7069 DECADE November 2013

 ("challenge"), the seed number, and the hash function name are put in
 a URL.  In the reply, the hash is sent in an Entity Tag (ETag)
 header.

A.1.4. Other Operations

 HTTP supports deleting of content on the server through the DELETE
 method.

A.1.5. Conclusions

 HTTP can provide a rudimentary DRP and SDT for some aspects of
 DECADE, but it will not be able to satisfy all the DECADE
 requirements.  For example, HTTP does not provide a complete access
 control mechanism nor does it support storage resource controls at
 the endpoint server.
 It is possible, however, to envision combining HTTP with a custom
 suite of other protocols to fulfill most of the DECADE requirements
 for DRP and SDT.  For example, Google Storage for Developers is built
 using HTTP (with extensive proprietary extensions such as custom HTTP
 headers).  Google Storage also uses OAuth [RFC6749] (for access
 control) in combination with HTTP [GoogleStorageDevGuide].  An
 example of using OAuth for DRP is given in Appendix A.3.

A.2. CDMI

 The Cloud Data Management Interface (CDMI) specification defines a
 functional interface through which applications can store and manage
 data objects in a cloud storage environment.  The CDMI interface for
 reading/writing data is based on standard HTTP requests, with CDMI-
 specific encodings using JavaScript Object Notation (JSON).  CDMI is
 specified by the Storage Networking Industry Association (SNIA)
 [CDMI].

A.2.1. CDMI Support for DRP Primitives

 DRP provides configuration of access control and resource-sharing
 policies on DECADE servers.

A.2.1.1. Access Control Primitives

 Access control includes mechanisms for defining the access policies
 for the server and then checking the authorization of a user before
 allowing content storage or retrieval.  CDMI defines an Access
 Control List (ACL) per data object and thus supports access control
 (read and/or write) at the granularity of data objects.  An ACL

Alimi, et al. Informational [Page 31] RFC 7069 DECADE November 2013

 contains a set of Access Control Entries (ACEs), where each ACE
 specifies a principal (i.e., user or group of users) and a set of
 privileges that are granted to that principal.
 CDMI requires that an HTTP authentication mechanism be available for
 the server to validate the identity of a principal (client).
 Specifically, CDMI requires that either HTTP Basic Authentication or
 HTTP Digest Authentication be supported.  CDMI recommends that HTTP
 over TLS (HTTPS) is supported to encrypt the data sent over the
 network.

A.2.1.2. Resource Control Primitives for Communication

 Communication resources include bandwidth (upload/download) and the
 number of simultaneously connected clients (connections).  CDMI
 supports two key data attributes that provide control over the
 communication resources to a client: "cdmi_max_throughput" and
 "cdmi_max_latency".  These attributes are defined in the metadata for
 data objects and indicate the desired bandwidth or delay for
 transmission of the data object from the cloud server to the client.

A.2.1.3. Resource Control Primitives for Storage

 Storage resources include amount of quantity and lifetime of storage.
 CDMI defines metadata for individual data objects and general storage
 system configuration that can be used for storage resource control.
 In particular, CDMI defines the following metadata fields:
  1. cdmi_data_redundancy: desired number of copies to be maintained
  1. cdmi_geographic_placement: region where object is permitted to be

stored

  1. cdmi_retention_period: time interval object is to be retained
  1. cdmi_retention_autodelete: whether object should be automatically

deleted after retention period

A.2.2. CDMI Support for SDT Primitives

 SDT is used to write objects and read (download) objects from a
 DECADE server.  The object can be either a self-contained object such
 as a multimedia file or a chunk from a P2P system.

Alimi, et al. Informational [Page 32] RFC 7069 DECADE November 2013

A.2.2.1. Writing Primitives

 Writing involves uploading objects to the server.  CDMI supports
 standard HTTP methods for PUT and POST as described in
 Appendix A.1.2.1.

A.2.2.2. Downloading Primitives

 Downloading involves fetching of an object from the server.  CDMI
 supports the standard HTTP GET method as described in
 Appendix A.1.2.2.

A.2.3. Other Operations

 CDMI supports DELETE as described in Appendix A.1.4.  CDMI also
 supports COPY and MOVE operations.
 CDMI supports the concept of containers of data objects to support
 joint operations on related objects.  For example, GET may be done on
 a single data object or an entire container.
 CDMI supports a global naming scheme.  Every object stored within a
 CDMI system will have a globally unique object string identifier
 (ObjectID) assigned at creation time.

A.2.4. Conclusions

 CDMI has a rich array of features that can provide a good base for
 DRP and SDT for DECADE.  An initial analysis finds that the following
 CDMI features may be useful for DECADE:
  1. access control
  1. storage resource control
  1. communication resource control
  1. COPY/MOVE operations
  1. data containers
  1. naming scheme

Alimi, et al. Informational [Page 33] RFC 7069 DECADE November 2013

A.3. OAuth

 As mentioned in Appendix A.1, OAuth [RFC6749] may be used as part of
 the access and resource control of a DECADE system.  In this section,
 we provide an example of how to configure OAuth requests and
 responses for DRP.
 An OAuth request to access DECADE data objects should include the
 following fields:
    response_type: Value should be set to "token".
    client_id: The client_id indicates either the application that is
    using the DECADE service or the end user who is using the DECADE
    service from a DECADE storage service provider.  DECADE storage
    service providers should provide the ID distribution and
    management function.
    scope: Data object names that are requested.
 An OAuth response should include the following information:
    token_type: "Bearer"
    expires_in: The lifetime in seconds of the access token.
    access_token: A token denotes the following information.
    service_uri: The server address or URI which is providing the
    service;
    permitted_operations (e.g., read, write) and objects (e.g., names
    of data objects that might be read or written);
    priority: Value should be set to be either "Urgent", "High",
    "Normal" or "Low".
    bandwidth: Given to requested operation, a weight value used in a
    weighted bandwidth sharing scheme, or an integer in number of bits
    per second;
    amount: Data size in number of bytes that might be read or
    written.
    token_signature: The signature of the access token.

Alimi, et al. Informational [Page 34] RFC 7069 DECADE November 2013

Authors' Addresses

 Richard Alimi
 Google
 EMail: ralimi@google.com
 Akbar Rahman
 InterDigital Communications, LLC
 EMail: akbar.rahman@interdigital.com
 Dirk Kutscher
 NEC
 EMail: dirk.kutscher@neclab.eu
 Y. Richard Yang
 Yale University
 EMail: yry@cs.yale.edu
 Haibin Song
 Huawei Technologies
 EMail: haibin.song@huawei.com
 Kostas Pentikousis
 EICT
 EMail: k.pentikousis@eict.de

Alimi, et al. Informational [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7069.txt · Last modified: 2013/11/27 19:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki