[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-decade-arch

DECADE                                                          R. Alimi
Internet-Draft                                                    Google
Intended status: Informational                                   Y. Yang
Expires: April 21, 2011                                  Yale University
                                                               A. Rahman
                                        InterDigital Communications, LLC
                                                             D. Kutscher
                                                 NEC Laboratories Europe
                                                                 L. Chen
                                                                  H. Liu
                                                         Yale University
                                                        October 18, 2010


                          DECADE Architecture
                       draft-alimi-decade-arch-00

Abstract

   Peer-to-peer (P2P) applications have become widely used on the
   Internet today and make up a large portion of the traffic in many
   networks.  In P2P applications, one technique for reducing the total
   amount of P2P traffic is to introduce storage capabilities within the
   network.  The DECADE Working Group has been formed with the goal of
   developing an architecture to provide this capability.  This
   documents presents an architecture, discusses the underlying
   principles and identifies core components and protocols supporting
   the architecture.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at



Alimi, et al.            Expires April 21, 2011                 [Page 1]


Internet-Draft             DECADE Architecture              October 2010


   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 21, 2011.

Copyright Notice

   Copyright (c) 2010 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 BSD License.

































Alimi, et al.            Expires April 21, 2011                 [Page 2]


Internet-Draft             DECADE Architecture              October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Entities . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  DECADE Storage Servers . . . . . . . . . . . . . . . . . .  5
     2.2.  DECADE Storage Provider  . . . . . . . . . . . . . . . . .  5
     2.3.  Content Distribution Application . . . . . . . . . . . . .  5
     2.4.  DECADE Content Providers . . . . . . . . . . . . . . . . .  5
     2.5.  DECADE Content Consumers . . . . . . . . . . . . . . . . .  5
     2.6.  End-Point  . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Architectural Principles . . . . . . . . . . . . . . . . . . .  6
     3.1.  Decoupled Control and Data Planes  . . . . . . . . . . . .  6
     3.2.  Immutable Data Objects . . . . . . . . . . . . . . . . . .  7
     3.3.  Accessing Data Objects . . . . . . . . . . . . . . . . . .  8
     3.4.  Data Object Identifiers  . . . . . . . . . . . . . . . . .  8
     3.5.  Explicit Control . . . . . . . . . . . . . . . . . . . . .  8
     3.6.  Resource and Data Access Control through User
           Delegation . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.6.1.  Resource Allocation  . . . . . . . . . . . . . . . . .  9
       3.6.2.  User Delegations . . . . . . . . . . . . . . . . . . .  9
   4.  System Components  . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Reference Architecture . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

























Alimi, et al.            Expires April 21, 2011                 [Page 3]


Internet-Draft             DECADE Architecture              October 2010


1.  Introduction

   Peer-to-peer (P2P) applications have become widely used on the
   Internet today to distribute contents, and they contribute a large
   portion of the traffic in many networks.  The DECADE Working Group
   has been formed with the goal of developing an architecture to
   introduce in-network storage to be used by such applications, to
   achieve more efficient content distribution.  Specifically, in many
   subscriber networks, it is typically more 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 and CMTSs.  Thus, it can be
   cheaper to upgrade core infrastructure involving 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 discussion of the capabilities to be
   provided by DECADE.

   This document presents a potential architecture of 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.  In particular, content
   distribution applications that may split data into smaller pieces for
   distribution may be able to utilize DECADE.

   The design philosophy of the DECADE architecture is to provide only
   the core functionality that is needed for applications to make use of
   in-network storage.  With such core functionality, the protocol may
   be simple and easier to support by storage providers.  If more
   complex functionality is needed by a certain application or class of
   applications, it may be layered on top of the DECADE protocol.

   The DECADE protocol will leverage existing transport and application
   layer protocols and will be designed to work with a small set of
   alternative IETF protocols.

   This document proceeds in two steps.  First, it details the core
   architectural principles that can guide the DECADE design.  Next,
   given these core principles, this document presents the core
   components of the DECADE architecture and identifies usage of
   existing protocols and where there is a need for new protocol
   development.

   This document will be updated to track the progress of the DECADE
   survey [I-D.ietf-decade-survey] and requirements [I-D.gu-decade-reqs]
   drafts.




Alimi, et al.            Expires April 21, 2011                 [Page 4]


Internet-Draft             DECADE Architecture              October 2010


2.  Entities

2.1.  DECADE Storage Servers

   DECADE storage servers are operated by DECADE storage providers and
   provide the DECADE functionality as specified in this memo, including
   mechanisms to store, retrieve and manage data.  A storage provider
   will typically operate many storage servers.

2.2.  DECADE Storage Provider

   A DECADE in-storage provider deploys and/or manages DECADE servers
   within a network.  Storage providers may also own or manage the
   network in which the DECADE servers are deployed.

   A 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.3.  Content Distribution Application

   A content distribution application is developed by an Application
   Developer and installed on end-hosts.  End-hosts may be machines
   managed by the Application Developer itself, a Content Provider, or
   an End-User.

2.4.  DECADE Content Providers

   DECADE content providers access DECADE storage servers (by way of a
   DECADE client) to upload and manage data in the context of an context
   distribution application.  A content provider can access one or more
   storage servers.  A content provider may be a single process or a
   distributed application (in a P2P scenario).

2.5.  DECADE Content Consumers

   DECADE content consumers access storage servers (by way of a DECADE
   client) to download data that has previously been stored by a content
   provider in the context of a content distribution application.  A
   content consumer can access one more storage servers.  A content
   consumer may be a single process or a distributed application (in a
   P2P scenario).  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 April 21, 2011                 [Page 5]


Internet-Draft             DECADE Architecture              October 2010


2.6.  End-Point

   An End-Point is an instance of a Content Distribution Application
   that includes a DECADE client.  A particular End-Point may be a
   DECADE Content Provider, DECADE Content Consumer, or both.

   An End-Point need not be an active member of a "swarm" to interact
   with the DECADE storage system.  That is, an End-Point may interact
   with the DECADE storage servers as an offline activity.


3.  Architectural Principles

   We identify the following key principles.

3.1.  Decoupled Control and Data Planes

   The DECADE infrastructure is intended to support multiple content
   distribution applications.  A complete content distribution
   application implements of a set of control functions including
   content search, indexing and collection, access control, ad
   insertion, replication, request routing, and QoS scheduling.
   Different content distribution applications can have unique
   considerations designing the control and signaling functions.  For
   example, a major competitive advantage of many successful P2P systems
   is their substantial expertise in how to most efficiently utilize
   peer and infrastructural resources.  Many live P2P systems have their
   specific algorithms in selecting the peers that behave as the more
   stable, higher-bandwidth sources.  They continue to fine-tune such
   algorithms.  In other words, in-network storage should export basic
   mechanisms and allow as much flexibility as possible to the control
   planes to implement specific policies.  This conforms to the end-to-
   end systems principle and allows innovation and satisfaction of
   specific business goals.

   Specifically, in the DECADE architecture, the control plane focuses
   on the application-specific, complex, and/or processing intensive
   functions while the data plane provides storage and data transport
   functions.

   o  Control plane: Signals on which data are downloaded to whom, from
      where, at what time, and with what quality-of-service (e.g.,
      bandwidth).  It also provides higher layer meta-data management
      functions such as defining the sequence of data blocks forming a
      higher layer content object.  These are behaviors designed and
      implemented by the Application.





Alimi, et al.            Expires April 21, 2011                 [Page 6]


Internet-Draft             DECADE Architecture              October 2010


   o  Data plane: Stores and transfers data as instructed by the
      Application's Control Plane.

   Decoupling control plane and data plane is not new.  For example,
   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 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 (i.e., read and write of chunks of data).  NFS4 also implements
   this principle.

   Note that applications may have different Data Plane implementations
   in order to support particular requirements (e.g., low latency).  In
   order to provide interoperability, the DECADE architecture does not
   intend to enable arbitrary data transport protocols between DECADE
   servers.  However, the architecture should allow for multiple data
   transport protocols to be used.

   Also note that although an application's existing control plane
   functions remain implemented within the application, the particular
   implementation may need to be adjusted to support DECADE.

3.2.  Immutable Data Objects

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

   Many content distribution applications divide content objects into
   blocks for two reasons: (1) different blocks may be fetched from
   different content sources in parallel, and (2) individual blocks may
   be recovered from an alternate content source.  Typically,
   applications use a block size larger than a single packet in order to
   reduce control overhead.

   Common applications whose content matches this model include P2P
   streaming (live and video-on-demand) and P2P file-sharing content.
   However, other types of applications may additionally match this
   model.

   DECADE adopts a design in which immutable data objects may be stored
   at a storage server.  Applications may consider existing blocks as
   DECADE data objects, or or they may adjust block sizes before storing
   in a DECADE server.

   Focusing on immutable data blocks in the data plane can substantially



Alimi, et al.            Expires April 21, 2011                 [Page 7]


Internet-Draft             DECADE Architecture              October 2010


   simplify the data plane design, since consistency requirements can be
   relaxed.  It also allows effective reuse of data blocks and de-
   duplication of redundant data.

   Note that immutable content may still be deleted.  If applications
   require particular content to be modified, one possibility is to
   delete (or revoke access to) the existing content and then distribute
   a different version.

3.3.  Accessing Data Objects

   The DECADE data access protocol allows clients to store and retrieve
   data fragments ("data objects") of arbitrary size.  The DECADE
   architecture is agnostic to application-specific framing conventions,
   unfiform fragment lengths etc.

3.4.  Data Object Identifiers

   Objects that are stored in a DECADE storage server can be accessed by
   DECADE content consumers by a resource identifiers that has been
   assigned within a certain application context.

   Because a DECADE content consumer can access more than one storage
   server within a single application context, a data object that is
   replicated across different storage servers managed by a DECADE
   storage provider, can be accessed by a single identifier.

3.5.  Explicit Control

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

   Consider deletion/expiration policy as a simple example.
   Applications may require a DECADE server to store content for a
   relatively short period of time (e.g. for live-streaming data) or may
   need to store content long term (e.g., for video-on-demand).

3.6.  Resource and Data Access Control through User Delegation

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





Alimi, et al.            Expires April 21, 2011                 [Page 8]


Internet-Draft             DECADE Architecture              October 2010


3.6.1.  Resource Allocation

   There are two primary interacting entities in the DECADE
   architecture.  First, Storage Providers control where DECADE storage
   servers are provisioned and their total available resources.  Second,
   Applications executing on end-points control data transfers amongst
   available DECADE servers and between DECADE servers and end-points.
   A form of isolation is required to enable concurrently-running
   Applications to each explicitly manage their own content and share of
   resources at the available servers.

   Management of the resources at a server are delegated by a Storage
   Provider to one or more applications.  Applications are able to
   explicitly and independently manage their own share of resources.

3.6.2.  User Delegations

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

   To provide a scalable way to manage applications granted resources at
   a DECADE server, a layer of indirection is added.  Instead of
   granting resources to an application, the DECADE 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.

   A User Delegation may be granted to an end-user (e.g., an ISP
   subscriber), a Content Provider, or an Application Provider.  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 Provider.


4.  System Components

   The current version of the document has primarily focused on the
   architectural principles.  The detailed system components will be
   discussed in the next document revision.




Alimi, et al.            Expires April 21, 2011                 [Page 9]


Internet-Draft             DECADE Architecture              October 2010


5.  Reference Architecture

   The current version of the document has primarily focused on the
   architectural principles.  The detailed reference architecture will
   be discussed in the next document revision.


6.  Security Considerations

   This document currently does not contain any security considerations
   beyond those mentioned in [I-D.ietf-decade-problem-statement].


7.  IANA Considerations

   This document does not have any IANA considerations.


8.  Informative References

   [I-D.ietf-decade-problem-statement]
              Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled
              Application Data Enroute (DECADE) Problem Statement",
              draft-ietf-decade-problem-statement-00 (work in progress),
              August 2010.

   [I-D.ietf-decade-survey]
              Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
              network Storage Systems", draft-ietf-decade-survey-00
              (work in progress), September 2010.

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


Authors' Addresses

   Richard Alimi
   Google

   Email: ralimi@google.com








Alimi, et al.            Expires April 21, 2011                [Page 10]


Internet-Draft             DECADE Architecture              October 2010


   Y. Richard Yang
   Yale University

   Email: yry@cs.yale.edu


   Akbar Rahman
   InterDigital Communications, LLC

   Email: akbar.rahman@interdigital.com


   Dirk Kutscher
   NEC Laboratories Europe

   Email: dirk.kutscher@neclab.eu


   Lijiang Chen
   Yale University

   Email: lijiang.chen@yale.edu


   Hongqiang Liu
   Yale University

   Email: hongqiang.liu@yale.edu























Alimi, et al.            Expires April 21, 2011                [Page 11]


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