DECADE                                                          R. Alimi
Internet-Draft                                                    Google
Intended status: Informational                                 A. Rahman
Expires: September 13, December 2, 2012               InterDigital Communications, LLC
                                                             D. Kutscher
                                                                     NEC
                                                                 Y. Yang
                                                         Yale University
                                                          March 12,
                                                            May 31, 2012

                          DECADE Architecture
                       draft-ietf-decade-arch-05
                       draft-ietf-decade-arch-06

Abstract

   Content Distribution Applications (e.g., P2P applications) are widely
   used on the Internet and make up a large portion of the traffic in
   many networks.  One technique to improve the network efficiency of
   these applications is to introduce storage capabilities within the
   networks; this is the capability to be provided by a DECADE (DECoupled
   Application Data Enroute) compliant compatible system.  This document presents
   an architecture for DECADE, architecture, discusses the underlying principles, and identifies
   key functionalities required for introducing in-network a DECADE-compatible in-
   network storage for these applications. system.  In addition, some examples are given to
   illustrate these concepts in an
   informative manner. concepts.

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.

   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 September 13, December 2, 2012.

Copyright Notice

   Copyright (c) 2012 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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Functional Entities  .  Terminology  . . . . . . . . . . . . . . . . . . . .  5
     2.1.  DECADE Server . . . . .  5
     2.1.  DECADE-compatible Client . . . . . . . . . . . . . . . . .  6  5
     2.2.  DECADE Client  .  DECADE-compatible Server . . . . . . . . . . . . . . . . .  5
     2.3.  Content Provider . . . .  6
     2.3.  DECADE Storage Provider . . . . . . . . . . . . . . . . .  6
     2.4.  Content Provider Using DECADE Consumer . . . . . . . . . . . . . . . . . . . . .  6
     2.5.  Content Consumer Using DECADE  Storage Provider . . . . . . . . . . . . . . . . . . . . .  6
     2.6.  Content Distribution Application . . . . . . . . . . . . .  7  6
     2.7.  Application End-Point  . . . . . . . . . . . . . . . . . .  6
     2.8.  Data Object  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Protocol Flow  . . . . . . . . . . . . . . . . . . . . . . . .  7  6
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  An Example . . . . . . . . . . . . . . . . . . . . . . . .  9  8
   4.  Architectural Principles . . . . . . . . . . . . . . . . . . .  9
     4.1.  Decoupled Control/Metadata and Data Planes . . . . . . . . 10  9
     4.2.  Immutable Data Objects . . . . . . . . . . . . . . . . . . 10
     4.3.  Data Object Objects With Identifiers  . . . . . . . . . . . . . . . . . 11 10
     4.4.  DECADE  Data Object Naming Scheme  . . . . . . . . . . . . . 12 . . . 11
     4.5.  Explicit Control . . . . . . . . . . . . . . . . . . . . . 13 12
     4.6.  Resource and Data Access Control through User
           Delegation . . . . . . . . . . . . . . . . . . . . . . . . 14 13
   5.  System Components  . . . . . . . . . . . . . . . . . . . . . . 15 14
     5.1.  Content Distribution Application . . . . . . . . . . . . . 15 14
     5.2.  DECADE  Server . . . . . . . . . . . . . . . . . . . . . . 17 . . . . 16
     5.3.  Data Sequencing and Naming . . . . . . . . . . . . . . . . 19 18
     5.4.  Token-based Authentication and Resource Control  . . . . . 22 20
     5.5.  Discovery  . . . . . . . . . . . . . . . . . . . . . . . . 23 21
   6.  DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 24 22
     6.1.  DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 24 22
     6.2.  Standard Data Transfer (SDT) Protocol  . . . . . . . . . . . . . . . 27 25
     6.3.  Server-to-Server Protocols . . . . . . . . . . . . . . . . 29 26
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31 28
     7.1.  Threat: System Denial of Service Attacks . . . . . . . . . 31 28
     7.2.  DECADE  Threat: Protocol Security Threats  . . . . . . . . . . . . . 32 . . . 29
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33 30
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 33 30
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 31
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 34 31
     10.2. Informative References . . . . . . . . . . . . . . . . . . 34 31
   Appendix A.  In-Network Storage Components Mapped to DECADE
                Architecture  . . . . . . . . . . . . . . . . . . . . 35 31
     A.1.  Data Access Interface  . . . . . . . . . . . . . . . . . . 35 32
     A.2.  Data Management Operations . . . . . . . . . . . . . . . . 35 32
     A.3.  Data Search Capability . . . . . . . . . . . . . . . . . . 35 32
     A.4.  Access Control Authorization . . . . . . . . . . . . . . . 36 32
     A.5.  Resource Control Interface . . . . . . . . . . . . . . . . 36 32
     A.6.  Discovery Mechanism  . . . . . . . . . . . . . . . . . . . 36 32
     A.7.  Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 36 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 33

1.  Introduction

   Content Distribution Applications (e.g., P2P applications) Applications, such as Peer-to-Peer (P2P)
   applications, are widely used on the Internet today to distribute data, and
   they contribute a large portion of the traffic in many networks.  The
   DECADE-compatible architecture described in this document enables
   such applications to leverage in-network storage to achieve more
   efficient content distribution.  Specifically, 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 at individual homes, businesses, and devices such as DSLAMs
   (Digital Subscriber Line Access Multiplexers) and CMTSs (Cable Modem
   Termination Systems) in remote locations.  Therefore, it may be
   cheaper to upgrade the core infrastructure, which involves fewer
   components that are shared by many subscribers.  See
   [I-D.ietf-decade-problem-statement] for a more complete discussion of
   the problem domain and general discussions of the capabilities to be
   provided by a DECADE-compatible system.

   This document presents an architecture for providing in-network
   storage that can be integrated into Content Distribution
   Applications.  The primary focus is P2P-based content distribution,
   but the architecture may be useful to other applications with similar
   characteristics and requirements.  See [I-D.ietf-decade-reqs] for a
   definition of the target applications supported by a DECADE-
   compatible system.

   The approach of this document is to define the core functionalities
   and protocol requirements behaviour that are needed to support in-network storage
   in a DECADE-compatible system.  The protocol themselves are not
   selected or designed.  Also, if more complex functionalities are
   needed, they should be layered on top of the DECADE-compatible system designed in an application specific manner. this document.  Some illustrative examples
   are given to help the reader understand certain concepts.  These
   examples are purely informational and are not meant to guide or constrain
   future protocol design or selection.

2.  Functional Entities

   This section defines the functional entities involved in a DECADE
   system.  Functional entities are classified as follows:

   o  Terminology

2.1.  DECADE-compatible Client

   A physical or logical component in the DECADE architecture: DECADE
      Client, DECADE Server, Content Distribution Application and
      Application End Point;

   o  Operator of a physical or logical component in the DECADE
      architecture: DECADE Storage Provider; and

   o  Source or sink of content distributed via DECADE-compatible client uploads and/or retrieves data from DECADE-
   compatible servers.  We simply use the DECADE architecture:
      DECADE Content Provider, and DECADE Content Consumer.

2.1.  DECADE term "client" if there is no
   ambiguity.

2.2.  DECADE-compatible Server

   A DECADE DECADE-compatible server stores DECADE data inside the network, and
   thereafter manages both the stored data and access to that data.  To reinforce
   that these servers are responsible for storage of raw data, this
   document also refers to them as storage servers.

2.2.  DECADE Client  We
   simply use the term "server" if there is no ambiguity.

2.3.  Content Provider

   A DECADE client stores which owns (i.e. uploads and retrieves data manages) storage at DECADE Servers.

2.3.  DECADE a DECADE-
   compatible server.

2.4.  Content Consumer

   A client which has been granted permission to retrieve data from a
   DECADE-compatible server by a Content Provider.

2.5.  Storage Provider

   A DECADE storage provider Storage Provider deploys and/or manages DECADE storage DECADE-compatible server(s)
   within a network.

2.6.  Content Distribution Application

   A storage provider may also own or
   manage the network in which the DECADE servers are deployed, but this Content Distribution Application is not mandatory.

   A DECADE storage provider, possibly in cooperation with one or more
   network providers, determines deployment locations for DECADE servers
   and determines the available resources an application (e.g., P2P)
   designed for each.

2.4.  Content Provider Using DECADE

   A content provider using DECADE accesses DECADE storage servers (by
   way dissemination of a DECADE client) large amounts of data to upload and manage data.  Such a content
   provider can access one or more storage servers.  Such a multiple
   consumers.  Content Distribution Applications typically divide
   content
   provider may be a single process or into smaller blocks for dissemination.

   We consider Content Distribution Applications that include a distributed DECADE-
   compatible client along with other application functionality (e.g.,
   in a
   P2P scenario), and may be either fixed or mobile.

2.5.  Content Consumer Using DECADE

   A content consumer using DECADE accesses DECADE storage servers (by
   way of a DECADE video streaming client).  A content consumer can access one or more
   DECADE storage servers.  A content consumer may be a single process
   or a distributed application (e.g., in a P2P scenario), and may be
   either fixed or mobile.  An instance of a distributed application,
   such as a P2P application, may both provide content to and consume
   content from DECADE storage servers.

2.6.  Content Distribution Application

   A content distribution application (as a target application for
   DECADE as described in [I-D.ietf-decade-reqs]) is a distributed
   application designed for dissemination of a possibly-large data set
   to multiple consumers.  Content Distribution Applications typically
   divide content into smaller blocks for dissemination.

2.6.1.

2.7.  Application End-Point

   An Application End-Point is an instance of a Content Distribution
   Application that makes use of DECADE server(s).
   Application.  A particular Application End-Point may might be a DECADE Content
   Provider, a DECADE Content Consumer, or both.  For example, an Application
   End-Point may might be an instance of a video streaming client, or it may
   might be the source providing the video to a set of clients.

   An Application End-Point need not be actively transferring

2.8.  Data Object

   A data with
   other Application End-Points to interact with object is the DECADE storage
   system.  That is, an End-Point may interact unit of data stored and retrieved from a DECADE-
   compatible server.  The data object is a string of raw bytes.  The
   server maintains metadata associated with each data object, but the DECADE storage
   servers as an offline activity.
   metadata is not included in the data object.

3.  Protocol Flow
3.1.  Overview

   A DECADE-compatible system supports will support two logical protocols, as
   shown in Figure 1.  First, the DECADE Resource Protocol (DRP) is
   responsible for communication of access control and resource
   scheduling policies from between a DECADE Client to client and a DECADE Server, server, as well as between DECADE Servers.
   servers.  A DECADE-compatible system includes will include exactly one DRP for
   interoperability and a common format through which these policies can
   be communicated.

                         Native Application
         .-------------.      Protocol(s)     .-------------.
         | Application | <------------------> | Application |
         |  End-Point  |                      |  End-Point  |
         |             |                      |             |
         | .--------.  |                      | .--------.  |
         | | DECADE |  |                      | | DECADE |  |
         | | Client |  |                      | | Client |  |
         | `--------'  |                      | `--------'  |
         `-------------'                      `-------------'
             |     ^                              |     ^
     DECADE  |     | Standard                     |     |
    Resource |     |   Data                   DRP |     | SDT
    Protocol |     | Transfer                     |     |
     (DRP)   |     |   (SDT)                      |     |
             |     |                              |     |
             |     |                              |     |
             |     |                              |     |
             |     |                              |     |
             |     |                              |     |
             |     |                              |     |
             v     V                              v     V
         .=============.         DRP          .=============.
         |   DECADE    | <------------------> |   DECADE    |
         |   Server    | <------------------> |   Server    |
         `============='         SDT          `============='

                      Figure 1: Generic Protocol Flow

   Second, a Standard Data Transport protocol Transfer (SDT) is protocol will be used to
   transfer data objects to and from a DECADE Server. server.  A DECADE-compatible
   system may support multiple SDT's.  If there are multiple SDT's, a
   negotiation mechanism is will be used to determine a suitable data transfer
   protocol SDT
   between a DECADE Client the client and DECADE Server. server.

   The two protocols (DRP and SDT) may or may not will be seperate either separate or combined
   on the wire.  For example,  If they are combined, DRP messages may can be piggy-backed
   within some extension fields provided by certain data transfer SDT protocols.  In
   such a scenario, DRP is technically a data structure (transported by
   other protocols), but it can still be considered as a logical
   protocol that provides the services of configuring DECADE DECADE-compatible
   resource usage.  If the protocols are physically separate on the
   wire, DRP can take the form of a separate control connection open
   between the a DECADE-compatible client and server.  Hence, this
   document considers SDT and DRP as two separate, logical functional
   components for clarity.  The abstract properties of the SDT and DRP
   are oultined outlined below but the final selection of these protocols is left to future steps.
   outside the scope of this document.

3.2.  An Example

   This section provides an example of steps in a data transfer scenario
   involving an in-network storage system.  We assume that Application
   End-Point B (the receiver) is requesting a data object from
   Application End-Point A (the sender).  Let S(A) denote A's the DECADE-
   compatible storage server. server to which A has access.  There are multiple
   usage scenarios (by choice of the Content Distribution Application).
   For simplicity of introduction, we design this example to use only a
   single DECADE-
   compatible Server; Section 6.3 details a case when both A and B wish
   to employ DECADE-compatible Servers.

   When an Application End-Point wishes to use its DECADE-compatible
   storage server, it provides a token to the other Application End-
   Point.  The token is sent using the Content Distribution
   Application's native protocol. server.

   The steps of the example are illustrated in Figure 2.  First, B
   requests a data object from A using their native protocol. application protocol
   (see Section 5.1.2).  Next, A uses the DECADE-compatible Resource Protocol (DRP) DRP to obtain a token.  There
   are multiple ways for A to obtain the token: compute locally, or
   request from its DECADE-compatible storage server, S(A).  See
   Section 6.1.2 for details.  A then provides the token to B (again,
   using their native application protocol).  Finally, B provides the
   token to S(A) via DRP, and requests and downloads the data object via
   a Standard
   Data Transport (SDT). SDT.

                               .----------.
      2. Obtain      --------> |   S(A)   | <------
         Token      /          `----------'        \   4. Request and
         (DRP)     /                                \    Download Object
         Locally  /                                  \    (DRP + SDT)
         or From /                                    \
         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

   We identify the following key principles. principles that will be followed in any
   DECADE-compatible system:

4.1.  Decoupled Control/Metadata and Data Planes

   A DECADE-compatible system will SHOULD be able to support multiple content distribution
   applications. Content
   Distribution Applications.  A complete content distribution application Content Distribution
   Application implements a set of "control plane" functions including
   content search, indexing and collection, access control, ad
   insertion, replication, request routing, and QoS scheduling.
   Different content distribution
   applications Content Distribution Applications will have unique
   considerations designing the control plane functions:

   o  Metadata Management Scheme: Traditional file systems provide a
      standard metadata abstraction: a recursive structure of
      directories to offer namespace management; each file is an opaque
      byte stream.  In content distribution, applications  Content Distribution Applications may use different
      metadata management schemes.  For example, one application may might
      use a sequence of blocks (e.g., for file sharing), while another
      application may might use a sequence of frames (with different sizes)
      indexed by time.

   o  Resource Scheduling Algorithms: a A major competitive advantage of many
      successful P2P systems is their substantial expertise in achieving
      highly efficient utilization of peer and infrastructural
      resources.  For instance, many streaming P2P systems have their
      specific algorithms in constructing topologies to achieve low-
      latency, high-bandwidth streaming.  They continue to continuously fine-tune
      such algorithms.

   Given the diversity of control plane functions, in-network storage
   should export basic mechanisms and a DECADE-compatible
   system SHOULD allow as much flexibility as possible to the control
   plane to implement specific policies.  This conforms to the end-to-end end-to-
   end systems principle and allows innovation and satisfaction of
   specific business performance goals.

   Decoupling control plane and data plane is not new.  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.  Google File
   System [GoogleFileSystem] applies the principle to file system
   design, by utilizing the Master to handle the meta-data management,
   and the Chunk Servers servers to handle the data plane functions (i.e., read
   and write of chunks of data).  NFSv4.1's pNFS extension [RFC5661]
   also implements this principle.

4.2.  Immutable Data Objects

   A property of bulk contents content to be broadly distributed is that they
   typically are immutable -- once content is generated, it is typically
   not modified.  It is not common that bulk contents content such as video
   frames and images need to be modified after distribution.

   Focusing on immutable data in the data plane can substantially
   simplify the data plane design, since consistency requirements can be
   relaxed.  It also allows effective simplifies reuse of data and de-duplication implementation of redundant content. de-
   duplication.

   Depending on its specific requirements, an application may store
   immutable data objects in DECADE-compatible 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 blocks that require application level assembly.
   Many content distribution applications Content Distribution Applications divide bulk content into
   blocks for two reasons: multiple reasons, including (1) multipath: different
   blocks may might be fetched from different sources in parallel, parallel; and (2)
   faster recovery and verification: individual blocks may might be
   recovered and verified.  Typically, applications use a block size
   larger than a single packet in order to reduce control overhead.

   A DECADE-compatible system is SHOULD be agnostic to the nature of the
   data objects and does not SHOULD NOT specify a fixed size for them, though them.  Though a
   protocol specification based on this architecture may MAY prescribe
   requirements on minimum and maximum sizes by compliant implementatations.
   implementations.  Applications may consider existing blocks as data
   objects, or they may adjust block sizes before storing in the DECADE-compatible DECADE-
   compatible server.

   Immutable content may data objects can still be deleted.  Applications may
   support modification of existing data stored at a DECADE-compatible
   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 may might associate a name with a sequence of
   immutable blocks.  If one of the blocks is modified, the meta-data
   management function changes the mapping of the name to a new sequence
   of immutable blocks.

   Throughout this document, all data objects/blocks are referred assumed to as
   immutable data objects/blocks. be
   immutable.

4.3.  Data Object Identifiers Objects With Identifiers

   An object that are is stored in a DECADE-compatible storage server can SHOULD
   be accessed by content consumers Content Consumers via a data object identifier that has
   been assigned within a certain application context and that is unique
   within that application context. identifier.

   A content consumer Content Consumer may be able to access more than one storage server
   within a single application context.
   server.  A data object that is replicated across different storage
   servers managed by a DECADE-
   compatible storage provider can DECADE-compatible Storage Provider MAY still be
   accessed by a single identifier.

   Since data objects are immutable, it is SHALL be possible to support
   persistent identifiers for data objects.

   Data object identifiers for data objects MUST SHOULD be created by content
   providers Content
   Providers that upload the objects to DECADE servers.

   For some applications it is important that

4.4.  Data Object Naming Scheme

   The DECADE clients and architecture is based on data object identifiers as
   described above, and the assignment/derivation of the data object
   identifier to a data object depends on the data object naming scheme.
   The details of data naming schemes will be provided by future DECADE-
   compatible protocol/naming specifications.  This document describes
   naming schemes on a semantic level and specific SDTs and DRPs SHOULD
   use specific representations.

   In particular, for some applications it is important that clients and
   servers
   are SHOULD be able to validate the name-object binding for a data
   object, 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-content name-
   object binding validation by providing message digests or so-called
   self-certifying naming information -- if a specific application has
   this requirement.

4.4.  DECADE Data Object Naming Scheme

   The DECADE architecture is based on the data object identifier
   properties as described in Section 4.3, but does neither specify a
   specific scheme nor specific name-object binding validation functions
   (for example, hash functions).  Different applications will have
   specific requirements regarding security (for example, cryptographic
   strength of hash functions), performance (for example, larger static
   objects vs streaming) etc.

   The details of such naming schemes will be provided by DECADE
   protocol/naming specifications.  This documents describes the scheme
   on a semantic level will but specific SDTs and DRPs may use specific
   representations.  The

   A DECADE-compatible naming scheme meets follows the following general
   requirements:

   o  Different name-object binding validation mechanisms are MAY be
      supported;

   o  an application (DECADE content provider) can  Content Distribution Applications will decide what mechanism to use (or
      use, or to not provide name-object validation -- for example (e.g., if
      authenticity and integrity can be by ascertained by alternative
      means);

   o  simple (digest hash based) name-object binding validation is
      supported; and

   o  applications are  Applications MAY be able to construct unique names (with high
      probability) without requiring a registry or other forms of
      coordination; and

   o  names are  Names MAY be self-describing so that a receiving entity (DECADE
      content consumer) (Content
      Consumer) knows what hash function (for example) to use for
      validating name-object binding.

   For most content distribution scenarios, it

   Some Content Distribution Applications will be appropriate to derive the name of a data
   object from the hash over the data object's
   content (the raw bytes), object, which is made possible by
   the fact that DECADE-compatible objects are immutable.  But there
   maybe other applications such as live streaming where object/chunk
   names are will not based on hashes but rather on a an enumeration scheme.
   The DECADE naming scheme will also enables enable those applications to construct
   unique names.

   In order to enable the uniqueness, flexibility and self-describing
   properties, the DECADE naming scheme provides SHOULD provide the following name
   elements:

   o  a  A "type" field that indicates the name-object validation function
      type (for example, "sha-256");

   o  cryptographic  Cryptographic data (such as an object hash) that corresponds to
      the type information; and

   The naming scheme MAY additionally provide the following name
   elements:

   o  (optionally) additional information such as application context  Application or publisher information.

   The specific format of the name (e.g., encoding, hash algorithms,
   etc) is out of scope of this document, and is left for protocol
   specification.

   The DECADE DECADE-compatible naming scheme can SHOULD be used in scenarios where
   a client knows the name of a data object before it is completely
   stored at the server.  This allows for particular optimizations, such
   as advertising data object while the data object is being stored,
   removing store-and-forward delays.  For example, a client A may might
   simultaneously begin storing an object to a server, and advertise
   that the object is available to client B. If it is supported by the
   server, client B may might begin downloading the object before A is
   finished storing the object.

   If object names are not based on content hashes, DECADE hashes of the data objects
   themselves, names can also be used in scenarios, scenarios where a client knows
   the name of a data object before it is locally created.

4.5.  Explicit Control

   To support the functions of an application's control plane,
   applications must SHOULD be able to know and coordinate which data is
   stored at particular servers.  Thus, in contrast with content traditional
   caches, applications are given explicit control over the placement
   (selection of a DECADE-compatible server), deletion (or expiration
   policy), and access control for stored data.

   Consider deletion/expiration policy as a simple example.  An
   application may might require that a server store content data objects for a
   relatively short period of time (e.g., for live-streaming data).
   Another application may might need to store content data objects for a longer
   duration (e.g., for video-on-demand).

4.6.  Resource and Data Access Control through User Delegation

   A DECADE-compatible system provides will provide a shared infrastructure to be
   used by multiple tenants of Content Consumers and Content Providers spanning
   multiple content distribution
   applications. Content Distribution Applications.  Thus, it needs to
   provide both resource and data access control.

4.6.1.  Resource Allocation

   There are two primary interacting entities in a DECADE-compatible
   system.  First, Storage Providers SHOULD coordinate where storage
   servers are provisioned and their total available resources.  Second,
   Applications will coordinate data transfers amongst available servers
   and between servers and end-points. clients.  A form of isolation is required to
   enable concurrently-running Applications to each explicitly manage
   its own content data objects and share of resources at the available servers.

   The Storage Provider delegates SHOULD delegate the management of the resources
   on a server to applications.  It DECADE Content Providers.  This means applications that Content
   Providers are able to explicitly and independently manage their own
   shares of resources on a DECADE server.

4.6.2.  User Delegations

   Storage providers Providers will have the ability to explicitly manage the
   entities allowed to utilize the resources at a DECADE-compatible
   server.  This capability is needed for reasons such as capacity-planning capacity-
   planning and legal considerations in certain deployment scenarios.

   The server grants SHOULD grant a share of the resources to a user. Content
   Provider or Content Consumer.  The user may client can in turn share the
   granted resources amongst its multiple applications.  The share of
   resources granted by a storage provider server is called a User Delegation.

   As a simple example, a DECADE-compatible Server server operated by an ISP
   may
   might be configured to grant each ISP Subscriber 1.5 Mbps Mbit/s of
   bandwidth.  The ISP Subscriber may might in turn divide this share of
   resources amongst a video streaming application and file-sharing
   application which are running concurrently.

   In general, a User Delegation may be granted to an end-user (e.g., an
   ISP subscriber), a Content Provider, or an application.  A particular
   instance of an application may make use of the storage resources:

   o  granted to the end-user (with the end-user's permission),

   o  granted to the Content Provider (with the Content Provider's
      permission), and/or

   o  granted to the application.

5.  System Components

   The primary focus of this document is the architectural principles
   and the system components that implement them.  While certain system
   components might differ amongst implementations, the 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 may will require
   additional components (e.g., monitoring and accounting at a server),
   but they are intentionally omitted from this document.

5.1.  Content Distribution Application

   Content Distribution Applications have many functional components.
   For example, many P2P applications have components and algorithms to
   manage overlay topology management, rate allocation, piece selection,
   etc.  In this document, we focus on the components directly employed
   to support a DECADE-compatible system.

   Figure 3 illustrates the components discussed in this section from
   the perspective of a single Application End-Point.

                                    Native Protocol(s)
                            (with other Application End-Points)
                                    .--------------------->
                                    |
                                    |
   .----------------------------------------------------------.
   | Application End-Point                                    |
   | .------------.                 .-------------------.     |
   | | App-Layer  |   ...           | App Data Assembly |     |
   | | Algorithms |                 |    Sequencing     |     |
   | `------------'                 `-------------------'     |
   |                                                          |
   | .------------------------------------------------------. |
   | | DECADE Client                                        | |
   | |                                                      | |
   | | .-------------------------. .----------------------. | |
   | | | Resource Controller     | | Data Controller      | | |
   | | | .--------. .----------. | | .--------. .-------. | | |
   | | | |  Data  | | Resource | | | |  Data  | | Data  | | | |
   | | | | Access | | Sharing  | | | | Sched. | | Index | | | |
   | | | | Policy | |  Policy  | | | |        | |       | | | |
   | | | '--------' `----------' | | `--------' `-------' | | |
   | | `-------------------------' `----------------------' | |
   | |             |                   ^                    | |
   | `------------ | ----------------- | -------------------' |
   `-------------- | ----------------- | ---------------------'
                   |                   |
                   |  DECADE           | Standard
                   | Resource          |   Data
                   | Protocol          | Transfer
                   |   (DRP)           |   (SDT)
                   v                   V

                     Figure 3: Application Components

5.1.1.  Data Assembly

   A DECADE-compatible system is geared towards supporting applications
   that can divide distributed contents content into data objects.  To accomplish
   this, applications can include a component responsible for creating
   the individual data objects before distribution and then re-
   assembling data objects at the Content Consumer.  We call this
   component the Application Data Assembly.

   In producing and assembling the data objects, two important
   considerations are sequencing and naming.  A DECADE-compatible system
   assumes that applications implement this functionality themselves.
   See Section 5.3 for further discussion.

5.1.2.  Native Application Protocols

   Applications may still use existing protocols.

   In particular, an
   application may reuse addition to the DECADE-compatible DRP/SDT, applications will also
   support their existing protocols primarily for control/
   signaling.  However, an native application may still retain its existing
   data transfer protocols in addition to employing a (e.g., P2P
   control and data transfer
   protocol with DECADE-complliant support.  This is important for
   applications that are designed to be highly robust (e.g., if in-
   network servers are unavailable). protocols).

5.1.3.  DECADE Client

   An application needs to be modified to support a DECADE-compatible
   system.  The DECADE Client client provides the local support to an
   application.  A DECADE Client need not be application, and
   can standalone, embedded into the
   application.  It could be implemented alone, application, or could be integrated in other
   entities such as network devices themselves.

5.1.3.1.  Resource Controller

   Applications may have different Resource Sharing Policies and Data
   Access Policies to control their resource and data in DECADE-
   compatible servers.  These policies can may be existing policies of
   applications (e.g., tit-for-tat) or custom policies.  The specific implementation is
   decided by the application.

5.1.3.2.  Data Controller

   A DECADE-compatible system decouples the control and the data
   transfer of applications.  A Data Scheduling component schedules data
   transfers according to network conditions, available Servers, servers, and/or
   available Server server resources.  The Data Index indicates data available
   at remote servers.  The Data Index (or a subset of it) may can be
   advertised to other Application End-Points. clients.  A common use case for this is to
   provide the ability to locate data amongst a distributed
   set of Application
   End-Points (i.e., a data search mechanism). mechanism such as a Distributed Hash
   Table).

5.2.  DECADE  Server

   A

   Figure 4 illustrates the components discussed in a DECADE-compatible Server stores data from Application End-Points,
   and provides control and access of those data to Application End-
   Points.
   server.  A Server server is not necessarily a single physical machine, it
   could
   can also be implemented as a cluster of machines.

          |                   |
          |  DECADE           | Standard
          | Resource          |   Data
          | Protocol          | Transfer
          |   (DRP)           |   (SDT)
          |                   |
       .= | ================= | ======================.
       |  |                   v                       |
       |  |      .----------------.                   |
       |  |----> | Access Control | <--------.        |
       |  |      `----------------'          |        |
       |  |                   ^              |        |
       |  |                   |              |        |
       |  |                   v              |        |
       |  |   .---------------------.        |        |
       |  `-> | Resource Scheduling | <------|        |
       |      `---------------------'        |        |
       |                      ^              |        |
       |                      |              |        |
       |                      v        .------------. |
       |        .-----------------.    |    User    | |
       |        |    Data Store   |    | Delegation | |
       |        `-----------------'    | Management | |
       | DECADE Server                 `------------' |
       `=============================================='

                    Figure 4: DECADE Server Components

5.2.1.  Access Control

   An Application End-Point can

   A client SHALL be able to access its own data or other Application
   End-Point's client's data
   (provided sufficient authorization) in DECADE-
   compatible DECADE-compatible servers.  Application End-Points may
   Clients MAY also authorize other
   End-Points Clients to store data.  If an access
   is authorized by an
   Application End-Point, a Client, the Server will server SHOULD provide access.  Even if
   a request is authorized, it may MAY still fail to complete due to
   insufficient resources by either the requesting Application End-
   Point, the providing Application End-Point, or the Server itself.

5.2.2.  Resource Scheduling

   Applications apply resource sharing policies or use a custom policy.
   Servers perform resource scheduling according to the resource sharing
   policies indicated by Application End-Points as well as configured
   User Delegations.

5.2.3.  Data Store

   Data from applications may be stored at a DECADE-compatible Server.
   Data can be deleted from storage either explicitly or automatically
   (e.g., after a TTL expiration).  It may be possible to perform
   optimizations in certain cases, such as avoiding writing temporary
   data (e.g., live streaming) to persistent storage, if appropriate
   storage hints are supported by the SDT.

5.3.  Data Sequencing and Naming

   In order to provide a simple and generic interface, the DECADE-
   compatible Server is only responsible for storing and retrieving
   individual data objects.  Furthermore, a DECADE-compatible system
   uses its own simple naming scheme that provides uniqueness (with high
   probability) between data objects, even across multiple applications.

5.3.1.  DECADE Data Object Naming Scheme

   The name of a data object is derived from the hash over the data
   object's content (the raw bytes), which is made possible by the fact
   that bjects are immutable.  This scheme has multiple appealing
   properties:

   o  Simple integrity verification

   o  Unique names (with high probability)

   o  Application independent, without a new IANA-maintained registry

   The DECADE-compatible naming scheme also includes a "type" field, the
   "type" identifier indicates that the name is the hash of the data
   object's content and the particular hashing algorithm used.  This
   allows it to evolve by either changing the hashing algorithm (e.g.,
   if security vulnerabilities with an existing hashing algorithm are
   discovered), or moving to a different naming scheme altogether.

   The specific format of the name (e.g., encoding, hash algorithms,
   etc) is out of scope of this document, and left for protocol
   specification.

   Another advantage of this scheme is that a DECADE-compatible client
   knows the name of server.

5.2.2.  Resource Scheduling

   Applications will apply resource sharing policies or use a data object before it is completely custom
   policy.  Servers perform resource scheduling according to the
   resource sharing policies indicated by Clients as well as configured
   User Delegations.

5.2.3.  Data Store

   Data from applications will be stored at the a DECADE-compatible server.  This allows for particular optimizations,
   Data SHOULD be deleted from storage either explicitly or
   automatically (e.g., after a TTL expiration).  It SHOULD be possible
   to perform optimizations in certain cases, such as
   advertising data object while the avoiding writing
   temporary data object is being stored,
   removing store-and-forward delays.  For example, a client A may
   simultaneously begin storing an object to a server, and advertise
   that the object is available (e.g., live streaming) to client B. If it is persistent storage, if
   appropriate storage hints are supported by the
   server, client B may begin downloading the object before A is
   finished storing the object. SDT.

5.3.  Data Sequencing and Naming

   In certain scenarios (e.g., where a client has limited computational
   power), it may be advantageous order to offload provide a simple and generic interface, the computation of DECADE-
   compatible server will only be responsible for storing and retrieving
   individual data objects.  Furthermore, a DECADE-compatible system
   will use its own naming scheme that provides uniqueness (with high
   probability) between data
   object's name to objects, even across multiple applications.

5.3.1.  Data Object Naming Scheme

   Details of the Server.  This possibility is not considered naming scheme are discussed in
   the current architecture, but may be a topic for future extensions. Section 4.4.

5.3.2.  Application Usage

   Recall from Section 5.1.1 that an Application typically includes its
   own naming and sequencing scheme.  The DECADE-compatible naming
   format does not SHOULD NOT attempt to replace any naming or sequencing of data
   objects already performed by an Application; instead, the naming is
   intended to apply only to data objects referenced by DECADE-specific
   purposes .

   DECADE-compatible names are not necessarily correlated with the
   naming or sequencing used referenced by the DECADE-specific
   purposes.

   An Application using a DECADE-
   compatible client. DECADE-compatible client may use a naming and
   sequencing scheme independent of DECADE-compatible names.  The
   DECADE-compatible client is expected to SHOULD maintain a mapping from its own data
   objects and their names to the DECADE-specific data objects and
   names.  Furthermore, the DECADE-
   compatible naming scheme implies no sequencing or grouping of
   objects, even if this is done at the application layer.

   Not only does an Application retain its own naming scheme, it may
   also decide the sizes of data objects to be distributed via the
   DECADE-compatible system.  This is desirable since sizes of data
   objects may impact Application performance (e.g., overhead vs. data
   distribution delay), and the particular tradeoff is application-
   dependent.

5.3.3.  Application Usage Example

   To illustrate these properties, this section presents multiple
   examples.

5.3.3.1.  Application with Fixed-Size Chunks

   Similar to the example in Section 5.1.1, 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 16KB. 16 KiloByte (KB).

   Now, assume that this application wishes to store data in DECADE-
   compatible servers in data objects of size 64KB. 64 KB.  To accomplish
   this, it can map a sequence of 4 chunks into a single 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 might maintain a logical mapping
   that is able to determine the name of a DECADE-compatible data object
   given the chunks contained within that data object.  The name might
   be learned from either the original source, another endpoint End-Point with
   which the it Application is communicating, a tracker, etc.

   As long as the data contained within each sequence of chunks is
   globally unique, the corresponding data objects have globally unique
   names.  This is desired, and happens automatically if particular
   Application segments the same stream of data in a different way,
   including different chunk sizes or different padding schemes.

5.3.3.2.  Application with Continuous Streaming Data

   Next, consider

   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 shows how a video streaming application might produce
   variable-sized data objects such that each data object contains 10
   seconds of video data.

     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

   Similar to the previous example, the Application might maintain a
   mapping that is able to determine the name of a DECADE data object given the
   time offset of the video chunk.

5.4.  Token-based Authentication and Resource Control

   A key feature of a DECADE-compatible system is that a Client client can
   authorize other Clients to store or retrieve data objects from the
   in-network storage.  A token-based authentication scheme is used to
   accomplish this.

   Specifically, an entity trusted by a Client client generates a digitally- signed token
   with particular properties (see Section 6.1.2 for details).  The Client
   client then distributes this token to other Clients which then use
   the token when sending requests to the DECADE-compatible
   Server. server.
   Upon receiving a token, the Server server validates the signature and the
   operation being performed. performed (e.g.  PUT, GET).

   This is a simple scheme, but has some important advantages over an
   alternate approach in which a Client client explicitly manipulates an Access
   Control List (ACL) associated with each data object.  In particular,
   it has the following advantages when applied to DECADE-compliant DECADE-compatible
   target applications:

   o  Authorization policies are implemented within the Application; an
      Application explicitly controls when tokens are generated and to
      whom they are distributed.

   o  Fine-grained access and resource control can be applied to data
      objects; see Section 6.1.2 for the list of restrictions that can
      be enforced with a token.

   o  There is no messaging between a Client client and Server 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.

   o  Tokens can provide anonymous access, in which a Server server does not
      need to know the identity of each Client client that accesses it.  This
      enables a Client client to send tokens to Clients clients in other administrative
      or security domains, and allow them to read or write data objects
      from its storage.

   In addition to Clients clients applying access control policies to data
   objects, the Server may server MAY be configured to apply additional policies
   based on user, object, geographic location, etc.  A Client may client might thus
   be denied access even though it possess a valid token.

   Existing protocols (e.g., OAuth [RFC5849]) implement similar referral
   mechanisms using tokens.  A protocol specification of this
   architecture will prefer SHOULD endeavor to use existing mechanisms wherever
   possible.

5.5.  Discovery

   A DECADE-compatible systme includes system SHOULD include a discovery mechanism
   through which clients locate an appropriate Server. server.
   [I-D.ietf-decade-reqs] details specific requirements of the discovery
   mechanism; this section discusses how they relate to other principles
   outlined in this document.

   A discovery mechanism allows 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 may might also result in an error if
   no such servers can be located.)  After discovering one or more
   servers, a client may 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 particular protocol used for discovery is out of scope of this
   document, but any specification will SHOULD re-use standard protocols
   wherever possible.

   The discovery mechanism outlined here does not provide the ability to
   locate arbitrary DECADE-compatible servers to which a client might
   obtain tokens from others.  To do so requires application-level
   knowledge, and it is assumed that this functionality is implemented
   in the Content Distribution Application, or if desired and needed, as
   an extension to a DECADE-compatible system. Application.

6.  DECADE Protocols

   This section presents the DECADE Resource Protocol (DRP) DRP and the
   Standard Data Transfer (SDT) SDT protocol in terms of
   abstract protocol interactions that are intended to be mapped to
   specific protocols.  In general, the DRP/SDT functionality between a
   DECADE-compatible client-server are very similiar similar to the DRP/SDT
   functionality between running between server-server.  Any differences
   are highlighted below.

   The DRP is will be the protocol used by a DECADE-compatible client to
   configure the resources and authorization used to satisfy requests
   (reading, writing, and management operations concerning objects) at a
   server.  The SDT is will be used to send the operations data to the server.
   Necessary DRP metadata is supplied using mechanisms in the SDT that
   are provided for extensibility (e.g., additional request parameters
   or extension headers).

6.1.  DECADE Resource Protocol (DRP)

   DRP provides will provide configuration of access control and resource sharing
   policies on DECADE-compatible servers.  A content distribution
   application, Content Distribution
   Application, e.g., a live P2P streaming session, may can have permission
   to manage data at several servers, for instance, servers in different
   operator domains, and DRP allows one instance of such an application,
   e.g., an application endpoint, Application End-Point, to apply access control and resource
   sharing policies on each of them.

6.1.1.  Controlled Resources

   On a single DECADE-compatible server, the following resources may SHOULD
   be managed:

   communication resources:  Servers have limited communication

   o  Communication resources in terms of bandwidth (upload/download) but
      and also in terms of number of connected clients (connections) at
      a time.

   storage resources:  Servers have limited storage

   o  Storage resources.

6.1.2.  Access and Resource Control Token

   A token includes SHOULD include the following information:

   o  Permitted operations (e.g., read, write)

   o  Permitted objects (e.g., names of data objects that may might be read
      or written)

   o  Expiration time

   o  Priority for bandwidth given to requested operation (e.g., a
      weight used in a weighted bandwidth sharing scheme)

   o  Amount of data that may be read or written

   The particular format for the token is out of scope of this document. might be read or written

   The tokens are SHOULD be generated by a trusted an entity trusted by both the
   DECADE-compatible client and server at the request of a
   DECADE-compatible Client.  It is out of scope of DECADE-
   compatible client.  For example this document to
   identify which entity serves this purpose, but examples include could be the
   Client itself, client, a Server
   server trusted by the Client, client, or another server managed by a Storage
   Provider trusted by the Client. 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.

   Upon generating a token, a Client may client MAY distribute it to another Client client
   (e.g., via their native Application application protocol).  The receiving Client
   may client
   MAY then connect to the sending Client's Server client's server and perform any
   operation permitted by the token.  The token must SHOULD be sent along
   with the operation.  The Server validates server SHOULD validate the token to identify
   the Client 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 applies 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 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 Content Provider may have a
   limited budget (see Section 4.6), the a Content Provider should be
   able to indicate if a token may be used multiple times.

   It is SHOULD be possible for DRP to allow tokens to apply to a batch of
   operations to reduce communication overhead required between Clients. clients.
   A request sent in this way explicitly denotes the objects to which it
   applies.

   It SHOULD be possible to revoke tokens after they are generated.
   This could be accomplished by supplying the server the unique
   identifiers of the tokens which are to be revoked.

6.1.3.  Status Information

   DRP provides SHOULD provide a request service for status information that
   clients can use to request information from a server.

   status

   Status information per application context on a specific server:  Access to such status
      information requires SHOULD require client authorization, i.e., clients
      need to be authorized to access the requested status information
      for a specific application context. information.
      This authorization (and the
      mapping to application contexts) is based on the user delegation concept as
      described in Section 4.6.  The following status information
      elements can SHOULD be obtained:

      *  list  List of associated objects (with properties)

      *  resources  Resources used/available

      The following information elements MAY additionally be available:

      *  list  List of servers to which objects have been distributed (in a
         certain time-frame)

      *  list  List of clients to which objects have been distributed (in a
         certain time-frame)

      For the list of servers/clients to which objects have been
      distributed to, the server can 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
      can may be used for accounting purposes, e.g., the list of
      clients to which objects have been distributed.

   access

   Access information per application context on a specific server:  Access information can MAY be
      provided for accounting purposes, for example, when application service providers Content
      Providers are interested to
      maintain in access statistics for resources and/or
      to perform accounting per user.  Again, access to such information
      requires client authorization SHOULD based on the user delegation
      concept as described in Section 4.6.  The following type of access
      information elements can MAY be requested:

      *  what  What objects have been accessed how many times

      *  access  Access tokens that a server as seen for a given object

      The server can SHOULD decide on time bounds for which this information
      is stored and specify the corresponding time frame in the response
      to such requests.

6.1.4.  Object Attributes

   Objects that are stored on a DECADE-compatible server may SHOULD have
   associated attributes (in addition to the object identifier and the
   actual content) 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 storage-layer properties
   to the data object.  These attributes have a scope local to a server.
   In particular, these attributes are not SHOULD NOT be applied to a server or
   client to which a data object is copied.

   Depending on authorization, clients may SHOULD be permitted to get or set
   such attributes.  This authorization (and the mapping to application contexts) is based on the user delegation
   concept as described in Section 4.6.  The architecture does not limit
   the set of permissible attributes, but rather specifies a set of
   baseline attributes that should SHOULD be
   supported by implementations.

   Suggested attributes are the following: supported:

   Expiration Time:  Time at which the object may might be deleted

   object

   Object size:  in  In bytes

   Media type

   access  Labelling of type as per [RFC4288]

   Access statistics:  how  How often the object has been accessed (and what
      tokens have been used)

   The Object Attributes defined here are distinct from application
   metadata (see Section 4.1).  Application metadata is custom
   information that an application may 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.2.  Standard Data Transfer (SDT) Protocol

   A DECADE-compatible server will provide a data access interface, and
   the SDT
   is will be used to write objects to a server and to read
   (download) objects from a server.  Semantically, SDT is a client-server client-
   server protocol, i.e., the server always responds to client requests.

6.2.1.  Writing/Uploading Objects

   To write an object, a client first generates the object's name (see
   Section 5.3), and then uploads the object to a server and supplies
   the generated name.  The name can be used to access (download) the
   object later, e.g., the client can pass the name as a reference to
   other client that can then refer to the object.

   Objects can be self-contained objects such as multimedia resources,
   files etc., but also chunks, such as chunks of a P2P distribution
   protocol that can be part of a containing object or a stream.

   A

   If supported, a server may can accept download requests for an object
   that is still being uploaded.

   The application that originates the objects generates DECADE-
   compatible object names according to the naming specification in
   Section 5.3.  The naming scheme provides that the name is unique.  Clients (as parts of application entities) upload a
   named object to a server.  A  If supported, a server may can verify the
   integrity and other security properties of uploaded objects.

   In the following we provide an abstract specification of the upload
   operation that we name 'PUT METHOD'.

   Method  PUT:

   Parameters:

      NAME:  The naming of the object according to Section 5.3

      OBJECT:  The object itself.

   Description:  The PUT method is used by a DECADE-compatible client to
      upload an object with an associated name 'NAME' to a DECADE-
      compatible server.

   RESPONSES:  The server responds with one the following response
      messages:

      CREATED:  The object has been uploaded successfully and is now
         available under the specified name.

      ERRORs:

         VALIDATION_FAILED:  The contents of the data object received by
            the server did not match the provided name (i.e., hash
            validation failed).

         PERMISSION_DENIED:  The client lacked sufficient permission to
            store the object.

         Specifics regarding error handling, including additional error
         conditions, precedence for returned errors and its relation
         with server policy, are deferred to eventual protocol
         specification.

6.2.2.  Downloading Objects

   A client can request named objects from a server.  In the following,
   we provide an abstract specification of the download operation that
   we name 'GET METHOD'.

   Method  GET:

   Parameters:

      NAME:  The naming of the object according to Section 5.3.

   Description:  The GET method is used by uploaded objects.

6.2.2.  Downloading Objects

   A client can request named objects from a server.  In a corresponding
   request message, a client to download an specifies the object with an associated name 'NAME' from and a server.

   RESPONSES: suitable
   access and resource control token.  The server responds with one checks the following response
      messages:

      OK:  The request has succeeded, and an entity corresponding to validity of
   the
         requested received token and its associated resource is sent in usage-related
   properties.

   If the named object exists on the response.

      ERRORs:

         NOT_FOUND:  The server and then token has not found anything matching been
   validated, the
            request server delivers the requested object name.

         PERMISSION_DENIED:  The client lacked sufficient permission to
            read in a response
   message.

   If the object.

         NOT_AVAILABLE:  The data object exists but is currently
            unavailable for download (e.g., due to cannot be delivered the server policy). provides an
   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.3.  Server-to-Server Protocols

   An important feature of a DECADE-compatible system is the capability
   for one server to directly download 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 will 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
   object may might be limited to being exchanged between servers even if
   the instruction is triggered by the client). clients  Clients thus must will be
   able to indicate to a server the following additional parameters:

   o  which  Which remote server(s) to access;

   o  the  The operation to be performed (e.g.  PUT, GET); and

   o  Credentials indicating permission to perform the operation at the
      remote server.

   In this way, a server acts as a proxy for a client, and a client may
   instantiate requests via that proxy.  The operations are performed as
   if the original requester had its own client co-located with the
   server.  It is this mode of operation that provides substantial
   savings in uplink capacity.  This mode of operation may also be
   triggered by an administrative/management application outside the
   architecture.

6.3.1.  Operational Overview

   Server-to-server support is focused on reading and writing data
   objects between servers.  A DECADE-compatible GET or PUT request may
   supply the following additional parameters:

   REMOTE_SERVER:  Address of the remote server.  The format of the
      address is out-of-scope of this document.

   REMOTE_USER:  The account Content Provider at the remote server from which to retrieve
      the object (for a GET), or in which the object is to be stored
      (for a PUT).

   TOKEN:  Credentials to be used at the remote server.

   These parameters are used by which the server object is to instantiate be stored
      (for a request PUT).

   o  Credentials indicating permission to perform the operation at the specified
      remote server.  It

   Server-to-server support is assumed that the focused on reading and writing data
   objects between servers.  The data object referred to at the remote
   server is the same as the original request.  Object attributes (see
   Section 6.1.4) may 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.  It is this mode of operation that provides
   substantial savings in uplink capacity.  This mode of operation can
   also be triggered by an administrative/management application outside
   the architecture.

   When a client sends a request to a server with these additional
   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 GET operation, the server is to retrieve the data
   object from the remote server using the specified credentials (via a
   GET request to the remote server), and then optionally return the
   object to a client.  In the case of a PUT operation, the server is to
   store the object to the remote server using the specified credentials
   (via a PUT request to the remote server).  The object may might
   optionally be uploaded from the client or may might already exist at the proxying
   proxy server.

7.  Security Considerations

   In general, the security considerations mentioned in
   [I-D.ietf-decade-problem-statement] apply to this document as well.

   A DECADE-compatible 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 content distribution application, Content Distribution Application, and it is
   generally
   expected that DECADE-compatible clients take part in
   application-specific application-
   specific communication sessions.

   The security considerations here focus on threats related to the
   DECADE-compatible system and its communication services, i.e., the
   DRP/SDT protocols that have been described in an abstract fashion in
   this document.

7.1.  Threat: System Denial of Service Attacks

   A DECADE-compatible network of servers may 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 its access control and resource control
   framework.  Servers can require application endpoints Application End-Points to be
   authorized to store and to download objects, and application
   endpoints Application End-
   Points can delegate authorization to other application endpoints 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) may might still lead to considerable load for
   processing requests and invalidating tokens.  A SDT therefore MUST
   provide a redirection mechanism as described as a requirement in
   [I-D.ietf-decade-reqs].

7.2.  DECADE  Threat: Protocol Security Threats

7.2.1.  Threat: Authorization Mechanisms Compromised

   A DECADE-compatible system does not require application endpoints Application End-Points to
   authenticate in order to access a server for downloading objects,
   since authorization is not based on endpoint End-Point or user identities but
   on the 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, or at least the affected application context on servers,
   servers is compromised.

   This is a general security threat that applies to authorization
   delegation schemes.  Specifications of existing delegation schemes
   such as OAuth [RFC5849] 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.

7.2.2.  Threat: Object Spoofing

   In a DECADE-compliant DECADE-compatible system, an application endpoint Application End-Point is referring
   other application endpoints 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 endpoint End-Point effectively
   receives a different object (compared to what the uploading endpoint End-Point
   provided).  As result, the downloading endpoint 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 endpoints 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-compliant DECADE-compatible systems fundamental mechanism against object
   spoofing is name-content name-object binding validation, i.e., the ability of a
   receiver to check whether the name he was provided and that he used
   to request an object, actually corresponds to the bits he received.
   As described above, this allows for different forms of name-content name-object
   binding, for example using content hashes, hashes of data objects, with different
   hash functions (different algorithms, different digest lengths).  For
   those application scenarios where content hashes of data objects are not
   applicable (for example live-streaming) other forms of name-content name-object
   binding can be used (see Section 5.3. 5.3).  This flexibility also
   addresses cryptographic algorithm evolvability: hash functions may might
   get deprecated, better alternatives may might be invented etc., so that
   applications can choose appropriate mechanisms meeting their security
   requirements.

   DECADE-compliant

   DECADE-compatible servers MAY perform name-content name-object binding validation
   on stored objects, but application endpoints Application End-Points MUST NOT rely on that.
   In other forms: application endpoints Application End-Points SHOULD perform name-content name-object
   binding validation on received objects.

8.  IANA Considerations

   This document does not have any IANA considerations.

9.  Acknowledgments

   We thank the following people for their contributions to this
   document:

   David Bryan

   Hongqiang (Harry) Liu

   Yingjie Gu

   David McDysan

   Borje Ohlman

   Haibin Song

   Martin Stiemerling

   Richard Woundy

   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.

   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
              Distributed Authoring and Versioning (WebDAV)
              Access Control Protocol", RFC 3744, May 2004.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC4331]  Korver, B. and L. Dusseault, "Quota and Size Properties fo
              r Distributed Authoring and Versioning (DAV) Collections",
              RFC 4331, February 2006.

   [RFC4709]  Reschke, J., "Mounting Web Distributed Authoring and
              Versioning (WebDAV) Servers", RFC 4709, October 2006.

   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

   [RFC5661]  Shepler, S., Eisler, M., and D. Noveck, "Network File
              System (NFS) Version 4 Minor Version 1 Protocol",
              RFC 5661, January 2010.

   [RFC5849]  Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
              April 2010.

   [RFC6392]  Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
              Network Storage Systems", RFC 6392, October 2011.

   [I-D.ietf-decade-problem-statement]
              Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
              Application Data Enroute (DECADE) Problem Statement",
              draft-ietf-decade-problem-statement-05
              draft-ietf-decade-problem-statement-06 (work in progress),
              February
              May 2012.

   [I-D.ietf-decade-reqs]
              Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE
              Requirements", draft-ietf-decade-reqs-05 draft-ietf-decade-reqs-06 (work in
              progress), October 2011.

   [GoogleStorageDevGuide]
              "Google Storage Developer Guide", <http://code.google.com/
              apis/storage/docs/developer-guide.html>. March 2012.

   [OpenFlow]
              "OpenFlow Organization", <http://www.openflow.org/>.

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

Appendix A.  In-Network Storage Components Mapped to DECADE Architecture

   In this section we evaluate how the basic components of an in-network
   storage system identified in Section 3 of [RFC6392] map into a
   DECADE-compatible system.

   It is important to note that complex and/or application-specific
   behavior is delegated to applications instead of tuning the storage
   system wherever possible.

A.1.  Data Access Interface

   Users

   Clients can read and write objects of arbitrary size through the
   Client's
   client's Data Controller, making use of a SDT.

A.2.  Data Management Operations

   Users

   Clients can move or delete previously stored objects via the Client's client's
   Data Controller, making use of a SDT.

A.3.  Data Search Capability

   Users

   Clients can enumerate or search contents of Servers 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 may might consult their
   local Data Index in the Client's client's Data Controller.

A.4.  Access Control Authorization

   All methods of access control are supported: public-unrestricted,
   public-restricted and private.  Access Control Policies are generated
   by a Content Distribution Application and provided to the Client's client's
   Resource Controller.  The Server server is responsible for implementing the
   access control checks.

A.5.  Resource Control Interface

   Users

   Clients can manage the resources (e.g. bandwidth) on the DECADE
   server that can be used by other Application End-Points.  Resource
   Sharing Policies are generated by a Content Distribution Application
   and provided to the Client's client's Resource Controller.  The Server server is
   responsible for implementing the resource sharing policies.

A.6.  Discovery Mechanism

   The particular protocol used for discovery is outside the scope of
   this document.  However, options and considerations have been
   discussed in Section 5.5.

A.7.  Storage Mode

   Servers provide an object-based storage mode.  Immutable data objects
   may
   might be stored at a Server. server.  Applications may might consider existing
   blocks as data objects, or they may might adjust block sizes before
   storing in a
   Server. server.

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