idnits 2.17.1 draft-ietf-decade-arch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) == Outdated reference: A later version (-06) exists of draft-ietf-decade-problem-statement-04 == Outdated reference: A later version (-08) exists of draft-ietf-decade-reqs-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE R. Alimi 3 Internet-Draft Google 4 Intended status: Informational Y. Yang 5 Expires: May 3, 2012 Yale University 6 A. Rahman 7 InterDigital Communications, LLC 8 D. Kutscher 9 NEC 10 H. Liu 11 Yale University 12 October 31, 2011 14 DECADE Architecture 15 draft-ietf-decade-arch-04 17 Abstract 19 Content Distribution Applications (e.g., P2P applications) are widely 20 used on the Internet and make up a large portion of the traffic in 21 many networks. One technique to improve the network efficiency of 22 these applications is to introduce storage capabilities within the 23 networks; this is the capability to be provided by DECADE (DECoupled 24 Application Data Enroute). This document presents an architecture 25 for DECADE, discusses the underlying principles, and identifies core 26 components and protocols for introducing in-network storage for these 27 applications. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on May 3, 2012. 57 Copyright Notice 59 Copyright (c) 2011 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Functional Entities . . . . . . . . . . . . . . . . . . . . . 6 76 2.1. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 6 77 2.2. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 6 78 2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6 79 2.4. Content Provider Using DECADE . . . . . . . . . . . . . . 6 80 2.5. Content Consumer Using DECADE . . . . . . . . . . . . . . 7 81 2.6. Content Distribution Application . . . . . . . . . . . . . 7 82 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 7 83 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4. Architectural Principles . . . . . . . . . . . . . . . . . . . 9 86 4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 10 87 4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 11 88 4.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 12 89 4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . . 12 90 4.5. Resource and Data Access Control through User 91 Delegation . . . . . . . . . . . . . . . . . . . . . . . . 12 92 5. System Components . . . . . . . . . . . . . . . . . . . . . . 13 93 5.1. Content Distribution Application . . . . . . . . . . . . . 14 94 5.2. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 16 95 5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 18 96 5.4. Token-based Authentication and Resource Control . . . . . 21 97 5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 22 98 6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 23 99 6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 23 100 6.2. Standard Data Transport (SDT) . . . . . . . . . . . . . . 26 101 7. Server-to-Server Protocols . . . . . . . . . . . . . . . . . . 29 102 7.1. Operational Overview . . . . . . . . . . . . . . . . . . . 29 103 8. Potential Optimizations . . . . . . . . . . . . . . . . . . . 30 104 8.1. Pipelining to Avoid Store-and-Forward Delays . . . . . . . 30 105 8.2. Deduplication . . . . . . . . . . . . . . . . . . . . . . 31 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 108 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 110 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 111 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 112 Appendix A. Appendix: Evaluation of Some Candidate Existing 113 Protocols for DECADE DRP and SDT . . . . . . . . . . 34 114 A.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 115 A.2. WEBDAV . . . . . . . . . . . . . . . . . . . . . . . . . . 37 116 A.3. CDMI . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 117 Appendix B. In-Network Storage Components Mapped to DECADE 118 Architecture . . . . . . . . . . . . . . . . . . . . 42 119 B.1. Data Access Interface . . . . . . . . . . . . . . . . . . 43 120 B.2. Data Management Operations . . . . . . . . . . . . . . . . 43 121 B.3. Data Search Capability . . . . . . . . . . . . . . . . . . 43 122 B.4. Access Control Authorization . . . . . . . . . . . . . . . 43 123 B.5. Resource Control Interface . . . . . . . . . . . . . . . . 43 124 B.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 43 125 B.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 44 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 128 1. Introduction 130 Content Distribution Applications are widely used on the Internet 131 today to distribute data, and they contribute a large portion of the 132 traffic in many networks. The DECADE architecture described in this 133 document enables such applications to leverage in-network storage to 134 achieve more efficient content distribution. Specifically, in many 135 subscriber networks, it can be expensive to upgrade network equipment 136 in the "last-mile", because it can involve replacing equipment and 137 upgrading wiring at individual homes, businesses, and devices such as 138 DSLAMs (Digital Subscriber Line Access Multiplexers) and CMTSs (Cable 139 Modem Termination Systems) in remote locations. Therefore, it can be 140 cheaper to upgrade the core infrastructure, which involves fewer 141 components that are shared by many subscribers. See 142 [I-D.ietf-decade-problem-statement] for a more complete discussion of 143 the problem domain and general discussions of the capabilities to be 144 provided by DECADE. 146 This document presents an architecture for providing in-network 147 storage that can be integrated into Content Distribution 148 Applications. The primary focus is P2P-based content distribution, 149 but the architecture may be useful to other applications with similar 150 characteristics and requirements. See [I-D.ietf-decade-reqs] for a 151 definition of the target applications supported by DECADE. 153 The design philosophy of the DECADE architecture is to provide only 154 the core functionalities that are needed for applications to make use 155 of in-network storage. Focusing on only core functionalities, DECADE 156 may be simpler and easier to support by service providers. If more 157 complex functionalities are needed by a certain application or class 158 of applications, it may be layered on top of DECADE. 160 DECADE will leverage existing data transport and application-layer 161 protocols. The design is to work with a small set of alternative 162 IETF protocols. In this document, we use "data transport" to refer 163 to a protocol that is used to read data from and write data into 164 DECADE in-network storage. 166 This document proceeds in two steps. First, it details the core 167 architectural principles that we use to guide the DECADE design. 168 Next, given these core principles, this document presents the core 169 components of the DECADE architecture and identifies the usage of 170 existing protocols and where there is a need for new protocol 171 development. 173 This document does not define any new protocol. Instead, when 174 identifying the need for a new protocol, it presents an abstract 175 design including the necessary functions of that protocol (including 176 rationale) in order to guide future protocol development. 178 2. Functional Entities 180 This section defines the functional entities involved in a DECADE 181 system. Functional entities can be classified as follows: 183 o A physical or logical component in the DECADE architecture: DECADE 184 Client, DECADE Server, Content Distribution Application and 185 Application End Point; 187 o Operator of a physical or logical component in the DECADE 188 architecture: DECADE Storage Provider; and 190 o Source or sink of content distributed via the DECADE architecture: 191 DECADE Content Provider, and DECADE Content Consumer. 193 2.1. DECADE Server 195 A DECADE server stores DECADE data inside the network, and thereafter 196 manages both the stored data and access to that data. To reinforce 197 that these servers are responsible for storage of raw data, this 198 document also refers to them as storage servers. 200 2.2. DECADE Client 202 A DECADE client stores and retrieves data at DECADE Servers. 204 2.3. DECADE Storage Provider 206 A DECADE storage provider deploys and/or manages DECADE storage 207 server(s) within a network. A storage provider may also own or 208 manage the network in which the DECADE servers are deployed, but this 209 is not mandatory. 211 A DECADE storage provider, possibly in cooperation with one or more 212 network providers, determines deployment locations for DECADE servers 213 and determines the available resources for each. 215 2.4. Content Provider Using DECADE 217 A content provider using DECADE accesses DECADE storage servers (by 218 way of a DECADE client) to upload and manage data. Such a content 219 provider can access one or more storage servers. Such a content 220 provider may be a single process or a distributed application (e.g., 221 in a P2P scenario), and may either be fixed or mobile. 223 2.5. Content Consumer Using DECADE 225 A content consumer using DECADE accesses DECADE storage servers (by 226 way of a DECADE client). A content consumer can access one or more 227 DECADE storage servers. A content consumer may be a single process 228 or a distributed application (e.g., in a P2P scenario), and may 229 either be fixed or mobile. An instance of a distributed application, 230 such as a P2P application, may both provide content to and consume 231 content from DECADE storage servers. 233 2.6. Content Distribution Application 235 A content distribution application (as a target application for 236 DECADE as described in [I-D.ietf-decade-reqs]) is a distributed 237 application designed for dissemination of a possibly-large data set 238 to multiple consumers. Content Distribution Applications typically 239 divide content into smaller blocks for dissemination. 241 The term Application Developer refers to the developer of a 242 particular Content Distribution Application. 244 2.6.1. Application End-Point 246 An Application End-Point is an instance of a Content Distribution 247 Application that makes use of DECADE server(s). A particular 248 Application End-Point may be a DECADE Content Provider, a DECADE 249 Content Consumer, or both. For example, an Application End-Point may 250 be an instance of a video streaming client, or it may be the source 251 providing the video to a set of clients. 253 An Application End-Point need not be actively transferring data with 254 other Application End-Points to interact with the DECADE storage 255 system. That is, an End-Point may interact with the DECADE storage 256 servers as an offline activity. 258 3. Protocol Flow 260 3.1. Overview 262 The DECADE Architecture uses two protocols, as shown in Figure 1. 263 First, the DECADE Resource Protocol is responsible for communication 264 of access control and resource scheduling policies from DECADE Client 265 to DECADE Server, as well as between DECADE Servers. The DECADE 266 Architecture includes exactly one DRP for interoperability and a 267 common format through which these policies can be communicated. 269 Native Application 270 .-------------. Protocol(s) .-------------. 271 | Application | <------------------> | Application | 272 | End-Point | | End-Point | 273 | | | | 274 | .--------. | | .--------. | 275 | | DECADE | | | | DECADE | | 276 | | Client | | | | Client | | 277 | `--------' | | `--------' | 278 `-------------' `-------------' 279 | ^ | ^ 280 DECADE | | Standard | | 281 Resource | | Data DRP | | SDT 282 Protocol | | Transport | | 283 (DRP) | | (SDT) | | 284 | | | | 285 | | | | 286 | | | | 287 | | | | 288 | | | | 289 | | | | 290 v V v V 291 .=============. DRP .=============. 292 | DECADE | <------------------> | DECADE | 293 | Server | <------------------> | Server | 294 `=============' SDT `=============' 296 Figure 1: Generic Protocol Flow 298 Second, Standard Data Transport protocols (e.g., HTTP, WebDAV, or 299 CDMI) are used to transfer data objects to and from a DECADE Server. 300 The DECADE architecture may be used with multiple standard data 301 transports. 303 Decoupling the protocols in this way allows DECADE to directly 304 utilize existing standard data transports, as well as allowing both 305 DECADE and DRP to evolve independently from data transports. 307 It is also important to note that the two protocols do not need to be 308 separate on the wire. For example, DRP messages may be piggybacked 309 within some extension fields provided by certain data transport 310 protocols. In such a scenario, DRP is technically a data structure 311 (transported by other protocols), but it can still be considered as a 312 logical protocol that provides the services of configuring DECADE 313 resource usage. Hence, this document considers SDT and DRP as two 314 separate, logical functional components for clarity. 316 3.2. An Example 318 Before discussing details of the architecture, this section provides 319 an example data transfer scenario to illustrate how the DECADE 320 Architecture can be applied. 322 In this example, we assume that Application End-Point B (the 323 receiver) is requesting a data object from Application End-Point A 324 (the sender). Let S(A) denote A's DECADE storage server. There are 325 multiple usage scenarios (by choice of the Content Distribution 326 Application). For simplicity of introduction, we design the example 327 to use only a single DECADE Server; Section 7 details a case when 328 both A and B wish to employ DECADE Servers. 330 When an Application End-Point wishes to use its DECADE storage 331 server, it provides a token (see Section 6.1.2 for details) to the 332 other Application End-Point. The token is sent using the Content 333 Distribution Application's native protocol. 335 The steps of the example are illustrated in Figure 2. First, B 336 requests a data object from A using their native protocol. Next, A 337 uses the DECADE Resource Protocol (DRP) to obtain a token from its 338 DECADE storage server, S(A). A then provides the token to B (again, 339 using their native protocol). Finally, B provides the token to S(A) 340 via DRP, and requests and downloads the data object via a Standard 341 Data Transport (SDT). 343 .----------. 344 ----------> | S(A) | <------ 345 2. Obtain / `----------' \ 4. Request and 346 Token / \ Download Object 347 (DRP) / \ (DRP + SDT) 348 v 1. App request v 349 .-------------. <--------------------------- .-------------. 350 | End-Point A | | End-Point B | 351 `-------------' ---------------------------> `-------------' 352 3. App response (token) 354 Figure 2: Download from Storage Server 356 4. Architectural Principles 358 We identify the following key principles. 360 4.1. Decoupled Control/Metadata and Data Planes 362 The DECADE infrastructure is intended to support multiple content 363 distribution applications. A complete content distribution 364 application implements a set of control and management functions 365 including content search, indexing and collection, access control, ad 366 insertion, replication, request routing, and QoS scheduling. An 367 observation of DECADE is that different content distribution 368 applications can have unique considerations designing the control and 369 signaling functions: 371 o Metadata Management Scheme: Traditional file systems provide a 372 standard metadata abstraction: a recursive structure of 373 directories to offer namespace management; each file is an opaque 374 byte stream. In content distribution, applications may use 375 different metadata management schemes. For example, one 376 application may use a sequence of blocks (e.g., for file sharing), 377 while another application may use a sequence of frames (with 378 different sizes) indexed by time. 380 o Resource Scheduling Algorithms: a major competitive advantage of 381 many successful P2P systems is their substantial expertise in 382 achieving highly efficient utilization of peer and infrastructural 383 resources. For instance, many live P2P systems have their 384 specific algorithms in constructing topologies to achieve low- 385 latency, high-bandwidth streaming. They continue to fine-tune 386 such algorithms. 388 Given the diversity of control-plane functions, in-network storage 389 should export basic mechanisms and allow as much flexibility as 390 possible to the control planes to implement specific policies. This 391 conforms to the end-to-end systems principle and allows innovation 392 and satisfaction of specific business goals. 394 Decoupling control plane and data plane is not new. For example, 395 OpenFlow is an implementation of this principle for Internet routing, 396 where the computation of the forwarding table and the application of 397 the forwarding table are separated. Google File System 398 [GoogleFileSystem] applies the principle to file system design, by 399 utilizing the Master to handle the meta-data management, and the 400 Chunk Servers to handle the data plane functions (i.e., read and 401 write of chunks of data). NFSv4.1's pNFS extension [RFC5661] also 402 implements this principle. 404 Note that applications may have different Data Plane implementations 405 in order to support particular requirements (e.g., low latency). In 406 order to provide interoperability, the DECADE architecture does not 407 intend to enable arbitrary data transport protocols. However, the 408 architecture may allow for more-than-one data transport protocols to 409 be used. 411 Also note that although an application's existing control plane 412 functions remain implemented within the application, the particular 413 implementation may need to be adjusted to support DECADE. 415 4.2. Immutable Data Objects 417 A property of bulk contents to be broadly distributed is that they 418 typically are immutable -- once a piece of content is generated, it 419 is typically not modified. It is not common that bulk contents such 420 as video frames and images need to be modified after distribution. 422 Many content distribution applications divide content objects into 423 blocks for two reasons: (1) multipath: different blocks may be 424 fetched from different content sources in parallel, and (2) faster 425 recovery and verification: individual blocks may be recovered and 426 verified. Typically, applications use a block size larger than a 427 single packet in order to reduce control overhead. 429 Common applications using the aforementioned data model include P2P 430 streaming (live and video-on-demand) and P2P file-sharing. However, 431 other additional types of applications may match this model. 433 DECADE adopts a design in which immutable data objects may be stored 434 at a storage server. Applications may consider existing blocks as 435 DECADE data objects, or they may adjust block sizes before storing in 436 a DECADE server. 438 Focusing on immutable data blocks in the data plane can substantially 439 simplify the data plane design, since consistency requirements can be 440 relaxed. It also allows effective reuse of data blocks and de- 441 duplication of redundant data. 443 Depending on its specific requirements, an application may store data 444 in DECADE servers such that each data object is completely self- 445 contained (e.g., a complete, independently decodable video segment). 446 An application may also divide data into chunks that require 447 application level assembly. The DECADE architecture and protocols 448 are agnostic to the nature of the data objects and do not specify a 449 fixed size for them. 451 Note that immutable content may still be deleted. Also note that 452 immutable data blocks do not imply that contents cannot be modified. 453 For example, a meta-data management function of the control plane may 454 associate a name with a sequence of immutable blocks. If one of the 455 blocks is modified, the meta-data management function changes the 456 mapping of the name to a new sequence of immutable blocks. 458 Throughout this document, all the data objects/blocks are referred as 459 immutable data objects/blocks. 461 4.3. Data Object Identifiers 463 Objects that are stored in a DECADE storage server can be accessed by 464 DECADE content consumers by a resource identifier that has been 465 assigned within a certain application context. 467 Because a DECADE content consumer can access more than one storage 468 server within a single application context, a data object that is 469 replicated across different storage servers managed by a DECADE 470 storage provider, can be accessed by a single identifier. 472 Note that since data objects are immutable, it is possible to support 473 persistent identifiers for data objects. 475 4.4. Explicit Control 477 To support the functions of an application's control plane, 478 applications must be able to know and control which data is stored at 479 particular locations. Thus, in contrast with content caches, 480 applications are given explicit control over the placement (selection 481 of a DECADE server), deletion (or expiration policy), and access 482 control for stored data. 484 Consider deletion/expiration policy as a simple example. An 485 application may require that a DECADE server store content for a 486 relatively short period of time (e.g., for live-streaming data). 487 Another application may need to store content for a longer duration 488 (e.g., for video-on-demand). 490 4.5. Resource and Data Access Control through User Delegation 492 DECADE provides a shared infrastructure to be used by multiple 493 tenants of multiple content distribution applications. Thus, it 494 needs to provide both resource and data access control. 496 4.5.1. Resource Allocation 498 There are two primary interacting entities in the DECADE 499 architecture. First, Storage Providers control where DECADE storage 500 servers are provisioned and their total available resources. Second, 501 Applications control data transfers amongst available DECADE servers 502 and between DECADE servers and end-points. A form of isolation is 503 required to enable concurrently-running Applications to each 504 explicitly manage its own content and share of resources at the 505 available servers. 507 The Storage Provider delegates the management of the resources at a 508 DECADE server to one or more applications. Applications are able to 509 explicitly and independently manage their own shares of resources. 511 4.5.2. User Delegations 513 Storage providers have the ability to explicitly manage the entities 514 allowed to utilize the resources at a DECADE server. This capability 515 is needed for reasons such as capacity-planning and legal 516 considerations in certain deployment scenarios. 518 To provide a scalable way to manage applications granted resources at 519 a DECADE server, we consider an architecture that adds a layer of 520 indirection. Instead of granting resources to an application, the 521 DECADE server grants a share of the resources to a user. The user 522 may in turn share the granted resources amongst multiple 523 applications. The share of resources granted by a storage provider 524 is called a User Delegation. 526 As a simple example, a DECADE Server operated by an ISP may be 527 configured to grant each ISP Subscriber 1.5 Mbps of bandwidth. The 528 ISP Subscriber may in turn divide this share of resources amongst a 529 video streaming application and file-sharing application which are 530 running concurrently. 532 In general, a User Delegation may be granted to an end-user (e.g., an 533 ISP subscriber), a Content Provider, or an Application Provider. A 534 particular instance of an application may make use of the storage 535 resources: 537 o granted to the end-user (with the end-user's permission), 539 o granted to the Content Provider (with the Content Provider's 540 permission), and/or 542 o granted to the Application Provider. 544 5. System Components 546 The primary focus of this document is the architectural principals 547 and the system components that implement them. While certain system 548 components might differ amongst implementations, the document details 549 the major components and their overall roles in the architecture. 551 To keep the scope narrow, we only discuss the primary components 552 related to protocol development. Particular deployments may require 553 additional components (e.g., monitoring and accounting at a DECADE 554 server), but they are intentionally omitted from this document. 556 5.1. Content Distribution Application 558 Content Distribution Applications have many functional components. 559 For example, many P2P applications have components and algorithms to 560 manage overlay topology management, piece selection, etc. In 561 supporting DECADE, it may be advantageous for an application 562 developer to consider DECADE in the implementation of these 563 components. However, in this architecture document, we focus on the 564 components directly employed to support DECADE. 566 Figure 3 illustrates the components discussed in this section from 567 the perspective of a single Application End-Point and their relation 568 to DECADE. 570 Native Protocol(s) 571 (with other Application End-Points) 572 .---------------------> 573 | 574 | 575 .----------------------------------------------------------. 576 | Application End-Point | 577 | .------------. .-------------------. | 578 | | App-Layer | ... | App Data Assembly | | 579 | | Algorithms | | Sequencing | | 580 | `------------' `-------------------' | 581 | | 582 | .------------------------------------------------------. | 583 | | DECADE Client | | 584 | | | | 585 | | .-------------------------. .----------------------. | | 586 | | | Resource Controller | | Data Controller | | | 587 | | | .--------. .----------. | | .--------. .-------. | | | 588 | | | | Data | | Resource | | | | Data | | Data | | | | 589 | | | | Access | | Sharing | | | | Sched. | | Index | | | | 590 | | | | Policy | | Policy | | | | | | | | | | 591 | | | '--------' `----------' | | `--------' `-------' | | | 592 | | `-------------------------' `----------------------' | | 593 | | | ^ | | 594 | `------------ | ----------------- | -------------------' | 595 `-------------- | ----------------- | ---------------------' 596 | | 597 | DECADE | Standard 598 | Resource | Data 599 | Protocol | Transport 600 | (DRP) | (SDT) 601 v V 603 Figure 3: Application Components 605 5.1.1. Data Assembly 607 DECADE is primarily designed to support applications that can divide 608 distributed contents into data objects. To accomplish this, 609 applications include a component responsible for creating the 610 individual data objects before distribution and then re-assembling 611 data objects at the Content Consumer. We call this component 612 Application Data Assembly. The specific implementation is entirely 613 decided by the application. 615 In producing and assembling the data objects, two important 616 considerations are sequencing and naming. The DECADE architecture 617 assumes that applications implement this functionality themselves. 619 See Section 5.3 for further discussion. 621 5.1.2. Native Protocols 623 Applications may still use existing protocols. In particular, an 624 application may reuse existing protocols primarily for control/ 625 signaling. However, an application may still retain its existing 626 data transport protocols, in addition to DECADE as the data transport 627 protocol. This can be important for applications that are designed 628 to be highly robust (e.g., if DECADE servers are unavailable). 630 5.1.3. DECADE Client 632 An application may be modified to support DECADE. We call the layer 633 providing the DECADE support to an application the DECADE Client. It 634 is important to note that a DECADE Client need not be embedded into 635 an application. It could be implemented alone, or could be 636 integrated in other entities such as network devices themselves. 638 5.1.3.1. Resource Controller 640 Applications may have different Resource Sharing Policies and Data 641 Access Policies to control their resource and data in DECADE servers. 642 These policies can be existing policies of applications (e.g., tit- 643 for-tat) or custom policies adapted for DECADE. The specific 644 implementation is decided by the application. 646 5.1.3.2. Data Controller 648 DECADE is designed to decouple the control and the data transport of 649 applications. Data transport between applications and DECADE servers 650 uses standard data transport protocols. A Data Scheduling component 651 schedules data transfers according to network conditions, available 652 DECADE Servers, and/or available DECADE Server resources. The Data 653 Index indicates data available at remote DECADE servers. The Data 654 Index (or a subset of it) may be advertised to other Application End- 655 Points. A common use case for this is to provide the ability to 656 locate data amongst a distributed set of Application End-Points 657 (i.e., a data search mechanism). 659 5.2. DECADE Server 661 A DECADE Server stores data from Application End-Points, and provides 662 control and access of those data to Application End-Points. Note 663 that a DECADE Server is not necessarily a single physical machine, it 664 could also be implemented as a cluster of machines. 666 | | 667 | DECADE | Standard 668 | Resource | Data 669 | Protocol | Transport 670 | (DRP) | (SDT) 671 | | 672 .= | ================= | ======================. 673 | | v | 674 | | .----------------. | 675 | |----> | Access Control | <--------. | 676 | | `----------------' | | 677 | | ^ | | 678 | | | | | 679 | | v | | 680 | | .---------------------. | | 681 | `-> | Resource Scheduling | <------| | 682 | `---------------------' | | 683 | ^ | | 684 | | | | 685 | v .------------. | 686 | .-----------------. | User | | 687 | | Data Store | | Delegation | | 688 | `-----------------' | Management | | 689 | DECADE Server `------------' | 690 `==============================================' 692 Figure 4: DECADE Server Components 694 5.2.1. Access Control 696 An Application End-Point can access its own data or other Application 697 End-Point's data (provided sufficient authorization) in DECADE 698 servers. Application End-Points may also authorize other End-Points 699 to store data. If an access is authorized by an Application End- 700 Point, the DECADE Server will provide access. 702 Note that even if a request is authorized, it may still fail to 703 complete due to insufficient resources by either the requesting 704 Application End-Point, the providing Application End-Point, or the 705 DECADE Server itself. 707 5.2.2. Resource Scheduling 709 Applications may apply their existing resource sharing policies or 710 use a custom policy for DECADE. DECADE servers perform resource 711 scheduling according to the resource sharing policies indicated by 712 Application End-Points as well as configured User Delegations. 714 5.2.3. Data Store 716 Data from applications may be stored at a DECADE Server. Data can be 717 deleted from storage either explicitly or automatically (e.g., after 718 a TTL expiration). It may be possible to perform optimizations in 719 certain cases, such as avoiding writing temporary data (e.g., live 720 streaming) to persistent storage, if appropriate storage hints are 721 supported by the SDT. 723 5.3. Data Sequencing and Naming 725 In order to provide a simple and generic interface, the DECADE Server 726 is only responsible for storing and retrieving individual data 727 objects. Furthermore, DECADE uses its own simple naming scheme that 728 provides uniqueness (with high probability) between data objects, 729 even across multiple applications. 731 5.3.1. DECADE Data Object Naming Scheme 733 The name of a data object is derived from the hash over the data 734 object's content (the raw bytes), which is made possible by the fact 735 that DECADE objects are immutable. This scheme multiple appealing 736 properties: 738 o Simple integrity verification 740 o Unique names (with high probability) 742 o Application independent, without a new IANA-maintained registry 744 The DECADE naming scheme also includes a "type" field, the "type" 745 identifier indicates that the name is the hash of the data object's 746 content and the particular hashing algorithm used. This allows 747 DECADE to evolve by either changing the hashing algorithm (e.g., if 748 security vulnerabilities with an existing hashing algorithm are 749 discovered), or moving to a different naming scheme altogether. 751 The specific format of the name (e.g., encoding, hash algorithms, 752 etc) is out of scope of this document, and left for protocol 753 specification. 755 Another advantage of this scheme is that a DECADE client knows the 756 name of a data object before it is completely stored at the DECADE 757 server. This allows for particular optimizations, such as 758 advertising data object while the data object is being stored, 759 removing store-and-forward delays. For example, a DECADE client A 760 may simultaneously begin storing an object to a DECADE server, and 761 advertise that the object is available to DECADE client B. If it is 762 supported by the DECADE server, client B may begin downloading the 763 object before A is finished storing the object. 765 In certain scenarios (e.g., where a DECADE client has limited 766 computational power), it may be advantageous to offload the 767 computation of a data object's name to the DECADE Server. This 768 possibility is not considered in the current architecture, but may be 769 a topic for future extensions. 771 5.3.2. Application Usage 773 Recall from Section 5.1.1 that an Application typically includes its 774 own naming and sequencing scheme. It is important to note that the 775 DECADE naming format does not attempt to replace any naming or 776 sequencing of data objects already performed by an Application; 777 instead, the DECADE naming is intended to apply only to data objects 778 referenced at the DECADE layer. 780 DECADE names are not necessarily correlated with the naming or 781 sequencing used by the Application using a DECADE client. The DECADE 782 client is expected to maintain a mapping from its own data objects 783 and their names to the DECADE data objects and names. Furthermore, 784 the DECADE naming scheme implies no sequencing or grouping of 785 objects, even if this is done at the application layer. 787 Not only does an Application retain its own naming scheme, it may 788 also decide the sizes of data objects to be distributed via DECADE. 789 This is desirable since sizes of data objects may impact Application 790 performance (e.g., overhead vs. data distribution delay), and the 791 particular tradeoff is application-dependent. 793 5.3.3. Application Usage Example 795 To illustrate these properties, this section presents multiple 796 examples. 798 5.3.3.1. Application with Fixed-Size Chunks 800 Similar to the example in Section 5.1.1, consider an Application in 801 which each individual application-layer segment of data is called a 802 "chunk" and has a name of the form: "CONTENT_ID:SEQUENCE_NUMBER". 803 Furthermore, assume that the application's native protocol uses 804 chunks of size 16KB. 806 Now, assume that this application wishes to make use of DECADE, and 807 assume that it wishes to store data to DECADE servers in data objects 808 of size 64KB. To accomplish this, it can map a sequence of 4 chunks 809 into a single DECADE object, as shown in Figure 5. 811 Application Chunks 812 .---------.---------.---------.---------.---------.---------.-------- 813 | | | | | | | 814 | Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6 815 | | | | | | | 816 `---------`---------`---------`---------`---------`---------`-------- 818 DECADE Data Objects 819 .---------------------------------------.---------------------------- 820 | | 821 | Object_0 | Object_1 822 | | 823 `---------------------------------------`---------------------------- 825 Figure 5: Mapping Application Chunks to DECADE Data Objects 827 In this example, the Application might maintain a logical mapping 828 that is able to determine the name of a DECADE data object given the 829 chunks contained within that data object. The name might be learned 830 from either the original source, another endpoint with which the it 831 is communicating, a tracker, etc. 833 It is important to note that as long as the data contained within 834 each sequence of chunks is unique, the corresponding DECADE data 835 objects have unique names. This is desired, and happens 836 automatically if particular Application segments the same stream of 837 data in a different way, including different chunk size sizes or 838 different padding schemes. 840 5.3.3.2. Application with Continuous Streaming Data 842 Next, consider an Application whose native protocol retrieves a 843 continuous data stream (e.g., an MPEG2 stream) instead of downloading 844 and redistributing chunks of data. Such an application could segment 845 the continuous data stream to produce either fixed-sized or variable- 846 sized DECADE data objects. 848 Figure 6 shows how a video streaming application might produce 849 variable-sized DECADE data objects such that each DECADE data object 850 contains 10 seconds of video data. 852 Application's Video Stream 853 .-------------------------------------------------------------------- 854 | 855 | 856 | 857 `-------------------------------------------------------------------- 858 ^ ^ ^ ^ ^ 859 | | | | | 860 0 Seconds 10 Seconds 20 Seconds 30 Seconds 40 Seconds 861 0 B 400 KB 900 KB 1200 KB 1500 KB 863 DECADE Data Objects 864 .--------------.--------------.--------------.--------------.-------- 865 | | | | | 866 | Object_0 | Object_1 | Object_2 | Object_3 | 867 | (400 KB) | (500 KB) | (300 KB) | (300 KB) | 868 `--------------`--------------`--------------`--------------`-------- 870 Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects 872 Similar to the previous example, the Application might maintain a 873 mapping that is able to determine the name of a DECADE data object 874 given the time offset of the video chunk. 876 5.4. Token-based Authentication and Resource Control 878 A primary use case for DECADE is a DECADE Client authorizing other 879 DECADE Clients to store or retrieve data objects from its DECADE 880 storage. To support this, DECADE uses a token-based authentication 881 scheme. 883 In particular, an entity trusted by a DECADE Client generates a 884 digitally-signed token with particular properties (see Section 6.1.2 885 for details). The DECADE Client distributes this token to other 886 DECADE Clients which then use the token when sending requests to the 887 DECADE Server. Upon receiving a token, the DECADE Server validates 888 the signature and the operation being performed. 890 This is a simple scheme, but has multiple important advantages over 891 an alternate approach in which a DECADE Client explicitly manipulates 892 an Access Control List (ACL) associated with each DECADE data object. 893 In particular, it has the following advantages when applied to 894 DECADE's target applications: 896 o Authorization policies are implemented within the Application; an 897 Application explicitly controls when tokens are generated and to 898 whom they are distributed. 900 o Fine-grained access and resource control can be applied to data 901 objects; see Section 6.1.2 for the list of restrictions that can 902 be enforced with a token. 904 o There is no messaging between a DECADE Client and DECADE Server to 905 manipulate data object permissions. This can simplify, in 906 particular, Applications which share data objects with many 907 dynamic peers and need to frequently adjust access control 908 policies attached to DECADE data objects. 910 o Tokens can provide anonymous access, in which a DECADE Server does 911 not need to know the identity of each DECADE Client that accesses 912 it. This enables a DECADE Client to send tokens to DECADE Clients 913 in other administrative or security domains, and allow them to 914 read or write data objects from its DECADE storage. 916 It is important to note that, in addition to DECADE Clients applying 917 access control policies to DECADE data objects, the DECADE Server may 918 be configured to apply additional policies based on user, object, 919 geographic location, etc. Defining such policies is out of scope for 920 DECADE, but in such a case, a DECADE Client may be denied access even 921 though it possess a valid token. 923 5.5. Discovery 925 DECADE includes a discovery mechanism through which DECADE clients 926 locate an appropriate DECADE Server. [I-D.ietf-decade-reqs] details 927 specific requirements of the discovery mechanism; this section 928 discusses how they relate to other principles outlined in this 929 document. 931 A discovery mechanism allows a DECADE client to determine an IP 932 address or some other identifier that can be resolved to locate the 933 server for which the client will be authorized to generate tokens 934 (via DRP). (Note that the discovery mechanism may also result in an 935 error if no such DECADE servers can be located.) After discovering 936 one or more DECADE servers, a DECADE client may distribute load and 937 requests across them (subject to resource limitations and policies of 938 the DECADE servers themselves) according to the policies of the 939 Application End-Point in which it is embedded. 941 The particular protocol used for discovery is out of scope of this 942 document, but any specification will re-use standard protocols 943 wherever possible. 945 It is important to note that the discovery mechanism outlined here 946 does not provide the ability to locate arbitrary DECADE servers to 947 which a DECADE client might obtain tokens from others. To do so 948 requires application-level knowledge, and it is assumed that this 949 functionality is implemented in the Content Distribution Application, 950 or if desired and needed, as an extension to this DECADE 951 architecture. 953 6. DECADE Protocols 955 This section presents the DECADE Resource Protocol (DRP) and the 956 Standard Data Transport (SDT) in terms of abstract protocol 957 interactions that are intended to mapped to specific protocols. Note 958 that while the protocols are logically separate, DRP is specified as 959 being carried through extension fields within an SDT (e.g., HTTP 960 headers). 962 The DRP is the protocol used by a DECADE client to configure the 963 resources and authorization used to satisfy requests (reading, 964 writing, and management operations concerning DECADE objects) at a 965 DECADE server. The SDT is used to send the operations to the DECADE 966 server. Necessary DRP metadata is supplied using mechanisms in the 967 SDT that are provided for extensibility (e.g., additional request 968 parameters or extension headers). 970 6.1. DECADE Resource Protocol (DRP) 972 DRP provides configuration of access control and resource sharing 973 policies on DECADE servers. A content distribution application, 974 e.g., a live P2P streaming session, MAY employ several DECADE 975 servers, for instance, servers in different operator domains, and DRP 976 allows one instance of such an application, e.g., an application 977 endpoint, to apply access control and resource sharing policies on 978 each of them. 980 6.1.1. Controlled Resources 982 On a single DECADE server, the following resources may be managed: 984 communication resources: DECADE servers have limited communication 985 resources in terms of bandwidth (upload/download) but also in 986 terms of number of connected clients (connections) at a time. 988 storage resources: DECADE servers have limited storage resources. 990 6.1.2. Access and Resource Control Token 992 A token includes the following fields: 994 Permitted operations (e.g., read, write) 996 Permitted objects (e.g., names of data objects that may be read or 997 written) 999 Permitted clients (e.g., as indicated by IP address or other 1000 identifier) that may use the token 1002 Expiration time 1004 Priority for bandwidth given to requested operation (e.g., a 1005 weight used in a weighted bandwidth sharing scheme) 1007 Amount of data that may be read or written 1009 The particular format for the token is out of scope of this document. 1011 The tokens are generated by a trusted entity at the request of a 1012 DECADE Client. It is out of scope of this document to identify which 1013 entity serves this purpose, but examples include the DECADE Client 1014 itself, a DECADE Server trusted by the DECADE Client, or another 1015 server managed by a Storage Provider trusted by the DECADE Client. 1017 Upon generating a token, a DECADE Client may distribute it to another 1018 DECADE Client (e.g., via their native Application protocol). The 1019 receiving DECADE Client may then connect to the sending DECADE 1020 Client's DECADE Server and perform any operation permitted by the 1021 token. The token must be sent along with the operation. The DECADE 1022 Server validates the token to identify the DECADE Client that issued 1023 it and whether the requested operation is permitted by the contents 1024 of the token. If the token is successfully validated, the DECADE 1025 Server applies the resource control policies indicated in the token 1026 while performing the operation. 1028 It is possible for DRP to allow tokens to apply to a batch of 1029 operations to reduce communication overhead required between DECADE 1030 Clients. 1032 DRP may also define tokens to include a unique identifier to allow a 1033 DECADE Server to detect when a token is used multiple times. 1035 6.1.3. Status Information 1037 DRP provides a request service for status information that DECADE 1038 clients can use to request information from a DECADE server. 1040 status information per application context on a specific server: 1041 Access to such status information requires client authorization, 1042 i.e., DECADE clients need to be authorized to access status 1043 information for a specific application context. This 1044 authorization (and the mapping to application contexts) is based 1045 on the user delegation concept as described in Section 4.5. The 1046 following status information elements can be obtained: 1048 * list of associated objects (with properties) 1050 * resources used/available 1052 * list of servers to which objects have been distributed (in a 1053 certain time-frame) 1055 * list of clients to which objects have been distributed (in a 1056 certain time-frame) 1058 For the list of servers/clients to which objects have been 1059 distributed to, the DECADE server can decide on time bounds for 1060 which this information is stored and specify the corresponding 1061 time frame in the response to such requests. Some of this 1062 information can be used for accounting purposes, e.g., the list of 1063 clients to which objects have been distributed. 1065 access information per application context on a specific server: 1066 Access information can be provided for accounting purposes, for 1067 example, when application service providers are interested to 1068 maintain access statistics for resources and/or to perform 1069 accounting per user. Again, access to such information requires 1070 client authorization based on the user delegation concept as 1071 described in Section 4.5. The following access information 1072 elements can be requested: 1074 * what objects have been accessed how many times 1076 * access tokens that a server as seen for a given object 1078 The DECADE server can decide on time bounds for which this 1079 information is stored and specify the corresponding time frame in 1080 the response to such requests. 1082 6.1.4. Object Attributes 1084 Objects that are stored on a DECADE server may have associated 1085 attributes (in addition to the object identifier and the actual 1086 content) that relate to the data storage and its management. These 1087 attributes may be used by the DECADE server (and possibly the 1088 underlying storage system) to perform specialized processing or 1089 handling for the data object, or to attach related DECADE server or 1090 storage-layer properties to the data object. These attributes have a 1091 scope local to a DECADE server. In particular, these attributes are 1092 not applied to a DECADE server or client to which a data object is 1093 copied. 1095 Depending on authorization, DECADE clients may get or set such 1096 attributes. This authorization (and the mapping to application 1097 contexts) is based on the user delegation concept as described in 1098 Section 4.5. The DECADE architecture does not limit the set of 1099 permissible attributes, but rather specifies a set of baseline 1100 attributes that SHOULD be supported by implementations. 1102 Suggested attributes are the following: 1104 TTL: TTL of the object as an absolute time value 1106 object size: in bytes 1108 MIME type 1110 access statistics: how often the object has been accessed (and what 1111 tokens have been used) 1113 It is important to note that the Object Attributes defined here are 1114 distinct from application metadata (see Section 4.1). Application 1115 metadata is custom information that an application may wish to 1116 associate with a data object to understand its semantic meaning 1117 (e.g., whether it is video and/or audio, its playback length in time, 1118 or its index in a stream). If an application wishes to store such 1119 metadata persistently within DECADE, it can be stored within data 1120 objects themselves. 1122 6.2. Standard Data Transport (SDT) 1124 A DECADE server provide a data access interface, and SDT is used to 1125 write objects to a server and to read (download) objects from a 1126 server. Semantically, SDT is a client-server protocol, i.e., the 1127 DECADE server always responds to client requests. 1129 An SDT used in DECADE SHOULD offer a transport mode that provides 1130 confidentiality and integrity. 1132 6.2.1. Writing/Uploading Objects 1134 To write an object, a client first generates the object's name (see 1135 Section 5.3), and then uploads the object to a DECADE server and 1136 supplies the generated name. The name can be used to access 1137 (download) the object later, e.g., the client can pass the name as a 1138 reference to other client that can then refer to the object. 1140 DECADE objects can be self-contained objects such as multimedia 1141 resources, files etc., but also chunks, such as chunks of a P2P 1142 distribution protocol that can be part of a containing object or a 1143 stream. 1145 A server MAY accept download requests for an object that is still 1146 being uploaded. 1148 The application that originates the objects MUST generate DECADE 1149 object names according to the naming specification in Section 5.3. 1150 The naming scheme provides that the name is unique. DECADE clients 1151 (as parts of application entities) upload a named object to a server, 1152 and a DECADE server MUST NOT change the name. It MUST be possible 1153 for downloading clients, to access the object using the original 1154 name. A DECADE server MAY verify the integrity and other security 1155 properties of uploaded objects. 1157 In the following we provide an abstract specification of the upload 1158 operation that we name 'PUT METHOD'. See Appendix A.1 for an example 1159 how this could be mapped to HTTP. 1161 Method PUT: 1163 Parameters: 1165 NAME: The naming of the object according to Section 5.3 1167 OBJECT: The object itself. The protocol MUST provide transparent 1168 binary object transport. 1170 Description: The PUT method is used by a DECADE client to upload an 1171 object with an associated name 'NAME' to a DECADE server. 1173 RESPONSES: The DECADE server MUST respond with one the following 1174 response messages: 1176 CREATED: The object has been uploaded successfully and is now 1177 available under the specified name. 1179 ERRORs: 1181 VALIDATION_FAILED: The contents of the data object received by 1182 the DECADE server did not match the provided name (i.e., 1183 hash validation failed). 1185 PERMISSION_DENIED: The DECADE client lacked sufficient 1186 permission to store the object. 1188 Specifics regarding error handling, including additional error 1189 conditions, precedence for returned errors and its relation 1190 with server policy, are deferred to eventual protocol 1191 specification. 1193 6.2.2. Downloading Objects 1195 A DECADE client can request named objects from a DECADE server. In 1196 the following, we provide an abstract specification of the download 1197 operation that we name 'GET METHOD'. See Appendix A.1 for an example 1198 how this could be mapped to HTTP. 1200 Method GET: 1202 Parameters: 1204 NAME: The naming of the object according to Section 5.3. 1206 Description: The GET method is used by a DECADE client to download 1207 an object with an associated name 'NAME' from a DECADE server. 1209 RESPONSES: The DECADE server MUST respond with one the following 1210 response messages: 1212 OK: The request has succeeded, and an entity corresponding to the 1213 requested resource is sent in the response. 1215 ERRORs: 1217 NOT_FOUND: The DECADE server has not found anything matching 1218 the request object name. 1220 PERMISSION_DENIED: The DECADE client lacked sufficient 1221 permission to read the object. 1223 NOT_AVAILABLE: The data object exists but is currently 1224 unavailable for download (e.g., due to server policy). 1226 Specifics regarding error handling, including additional error 1227 conditions (e.g. overload), precedence for returned errors and 1228 its relation with server policy, are defered to eventual 1229 protocol specification. 1231 7. Server-to-Server Protocols 1233 An important feature of DECADE is the capability for one DECADE 1234 server to directly download objects from another DECADE server. This 1235 capability allows Applications to directly replicate data objects 1236 between servers without requiring end-hosts to use uplink capacity to 1237 upload data objects to a different DECADE server. 1239 To support this functionality, DECADE uses the DRP and SDT to support 1240 operations directly between servers. DECADE servers are not assumed 1241 to trust each other nor are configured to do so. All data operations 1242 are performed on behalf of DECADE clients via explicit instruction. 1243 Note, however, that the objects being processed do not necessarily 1244 have to originate or terminate at the DECADE client (i.e. the object 1245 may be limited to being exchanged between DECADE servers even if the 1246 instruction is triggered by the client). DECADE clients thus must be 1247 able to indicate to a DECADE server the following additional 1248 parameters: 1250 o which remote DECADE server(s) to access; 1252 o the operation to be performed (e.g. PUT, GET); and 1254 o Credentials indicating permission to perform the operation at the 1255 remote DECADE server. 1257 In this way, a DECADE server acts as a proxy for a DECADE client, and 1258 a DECADE client may instantiate requests via that proxy. The 1259 operations are performed as if the original requester had its own 1260 DECADE client co-located with the DECADE server. It is this mode of 1261 operation that provides substantial savings in uplink capacity. Note 1262 that this mode of operation may also be triggered by an 1263 administrative/management application outside the DECADE 1264 architecture. 1266 7.1. Operational Overview 1268 DECADE's server-to-server support is focused on reading and writing 1269 data objects between DECADE servers. A DECADE GET or PUT request MAY 1270 supply the following additional parameters: 1272 REMOTE_SERVER: Address of the remote DECADE server. The format of 1273 the address is out-of-scope of this document. 1275 REMOTE_USER: The account at the remote server from which to retrieve 1276 the object (for a GET), or in which the object is to be stored 1277 (for a PUT). 1279 TOKEN: Credentials to be used at the remote server. 1281 These parameters are used by the DECADE server to instantiate a 1282 request to the specified remote server. It is assumed that the data 1283 object referred to at the remote server is the same as the original 1284 request. It is also assumed that the operation performed at the 1285 remote server is the same as the operation in the original request. 1286 Note that object attributes (see Section 6.1.4) may also be specified 1287 in the request to the remote server. 1289 Note that when a DECADE client invokes a request a DECADE server with 1290 these additional parameters, it is giving the DECADE server 1291 permission to act (proxy) on its behalf. Thus, it would be wise for 1292 the supplied token to have narrow privileges (e.g., limited to only 1293 the necessary data objects) or validity time (e.g., a small 1294 expiration time). 1296 In the case of a GET operation, the DECADE server is to retrieve the 1297 data object from the remote server using the specified credentials 1298 (via a GET request to the remote server), and then optionally return 1299 the object to a client. In the case of a PUT operation, the DECADE 1300 server is to store the object to the remote server using the 1301 specified credentials (via a PUT request to the remote server). The 1302 object may optionally be uploaded from the client or may already 1303 exist at the proxying server. 1305 8. Potential Optimizations 1307 As suggestions for the protocol design and eventual implementations, 1308 we discuss particular optimizations that are enabled by the DECADE 1309 Architecture discussed in this document. 1311 8.1. Pipelining to Avoid Store-and-Forward Delays 1313 A DECADE server may choose to not fully store an object before 1314 beginning to serve it. For example, when serving a GET request, 1315 instead of waiting for the complete data to arrive from a remote 1316 server or DECADE client, a DECADE server may forward received data 1317 bytes as they come in. This pipelining mode reduces store-and- 1318 forward delays, which could be substantial for large objects. A 1319 similar behavior could be used for PUT. 1321 8.2. Deduplication 1323 A common concern amongst Storage Providers is the total volume of 1324 data that needs to be stored. An optimization frequently applied in 1325 existing storage systems is de-duplication, which attempts to avoid 1326 storing identical data multiple times. A DECADE Server 1327 implementation may internally perform de-duplication of data on disk. 1328 The DECADE architecture enables additional forms of de-duplication. 1330 Note that these techniques may impact protocol design. Discussions 1331 of whether or not they should be adopted is out of the scope of this 1332 document. 1334 8.2.1. Traffic De-duplication 1336 8.2.1.1. Rationale 1338 When a DECADE client (A) indicates its DECADE account on a DECADE 1339 server (S) to fetch an object from a remote entity (R) (a DECADE 1340 server or DECADE client) and if the object is already stored locally 1341 in S, S may perform Traffic De-duplication. This means that S does 1342 not download the object from R, in order to save network traffic. In 1343 particular, S performs a challenge to make sure that the remote 1344 entity R actually has the object and then replies with its local 1345 object copy directly. 1347 8.2.1.2. An Example 1349 As shown in Figure 7, without Traffic De-duplication, unnecessary 1350 transfer of an object from R to S may happen, if the server S already 1351 has the object requested by A. If Traffic De-duplication is enabled, 1352 S only needs to challenge R to verify that it does have the data to 1353 avoid data-stealing attacks. 1355 A S R 1356 +----------+ obj req +------------+ obj req +----------+ 1357 | DECADE |=========>| A's |==========>| Remote | 1358 | CLIENT |<=========| Account |<==========| Entity | 1359 +----------+ obj rsp +------------+ obj rsp +----------+ 1361 (a) Without Traffic De-duplication 1363 A S R 1364 +----------+ obj req +------------+ challenge +----------+ 1365 | DECADE |=========>| A's |---------->| Remote | 1366 | CLIENT |<=========| Account |<----------| Entity | 1367 +----------+ obj rsp +------------+ obj hash +----------+ 1369 (b) With Traffic De-duplication 1371 Figure 7 1373 8.2.1.3. HTTP Compatibility of Challenge 1375 How to integrate traffic de-duplication with HTTP is shown in 1376 Appendix A.1.3. 1378 8.2.2. Cross-Server Storage De-duplication 1380 The same object might be uploaded multiple times to different DECADE 1381 servers. For storage efficiency, storage providers may desire that a 1382 single object be stored on one or a few servers. They might 1383 implement an internal mechanism to achieve the goal, for example, by 1384 redirecting requests to proper servers. DECADE supports the 1385 redirection of DECADE client requests to support further cross-server 1386 storage de-duplication. 1388 9. Security Considerations 1390 In general, the security considerations mentioned in 1391 [I-D.ietf-decade-problem-statement] apply to this document as well. 1393 In addition, it should be noted that the token-based approach 1394 Section 5.4 provides authorization through token delegation. The 1395 strength of this authorization depends on several factors: 1397 1. the uniqueness of tokens: tokens should be constructed in a way 1398 that minimize the possibilities for collisions; 1400 2. validity of tokens: applications/users should not re-use tokens; 1401 and 1403 3. secrecy of tokens: if tokens are compromised to unauthorized 1404 entities, access control for the associated resources cannot be 1405 provided. 1407 Depending on the specific application, DECADE can be used to access 1408 confidential information. Hence DECADE implementations SHOULD 1409 provide a secure transport mode that allows for encryption. 1411 10. IANA Considerations 1413 This document does not have any IANA considerations. 1415 11. Acknowledgments 1417 We thank the following people for their contributions to this 1418 document: 1420 David Bryan 1422 Yingjie Gu 1424 David McDysan 1426 Borje Ohlman 1428 Haibin Song 1430 Martin Stiemerling 1432 Richard Woundy 1434 Ning Zong 1436 12. References 1438 12.1. Normative References 1440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1441 Requirement Levels", BCP 14, RFC 2119, March 1997. 1443 12.2. Informative References 1445 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1446 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1447 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1449 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1450 Distributed Authoring and Versioning (WebDAV) 1451 Access Control Protocol", RFC 3744, May 2004. 1453 [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties fo 1454 r Distributed Authoring and Versioning (DAV) Collections", 1455 RFC 4331, February 2006. 1457 [RFC4709] Reschke, J., "Mounting Web Distributed Authoring and 1458 Versioning (WebDAV) Servers", RFC 4709, October 2006. 1460 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 1461 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 1463 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 1464 System (NFS) Version 4 Minor Version 1 Protocol", 1465 RFC 5661, January 2010. 1467 [RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- 1468 Network Storage Systems", RFC 6392, October 2011. 1470 [I-D.ietf-decade-problem-statement] 1471 Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 1472 Application Data Enroute (DECADE) Problem Statement", 1473 draft-ietf-decade-problem-statement-04 (work in progress), 1474 October 2011. 1476 [I-D.ietf-decade-reqs] 1477 Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE 1478 Requirements", draft-ietf-decade-reqs-04 (work in 1479 progress), September 2011. 1481 [GoogleStorageDevGuide] 1482 "Google Storage Developer Guide", . 1485 [GoogleFileSystem] 1486 Ghemawat, S., Gobioff, H., and S. Leung, "The Google File 1487 System", SOSP 2003, October 2003. 1489 [CDMI] "CDMI", . 1491 Appendix A. Appendix: Evaluation of Some Candidate Existing Protocols 1492 for DECADE DRP and SDT 1494 In this section we evaluate how well the abstract protocol 1495 interactions specified in Section 6 for DECADE DRP and SDT can be 1496 fulfilled by existing protocols such as HTTP, WEBDAV, and CDMI. 1498 A.1. HTTP 1500 HTTP [RFC2616] is a key protocol for the Internet in general and 1501 especially for the World Wide Web. HTTP is a request-response 1502 protocol. A typical transaction involves a client (e.g. web browser) 1503 requesting content (resources) from a web server. Another example is 1504 when a client stores or deletes content from a server. 1506 A.1.1. HTTP Support for DECADE Resource Protocol Primitives 1508 DRP provides configuration of access control and resource sharing 1509 policies on DECADE servers. 1511 A.1.1.1. Access Control Primitives 1513 Access control requires mechanisms for defining the access policies 1514 for the server, and then checking the authorization of a user before 1515 it stores or retrieves content. HTTP supports a rudimentary access 1516 control via "HTTP Secure" (HTTPS). HTTPS is a combination of HTTP 1517 with SSL/TLS. The main use of HTTPS is to authenticate the server 1518 and encrypt all traffic between the client and the server. There is 1519 also a mode to support client authentication though this is less 1520 frequently used. 1522 A.1.1.2. Communication Resource Controls Primitives 1524 Communication resources include bandwidth (upload/download) and 1525 number of simultaneous connected clients (connections). HTTP 1526 supports bandwidth control indirectly through "persistent" HTTP 1527 connections. Persistent HTTP connections allows a client to keep 1528 open the underlying TCP connection to the server to allow streaming 1529 and pipelining (multiple simultaneous requests for a given client). 1531 HTTP does not define protocol operation to allow limiting the 1532 communication resources to a client. However servers typically 1533 perform this function via implementation algorithms. 1535 A.1.1.3. Storage Resource Control Primitives 1537 Storage resources include amount of memory and lifetime of storage. 1538 HTTP does not allow direct control of storage at the server end 1539 point. However HTTP supports caching at intermediate points such as 1540 a web proxy. For this purpose, HTTP defines cache control mechanisms 1541 that define how long and in what situations the intermediate point 1542 may store and use the content. 1544 A.1.2. HTTP Support for DECADE Standard Data Transport Protocol 1545 Primitives 1547 SDT is used to write objects and read (download) objects from a 1548 DECADE server. The object can be either a self-contained object such 1549 as a multimedia file or a chunk from a P2P system. 1551 A.1.2.1. Writing Primitives 1553 Writing involves uploading objects to the server. HTTP supports two 1554 methods of writing called PUT and POST. In HTTP the object is called 1555 a resource and is identified by a URI. PUT uploads a resource to a 1556 specific location on the server. POST, on the other hand, submits 1557 the object to the server and the server decides whether to update an 1558 existing resource or to create a new resource. 1560 For DECADE, the choice of whether to use PUT or POST will be 1561 influenced by which entity is responsible for the naming. If the 1562 client performs the naming, then PUT is appropriate. If the server 1563 performs the naming, then POST should be used (to allow the server to 1564 define the URI). 1566 A.1.2.2. Downloading Primitives 1568 Downloading involves fetching of an object from the server. HTTP 1569 supports downloading through the GET and HEAD methods. GET fetches a 1570 specific resource as identified by the URL. HEAD is similar but only 1571 fetches the metadata ("header") associated with the resource but not 1572 the resource itself. 1574 A.1.3. Traffic De-duplication Primitives 1576 To challenge a remote entity for an object, the DECADE server should 1577 provide a seed number, which is generated by the server randomly, and 1578 ask the remote entity to return a hash calculated from the seed 1579 number and the content of the object. The server may also specify 1580 the hash function which the remote entity should use. HTTP supports 1581 the challenge message through the GET methods. The message type 1582 ("challenge"), the seed number and the hash function name are put in 1583 URL. In the reply, the hash is sent in an ETAG header. 1585 A.1.4. Other Operations 1587 HTTP supports deleting of content on the server through the DELETE 1588 method. 1590 A.1.5. Conclusions 1592 HTTP can provide a rudimentary DRP and SDT for some aspects of 1593 DECADE, but will not be able to satisfy all the DECADE requirements. 1594 For example, HTTP does not provide a complete access control 1595 mechanism, nor does it support storage resource controls at the end 1596 point server. 1598 It is possible, however, to envision combining HTTP with a custom 1599 suite of other protocols to fulfill most of the DECADE requirements 1600 for DRP and SDT. For example, Google Storage for Developers is built 1601 using HTTP (with extensive proprietary extensions such as custom HTTP 1602 headers). Google Storage also uses OAUTH 2.0 (for access control) in 1603 combination with HTTP [GoogleStorageDevGuide]. 1605 A.2. WEBDAV 1607 WebDAV [RFC4918] is a protocol for enhanced Web content creation and 1608 management. It was developed as an extension to HTTP Appendix A.1. 1609 WebDAV supports traditional operations for reading/writing from 1610 storage, as well as more advanced features such as locking and 1611 namespace management which are important when multiple users 1612 collaborate to author or edit a set of documents. HTTP is a subset 1613 of WebDAV functionality. Therefore, all the points noted above in 1614 Appendix A.1 apply implicitly to WebDAV as well. 1616 A.2.1. WEBDAV Support for DECADE Resource Protocol Primitives 1618 DRP provides configuration of access control and resource sharing 1619 policies on DECADE servers. 1621 A.2.1.1. Access Control Primitives 1623 Access control requires mechanisms for defining the access policies 1624 for the server, and then checking the authorization of a user before 1625 it stores or retrieves content. WebDAV has an Access Control 1626 Protocol defined in [RFC3744]. 1628 The goal of WebDAV access control is to provide an interoperable 1629 mechanism for handling discretionary access control for content and 1630 metadata managed by WebDAV servers. WebDAV defines an Access Control 1631 List (ACL) per resource. An ACL contains a set of Access Control 1632 Entries (ACEs), where each ACE specifies a principal (i.e. user or 1633 group of users) and a set of privileges that are granted to that 1634 principal. When a principal tries to perform an operation on that 1635 resource, the server evaluates the ACEs in the ACL to determine if 1636 the principal has permission for that operation. 1638 WebDAV also requires that an authentication mechanism be available 1639 for the server to validate the identity of a principal. As a 1640 minimum, all WebDAV compliant implementations are required to support 1641 HTTP Digest Authentication. 1643 A.2.1.2. Communication Resource Controls Primitives 1645 Communications resources include bandwidth (upload/download) and 1646 number of simultaneous connected clients (connections). WebDAV 1647 supports communication resource control as described in 1648 Appendix A.1.1.2. 1650 A.2.1.3. Storage Resource Control Primitives 1652 Storage resources include amount of memory and lifetime of storage. 1653 WebDAV supports the concept of properties (which are metadata for a 1654 resource). A property is either "live" or "dead". Live properties 1655 include cases where a) the value of a property is protected and 1656 maintained by the server, and b) the value of the property is 1657 maintained by the client, but the server performs syntax checking on 1658 submitted values. A dead property has its syntax and semantics 1659 enforced by the client; the server merely records the value of the 1660 property. 1662 WebDAV supports a list of standardized properties [RFC4918] that are 1663 useful for storage resource control. These include the self- 1664 explanatory "creationdate", and "getcontentlength" properties. There 1665 is also an operation called PROPFIND to retrieve all the properties 1666 defined for the requested URI. 1668 WebDAV also has a Quota and Size Properties mechanism defined in 1669 [RFC4331] that can be used for storage control. Specifically, two 1670 key properties are defined per resource: "quota-available-bytes" and 1671 "quota-used-bytes". 1673 WebDAV does not define protocol operation for storage resource 1674 control. However servers typically perform this function via 1675 implementation algorithms in conjunction with the storage related 1676 properties discussed above. 1678 A.2.2. WebDAV Support for DECADE Standard Transport Protocol Primitives 1680 SDT is used to write objects and read (download) objects from a 1681 DECADE server. The object can be either a self-contained object such 1682 as a multimedia file or a chunk from a P2P system. 1684 A.2.2.1. Writing Primitives 1686 Writing involves uploading objects to the server. WebDAV supports 1687 PUT and POST as described in Appendix A.1.2.1. WebDAV LOCK/UNLOCK 1688 functionality is not needed as DECADE assumes immutable data objects. 1689 Therefore, resources cannot be edited and so do not need to be 1690 locked. This approach should help to greatly simplify DECADE 1691 implementations as the LOCK/UNLOCK functionality is quite complex. 1693 A.2.2.2. Downloading Primitives 1695 Downloading involves fetching of an object from the server. WebDAV 1696 supports GET and HEAD as described in Appendix A.1.2.2. WebDAV LOCK/ 1697 UNLOCK functionality is not needed as DECADE assumes immutable data 1698 objects. 1700 A.2.3. Other Operations 1702 WebDAV supports DELETE as described in Appendix A.1.4. In addition 1703 WebDAV supports COPY and MOVE methods. The COPY operation creates a 1704 duplicate of the source resource identified by the Request-URI, in 1705 the destination resource identified by the URI in the Destination 1706 header. 1708 The MOVE operation on a resource is the logical equivalent of a COPY, 1709 followed by consistency maintenance processing, followed by a delete 1710 of the source, where all three actions are performed in a single 1711 operation. The consistency maintenance step allows the server to 1712 perform updates caused by the move, such as updating all URLs, other 1713 than the Request-URI that identifies the source resource, to point to 1714 the new destination resource. 1716 WebDAV also supports the concept of "collections" of resources to 1717 support joint operations on related objects (e.g. file system 1718 directories) within a server's namespace. For example, GET and HEAD 1719 may be done on a single resource (as in HTTP) or on a collection. 1720 The MKCOL operation is used to create a new collection. DECADE may 1721 find the concept of collections to be useful if there is a need to 1722 support directory like structures in DECADE. 1724 WebDAV servers can be interfaced from an HTML-based user interface in 1725 a web browser. However, it is frequently desirable to be able to 1726 switch from an HTML-based view to a presentation provided by a native 1727 WebDAV client, directly supporting WebDAV features. The method to 1728 perform this in a platform-neutral mechanism is specified in the 1729 WebDAV protocol for "mounting WebDAV servers" [RFC4709]. This type 1730 of feature may also be attractive for DECADE clients. 1732 A.2.4. Conclusions 1734 WebDAV has a rich array of features that can provide a good base for 1735 DRP and SDT for DECADE. An initial analysis finds that the following 1736 WebDAV features will be useful for DECADE: 1738 - access control 1740 - properties (and PROPFIND operation) 1742 - COPY/MOVE operations 1744 - collections 1746 - mounting WebDAV servers 1748 It is recommended that the following WebDAV features NOT be used for 1749 DECADE: 1751 - LOCK/UNLOCK 1753 Finally, some extensions to WebDAV may still be required to meet all 1754 DECADE requirements. For example, defining a new WebDAV "time-to- 1755 live" property may be useful for DECADE. Further analysis is 1756 required to fully define the potential extensions to WebDAV to meet 1757 all DECADE requirements. 1759 A.3. CDMI 1761 The Cloud Data Management Interface (CDMI) specification defines a 1762 functional interface through which applications can store and manage 1763 data objects in a cloud storage environment. The CDMI interface for 1764 reading/writing data is based on standard HTTP requests, with CDMI- 1765 specific encodings using JavaScript Object Notation (JSON). CDMI is 1766 specified by the Storage Networking Industry Association (SNIA) 1767 [CDMI]. 1769 A.3.1. CDMI Support for DECADE Resource Protocol Primitives 1771 DRP provides configuration of access control and resource sharing 1772 policies on DECADE servers. 1774 A.3.1.1. Access Control Primitives 1776 Access control includes mechanisms for defining the access policies 1777 for the server, and then checking the authorization of a user before 1778 it stores or retrieves content. CDMI defines an Access Control List 1779 (ACL) per data object, and thus supports access control (read and/or 1780 write) at the data object granularity. An ACL contains a set of 1781 Access Control Entries (ACEs), where each ACE specifies a principal 1782 (i.e. user or group of users) and a set of privileges that are 1783 granted to that principal. 1785 CDMI requires that an HTTP authentication mechanism be available for 1786 the server to validate the identity of a principal (client). 1787 Specifically, CDMI requires that either HTTP Basic Authentication or 1788 HTTP Digest Authentication be supported. CDMI recommends that HTTP 1789 over TLS (HTTPS) is supported to encrypt the data sent over the 1790 network. 1792 A.3.1.2. Communication Resource Controls Primitives 1794 Communication resources include bandwidth (upload/download) and 1795 number of simultaneous connected clients (connections). CDMI 1796 supports two key data attributes which provide control over the 1797 communication resources to a client: "cdmi_max_throughput" and 1798 "cdmi_max_latency". These attributes are defined in the metadata for 1799 data objects and indicate the desired bandwidth or delay for 1800 transmission of the data object from the cloud server to the client. 1802 A.3.1.3. Storage Resource Control Primitives 1804 Storage resources include amount of quantity and lifetime of storage. 1805 CDMI defines metadata for individual data objects and general storage 1806 system configuration which can be used for storage resource control. 1807 In particular, CDMI defines the following metadata fields: 1809 - cdmi_data_redundancy: desired number of copies to be 1810 maintained, 1812 - cdmi_geographic_placement: region where object is permitted to 1813 be stored, 1815 - cdmi_retention_period: time interval object is to be retained, 1816 and 1818 - cdmi_retention_autodelete: whether object should be auto 1819 deleted after retention period. 1821 A.3.2. CDMI Support for DECADE Standard Transport Protocol Primitives 1823 SDT is used to write objects and read (download) objects from a 1824 DECADE server. The object can be either a self-contained object such 1825 as a multimedia file or a chunk from a P2P system. 1827 A.3.2.1. Writing Primitives 1829 Writing involves uploading objects to the server. CDMI supports 1830 standard HTTP methods for PUT and POST as described in 1831 Appendix A.1.2.1. 1833 A.3.2.2. Downloading Primitives 1835 Downloading involves fetching of an object from the server. CDMI 1836 supports the standard HTTP GET method as described in 1837 Appendix A.1.2.2. 1839 A.3.3. Other Operations 1841 CDMI supports DELETE as described in Appendix A.1.4. CDMI also 1842 supports COPY and MOVE operations. 1844 CDMI supports the concept of containers of data objects to support 1845 joint operations on related objects. For example, GET may be done on 1846 a single data object or on an entire container. 1848 CDMI supports a global naming scheme. Every object stored within a 1849 CDMI system will have a globally unique object string identifier 1850 (ObjectID) assigned at creation time. 1852 A.3.4. Conclusions 1854 CDMI has a rich array of features that can provide a good base for 1855 DRP and SDT for DECADE. An initial analysis finds that the following 1856 CDMI features may be useful for DECADE: 1858 - access control 1860 - storage resource control 1862 - communication resource control 1864 - COPY/MOVE operations 1866 - data containers 1868 - naming scheme 1870 Appendix B. In-Network Storage Components Mapped to DECADE Architecture 1872 In this section we evaluate how the basic components of an in-network 1873 storage system identified in Section 3 of [RFC6392] map into the 1874 DECADE architecture. 1876 It is important to note that complex and/or application-specific 1877 behavior is delegated to applications instead of tuning the storage 1878 system wherever possible. 1880 B.1. Data Access Interface 1882 Users can read and write objects of arbitrary size through the DECADE 1883 Client's Data Controller, making use of a standard data transport. 1885 B.2. Data Management Operations 1887 Users can move or delete previously stored objects via the DECADE 1888 Client's Data Controller, making use of a standard data transport. 1890 B.3. Data Search Capability 1892 Users can enumerate or search contents of DECADE servers to find 1893 objects matching desired criteria through services provided by the 1894 Content Distribution Application (e.g., buffer-map exchanges, a DHT, 1895 or peer-exchange). In doing so, End-Points may consult their local 1896 Data Index in the DECADE Client's Data Controller. 1898 B.4. Access Control Authorization 1900 All methods of access control are supported: public-unrestricted, 1901 public-restricted and private. Access Control Policies are generated 1902 by a Content Distribution Application and provided to the DECADE 1903 Client's Resource Controller. The DECADE Server is responsible for 1904 implementing the access control checks. 1906 B.5. Resource Control Interface 1908 Users can manage the resources (e.g. bandwidth) on the DECADE server 1909 that can be used by other Application End-Points. Resource Sharing 1910 Policies are generated by a Content Distribution Application and 1911 provided to the DECADE Client's Resource Controller. The DECADE 1912 Server is responsible for implementing the resource sharing policies. 1914 B.6. Discovery Mechanism 1916 The particular protocol used for discovery is outside the scope of 1917 this document. However, options and considerations have been 1918 discussed in Section 5.5. 1920 B.7. Storage Mode 1922 DECADE Servers provide an object-based storage mode. Immutable data 1923 objects may be stored at a DECADE server. Applications may consider 1924 existing blocks as DECADE data objects, or they may adjust block 1925 sizes before storing in a DECADE server. 1927 Authors' Addresses 1929 Richard Alimi 1930 Google 1932 Email: ralimi@google.com 1934 Y. Richard Yang 1935 Yale University 1937 Email: yry@cs.yale.edu 1939 Akbar Rahman 1940 InterDigital Communications, LLC 1942 Email: akbar.rahman@interdigital.com 1944 Dirk Kutscher 1945 NEC 1947 Email: dirk.kutscher@neclab.eu 1949 Hongqiang Liu 1950 Yale University 1952 Email: hongqiang.liu@yale.edu