[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 RFC 7069

APPSAWG                                                         R. Alimi
Internet-Draft                                                    Google
Intended status: Informational                                 A. Rahman
Expires: March 07, 2014                 InterDigital Communications, LLC
                                                             D. Kutscher
                                                                     NEC
                                                                 Y. Yang
                                                         Yale University
                                                                 H. Song
                                                     Huawei Technologies
                                                          K. Pentikousis
                                                                    EICT
                                                      September 03, 2013


              DECoupled Application Data Enroute (DECADE)
                         draft-alimi-decade-04

Abstract

   Content distribution applications, such as those 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 in a
   counter-productive manner.  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 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.

Requirements Language

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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.







Alimi, et al.            Expires March 07, 2014                 [Page 1]

Internet-Draft                   DECADE                   September 2013


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 07, 2014.

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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Architectural Principles  . . . . . . . . . . . . . . . . . .   7
     4.1.  Data and Control Plane Decoupling . . . . . . . . . . . .   7
     4.2.  Immutable Data Objects  . . . . . . . . . . . . . . . . .   8
     4.3.  Data Object Identifiers . . . . . . . . . . . . . . . . .   9
     4.4.  Explicit Control  . . . . . . . . . . . . . . . . . . . .  10
     4.5.  Resource and Data Access Control through Delegation . . .  10
   5.  System Components . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Application End-Point . . . . . . . . . . . . . . . . . .  11
     5.2.  DECADE Client . . . . . . . . . . . . . . . . . . . . . .  12
     5.3.  DECADE Server . . . . . . . . . . . . . . . . . . . . . .  13
     5.4.  Data Sequencing and Naming  . . . . . . . . . . . . . . .  14
     5.5.  Token-based Authorization and Resource Control  . . . . .  15
     5.6.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .  16
   6.  DECADE Protocol Considerations  . . . . . . . . . . . . . . .  17
     6.1.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.2.  Resource Protocol . . . . . . . . . . . . . . . . . . . .  17



Alimi, et al.            Expires March 07, 2014                 [Page 2]

Internet-Draft                   DECADE                   September 2013


     6.3.  Data Transfer . . . . . . . . . . . . . . . . . . . . . .  20
     6.4.  Server-to-Server Protocols  . . . . . . . . . . . . . . .  21
     6.5.  Potential DRP/SDT Candidates  . . . . . . . . . . . . . .  22
   7.  In-Network Storage Components Mapping to DECADE . . . . . . .  22
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     8.1.  Threat: System Denial of Service Attacks  . . . . . . . .  23
     8.2.  Threat: Authorization Mechanisms Compromised  . . . . . .  23
     8.3.  Threat: Data Object Spoofing  . . . . . . . . . . . . . .  24
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  25
   11. Informative References  . . . . . . . . . . . . . . . . . . .  25
   Appendix A.  Evaluation of Candidate Protocols for DECADE DRP/SDT  26
     A.1.  HTTP  . . . . . . . . . . . . . . . . . . . . . . . . . .  26
     A.2.  CDMI  . . . . . . . . . . . . . . . . . . . . . . . . . .  29
     A.3.  OAUTH . . . . . . . . . . . . . . . . . . . . . . . . . .  31
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Terminology

   This document uses the following terminology:

   Application End-Point
      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
      End-Point.  A Content Distribution Application is an application
      (e.g., P2P) designed for dissemination of a 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



Alimi, et al.            Expires March 07, 2014                 [Page 3]

Internet-Draft                   DECADE                   September 2013


      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 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 which is composed of DECADE clients
      and DECADE servers.  The DECADE servers may be deployed by one or
      more DECADE Storage Providers.

   In-network Storage
      A service inside a network that provides storage to applications.
      In-network storage may reduce upload/tansit/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 Protocol (SDT)
      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.

2.  Introduction

   Content distribution applications, such as peer-to-peer (P2P)
   applications, are widely used on the Internet to distribute data
   objects, and comprise 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



Alimi, et al.            Expires March 07, 2014                 [Page 4]

Internet-Draft                   DECADE                   September 2013


   more complete discussion of the problem domain and general
   discussions of the capabilities envisioned for a DECADE system.

   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].

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 a
   selected server(s), 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 End-Point, 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 standard data transfer (SDT) protocol to transfer data
   objects to and from a server, as we will explain later.

                        Native Application
                         Protocol(s)
        .-------------.   (e.g., P2P)        .-------------.
        | Application | <------------------> | Application |
        |  End-Point  |                      |  End-Point  |
        |             |                      |             |
        | .--------.  |                      | .--------.  |
        | | DECADE |  |                      | | DECADE |  |
        | | Client |  |                      | | Client |  |
        | `--------'  |                      | `--------'  |
        `-------------'                      `-------------'
            |     ^                              |     ^



Alimi, et al.            Expires March 07, 2014                 [Page 5]

Internet-Draft                   DECADE                   September 2013


    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 End-Point B requests a
   data object from Application End-Point A using their native
   application protocols (e.g., P2P protocol) as in Figure 2.  In this
   case, End-Point A will act as the sender and End-Point B as the
   receiver for said data object.  S(A) is the DECADE storage server
   which is access controlled.  This means, first, that End-Point A has
   a right to store the data object in S(A).  Secondly, End-Point B
   needs to obtain authorization before being able to retrieve the data
   object from S(A).

   The four steps involved in a DECADE session is illustrated in Figure
   2.  The sequence starts with the initial contact between End-Point B
   and End-Point A, where End-Point B requests a data object using their
   native application protocol (e.g., P2P).  Next, End-Point A uses DRP
   to obtain a token corresponding to the data object that was requested
   by End-Point B. There may be several ways for End-Point A to obtain
   such a token, e.g., compute it locally or request one from its DECADE
   storage server, S(A).  Once obtained, End-Point A then provides the
   token to End-Point B (again, using their native application
   protocol).  Finally, End-Point 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 pre-cursor step
   (not shown) to Figure 2 where End-Point A first discovers and then
   stores the data object(s) of interest in S(A).

                               .----------.
      2. Obtain      --------> |   S(A)   | <------



Alimi, et al.            Expires March 07, 2014                 [Page 6]

Internet-Draft                   DECADE                   September 2013


         Token      /          `----------'        \   4. Request and
         (DRP)     /                                \    Download Data
         Locally  /                                  \    Object
         or From /                                    \   (DRP + SDT)
         S(A)   v          1. App Request              v
       .-------------. <--------------------------- .-------------.
       | Application |                              | Application |
       | End-Point A |                              | End-Point 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
   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



Alimi, et al.            Expires March 07, 2014                 [Page 7]

Internet-Draft                   DECADE                   September 2013


   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 meta-data management and several
   Chunk servers to handle data plane functions (i.e., read and write of
   chunks of data).  Finally, NFSv4.1's 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 implementation of de-
   duplication.

   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
   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.





Alimi, et al.            Expires March 07, 2014                 [Page 8]

Internet-Draft                   DECADE                   September 2013


   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 meta-data 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
   will use specific representations.

   In particular, for some applications it is important that clients and
   servers are 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).  Data object identifiers can support name-object binding
   validation by providing message digests or so-called self-certifying
   naming information -- if a specific application has this requirement.

   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.





Alimi, et al.            Expires March 07, 2014                 [Page 9]

Internet-Draft                   DECADE                   September 2013


   Some content distribution applications will derive the name of a data
   object from the hash over the data object, which 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 End-Points.  Thus, it needs to provide both
   resource and data access control, as discussed in the following
   subsections.

4.5.1.  Resource Allocation














Alimi, et al.            Expires March 07, 2014                [Page 10]

Internet-Draft                   DECADE                   September 2013


   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 concurrently-running applications to each 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 Mb/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 which 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.

5.1.  Application End-Point

   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 End-Point.



Alimi, et al.            Expires March 07, 2014                [Page 11]

Internet-Draft                   DECADE                   September 2013


                               Native Application Protocol(s)
                            (with other Application End-Points)
                                    .--------------------->
                                    |
                                    V
   .----------------------------------------------------------------.
   | Application End-Point                                          |
   | .-------------------.          .-------------------.           |
   | | 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 then re-assembly
   of data objects.  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 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
   can be implemented standalone, embedded into the application, or



Alimi, et al.            Expires March 07, 2014                [Page 12]

Internet-Draft                   DECADE                   September 2013


   integrated in other software entities within network devices (i.e.
   hosts).  In general, applications may have different Resource Sharing
   Policies and Data Access Policies to control their resource and data
   in 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 End-Points (i.e., a
   data search mechanism such as a Distributed Hash Table).

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 but can also be implemented in a distributed
   manner on a cluster of machines.

       | 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




Alimi, et al.            Expires March 07, 2014                [Page 13]

Internet-Draft                   DECADE                   September 2013


   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
   illustrative examples of use.

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



Alimi, et al.            Expires March 07, 2014                [Page 14]

Internet-Draft                   DECADE                   September 2013


   either the original uploading DECADE client, another End-Point 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.  Similarly with 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.

     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 it's 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.





Alimi, et al.            Expires March 07, 2014                [Page 15]

Internet-Draft                   DECADE                   September 2013


   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 it explicitly controls when tokens are
   generated and 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 which 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
   allow them to read or write data objects from the storage of its own
   storage provider.  In addition to clients applying access control
   policies to data objects, the server may be 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 End-Point 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:

   -  a result of off-line administrative procedures;




Alimi, et al.            Expires March 07, 2014                [Page 16]

Internet-Draft                   DECADE                   September 2013


   -  access network dependent (e.g., all the subscribers to a
      particular ISP may be allowed by the ISP);

   -  due to a prior subscription;

   -  etc.

   The particular protocol used for discovery is out of scope of this
   document, but any specification should re-use well-known protocols
   wherever possible.

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 between a DECADE client-server are very similar to the
   DRP/SDT functionality between server-server.  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



Alimi, et al.            Expires March 07, 2014                [Page 17]

Internet-Draft                   DECADE                   September 2013


   storage providers.  DRP allows one instance of such an application,
   i.e., an Application End-Point, 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.

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 token to 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 a 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.






Alimi, et al.            Expires March 07, 2014                [Page 18]

Internet-Draft                   DECADE                   September 2013


   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 which 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
   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 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 for how many
   times; and b) access tokens that a server as 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 and 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



Alimi, et al.            Expires March 07, 2014                [Page 19]

Internet-Draft                   DECADE                   September 2013


   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:

   Expiration Time:  Time at which the data object can be deleted;

   Data Object size:  In bytes;

   Media type  Labelling 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



Alimi, et al.            Expires March 07, 2014                [Page 20]

Internet-Draft                   DECADE                   September 2013


   validity of the received token and its associated resource usage-
   related properties.  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.

6.4.  Server-to-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 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 the object is to be stored,
   and the credentials indicating access and resource control to perform
   the operation at the remote server.

   Server-to-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



Alimi, et al.            Expires March 07, 2014                [Page 21]

Internet-Draft                   DECADE                   September 2013


   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
   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 [I-D.zong-integration-example] provides some
   experimental examples of how to integrate DECADE-like in-network
   storage infrastructure into P2P applications.

7.  In-Network Storage Components Mapping 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 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 End-Points 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 End-Points
   (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



Alimi, et al.            Expires March 07, 2014                [Page 22]

Internet-Draft                   DECADE                   September 2013


   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.

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-to-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-to-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 End-Points to be authorized to store and to
   download objects, and Application End-Points can delegate
   authorization to other Application End-Points 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 re-direct and load balance
   across multiple HTTP origin servers [RFC2616].

8.2.  Threat: Authorization Mechanisms Compromised





Alimi, et al.            Expires March 07, 2014                [Page 23]

Internet-Draft                   DECADE                   September 2013


   A DECADE system does not require Application End-Points to
   authenticate in order to access a server for downloading objects,
   since authorization is not based on End-Point 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
   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: Data Object Spoofing

   In a DECADE system, an Application End-Point is referring other
   Application End-Points to servers to download a specified data
   objects.  An attacker could "inject" a faked version of the object
   into this process, so that the downloading End-Point effectively
   receives a different object (compared to what the uploading End-Point
   provided).  As result, the downloading End-Point 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 End-Points to servers), servers themselves (and their
   storage sub-systems), 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



Alimi, et al.            Expires March 07, 2014                [Page 24]

Internet-Draft                   DECADE                   September 2013


   might be invented etc., so that applications can choose appropriate
   mechanisms meeting their security requirements.

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

9.  IANA Considerations

   This document does not have any IANA considerations.

10.  Acknowledgments

   We thank the following people for their contributions to and/or
   detailed reviews of this or earlier versions 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.

11.  Informative References

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

   [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.






Alimi, et al.            Expires March 07, 2014                [Page 25]

Internet-Draft                   DECADE                   September 2013


   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13, RFC
              6838, January 2013.

   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keranen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", RFC 6920, April 2013.

   [I-D.zong-integration-example]
              Zong, N., Chen, X., Huang, Z., Chen, L., and H. Liu,
              "Integration Examples of DECADE System", draft-zong-
              integration-example-02 (work in progress), August 2013.

   [GoogleFileSystem]
              Ghemawat, S., Gobioff, H., and S. Leung, "The Google File
              System", SOSP 2003, October 2003.

   [GoogleStorageDevGuide]
              Google, ., "Google Storage Developer Guide", July 2013,
              <https://developers.google.com/storage/docs/concepts-
              techniques>.

   [OpenFlow]
              Open Networking Foundation, ., "Sofware-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]     SNIA, ., "Cloud Data Management Interface (CDMI)", July
              2013, <http://www.snia.org/cdmi>.

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





Alimi, et al.            Expires March 07, 2014                [Page 26]

Internet-Draft                   DECADE                   September 2013


   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.  Communication Resource Control Primitives

   Communication resources include bandwidth (upload/download) and
   number of simultaneous 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 pipe-lining (multiple simultaneous requests for a given client).

   HTTP does not define protocol operation to allow limiting the
   communication resources to a client.  However servers typically
   perform this function via implementation algorithms.

A.1.1.3.  Storage Resource Control Primitives

   Storage resources include amount of memory and lifetime of storage.
   HTTP does not allow direct control of storage at the server end
   point.  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



Alimi, et al.            Expires March 07, 2014                [Page 27]

Internet-Draft                   DECADE                   September 2013


   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 but not
   the resource itself.

A.1.3.  Traffic De-duplication Primitives

   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 which the remote entity should use.  HTTP supports
   the challenge message through the GET methods.  The message type
   ("challenge"), the seed number and the hash function name are put in
   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 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 end
   point 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.



Alimi, et al.            Expires March 07, 2014                [Page 28]

Internet-Draft                   DECADE                   September 2013


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
   it stores or retrieves content.  CDMI defines an Access Control List
   (ACL) per data object, and thus supports access control (read and/or
   write) at the data object granularity.  An ACL 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.  Communication Resource Control Primitives

   Communication resources include bandwidth (upload/download) and
   number of simultaneous connected clients (connections).  CDMI
   supports two key data attributes which 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.









Alimi, et al.            Expires March 07, 2014                [Page 29]

Internet-Draft                   DECADE                   September 2013


A.2.1.3.  Storage Resource Control Primitives

   Storage resources include amount of quantity and lifetime of storage.
   CDMI defines metadata for individual data objects and general storage
   system configuration which can be used for storage resource control.
   In particular, CDMI defines the following metadata fields:

   -cdmi_data_redundancy:  desired number of copies to be maintained;

   -cdmi_geographic_placement  region where object is permitted to be
      stored;

   -cdmi_retention_period  time interval object is to be retained;

   -cdmi_retention_autodelete  whether object should be auto 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.

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 on 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.




Alimi, et al.            Expires March 07, 2014                [Page 30]

Internet-Draft                   DECADE                   September 2013


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:

   -  access control

   -  storage resource control

   -  communication resource control

   -  COPY/MOVE operations

   -  data containers

   -  naming scheme

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;



Alimi, et al.            Expires March 07, 2014                [Page 31]

Internet-Draft                   DECADE                   September 2013


      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 a integer in number of bps;

      Amount: Data size in number of bytes that might be read or
      written.

      Token_signature: The signature of the access token.

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







Alimi, et al.            Expires March 07, 2014                [Page 32]

Internet-Draft                   DECADE                   September 2013


   Kostas Pentikousis
   EICT

   Email: k.pentikousis@eict.de















































Alimi, et al.            Expires March 07, 2014                [Page 33]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/