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

Versions: (draft-alimi-decade-arch) 00 01 02 03 04 05 06 07 08 09 10

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


                          DECADE Architecture
                       draft-ietf-decade-arch-05

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 system.  This document
   presents an architecture for DECADE, discusses the underlying
   principles, and identifies key functionalities required for
   introducing in-network storage for these applications.  In addition,
   some examples are given to illustrate these concepts in an
   informative manner.

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



Alimi, et al.          Expires September 13, 2012               [Page 1]


Internet-Draft             DECADE Architecture                March 2012


   This Internet-Draft will expire on September 13, 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.



































Alimi, et al.          Expires September 13, 2012               [Page 2]


Internet-Draft             DECADE Architecture                March 2012


Table of Contents

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



Alimi, et al.          Expires September 13, 2012               [Page 3]


Internet-Draft             DECADE Architecture                March 2012


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36


















































Alimi, et al.          Expires September 13, 2012               [Page 4]


Internet-Draft             DECADE Architecture                March 2012


1.  Introduction

   Content Distribution Applications (e.g., 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 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
   in an application specific manner.

   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  A physical or logical component in the DECADE architecture: DECADE
      Client, DECADE Server, Content Distribution Application and
      Application End Point;




Alimi, et al.          Expires September 13, 2012               [Page 5]


Internet-Draft             DECADE Architecture                March 2012


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

   o  Source or sink of content distributed via the DECADE architecture:
      DECADE Content Provider, and DECADE Content Consumer.

2.1.  DECADE Server

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

2.2.  DECADE Client

   A DECADE client stores and retrieves data at DECADE Servers.

2.3.  DECADE Storage Provider

   A DECADE storage provider deploys and/or manages DECADE storage
   server(s) within a network.  A storage provider may also own or
   manage the network in which the DECADE servers are deployed, but this
   is not mandatory.

   A DECADE storage provider, possibly in cooperation with one or more
   network providers, determines deployment locations for DECADE servers
   and determines the available resources for each.

2.4.  Content Provider Using DECADE

   A content provider using DECADE accesses DECADE storage servers (by
   way of a DECADE client) to upload and manage data.  Such a content
   provider can access one or more storage servers.  Such a content
   provider may be a single process or a distributed application (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 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.






Alimi, et al.          Expires September 13, 2012               [Page 6]


Internet-Draft             DECADE Architecture                March 2012


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

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

   An Application End-Point need not be actively transferring data with
   other Application End-Points to interact with the DECADE storage
   system.  That is, an End-Point may interact with the DECADE storage
   servers as an offline activity.


3.  Protocol Flow

3.1.  Overview

   A DECADE-compatible system supports 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 a DECADE Client to a DECADE Server, as well
   as between DECADE Servers.  A DECADE-compatible system includes
   exactly one DRP for interoperability and a common format through
   which these policies can be communicated.

















Alimi, et al.          Expires September 13, 2012               [Page 7]


Internet-Draft             DECADE Architecture                March 2012


                         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 (SDT) is used to transfer
   data objects to and from a DECADE Server.  A DECADE-compatible system
   may support multiple SDT's.  If there are multiple SDT's, a
   negotiation mechanism is used to determine a suitable data transfer
   protocol between a DECADE Client and DECADE Server.

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






Alimi, et al.          Expires September 13, 2012               [Page 8]


Internet-Draft             DECADE Architecture                March 2012


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 DECADE-
   compatible storage server.  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.

   The steps of the example are illustrated in Figure 2.  First, B
   requests a data object from A using their native protocol.  Next, A
   uses the DECADE-compatible Resource Protocol (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 protocol).  Finally, B provides the token to S(A)
   via DRP, and requests and downloads the data object via a Standard
   Data Transport (SDT).

                               .----------.
      2. Obtain      --------> |   S(A)   | <------
         Token      /          `----------'        \   4. Request and
         (DRP)     /                                \    Download Object
         Locally  /                                  \    (DRP + SDT)
         or From /                                    \
         S(A)   v          1. App Request              v
       .-------------. <--------------------------- .-------------.
       | End-Point A |                              | End-Point B |
       `-------------' ---------------------------> `-------------'
                          3. App Response (token)


                  Figure 2: Download from Storage Server


4.  Architectural Principles

   We identify the following key principles.





Alimi, et al.          Expires September 13, 2012               [Page 9]


Internet-Draft             DECADE Architecture                March 2012


4.1.  Decoupled Control/Metadata and Data Planes

   A DECADE-compatible system will support multiple content distribution
   applications.  A complete 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 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 may use
      different metadata management schemes.  For example, one
      application may use a sequence of blocks (e.g., for file sharing),
      while another application may use a sequence of frames (with
      different sizes) indexed by time.

   o  Resource Scheduling Algorithms: 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 fine-tune
      such algorithms.

   Given the diversity of control plane functions, in-network storage
   should export basic mechanisms and allow as much flexibility as
   possible to the control plane to implement specific policies.  This
   conforms to the end-to-end systems principle and allows innovation
   and satisfaction of specific business 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 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 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 such as video



Alimi, et al.          Expires September 13, 2012              [Page 10]


Internet-Draft             DECADE Architecture                March 2012


   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 reuse of data and de-duplication
   of redundant content.

   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 divide bulk content into
   blocks for two reasons: (1) multipath: different blocks may be
   fetched from different sources in parallel, and (2) faster recovery
   and verification: individual blocks may 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 agnostic to the nature of the data
   objects and does not specify a fixed size for them, though a protocol
   specification based on this architecture may prescribe requirements
   on minimum and maximum sizes by compliant implementatations.
   Applications may consider existing blocks as data objects, or they
   may adjust block sizes before storing in the DECADE-compatible
   server.

   Immutable content may 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 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 to as
   immutable data objects/blocks.

4.3.  Data Object Identifiers

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

   A content consumer may be able to access more than one storage server
   within a single application context.  A data object that is



Alimi, et al.          Expires September 13, 2012              [Page 11]


Internet-Draft             DECADE Architecture                March 2012


   replicated across different storage servers managed by a DECADE-
   compatible storage provider can still be accessed by a single
   identifier.

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

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

   For some applications it is important that DECADE clients and servers
   are able to validate the name-object binding for a data object, i.e.,
   by verifying that a received object really corresponds to the name
   that was used for requesting it (or that was provided by a sender).
   Data object identifiers can support name-content 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 naming scheme meets the following general
   requirements:

   o  Different name-object binding validation mechanisms are supported;

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

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

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




Alimi, et al.          Expires September 13, 2012              [Page 12]


Internet-Draft             DECADE Architecture                March 2012


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

   For most content distribution scenarios, it will be appropriate to
   derive the name of a data object from the hash over the data object's
   content (the raw bytes), 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 not
   based on hashes but rather on a enumeration scheme.  The DECADE
   naming scheme also enables those applications to construct unique
   names.

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

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

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

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

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

   The DECADE naming scheme can 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
   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 begin downloading the object before A is
   finished storing the object.

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

4.5.  Explicit Control

   To support the functions of an application's control plane,
   applications must be able to know and coordinate which data is stored



Alimi, et al.          Expires September 13, 2012              [Page 13]


Internet-Draft             DECADE Architecture                March 2012


   at particular servers.  Thus, in contrast with content 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 require that a server store content for a relatively
   short period of time (e.g., for live-streaming data).  Another
   application may need to store content 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 a shared infrastructure to be
   used by multiple tenants of multiple 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 coordinate where storage servers
   are provisioned and their total available resources.  Second,
   Applications coordinate data transfers amongst available servers and
   between servers and end-points.  A form of isolation is required to
   enable concurrently-running Applications to each explicitly manage
   its own content and share of resources at the available servers.

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

4.6.2.  User Delegations

   Storage providers 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 and legal
   considerations in certain deployment scenarios.

   The server grants a share of the resources to a user.  The user may
   in turn share the granted resources amongst multiple applications.
   The share of resources granted by a storage provider is called a User
   Delegation.

   As a simple example, a DECADE-compatible Server operated by an ISP
   may be configured to grant each ISP Subscriber 1.5 Mbps of bandwidth.
   The ISP Subscriber may in turn divide this share of resources amongst



Alimi, et al.          Expires September 13, 2012              [Page 14]


Internet-Draft             DECADE Architecture                March 2012


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














Alimi, et al.          Expires September 13, 2012              [Page 15]


Internet-Draft             DECADE Architecture                March 2012


                                    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 into data objects.  To
   accomplish this, applications 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 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.



Alimi, et al.          Expires September 13, 2012              [Page 16]


Internet-Draft             DECADE Architecture                March 2012


5.1.2.  Native Protocols

   Applications may still use existing protocols.  In particular, an
   application may reuse existing protocols primarily for control/
   signaling.  However, an application may still retain its existing
   data transfer protocols in addition to employing a 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).

5.1.3.  DECADE Client

   An application needs to be modified to support a DECADE-compatible
   system.  The DECADE Client provides the local support to an
   application.  A DECADE Client need not be embedded into the
   application.  It could be implemented alone, 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 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, and/or
   available Server resources.  The Data Index indicates data available
   at remote servers.  The Data Index (or a subset of it) may be
   advertised to other Application End-Points.  A common use case for
   this is to provide the ability to locate data amongst a distributed
   set of Application End-Points (i.e., a data search mechanism).

5.2.  DECADE Server

   A DECADE-compatible Server stores data from Application End-Points,
   and provides control and access of those data to Application End-
   Points.  A Server is not necessarily a single physical machine, it
   could also be implemented as a cluster of machines.








Alimi, et al.          Expires September 13, 2012              [Page 17]


Internet-Draft             DECADE Architecture                March 2012


          |                   |
          |  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 access its own data or other Application
   End-Point's data (provided sufficient authorization) in DECADE-
   compatible servers.  Application End-Points may also authorize other
   End-Points to store data.  If an access is authorized by an
   Application End-Point, the Server will provide access.

   Even if a request is authorized, it 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.





Alimi, et al.          Expires September 13, 2012              [Page 18]


Internet-Draft             DECADE Architecture                March 2012


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 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
   simultaneously begin storing an object to a server, and advertise
   that the object is available to client B. If it is supported by the



Alimi, et al.          Expires September 13, 2012              [Page 19]


Internet-Draft             DECADE Architecture                March 2012


   server, client B may begin downloading the object before A is
   finished storing the object.

   In certain scenarios (e.g., where a client has limited computational
   power), it may be advantageous to offload the computation of a data
   object's name to the Server.  This possibility is not considered in
   the current architecture, but may be a topic for future extensions.

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 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 by the Application using a DECADE-
   compatible client.  The DECADE-compatible client is expected to
   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.

   Now, assume that this application wishes to store data in DECADE-
   compatible servers in data objects of size 64KB.  To accomplish this,
   it can map a sequence of 4 chunks into a single object, as shown in



Alimi, et al.          Expires September 13, 2012              [Page 20]


Internet-Draft             DECADE Architecture                March 2012


   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 with
   which the it is communicating, a tracker, etc.

   As long as the data contained within each sequence of chunks is
   unique, the corresponding data objects have 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 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.









Alimi, et al.          Expires September 13, 2012              [Page 21]


Internet-Draft             DECADE Architecture                March 2012


     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 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 generates a digitally-
   signed token with particular properties (see Section 6.1.2 for
   details).  The Client distributes this token to other Clients which
   then use the token when sending requests to the DECADE-compatible
   Server.  Upon receiving a token, the Server validates the signature
   and the operation being performed.

   This is a simple scheme, but has some important advantages over an
   alternate approach 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-compliant
   target applications:

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



Alimi, et al.          Expires September 13, 2012              [Page 22]


Internet-Draft             DECADE Architecture                March 2012


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

   o  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 in other administrative
      or security domains, and allow them to read or write data objects
      from its storage.

   In addition to Clients applying access control policies to data
   objects, the Server may be configured to apply additional policies
   based on user, object, geographic location, etc.  A Client may 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 to use existing mechanisms wherever
   possible.

5.5.  Discovery

   A DECADE-compatible systme includes a discovery mechanism through
   which clients locate an appropriate 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 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 also result in an error if no such
   servers can be located.)  After discovering one or more servers, a
   client may 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 re-use standard protocols



Alimi, et al.          Expires September 13, 2012              [Page 23]


Internet-Draft             DECADE Architecture                March 2012


   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.


6.  DECADE Protocols

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

   The DRP is 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 used to send the operations 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 configuration of access control and resource sharing
   policies on DECADE-compatible servers.  A content distribution
   application, e.g., a live P2P streaming session, may 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, 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 be
   managed:

   communication resources:  Servers have limited communication
      resources in terms of bandwidth (upload/download) but also in
      terms of number of connected clients (connections) at a time.





Alimi, et al.          Expires September 13, 2012              [Page 24]


Internet-Draft             DECADE Architecture                March 2012


   storage resources:  Servers have limited storage resources.

6.1.2.  Access and Resource Control Token

   A token includes the following information:

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

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

      Expiration time

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

      Amount of data that may be read or written

   The particular format for the token is out of scope of this document.

   The tokens are generated by a trusted entity at the request of a
   DECADE-compatible Client.  It is out of scope of this document to
   identify which entity serves this purpose, but examples include the
   Client itself, a Server trusted by the Client, or another server
   managed by a Storage Provider trusted by the Client.

   Upon generating a token, a Client may distribute it to another Client
   (e.g., via their native Application protocol).  The receiving Client
   may then connect to the sending Client's Server and perform any
   operation permitted by the token.  The token must be sent along with
   the operation.  The Server validates 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 applies the resource control policies indicated in the
   token while performing the operation.

   Tokens include a unique identifier to allow a Server to detect when a
   token is used multiple times.

   It is possible for DRP to allow tokens to apply to a batch of
   operations to reduce communication overhead required between Clients.

6.1.3.  Status Information

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





Alimi, et al.          Expires September 13, 2012              [Page 25]


Internet-Draft             DECADE Architecture                March 2012


   status information per application context on a specific server:
      Access to such status information requires client authorization,
      i.e., clients need to be authorized to access status information
      for a specific application context.  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 be obtained:

      *  list of associated objects (with properties)

      *  resources used/available

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

      *  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 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 be used for accounting purposes, e.g., the list of clients to
      which objects have been distributed.

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

      *  what objects have been accessed how many times

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

      The server can 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 have
   associated attributes (in addition to the object identifier and the
   actual content) that relate to the data storage and its management.
   These attributes may be used by the server (and possibly the



Alimi, et al.          Expires September 13, 2012              [Page 26]


Internet-Draft             DECADE Architecture                March 2012


   underlying storage system) to perform specialized processing or
   handling for the data object, or to attach related server or storage-
   layer properties to the data object.  These attributes have a scope
   local to a server.  In particular, these attributes are not applied
   to a server or client to which a data object is copied.

   Depending on authorization, clients may 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 be
   supported by implementations.

   Suggested attributes are the following:

   Expiration Time:  Time at which the object may be deleted

   object size:  in bytes

   Media type

   access statistics:  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 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)

   A DECADE-compatible server provide a data access interface, and SDT
   is used to write objects to a server and to read (download) objects
   from a server.  Semantically, SDT is a 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,



Alimi, et al.          Expires September 13, 2012              [Page 27]


Internet-Draft             DECADE Architecture                March 2012


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




Alimi, et al.          Expires September 13, 2012              [Page 28]


Internet-Draft             DECADE Architecture                March 2012


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 a client to download an
      object with an associated name 'NAME' from a server.

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

      OK:  The request has succeeded, and an entity corresponding to the
         requested resource is sent in the response.

      ERRORs:

         NOT_FOUND:  The server has not found anything matching the
            request object name.

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

         NOT_AVAILABLE:  The data object exists but is currently
            unavailable for download (e.g., due to server policy).

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



Alimi, et al.          Expires September 13, 2012              [Page 29]


Internet-Draft             DECADE Architecture                March 2012


   instruction.  However, the objects being processed do not necessarily
   have to originate or terminate at the client (i.e. the object may be
   limited to being exchanged between servers even if the instruction is
   triggered by the client). clients thus must be able to indicate to a
   server the following additional parameters:

   o  which remote server(s) to access;

   o  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 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 the server to instantiate a request to
   the specified remote server.  It is assumed that the data object
   referred to at the remote server is the same as the original request.
   Object attributes (see Section 6.1.4) may also be specified in the
   request to the remote 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).




Alimi, et al.          Expires September 13, 2012              [Page 30]


Internet-Draft             DECADE Architecture                March 2012


   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 optionally
   be uploaded from the client or may already exist at the proxying
   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, and it is
   generally expected that DECADE-compatible clients take part in
   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 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 to be
   authorized to store and to download objects, and application
   endpoints can delegate authorization to other application endpoints
   using the token mechanism.

   Of course the effective security of this approach depends on the
   strength of the token mechanism.  See below for a discussion of this
   and related communication security threats.



Alimi, et al.          Expires September 13, 2012              [Page 31]


Internet-Draft             DECADE Architecture                March 2012


   Denial of Service Attacks against a single server (directing many
   requests to that server) may 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 Protocol Security Threats

7.2.1.  Threat: Authorization Mechanisms Compromised

   A DECADE-compatible system does not require application endpoints to
   authenticate in order to access a server for downloading objects,
   since authorization is not based on endpoint or user identities but
   on 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, 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 system, an application endpoint is referring
   other application endpoints 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 effectively
   receives a different object (compared to what the uploading endpoint
   provided).  As result, the downloading endpoint believes that is has
   received an object that corresponds to the name it was provided
   earlier, whereas in fact it is a faked object.  Corresponding attacks
   could be mounted against the application protocol (that is used for
   referring other endpoints to servers), servers themselves (and their
   storage sub-systems), and the SDT by which the object is uploaded,



Alimi, et al.          Expires September 13, 2012              [Page 32]


Internet-Draft             DECADE Architecture                March 2012


   distributed and downloaded.

   A DECADE-compliant systems fundamental mechanism against object
   spoofing is name-content 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
   binding, for example using content hashes, with different hash
   functions (different algorithms, different digest lengths).  For
   those application scenarios where content hashes are not applicable
   (for example live-streaming) other forms of name-content binding can
   be used (see Section 5.3.  This flexibility also addresses
   cryptographic algorithm evolvability: hash functions may get
   deprecated, better alternatives may be invented etc., so that
   applications can choose appropriate mechanisms meeting their security
   requirements.

   DECADE-compliant servers MAY perform name-content binding validation
   on stored objects, but application endpoints MUST NOT rely on that.
   In other forms: application endpoints SHOULD perform name-content
   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



Alimi, et al.          Expires September 13, 2012              [Page 33]


Internet-Draft             DECADE Architecture                March 2012


   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 (work in progress),
              February 2012.



Alimi, et al.          Expires September 13, 2012              [Page 34]


Internet-Draft             DECADE Architecture                March 2012


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

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

   [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 can read and write objects of arbitrary size through the
   Client's Data Controller, making use of a SDT.

A.2.  Data Management Operations

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

A.3.  Data Search Capability

   Users 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, End-Points may consult their local Data
   Index in the Client's Data Controller.







Alimi, et al.          Expires September 13, 2012              [Page 35]


Internet-Draft             DECADE Architecture                March 2012


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
   Resource Controller.  The Server is responsible for implementing the
   access control checks.

A.5.  Resource Control Interface

   Users can manage the resources (e.g. bandwidth) on the DECADE server
   that can be used by other Application End-Points.  Resource Sharing
   Policies are generated by a Content Distribution Application and
   provided to the Client's Resource Controller.  The 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 be stored at a Server.  Applications may consider existing blocks
   as data objects, or they may adjust block sizes before storing in a
   Server.


Authors' Addresses

   Richard Alimi
   Google

   Email: ralimi@google.com


   Akbar Rahman
   InterDigital Communications, LLC

   Email: akbar.rahman@interdigital.com









Alimi, et al.          Expires September 13, 2012              [Page 36]


Internet-Draft             DECADE Architecture                March 2012


   Dirk Kutscher
   NEC

   Email: dirk.kutscher@neclab.eu


   Y. Richard Yang
   Yale University

   Email: yry@cs.yale.edu









































Alimi, et al.          Expires September 13, 2012              [Page 37]


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