RFC 7069
DECoupled Application Data Enroute (DECADE)
Abstract ✨
okay bestie, let's start with the vibe check 💖 Content distribution apps like P2P are everywhere on the Internet, and they make up a huge chunk of traffic in a lot of networks. The problem is they often use network resources inefficiently 😭 One way to fix that is to put storage inside the network and let end-host and in-network content distribution mechanisms work together. That's what a DECoupled Application Data Enroute (DECADE) system does, and this document introduces it 🦋 DECADE lets apps use in-network storage when they distribute data objects, instead of relying only on end-to-end resources. The doc covers the core principles and key functionalities, then walks through a set of examples so it all clicks 🧚
Status of This Memo 🌸
this one is not an Internet Standards Track spec, it's just published for information 💅
this is an independent contribution to the RFC Series, separate from any other RFC stream. the RFC Editor chose to publish it at their discretion and makes no statement about how valuable it is for implementation or deployment. documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard, see RFC 5741 Section 2 for that 🙈
info about the current status, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7069 🍓
Copyright Notice 🌈
Copyright (c) 2013 IETF Trust and the people listed as document authors. All rights reserved 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. read them carefully, because they spell out your rights and restrictions for this document 🫶
Table of Contents 🎀
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Architectural Principles . . . . . . . . . . . . . . . . . . 8
4.1. Data- and Control-Plane Decoupling . . . . . . . . . . . 8
4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . 9
4.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 10
4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . 11
4.5. Resource and Data Access Control through Delegation . . . 11
5. System Components . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Application Endpoint . . . . . . . . . . . . . . . . . . 13
5.2. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 14
5.3. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Data Sequencing and Naming . . . . . . . . . . . . . . . 15
5.5. Token-Based Authorization and Resource Control . . . . . 17
5.6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 18
6. DECADE Protocol Considerations . . . . . . . . . . . . . . . 19
6.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Resource Protocol . . . . . . . . . . . . . . . . . . . . 19
6.3. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 22
6.4. Server-Server Protocols . . . . . . . . . . . . . . . . . 23
6.5. Potential DRP/SDT Candidates . . . . . . . . . . . . . . 23
7. How In-Network Storage Components Map to DECADE . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8.1. Threat: System Denial-of-Service Attacks . . . . . . . . 25
8.2. Threat: Authorization Mechanisms Compromised . . . . . . 25
8.3. Threat: Spoofing of Data Objects . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Evaluation of Candidate Protocols for DECADE DRP/SDT 29
A.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. CDMI . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 34Title Block 🔥
okay so here's the lowdown on who made this and what it is 👑 RFC 7069, titled DECoupled Application Data Enroute (DECADE), came out in November 2013 as an Independent Submission with the category Informational and ISSN 2070-1721 ✨ The authors are R. Alimi (Google), A. Rahman (InterDigital Communications, LLC), D. Kutscher (NEC), Y. Yang (Yale University), H. Song (Huawei Technologies), and K. Pentikousis (EICT) 🫶 The title block doesn't list any RFC that this one obsoletes or updates, so it's standing on its own 💅
1. Introduction 💖
okay so content distribution apps, like peer-to-peer (P2P) apps, are everywhere on the Internet. they're used to distribute data objects, and they make up a massive share of traffic in lots of networks 😭 These apps can really create bottlenecks, even in networks that are otherwise well provisioned. sometimes operators have to spend big money on infrastructure just to handle them 💀 For example, in a lot of subscriber networks, upgrading equipment in the "last mile" is expensive, because it can mean replacing gear and upgrading wiring and devices at individual homes, businesses, DSLAMs (Digital Subscriber Line Access Multiplexers), and CMTSs (Cable Modem Termination Systems) in remote locations. it can be more practical and economical to upgrade the core infrastructure instead, since that involves fewer components shared by lots of subscribers 🧚 For a fuller look at the problem space and the capabilities a DECADE system is meant to have, check out [RFC6646] and [RFC6392]. As a historical note, those two came out of the now closed DECADE Working Group, and this doc is here to carry forward some of the valuable concepts from that group 🌸
this document presents mechanisms for in-network storage that can be built into content distribution applications 🦋 The main focus is P2P-based content distribution, but DECADE might also be useful for other apps with similar characteristics and requirements, like Content Distribution Networks (CDNs) or hybrid P2P/CDNs 🌈 The approach here is to define the core functionalities and protocol functions needed to support a DECADE system. there are illustrative examples so implementers can get the main concepts, but it's generally assumed that readers already know the terms and concepts from [RFC6646] and [RFC6392] 💜
1.1. 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] 🙈
2. Terminology 🍓
this doc uses the following terminology, so let's get the definitions straight 🧚
Application Endpoint A host that includes a DECADE client along with other application functionalities (e.g., peer-to-peer (P2P) client, video streaming client). 💅
Content Distribution Application A specific type of application that may exist in an Application Endpoint. it's an application (e.g., P2P) designed to spread large amounts of content (e.g., files or video streams) to multiple peers. Content distribution applications may divide content into smaller blocks for dissemination. 🔥
Data Object A data object is the unit of data stored and retrieved from a DECADE server. It's a sequence of raw bytes. The server maintains metadata for each data object, but that metadata is physically and logically separate from the data object 🫶
DECADE Client A DECADE client uploads and/or retrieves data from a DECADE server 🦋
DECADE Resource Protocol (DRP) A logical protocol for communicating access control and resource-scheduling policies from a DECADE client to a DECADE server, or between DECADE servers. In practice, the DRP's functionality may be spread across one or more actual protocols 🌈
DECADE Server A DECADE server stores data inside the network for a DECADE client or another DECADE server. After that, it manages both the stored data and access to that data by other DECADE clients 👑
DECADE Storage Provider A DECADE storage provider deploys and/or manages DECADE servers within a network 🌸
DECADE System An in-network storage system made up of DECADE clients and DECADE servers. The DECADE servers may be deployed by one or more DECADE storage providers 💖
In-Network Storage A service inside a network that provides storage to applications. In-network storage may reduce upload/transit/backbone traffic and improve application performance. It may, for example, be co-located with the border router (network-attached storage) or inside a data center. A DECADE system is an example of an in-network storage system ✨
Standard Data Transfer (SDT) Protocol A logical protocol used to transfer data objects between a DECADE client and DECADE server, or between DECADE servers. The intent is that in practice the SDT should map to an existing, well-known protocol already in use over the Internet for transporting data 🎀
part 1 of 7 done bestie 💖 there's way more DECADE goodness coming, so stay tuned 🧚
3. Overview ✨
Okay bestie, so a DECADE system is a distributed storage service built for content distribution apps (P2P is the big one 🍓). It's made of clients and servers. A client first uploads data objects to one or more chosen servers, and it can optionally ask for those objects to be distributed to other servers too 🦋. Then the client picks which other clients are allowed to download them 💅. The whole thing lives inside a bigger application (like P2P file sharing), and DECADE clients are expected to join the application's own communication sessions 🫶.
Figure 1 is a simple picture of a DECADE system with two DECADE clients and two DECADE servers 🌸. As you can see, a DECADE client lives inside an Application Endpoint, and it uses the DECADE Resource Protocol (DRP) to tell a server about access control and resource-scheduling policies 🔥. Servers can also use DRP to swap that same kind of info with each other 👑. To move data objects to and from a server, a DECADE system uses the Standard Data Transfer (SDT) protocol, and we'll get into how that works later 🧚.
Native Application
Protocol(s)
.-------------. (e.g., P2P) .-------------.
| Application | <------------------> | Application |
| Endpoint | | Endpoint |
| | | |
| .--------. | | .--------. |
| | 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: DECADE OverviewNow, picture this with Figure 1 in mind 🎀. Application Endpoint B wants a data object from Application Endpoint A, and they talk using their native app protocols (like a P2P protocol), as shown in Figure 2 🦋. In this situation, Endpoint A is the sender and Endpoint B is the receiver for that object. S(A) is the DECADE storage server, and it's access controlled, which means two things 👀. First, Endpoint A has to be allowed to store the data object in S(A). Second, Endpoint B needs to get authorization before it can pull the data object down from S(A) 🔒.
The DECADE session has four steps, all shown in Figure 2 💜. It kicks off with the first contact between Endpoint B and Endpoint A, where B asks for a data object using its native app protocol (like P2P) 🍓. Next, Endpoint A uses DRP to get a token that matches the object B asked for ✨. There are a few ways A can get that token. It can compute it locally, or it can ask its DECADE storage server, S(A), for one 🧚. Once A has the token, it hands it over to Endpoint B, again through the native application protocol 💅. Last step: Endpoint B gives the token to S(A) via DRP, and then it requests and downloads the data object via SDT 🎉. Just like before, DECADE is running inside a bigger application context, like a P2P file-sharing session 🫶.
There's one more important step that isn't drawn in Figure 2, so don't forget it 🙈. Before any of this happens, Endpoint A has to discover the data object(s) it cares about and store them in S(A) first 🌈.
.----------.
2. Obtain --------> | S(A) | <------
Token / `----------' \ 4. Request and
(DRP) / \ Download
Locally / \ Data Object
or From / \ (DRP + SDT)
S(A) v 1. App Request v
.-------------. <--------------------------- .-------------.
| Application | | Application |
| Endpoint A | | Endpoint B |
`-------------' ---------------------------> `-------------'
3. App Response (token)
Figure 2: Download from Storage Server4. Architectural Principles 🌟
Here are the key principles that every DECADE system follows 💖.
4.1. Data- and Control-Plane Decoupling
Okay so DECADE SDT and DRP count as data-plane stuff 📦. The algorithms and signaling for something like a P2P app would be control-plane stuff 🧠.
A DECADE system is meant to be application independent, and it should support lots of different content distribution apps 🌈. A full content distribution app usually has a bunch of control-plane functions: content search, indexing and collection, access control, replication, request routing, and QoS scheduling 💅. Different app builders might have their own special considerations when they design those control-plane functions 🦋. Metadata management is a good example 📂. Traditional file systems use a standard metadata abstraction, which is a recursive structure of directories for namespace management, where each file is an opaque byte stream 🗂️. But content distribution apps can use totally different metadata schemes. One app might use a sequence of blocks (like for file sharing), while another might use a sequence of frames, with different sizes, indexed by time 🎬.
Now resource scheduling. A big reason many successful P2P systems work so well is that they're really good at using peer resources efficiently 🔥. Many streaming P2P systems, for instance, have optimization algorithms for building overlay topologies that can handle low-latency, high-bandwidth streaming ⚡. Researchers and implementers keep fine-tuning these algorithms and inventing new ones 🤓. A DECADE system should be able to fit in and benefit from all of those new developments 🫶.
So bottom line, with so many control-plane functions out there, a DECADE system should give the control plane as much flexibility as possible to implement its own policies, and it should stay decoupled from the data-plane DRP/SDT 👑. Decoupling control from data isn't new, obviously 😌. OpenFlow [OpenFlow] does it for Internet routing, where computing the forwarding table and applying the forwarding table are kept separate 🛣️. The Google File System [GoogleFileSystem] uses the same idea for file systems, with a Master handling metadata management and several Chunk servers handling the data-plane work (reading and writing chunks of data) 🗄️. And NFSv4.1's parallel NFS (pNFS) extension [RFC5661] follows this principle too 💜.
4.2. Immutable Data Objects
Here's the vibe: most bulk content that gets widely distributed is immutable 🧊. Once it's made, it usually doesn't change 🎞️. Once a movie is edited and released, the video frames and images almost never need to be modified 🎥. Same goes for document distribution, like RFCs; audio files, like podcasts; and program patches 🩹. Focusing on immutable data makes the data plane way simpler, because consistency requirements can be relaxed 😎. It also makes reusing data and removing duplicates easier 🧹.
Depending on what it needs, an app might store immutable data objects on DECADE servers in a way where each object is completely self-contained, like a complete, independently decodable video segment 🎬. An app can also split its data into data objects that need to be put back together at the application level 🧩. A lot of content distribution apps chop bulk content into data objects for a few reasons 💅. First, they can fetch different data objects from different sources in parallel. Second, recovery and verification are faster, since individual data objects can be recovered and verified on their own 🚀. Usually apps use a data object size bigger than a single packet, because that cuts down on control overhead 📉.
A DECADE system doesn't care what kind of data the objects hold, and it doesn't set a fixed size for them 🤷♀️. A protocol spec built on this architecture can set requirements on minimum and maximum sizes for compliant implementations 📏.
Also, immutable data objects can still get deleted 🗑️. Apps can still support changing existing data stored on a DECADE server by storing new data objects and deleting the old ones 🔄. For example, a metadata management function in the control plane might link a name to a sequence of immutable data objects 🏷️. If one of those data objects gets modified, the metadata management function just changes the name's mapping to a new sequence of immutable data objects 🦋.
4.3. Data Object Identifiers 🎀
okay bestie, so a data object stored on a DECADE server gets accessed by DECADE clients through a data object identifier 💖 Each DECADE client may be able to reach more than one storage server. A data object that is replicated across different storage servers managed by a storage provider may be accessed through a single identifier ✨ Since data objects are immutable, it shall be possible to support persistent identifiers for data objects. That's the dream 🦋
Data object identifiers should be created by DECADE clients when they upload the matching objects to a DECADE server. How the identifier gets assigned or derived depends on the data object naming scheme, and that's out of scope for this doc 🧚 One possibility is to name data objects using hashes as described in [RFC6920]. Note that [RFC6920] describes naming schemes on a semantic level only, but specific SDTs and DRPs use specific representations 🤓
In particular, for some applications it's important that clients and servers can validate the name-object binding, i.e., verify that a received object really corresponds to the name (identifier) that was used to request it (or that was provided by a sender) 👀 If a specific application requires name-object binding validation, the data object identifiers can support it by providing message digests or so-called self-certifying naming information 🔐
Different name-object binding validation mechanisms may be supported in a single DECADE system 🌈 Content distribution applications can decide which mechanism to use, or choose not to provide name-object validation at all (e.g., if authenticity and integrity can be ascertained by alternative means) 💅 We expect that applications may be able to construct unique names (with high probability) without needing a registry or other forms of coordination. Names may be self-describing, so that a receiving DECADE client understands, for example, which hash function to use for validating name-object binding ⭐
Some content distribution applications will derive the name of a data object from the hash over the data object, and this is made possible by the fact that DECADE objects are immutable 🍓 But there may be other applications, such as live streaming, where object names won't be based on hashes and will instead rely on an enumeration scheme. The naming scheme will also let those applications construct unique names 💜
To get uniqueness, flexibility and self-describing properties, the naming scheme used in a DECADE system should provide a "type" field that indicates the name-object validation function type (for example, "sha-256" [RFC5754]) and the cryptographic data (such as an object hash) that corresponds to that type information. Moreover, the naming scheme may additionally provide application or publisher information 🫶
4.4. Explicit Control 🎛️
To support the functions of an application's control plane, applications should be able to keep track of and coordinate which data is stored at particular servers. So, unlike traditional caches, applications get explicit control over the placement (selection of a DECADE server), deletion (or expiration policy), and access control for stored data objects 👑 Deletion/expiration policy is a simple example. An application might require that a DECADE server store data objects for a relatively short period of time (e.g., for live-streaming data). Another application might need to store data objects for a longer duration (e.g., for video on demand), and so on 🎬
4.5. Resource and Data Access Control through Delegation 🤝
A DECADE system provides a shared infrastructure that multiple Application Endpoints use, so it needs to provide both resource and data access control, as discussed in the following subsections. It's giving teamwork 💖
4.5.1. Resource Allocation 🍰
There are two primary interacting entities in a DECADE system. First, storage providers coordinate DECADE server provisioning, including their total available resources. Second, applications coordinate data transfers among the available DECADE servers and between servers and clients. A form of isolation is required so that each of the concurrently running applications can explicitly manage its own data objects and its share of resources at the available servers 🛡️ Therefore, a storage provider should delegate resource management on a DECADE server to uploading DECADE clients, enabling them to explicitly and independently manage their own share of resources on a server. Main character energy for each client 🦋
4.5.2. User Delegation 🧁
DECADE storage providers will have the ability to explicitly manage the entities allowed to use the resources available on a DECADE server. This is needed for reasons such as capacity planning and legal considerations in certain deployment scenarios 📊 The DECADE server should grant a share of the resources to a DECADE client. The client can, in turn, share the granted resources among its (possibly) multiple applications. The share of resources granted by a server is called a User Delegation ✨ As a simple example, a DECADE server operated by an ISP might be configured to grant each ISP subscriber 1.5 Mbit/s of network capacity and 1 GB of memory. The ISP subscriber might then divide this share among a video-streaming application and a file-sharing application running at the same time 📺📁
5. System Components 🧩
As noted earlier, the primary focus of this document is the architectural principles and the system components that implement them. Specific system components might differ between implementations, but this document details the major components and their overall roles in the architecture. To keep the scope narrow, we only discuss the primary components related to protocol development. Particular deployments will require additional components (e.g., monitoring and accounting at a server), but those are intentionally left out of this document 🙈
5.1. Application Endpoint 📱
Content distribution applications have many functional components. For example, many P2P applications have components and algorithms to manage overlay topology, rate allocation, piece selection, and so on. In this document, we focus on the components directly engaged in a DECADE system. Figure 3 illustrates the components discussed in this section from the perspective of a single Application Endpoint 👀
Native Application Protocol(s)
(with other Application Endpoints)
.--------------------->
|
V
.----------------------------------------------------------------.
| Application Endpoint |
| .-------------------. .-------------------. |
| | Application-Layer | ... | App Data Assembly | |
| | Algorithms | | Sequencing | |
| `-------------------' `-------------------' |
| |
| .==========================================================. |
| | DECADE Client | |
| | .-------------------------. .--------------------------. | |
| | | Resource Controller | | Data Controller | | |
| | | .--------. .----------. | | .------------. .-------. | | |
| | | | Data | | Resource-| | | | Data | | Data | | | |
| | | | Access | | Sharing | | | | Scheduling | | Index | | | |
| | | | Policy | | Policy | | | | | | | | | |
| | | `--------' `----------' | | `------------' `-------' | | |
| | `-------------------------' `--------------------------' | |
| | | ^ | |
| `== | ============================== | ====================' |
`----- | ------------------------------ | -----------------------'
| |
| DECADE Resource Protocol | Standard Data Transfer
| (DRP) | (SDT)
v V
Figure 3: Application and DECADE Client ComponentsA DECADE system is geared toward supporting applications that distribute content using data objects (e.g., P2P) 🍿 To make that happen, applications can include a component that creates the individual data objects before distribution and reassembles them later. We call this component Application Data Assembly 🧃 When producing and assembling data objects, two important considerations are sequencing and naming. A DECADE system assumes that applications implement this functionality themselves. Besides DECADE DRP/SDT, applications will most likely also support other, native application protocols (e.g., P2P control and data transfer protocols) 🫧
5.2. DECADE Client 💻
The DECADE client provides the local support for an application. It can be implemented standalone, embedded into the application, or integrated into other software entities within network devices (i.e., hosts) 🌸 In general, applications may have different resource-sharing policies and data access policies with regard to DECADE servers. These policies may be existing application policies or custom policies. The specific implementation is up to the application 💅
Recall that DECADE decouples the control and the data transfer of applications 🔥 A data-scheduling component schedules data transfers according to network conditions, available servers, and/or available server resources. The Data Index shows what data is available at remote servers. The Data Index (or a subset of it) can be advertised to other clients. A common use case for this is locating data among distributed Application Endpoints (i.e., a data search mechanism such as a Distributed Hash Table (DHT)) 🔍
5.3. DECADE Server ✨
okay so figure 4 shows the main pieces of a DECADE server 🖥️ bestie, this description is NOT assuming it's one single machine in a closet. a DECADE server isn't necessarily one physical box, it can also be spread across a whole cluster of machines 💜
| DECADE Resource | Standard Data
| Protocol (DRP) | Transfer (SDT)
| |
.= | ================= | ===========================.
| | v DECADE Server |
| | .----------------. |
| |----> | Access Control | <--------. |
| | `----------------' | |
| | ^ | |
| | | | |
| | v | |
| | .---------------------. | |
| `-> | Resource Scheduling | <------| |
| `---------------------' | |
| ^ | |
| | | |
| v .-----------------. |
| .-----------------. | User Delegation | |
| | Data Store | | Management | |
| `-----------------' `-----------------' |
`==================================================='
Figure 4: DECADE Server Componentsso the vibe is: given the right authorization, a client shall be able to access its own data or other clients' data on a DECADE server 🔑 clients can also authorize other clients to store data for them 🫶 and if a client authorizes access, the server should provide it 💅 apps can apply resource-sharing policies or bring a custom one ✨ then DECADE servers do the resource scheduling according to those resource-sharing policies the client set up, plus any User Delegations that were configured before 🎀 data from apps gets stored on the DECADE server, and data can be deleted either explicitly or automatically (like after a Time To Live (TTL) expires) 🧚
5.4. Data Sequencing and Naming 🦋
the DECADE naming scheme implies no sequencing or grouping of objects, even if the app does that at the application layer 💖 to show what this looks like, here are a few examples 👀
5.4.1. Application with Fixed-Size Chunks 🍓
picture an app where each little piece of application-layer data is called a "chunk" and gets a name shaped like CONTENT_ID:SEQUENCE_NUMBER 📦 say the app's native protocol uses 16 KB chunks, but it wants to store stuff on a DECADE server in 64 KB data objects 🤔 no problem, it can map a sequence of 4 chunks into one data object, like this:
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 Objectsin this example the app keeps a logical mapping that can work out the name of a DECADE data object from the chunks inside it 🧠 that name could come from the original uploading DECADE client, from another Endpoint the app is talking to, or from somewhere else 🌸 and as long as the data in each sequence of chunks is globally unique, the data objects end up with globally unique names too 💜
5.4.2. Application with Continuous Streaming Data 🎬
now imagine an app whose native protocol pulls in a continuous data stream (like an MPEG2 stream) rather than downloading and passing around chunks 📺 that app could chop the stream up into either fixed-size or variable-size data objects ✂️ figure 6 shows how a video streaming app might make variable-size objects where each one holds 10 seconds of video 🍿 same vibe as the last example: the app can keep a mapping that works out the name of a data object from the time offset of the video chunk ⏱️
Application's Video Stream
.--------------------------------------------------------------------
|
|
|
`--------------------------------------------------------------------
^ ^ ^ ^ ^
| | | | |
0 seconds 10 seconds 20 seconds 30 seconds 40 seconds
0 B 400 KB 900 KB 1200 KB 1500 KB
DECADE Data Objects
.--------------.--------------.--------------.--------------.--------
| | | | |
| Object_0 | Object_1 | Object_2 | Object_3 |
| (400 KB) | (500 KB) | (300 KB) | (300 KB) |
`--------------`--------------`--------------`--------------`--------
Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects5.5. Token-Based Authorization and Resource Control 🎟️
a key feature of a DECADE system is that an Application Endpoint can authorize other Application Endpoints to store or retrieve data objects in its in-network storage using tokens 🔐 the peer client then uses that token when it sends requests to the DECADE server, and when the server gets a token it checks the signature and the operation being performed 🧾
yes it's a simple scheme, but it's got some seriously iconic advantages over the other option, where a client directly edits an Access Control List (ACL) attached to each data object 💅 first, the authorization policies live inside the application, so the Application Endpoint is the one that decides when tokens get generated, who they go to, and how long they stay valid 👑 second, you can apply fine-grained access and resource control to data objects 🔍 third, there's no messaging between client and server just to change data object permissions 🙌 that's a huge win for apps sharing data objects with lots of dynamic peers that need to keep adjusting access control policies all the time 🔄 and finally, tokens can give anonymous access, meaning the server doesn't need to know who each client is 🫥 this lets a client send tokens to clients from other storage providers so they can read or write data objects in the storage of the client's own provider 🌈 on top of clients applying their own access control policies to data objects, the server can also be set up to apply extra policies based on user, object properties, geographic location, and so on 🌍 which means a client might get denied even though it has a valid token 💀
5.6. Discovery 🔭
a DECADE system should include a discovery mechanism so DECADE clients can find a suitable DECADE server 🗺️ the discovery mechanism should let a client work out an IP address or some other identifier that can be resolved to locate the server it's authorized to generate tokens for (via DRP) 🎯 (it might also just return an error if no such servers can be found 🙈) after discovering one or more servers, a DECADE client can spread its load and requests across them (subject to the resource limitations and policies of the servers themselves) based on the policies of the Application Endpoint it's embedded in 💖 heads up though: this discovery mechanism does NOT let you find arbitrary DECADE servers that you could get tokens from other people for 🚫 doing that needs application-level knowledge, and it's assumed the content distribution application handles that part 🫶
as mentioned above, the discovered DECADE server should be authorized to let the client store data objects, and then generate tokens so other clients can retrieve those data objects 🎁 that authorization may be:
- a result of off-line administrative procedures;
- access network dependent (e.g., all the subscribers to a particular ISP may be allowed by the ISP);
- due to a prior subscription;
- etc.
the particular discovery protocol is out of scope for this document 🙅♀️ but any spec for it should reuse well-known protocols wherever possible 🧚♀️✨
6. DECADE Protocol Considerations 💜
this section introduces the DRP and the SDT protocol in terms of abstract protocol interactions, meant to be mapped onto specific protocols in an implementation 🧩 generally, the DRP/SDT functionality for DECADE client-server interaction is super similar to the server-server version, and any differences get called out below 👀 DRP is what a DECADE client uses to configure the resources and authorization that handle requests (reading, writing, and management operations on data objects) at a server 🛠️ SDT is what transports data between a client and a server, as shown in Figure 1 🚚
6.1. Naming 🏷️
a DECADE system SHOULD use [RFC6920] as the recommended and default naming scheme ✨ other naming schemes that meet the guidelines in Section 4.3 MAY be used instead 🌈 to keep the interface simple and generic, the DECADE server is only responsible for storing and retrieving individual data objects 📦
the DECADE naming format SHOULD NOT try to replace any naming or sequencing of data objects an application has already done 🙅♀️ naming is meant to apply only to data objects that DECADE-specific purposes refer to 💅 an application using a DECADE client can keep its own naming and sequencing scheme, totally independent of DECADE names 🦋 and the DECADE client SHOULD maintain a mapping from its own data objects and their names to the DECADE-specific data objects and names 🗂️ again, the DECADE naming scheme implies no sequencing or grouping of objects, even if the application does that at the application layer 💖
6.2. Resource Protocol 🎀
DRP is where you configure access control and resource-sharing policies on DECADE servers 🔧 a content distribution application (like a live P2P streaming session) can have permission to manage data on several servers, for example servers belonging to different storage providers 🌍 DRP lets one instance of that application, i.e., an Application Endpoint, apply access control and resource-sharing policies on each of them 👑
on a single DECADE server, the following resources SHOULD be managed: a) communication resources in terms of bandwidth (upload/download) and also in terms of number of active clients (simultaneous connections); and b) storage resources 📊🔥
6.2.1. Access and Resource Control Token 🎫
okay bestie, so the tokens SHOULD be generated by an entity that both the DECADE client and the server trust, and it gets made when a DECADE client asks for it 💅. That entity could be the client itself, a server the client trusts, or another server run by a storage provider that the client trusts. It's super important that the server trusts whoever makes the tokens, bc every token can cost the server resources when it's used 💸. It's just as important for the client to trust the maker, because the tokens grant access to the data stored on the server 🔐.
The token doesn't normally include info about who the authorized client is, so it's typically an anonymous token 🦋. Still, it's not prohibited to bind the token to an identity if you want, like binding it to the IP address of the authorized party 🌸.
Once a DECADE client has a token, it can pass it along to another client 🎀. Token confidentiality SHOULD be provided by whatever protocol the token is carried in (aka Application Protocol, DRP, or SDT) 🤫. The receiving client can then connect to the server named in the token and do anything the token permits 🧚. The token SHOULD be sent along with the operation. The server SHOULD validate the token to figure out which client issued it and whether the requested operation is allowed by what the token says 🔍. If the token passes validation, the server SHOULD apply the resource control policies the token indicates while doing the operation ✨.
Tokens SHOULD include a unique identifier so a server can spot when a token gets used more than once and reject the extra attempts 🚫. Using a token costs the server resources (like bandwidth and storage), and an uploading DECADE client might have a limited budget 💜. So the uploading DECADE client should be able to indicate whether a token may be used multiple times.
It SHOULD be possible to revoke tokens after they've been generated 🙈. This could be done by giving the server the unique identifiers of the tokens to be revoked.
6.2.2. Status Information 📊
okay so DRP SHOULD provide a status request service that clients can use to ask a server for its status info 📋. Access to that status info SHOULD require client authorization, meaning clients need to be authorized to see the requested status info 🔑. This authorization is based on the user delegation concept from Section 4.5 🫶. The following status info elements SHOULD be obtained: a) the list of associated data objects (with their properties), and b) resources used/available 📦. The following info elements MAY be available too: c) the list of servers that data objects have been distributed to (in a certain time frame), and d) the list of clients that data objects have been distributed to (in a certain time frame) 🌈.
For the list of servers/clients that data objects have been distributed to, the server SHOULD be able to decide the time bounds for how long this info is stored, and specify the matching time frame in its response to such requests ⏳. Some of this info may be used for accounting purposes, like the list of clients that data objects have been distributed to 💰.
Access info MAY be provided for accounting purposes 📈. For example, uploading DECADE clients might want access statistics for resources and/or want to do accounting per user. Again, access to that info requires client authorization and SHOULD be based on the delegation concept in Section 4.5 🔐. The following types of access info elements MAY be requested: a) what data objects have been accessed by whom and how many times, and b) access tokens that a server has seen for a given data object 👀.
The server SHOULD decide on the time bounds for how long this info is stored, and specify the corresponding time frame in the response to such requests ⏰.
6.2.3. Data Object Attributes 🏷️
Data objects stored on a DECADE server SHOULD have associated attributes (on top of the object identifier) that relate to the data storage and its management 🗂️. These attributes may be used by the server (and possibly the underlying storage system) to do specialized processing or handling for the data object, or to attach related server or storage-layer properties to it 🧩. These attributes have a scope local to a server. In particular, these attributes SHOULD NOT be applied to a server or client that a data object is copied to 🙅♀️.
Depending on authorization, clients SHOULD be permitted to get or set these attributes 🔓. This authorization is based on the delegation in Section 4.5. DECADE doesn't limit the set of permissible attributes, but it does define a set of baseline attributes that SHOULD be supported:
- Expiration Time: time at which the data object can be deleted ⏰
- Data Object size: in bytes 📏
- Media type: labeling of type as per [RFC6838] 🎨
- Access statistics: how often the data object has been accessed (and what tokens have been used) 📊
The data object attributes defined here are distinct from application metadata 💡. Application metadata is custom info an application might want to associate with a data object so it understands the semantic meaning (e.g., whether it's video and/or audio, its playback length in time, or its index in a stream) 🎬. If an application wants to store such metadata persistently, it can be stored within the data objects themselves 💾.
6.3. Data Transfer 🚚
A DECADE server will provide a data access interface, and SDT will be used to write data objects to a server and to read (download) data objects from a server 📥. Semantically, SDT is a client-server protocol, meaning the server always responds to client requests 🤝.
To write a data object, a client first generates the object's name (see Section 6.1), and then uploads the object to a server and supplies the generated name 🏷️. The name can be used to access (download) the object later. For example, the client can pass the name to other clients as a reference so they can refer to the object too 💌. Data objects can be self-contained things like multimedia resources, files, etc., but also chunks, like chunks of a P2P distribution protocol that can be part of a containing object or a stream 🧩. If supported, a server can verify the integrity and other security properties of uploaded objects 🛡️.
A client can request named data objects from a server. In a corresponding request message, a client specifies the object name and a suitable access and resource control token 🎫. The server checks the validity of the received token and its associated properties related to resource usage ✅. If the named data object exists on the server and the token can be validated, the server delivers the requested object in a response message 📦. If the data object can't be delivered, the server provides corresponding status/reason information in a response message 🙃. Specifics about error handling, including additional error conditions (e.g., overload), precedence for returned errors, and their relation with server policy, are deferred to an eventual protocol specification 🔮.
6.4. Server-Server Protocols 🤝
An important feature of a DECADE system is the ability for one server to directly download data objects from another server 🔥. This lets applications replicate data objects directly between servers, without end-hosts having to spend uplink capacity uploading data objects to a different server 🙌.
DRP and SDT SHOULD support operations directly between servers. Servers are not assumed to trust each other, nor are they configured to do so 🚫. All data operations are performed on behalf of clients via explicit instruction. However, the objects being processed don't necessarily have to originate or terminate at the client (i.e., the data object might be limited to being exchanged between servers even if the instruction is triggered by the client) 🔁. So clients can tell a server which remote server(s) to access, what operation is to be performed, or which server the object is to be stored in, along with the credentials indicating access and resource control needed to perform the operation at the remote server 🔑.
Server-server support is focused on reading and writing data objects between servers. The data object referred to at the remote server is the same as the original data object the client requested 🪞. Object attributes might also be specified in the request to the remote server 🏷️. This way, a server acts as a proxy for a client, and a client can make requests through that proxy 🧚. The operations are performed as if the original requester had its own client co-located with the server 📍. When a client sends a request to a server with these additional parameters, it's giving the server permission to act (proxy) on its behalf 🫡. So it would be prudent for the supplied token to have narrow privileges (e.g., limited to only the necessary data objects) or a short validity time (e.g., a small expiration time) ⚠️.
For a retrieval operation, the server is to retrieve the data object from the remote server using the specified credentials, and then optionally return the object to a client 📥. For a storage operation, the server is to store the object on the remote server using the specified credentials 📤. The object might optionally be uploaded from the client, or it might already exist at the server 💫.
6.5. Potential DRP/SDT Candidates 🔭
Having covered the key DRP/SDT functionalities above, it's useful to consider some potential DRP/SDT candidates as guidance for future DECADE protocol implementations 💡. To recap, DRP is a protocol for communicating access control and resource-scheduling policies from a DECADE client to a DECADE server, or between DECADE servers 📜. SDT is a protocol used to transfer data objects between a DECADE client and a DECADE server, or between DECADE servers 🚚. An evaluation of existing protocols for their suitability for DRP and SDT is given in Appendix A 🔍. Also, [INTEGRATION-EX] provides some experimental examples of how to integrate DECADE-like in-network storage infrastructure into P2P applications 🧪.
7. How In-Network Storage Components Map to DECADE ✨
okay so this section checks how the basic pieces of an in-network storage system (see Section 3 of [RFC6392]) line up with a DECADE system 🧚
For the data access interface, DECADE clients can read and write objects of any size through the client's Data Controller, using standard data transfer (SDT) 💖. For data management, clients can move or delete objects they stored before, also through the Data Controller with SDT 📦. Clients can enumerate or search what's on servers to find objects that match what they're after, using services from the content distribution application (for example buffer-map exchanges, a DHT, or peer exchange) 🔍. While doing this, Application Endpoints might check their local Data Index in the client's Data Controller (Data Search Capability) 🦋.
Next up is access control authorization, and every method is supported here: public-unrestricted, public-restricted, and private 🔐. The content distribution application generates the access control policies and hands them to the client's Resource Controller. The server is the one responsible for doing the access control checks 🛡️. Clients can manage the resources (e.g., bandwidth) on the DECADE server that other Application Endpoints can use (Resource Control Interface) 🌊. Resource-sharing policies also get generated by the content distribution application and provided to the client's Resource Controller, and the server is responsible for implementing those resource-sharing policies ✨.
Discovery is the one thing we're leaving out of scope here, since the actual protocol isn't covered in this document. But different options and considerations were already talked about in Section 5.6 📚. Last but not least, for storage mode, DECADE servers give you an object-based storage mode. Immutable data objects might get stored on a server 💅. Applications might treat existing blocks as data objects, or they might adjust block sizes before storing them on a server 🧱.
8. Security Considerations 🔒💀
Okay, this part is serious bestie, so pay attention 🙈. In general, the security considerations mentioned in [RFC6646] apply to this document as well. A DECADE system is a distributed storage service for content distribution and similar apps. It's made of servers and clients, and the clients use those servers to upload data objects, request distribution of data objects, and download data objects. This kind of system lives inside a bigger application context (for example, a P2P app), and DECADE clients are expected to take part in application-specific communication sessions 🤝. The security stuff here is mostly about threats to the DECADE system and its communication services, meaning the DRP/SDT protocols that this document describes in an abstract way 🧠.
8.1. Threat: System Denial-of-Service Attacks
A DECADE network might be used to distribute data objects from one client to a set of servers, using the server-server communication feature that a client can request when uploading an object. If lots of clients upload many objects to different servers at the same time and request server-server distribution for all of them, they could mount massive distributed denial-of-service (DDOS) attacks and overload a network of servers 😱. This threat is handled by the server's 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, how strong this is depends on how strong the token mechanism is. See below for a discussion of this and related communication security threats 👀.
Denial-of-service attacks against a single server (sending tons of requests to that one server) might still cause a lot of load, because the server has to process requests and invalidate tokens 📉. SDT MUST provide a redirection mechanism to allow requests to other servers, kind of like how an HTTP reverse proxy can redirect and load balance across multiple HTTP origin servers [RFC2616] ⚖️.
8.2. Threat: Authorization Mechanisms Compromised
A DECADE system does not require Application Endpoints to authenticate in order to access a server for downloading objects, since authorization is based on a delegation-based authorization mechanism rather than on Endpoint or user identities 🪪. That means most protocol security threats are tied to the authorization scheme 😬. The security of the token mechanism depends on how strong the token mechanism is and on keeping the tokens secret 🤫. 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 period, and so on. If an attacker can guess, construct, or simply obtain tokens, the integrity of the data maintained by the servers is compromised 🚨.
This is a general security threat that applies to authorization delegation schemes. Specifications of existing delegation schemes such as [RFC6749] discuss these general threats in detail 📖. We can say that the DRP has to specify appropriate algorithms for token generation 🔑. Moreover, authorization tokens should have a limited validity period, and the application should specify that period. Token confidentiality should be provided by application protocols that carry tokens, and the SDT and DRP should provide secure (confidential) communication modes 💜.
8.3. Threat: Spoofing of Data Objects
In a DECADE system, an Application Endpoint refers other Application Endpoints to servers so they can download a specified data object 📬. An attacker could "inject" a faked version of the object into this process, so the downloading Endpoint actually receives a different object from the one the uploading Endpoint provided 🎭. As a result, the downloading Endpoint thinks it received an object that matches the name it was given earlier, when in fact the object is fake 😭. Similar attacks could be aimed at the application protocol (the one used for referring other Endpoints to servers), at the servers themselves (and their storage subsystems), and at the SDT that's used to upload, distribute, and download the object 🕸️.
A DECADE system's fundamental defence against object spoofing is name-object binding validation: the ability of a receiver to check whether the name it was given, and used to request an object, actually matches the bits it received 🚩.
As described above, this allows for different forms of name-object binding, for example using hashes of data objects, with different hash functions (different algorithms and different digest lengths) 🧮. For application scenarios where hashes of data objects don't apply (for example, live streaming), other forms of name-object binding can be used 🎥. This flexibility also helps with cryptographic algorithm evolution. Hash functions might get deprecated, better alternatives might be invented, and so on, so applications can pick the mechanisms that meet their security requirements 🌱.
DECADE servers MAY perform name-object binding validation on stored objects, but Application Endpoints MUST NOT rely on that. In other words, Application Endpoints SHOULD perform name-object binding validation on received objects 🫶.
9. Acknowledgments 🌸
We thank the following people for their contributions to and/or detailed reviews of this document or earlier drafts of this document: Carlos Bernardos, Carsten Bormann, David Bryan, Dave Crocker, Yingjie Gu, David Harrington, Hongqiang (Harry) Liu, David McDysan, Borje Ohlman, Martin Stiemerling, Richard Woundy, and Ning Zong 💐.
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.
- [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
- [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
- [RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-Network Storage Systems", RFC 6392, October 2011.
- [RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", RFC 6646, July 2012.
- [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
- [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
- [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013.
- [INTEGRATION-EX] Zong, N., Ed., Chen, X., Huang, Z., Chen, L., and H. Liu, "Integration Examples of DECADE System", Work in Progress, August 2013.
- [GoogleFileSystem] Ghemawat, S., Gobioff, H., and S. Leung, "The Google File System", SOSP '03, Proceedings of the 19th ACM Symposium on Operating Systems Principles, October 2003.
- [GoogleStorageDevGuide] Google, "Google Cloud Storage - Developer's Guide",
https://developers.google.com/storage/docs/concepts-techniques. - [OpenFlow] Open Networking Foundation, "Software-Defined Networking: The New Norm for Networks", April 2013,
https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf. - [CDMI] Storage Networking Industry Association (SNIA), "Cloud Data Management Interface (CDMI (TM)), Version 1.0.2", June 2012,
http://snia.org/sites/default/files/CDMI%20v1.0.2.pdf.
Appendix A. Evaluation of Candidate Protocols for DECADE DRP/SDT 🦋
In this section we check how well the abstract protocol interactions specified in this document for DECADE DRP and SDT can be carried out by the existing protocols HTTP, CDMI, and OAuth 🧐.
A.1. HTTP
HTTP [RFC2616] is a key protocol for the Internet in general and especially for the World Wide Web 🌍. It's a request-response protocol. A typical transaction involves a client (e.g., web browser) requesting content (resources) from a web server. Another example is when a client stores or deletes content on a server 💾.
A.1.1. HTTP Support for DRP Primitives
DRP provides configuration of access control and resource-sharing policies on DECADE servers ⚙️.
A.1.1.1. Access Control Primitives
Access control needs mechanisms for defining the access policies for the server, and then checking the authorization of a user before it stores or retrieves content 🔐. HTTP supports rudimentary access control via "HTTP Secure" (HTTPS). HTTPS is a combination of HTTP with SSL/TLS 🧩. The main use of HTTPS is to authenticate the server and encrypt all traffic between the client and the server 🔒. There's also a mode to support client authentication, though it's less frequently used 🙃.
A.1.1.2. Resource Control Primitives for Communication 🌊
Okay bestie, communication resources are the pipes 🚰. That means bandwidth (upload/download) and how many clients can be connected at the same time (connections). HTTP handles bandwidth control kinda indirectly through "persistent" HTTP connections 🦋. Persistent connections let a client keep the underlying TCP connection to the server open, which allows streaming and pipelining (multiple simultaneous requests from a given client) 💅.
HTTP has no direct support for controlling the communication resources for a given client 😭. Servers usually handle this part themselves, through their implementation algorithms 🫶.
A.1.1.3. Resource Control Primitives for Storage 🧚
Storage resources cover the amount of memory and how long data lives. HTTP doesn't let you directly control storage at the server endpoint 🙈. But HTTP does support caching at intermediate points, like a web proxy 🍓. For that, HTTP defines cache control mechanisms that spell out how long and in what situations the intermediate point may store and use the content 💜.
A.1.2. HTTP Support for SDT Primitives 📦
SDT is used to write objects and read (download) objects from a DECADE server. The object can be a self-contained thing like a multimedia file, or a chunk from a P2P system 🎀.
A.1.2.1. Writing Primitives ✍️
Writing means uploading objects to the server. HTTP supports two writing methods, called PUT and POST. In HTTP, the object is called a resource and it's identified by a URI. PUT uploads a resource to a specific location on the server. POST, on the other hand, submits the object to the server, and the server decides whether to update an existing resource or create a new one 👑.
For DECADE, picking PUT or POST depends on who's responsible for the naming. If the client does the naming, then PUT is appropriate. If the server does the naming, then POST should be used (so the server can define the URI) ✨.
A.1.2.2. Downloading Primitives 📥
Downloading means fetching an object from the server. HTTP supports downloading through the GET and HEAD methods. GET fetches a specific resource as identified by the URL. HEAD is similar, but it only fetches the metadata ("header") associated with the resource, not the resource itself 🌸.
A.1.3. Primitives for Removing Duplicate Traffic 🔥
To challenge a remote entity for an object, the DECADE server should provide a seed number, which the server generates randomly. Then it asks the remote entity to return a hash calculated from the seed number and the content of the object. The server may also specify the hash function the remote entity should use 🧠. HTTP supports the challenge message through the GET methods. The message type ("challenge"), the seed number, and the hash function name all get put in a URL. In the reply, the hash is sent in an Entity Tag (ETag) header 💅.
A.1.4. Other Operations 🗑️
HTTP supports deleting content on the server through the DELETE method 💀.
A.1.5. Conclusions 📝
HTTP can provide a rudimentary DRP and SDT for some aspects of DECADE, but it won't be able to satisfy all the DECADE requirements. For example, HTTP doesn't provide a complete access control mechanism, and it doesn't support storage resource controls at the endpoint server 😭.
It's possible, though, to imagine combining HTTP with a custom suite of other protocols to fulfill most of the DECADE requirements for DRP and SDT. For example, Google Storage for Developers is built using HTTP (with extensive proprietary extensions such as custom HTTP headers). Google Storage also uses OAuth [RFC6749] (for access control) in combination with HTTP [GoogleStorageDevGuide]. An example of using OAuth for DRP is given in Appendix A.3 🦋.
A.2. CDMI 🌈
The Cloud Data Management Interface (CDMI) specification defines a functional interface that applications use to store and manage data objects in a cloud storage environment. The CDMI interface for reading and writing data is based on standard HTTP requests, with CDMI-specific encodings using JavaScript Object Notation (JSON). CDMI is specified by the Storage Networking Industry Association (SNIA) [CDMI] ⭐.
A.2.1. CDMI Support for DRP Primitives 🔐
DRP provides configuration of access control and resource-sharing policies on DECADE servers.
A.2.1.1. Access Control Primitives 🗝️
Access control includes mechanisms for defining the access policies for the server, and then checking a user's authorization before allowing content storage or retrieval. CDMI defines an Access Control List (ACL) per data object, so it supports access control (read and/or write) at the granularity of data objects. An ACL contains a set of Access Control Entries (ACEs), where each ACE specifies a principal (i.e., user or group of users) and a set of privileges granted to that principal 💜.
CDMI requires that an HTTP authentication mechanism be available so the server can validate the identity of a principal (client). Specifically, CDMI requires that either HTTP Basic Authentication or HTTP Digest Authentication be supported. CDMI recommends that HTTP over TLS (HTTPS) is supported to encrypt the data sent over the network 🔒.
A.2.1.2. Resource Control Primitives for Communication 📶
Communication resources include bandwidth (upload/download) and the number of simultaneously connected clients (connections). CDMI supports two key data attributes that control the communication resources for a client: cdmi_max_throughput and cdmi_max_latency. These attributes are defined in the metadata for data objects, and they indicate the desired bandwidth or delay for transmitting the data object from the cloud server to the client 🚀.
A.2.1.3. Resource Control Primitives for Storage 🗄️
Storage resources include the quantity and lifetime of storage. CDMI defines metadata for individual data objects and for general storage system configuration, and this metadata can be used for storage resource control. In particular, CDMI defines the following metadata fields:
cdmi_data_redundancy: desired number of copies to be maintainedcdmi_geographic_placement: region where the object is permitted to be storedcdmi_retention_period: time interval the object is to be retainedcdmi_retention_autodelete: whether the object should be automatically deleted after the retention period 🙌
A.2.2. CDMI Support for SDT Primitives 🍬
SDT is used to write objects and read (download) objects from a DECADE server. The object can be a self-contained thing like a multimedia file, or a chunk from a P2P system 🎀.
A.2.2.1. Writing Primitives ✍️
Writing means uploading objects to the server. CDMI supports the standard HTTP methods for PUT and POST, as described in Appendix A.1.2.1 💅.
A.2.2.2. Downloading Primitives 📥
Downloading means fetching an object from the server. CDMI supports the standard HTTP GET method, as described in Appendix A.1.2.2 🌷.
A.2.3. Other Operations 🧺
CDMI supports DELETE, as described in Appendix A.1.4. CDMI also supports COPY and MOVE operations 🔁.
CDMI supports the concept of containers of data objects, which allows joint operations on related objects. For example, GET may be done on a single data object or on an entire container 📚.
CDMI also supports a global naming scheme. Every object stored within a CDMI system will have a globally unique object string identifier (ObjectID) assigned at creation time 🆔.
A.2.4. Conclusions 🏁
CDMI has a rich array of features that can provide a good base for DRP and SDT for DECADE. An initial analysis finds that the following CDMI features may be useful for DECADE:
- access control
- storage resource control
- communication resource control
- COPY/MOVE operations
- data containers
- naming scheme
A.3. OAuth 🪪
As mentioned in Appendix A.1, OAuth [RFC6749] may be used as part of the access and resource control of a DECADE system. In this section, we give an example of how to configure OAuth requests and responses for DRP 🔑.
An OAuth request to access DECADE data objects should include the following fields:
response_type: Value should be set to"token".client_id: Theclient_idindicates either the application that is using the DECADE service or the end user who is using the DECADE service from a DECADE storage service provider. DECADE storage service providers should provide the ID distribution and management function.scope: Data object names that are requested.
An OAuth response should include the following information:
token_type:"Bearer"expires_in: The lifetime in seconds of the access token.access_token: A token denotes the following information.service_uri: The server address or URI which is providing the service;- permitted_operations (e.g., read, write) and objects (e.g., names of data objects that might be read or written);
priority: Value should be set to be either"Urgent","High","Normal"or"Low".bandwidth: Given to the requested operation, a weight value used in a weighted bandwidth sharing scheme, or an integer in number of bits per second;amount: Data size in number of bytes that might be read or written.token_signature: The signature of the access token.
Authors' Addresses 🫶
Richard Alimi Google
EMail: ralimi@google.com
Akbar Rahman InterDigital Communications, LLC
EMail: akbar.rahman@interdigital.com
Dirk Kutscher NEC
EMail: dirk.kutscher@neclab.eu
Y. Richard Yang Yale University
EMail: yry@cs.yale.edu
Haibin Song Huawei Technologies
EMail: haibin.song@huawei.com
Kostas Pentikousis EICT
EMail: k.pentikousis@eict.de
That's the whole RFC, bestie! 🎉💖
📦 where this page comes from
- ietf: rfc7069 2013-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms