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", . [OpenFlow] "OpenFlow Organization", . [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]