idnits 2.17.1 draft-ietf-decade-arch-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (February 7, 2013) is 4089 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6749' is defined on line 1265, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 A. Rahman 5 Expires: August 11, 2013 InterDigital Communications, LLC 6 D. Kutscher 7 NEC 8 Y. Yang 9 Yale University 10 H. Song 11 K. Pentikousis 12 Huawei 13 February 7, 2013 15 DECADE Protocol 16 draft-ietf-decade-arch-10 18 Abstract 20 Content Distribution Applications (e.g., P2P applications) are widely 21 used on the Internet and make up a large portion of the traffic in 22 many networks. One technique to improve the network efficiency of 23 these applications is to introduce storage capabilities within the 24 networks; this is the capability provided by a DECADE (DECoupled 25 Application Data Enroute) compatible system. This document presents 26 an architecture, discusses the underlying principles, and identifies 27 key functionalities in the architecture for introducing a DECADE in- 28 network storage system. In addition, some examples are given to 29 illustrate these concepts. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 11, 2013. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4. Architectural Principles . . . . . . . . . . . . . . . . . . . 6 77 4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 6 78 4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 7 79 4.3. Data Objects With Identifiers . . . . . . . . . . . . . . 8 80 4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . . 9 81 4.5. Resource and Data Access Control through Delegation . . . 10 82 5. System Components . . . . . . . . . . . . . . . . . . . . . . 11 83 5.1. Content Distribution Application . . . . . . . . . . . . . 11 84 5.2. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 13 85 5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 15 86 5.4. Token-based Authorization and Resource Control . . . . . . 16 87 5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 18 89 6.1. DECADE Naming . . . . . . . . . . . . . . . . . . . . . . 18 90 6.2. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 19 91 6.3. Standard Data Transfer (SDT) Protocol . . . . . . . . . . 23 92 6.4. Server-to-Server Protocols . . . . . . . . . . . . . . . . 24 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 94 7.1. Threat: System Denial of Service Attacks . . . . . . . . . 25 95 7.2. Threat: Protocol Security . . . . . . . . . . . . . . . . 26 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 97 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 101 Appendix A. In-Network Storage Components Mapped to DECADE 102 Architecture . . . . . . . . . . . . . . . . . . . . 29 103 A.1. Data Access Interface . . . . . . . . . . . . . . . . . . 29 104 A.2. Data Management Operations . . . . . . . . . . . . . . . . 29 105 A.3. Data Search Capability . . . . . . . . . . . . . . . . . . 29 106 A.4. Access Control Authorization . . . . . . . . . . . . . . . 29 107 A.5. Resource Control Interface . . . . . . . . . . . . . . . . 30 108 A.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 30 109 A.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 30 110 Appendix B. Hisotry . . . . . . . . . . . . . . . . . . . . . . . 30 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 113 1. Introduction 115 Content Distribution Applications, such as Peer-to-Peer (P2P) 116 applications, are widely used on the Internet to distribute data, and 117 they contribute a large portion of the traffic in many networks. The 118 architecture described in this document enables such applications to 119 leverage in-network storage to achieve more efficient content 120 distribution (i.e. DECADE system). Specifically, in many subscriber 121 networks, it can be expensive to upgrade network equipment in the 122 "last-mile", because it can involve replacing equipment and upgrading 123 wiring at individual homes, businesses, and devices such as DSLAMs 124 (Digital Subscriber Line Access Multiplexers) and CMTSs (Cable Modem 125 Termination Systems) in remote locations. Therefore, it may be 126 cheaper to upgrade the core infrastructure, which involves fewer 127 components that are shared by many subscribers. See [RFC6646] for a 128 more complete discussion of the problem domain and general 129 discussions of the capabilities to be provided by a DECADE system. 131 This document presents an architecture for providing in-network 132 storage that can be integrated into Content Distribution 133 Applications. The primary focus is P2P-based content distribution, 134 but the architecture may be useful to other applications with similar 135 characteristics and requirements. See [I-D.ietf-decade-reqs] for a 136 definition of the target applications as well as the requirements for 137 a DECADE system. 139 The approach of this document is to define the core functionalities 140 and protocol functions that are needed to support a DECADE system. 141 The specific protocols are not selected or designed in this document. 142 Some illustrative examples are given to help the reader understand 143 certain concepts. These examples are purely informational and are 144 not meant to constrain future protocol design or selection. 146 2. Terminology 148 This document assumes readers are familiar with the terms and 149 concepts that are used in [RFC6646] and [I-D.ietf-decade-reqs]. 151 3. Protocol Flow 153 3.1. Overview 155 Following[I-D.ietf-decade-reqs], the architecture consists of two 156 protocols: the DECADE Resource Protocol (DRP) that is responsible for 157 communication of access control and resource scheduling policies from 158 a client to a server, as well as between servers; and Standard Data 159 Transfer (SDT) protocol(s) that will be used to transfer data objects 160 to and from a server. We show the protocol components figure below: 162 Native Application 163 .-------------. Protocol(s) .-------------. 164 | Application | <------------------> | Application | 165 | End-Point | | End-Point | 166 | | | | 167 | .--------. | | .--------. | 168 | | DECADE | | | | DECADE | | 169 | | Client | | | | Client | | 170 | `--------' | | `--------' | 171 `-------------' `-------------' 172 | ^ | ^ 173 DECADE | | Standard | | 174 Resource | | Data DRP | | SDT 175 Protocol | | Transfer | | 176 (DRP) | | (SDT) | | 177 | | | | 178 | | | | 179 | | | | 180 | | | | 181 | | | | 182 | | | | 183 v V v V 184 .=============. DRP .=============. 185 | DECADE | <------------------> | DECADE | 186 | Server | <------------------> | Server | 187 `=============' SDT `=============' 189 Figure 1: Generic Protocol Flow 191 3.2. An Example 193 This section provides an example showing the steps in the 194 architecture for a data transfer scenario involving an in-network 195 storage system. We assume that Application End-Point B (the 196 receiver) is requesting a data object from Application End-Point A 197 (the sender). Let S(A) denote the DECADE storage server to which A 198 has access. There are multiple usage scenarios (by choice of the 199 Content Distribution Application). For simplicity of introduction, 200 we design this example to use only a single DECADE server. 202 The steps of the example are illustrated in Figure 2. First, B 203 requests a data object from A using their native application protocol 204 (see Section 5.1.2). Next, A uses the DRP to obtain a token. There 205 are multiple ways for A to obtain the token: compute locally, or 206 request from its DECADE storage server, S(A). See Section 6.2.2 for 207 details. A then provides the token to B (again, using their native 208 application protocol). Finally, B provides the token to S(A) via 209 DRP, and requests and downloads the data object via a SDT. 211 .----------. 212 2. Obtain --------> | S(A) | <------ 213 Token / `----------' \ 4. Request and 214 (DRP) / \ Download Data 215 Locally / \ Object 216 or From / \ (DRP + SDT) 217 S(A) v 1. App Request v 218 .-------------. <--------------------------- .-------------. 219 | Application | | Application | 220 | End-Point A | | End-Point B | 221 `-------------' ---------------------------> `-------------' 222 3. App Response (token) 224 Figure 2: Download from Storage Server 226 4. Architectural Principles 228 We identify the following key principles that will be followed in any 229 DECADE system: 231 4.1. Decoupled Control/Metadata and Data Planes 233 A DECADE system SHOULD be able to support multiple Content 234 Distribution Applications. A complete Content Distribution 235 Application implements a set of "control plane" functions including 236 content search, indexing and collection, access control, replication, 237 request routing, and QoS scheduling. Different Content Distribution 238 Applications will have unique considerations designing the control 239 plane functions: 241 o Metadata Management Scheme: Traditional file systems provide a 242 standard metadata abstraction: a recursive structure of 243 directories to offer namespace management; each file is an opaque 244 byte stream. Content Distribution Applications may use different 245 metadata management schemes. For example, one application might 246 use a sequence of blocks (e.g., for file sharing), while another 247 application might use a sequence of frames (with different sizes) 248 indexed by time. 250 o Resource Scheduling Algorithms: A major advantage of many 251 successful P2P systems is their substantial expertise in achieving 252 highly efficient utilization of peer and infrastructural 253 resources. For instance, many streaming P2P systems have their 254 specific algorithms in constructing topologies to achieve low- 255 latency, high-bandwidth streaming. They continuously fine-tune 256 such algorithms. 258 Given the diversity of control plane functions, a DECADE system 259 SHOULD allow as much flexibility as possible to the control plane to 260 implement specific policies. This conforms to the end-to-end systems 261 principle and allows innovation and satisfaction of specific 262 performance goals. 264 Decoupling control plane and data plane is not new. For example, 265 OpenFlow [OpenFlow] is an implementation of this principle for 266 Internet routing, where the computation of the forwarding table and 267 the application of the forwarding table are separated. Google File 268 System [GoogleFileSystem] applies the principle to file system 269 design, by utilizing the Master to handle the meta-data management, 270 and the Chunk servers to handle the data plane functions (i.e., read 271 and write of chunks of data). NFSv4.1's pNFS extension [RFC5661] 272 also implements this principle. 274 4.2. Immutable Data Objects 276 A property of bulk content to be broadly distributed is that they 277 typically are immutable -- once content is generated, it is typically 278 not modified. It is not common that bulk content such as video 279 frames and images need to be modified after distribution. 281 Focusing on immutable data in the data plane can substantially 282 simplify the data plane design, since consistency requirements can be 283 relaxed. It also simplifies reuse of data and implementation of de- 284 duplication. 286 Depending on its specific requirements, an application may store 287 immutable data objects in DECADE servers such that each data object 288 is completely self-contained (e.g., a complete, independently 289 decodable video segment). An application may also divide data into 290 data objects that require application level assembly. Many Content 291 Distribution Applications divide bulk content into data objects for 292 multiple reasons, including (1) fetching different data objects from 293 different sources in parallel; and (2) faster recovery and 294 verification: individual data objects might be recovered and 295 verified. Typically, applications use a data object size larger than 296 a single packet in order to reduce control overhead. 298 A DECADE system SHOULD be agnostic to the nature of the data objects 299 and SHOULD NOT specify a fixed size for them. A protocol 300 specification based on this architecture MAY prescribe requirements 301 on minimum and maximum sizes by compliant implementations. 303 Immutable data objects can still be deleted. Applications may 304 support modification of existing data stored at a DECADE server 305 through a combination of storing new data objects and deleting 306 existing data objects. For example, a meta-data management function 307 of the control plane might associate a name with a sequence of 308 immutable data objects. If one of the data objects is modified, the 309 meta-data management function changes the mapping of the name to a 310 new sequence of immutable data objects. 312 Throughout this document, all data objects are assumed to be 313 immutable. 315 4.3. Data Objects With Identifiers 317 An object that is stored in a DECADE storage server SHALL be accessed 318 by Content Consumers via a data object identifier. 320 A Content Consumer may be able to access more than one storage 321 server. A data object that is replicated across different storage 322 servers managed by a DECADE Storage Provider MAY still be accessed by 323 a single identifier. 325 Since data objects are immutable, it SHALL be possible to support 326 persistent identifiers for data objects. 328 Data object identifiers for data objects SHOULD be created by Content 329 Providers that upload the objects to servers. We refer to a scheme 330 for the assignment/derivation of the data object identifier to a data 331 object depends as the data object naming scheme. The details of data 332 naming schemes will be provided by future DECADE protocol/naming 333 specifications. This document describes naming schemes on a semantic 334 level and specific SDTs and DRPs SHOULD use specific representations. 336 In particular, for some applications it is important that clients and 337 servers SHOULD be able to validate the name-object binding for a data 338 object, i.e., by verifying that a received object really corresponds 339 to the name (identifier) that was used for requesting it (or that was 340 provided by a sender). Data object identifiers can support name- 341 object binding validation by providing message digests or so-called 342 self-certifying naming information -- if a specific application has 343 this requirement. 345 A DECADE naming scheme follows the following general requirements: 347 o Different name-object binding validation mechanisms MAY be 348 supported; 350 o Content Distribution Applications will decide what mechanism to 351 use, or to not provide name-object validation (e.g., if 352 authenticity and integrity can by ascertained by alternative 353 means); 355 o Applications MAY be able to construct unique names (with high 356 probability) without requiring a registry or other forms of 357 coordination; and 359 o Names MAY be self-describing so that a receiving entity (Content 360 Consumer) knows what hash function (for example) to use for 361 validating name-object binding. 363 Some Content Distribution Applications will derive the name of a data 364 object from the hash over the data object, which is made possible by 365 the fact that DECADE objects are immutable. But there may be other 366 applications such as live streaming where object names will not based 367 on hashes but rather on an enumeration scheme. The naming scheme 368 will also enable those applications to construct unique names. 370 In order to enable the uniqueness, flexibility and self-describing 371 properties, the naming scheme SHOULD provide the following name 372 elements: 374 o A "type" field that indicates the name-object validation function 375 type (for example, "sha-256"); 377 o Cryptographic data (such as an object hash) that corresponds to 378 the type information; and 380 The naming scheme MAY additionally provide the following name 381 elements: 383 o Application or publisher information. 385 The specific format of the name (e.g., encoding, hash algorithms, 386 etc) is out of scope of this document, and is left for protocol 387 specification. 389 4.4. Explicit Control 391 To support the functions of an application's control plane, 392 applications SHOULD be able to know and coordinate which data is 393 stored at particular servers. Thus, in contrast with traditional 394 caches, applications are given explicit control over the placement 395 (selection of a DECADE server), deletion (or expiration policy), and 396 access control for stored data. 398 Consider deletion/expiration policy as a simple example. An 399 application might require that a server stores data objects for a 400 relatively short period of time (e.g., for live-streaming data). 401 Another application might need to store data objects for a longer 402 duration (e.g., for video-on-demand). 404 4.5. Resource and Data Access Control through Delegation 406 A DECADE system will provide a shared infrastructure to be used by 407 multiple Content Consumers and Content Providers spanning multiple 408 Content Distribution Applications. Thus, it needs to provide both 409 resource and data access control. 411 4.5.1. Resource Allocation 413 There are two primary interacting entities in a DECADE system. 414 First, Storage Providers SHOULD coordinate where storage servers are 415 provisioned and their total available resources Section 6.2.1. 416 Second, Applications will coordinate data transfers amongst available 417 servers and between servers and clients. A form of isolation is 418 required to enable concurrently-running Applications to each 419 explicitly manage its own data objects and share of resources at the 420 available servers. 422 The Storage Provider SHOULD delegate the management of the resources 423 on a server to Content Providers. This means that Content Providers 424 are able to explicitly and independently manage their own shares of 425 resources on a server. 427 4.5.2. User Delegations 429 Storage Providers will have the ability to explicitly manage the 430 entities allowed to utilize the resources at a DECADE server. This 431 capability is needed for reasons such as capacity-planning and legal 432 considerations in certain deployment scenarios. 434 The server SHOULD grant a share of the resources to a Content 435 Provider or Content Consumer. The client can in turn share the 436 granted resources amongst its multiple applications. The share of 437 resources granted by a server is called a User Delegation. 439 As a simple example, a DECADE server operated by an ISP might be 440 configured to grant each ISP Subscriber 1.5 Mbit/s of bandwidth. The 441 ISP Subscriber might in turn divide this share of resources amongst a 442 video streaming application and file-sharing application which are 443 running concurrently. 445 5. System Components 447 The primary focus of this document is the architectural principles 448 and the system components that implement them. While certain system 449 components might differ amongst implementations, the document details 450 the major components and their overall roles in the architecture. 452 To keep the scope narrow, we only discuss the primary components 453 related to protocol development. Particular deployments will require 454 additional components (e.g., monitoring and accounting at a server), 455 but they are intentionally omitted from this document. 457 5.1. Content Distribution Application 459 Content Distribution Applications have many functional components. 460 For example, many P2P applications have components and algorithms to 461 manage overlay topology management, rate allocation, piece selection, 462 etc. In this document, we focus on the components directly employed 463 to support a DECADE system. 465 Figure 3 illustrates the components discussed in this section from 466 the perspective of a single Application End-Point. 468 Native Protocol(s) 469 (with other Application End-Points) 470 .---------------------> 471 | 472 | 473 .----------------------------------------------------------. 474 | Application End-Point | 475 | .------------. .-------------------. | 476 | | App-Layer | ... | App Data Assembly | | 477 | | Algorithms | | Sequencing | | 478 | `------------' `-------------------' | 479 | | 480 | .------------------------------------------------------. | 481 | | DECADE Client | | 482 | | | | 483 | | .-------------------------. .----------------------. | | 484 | | | Resource Controller | | Data Controller | | | 485 | | | .--------. .----------. | | .--------. .-------. | | | 486 | | | | Data | | Resource | | | | Data | | Data | | | | 487 | | | | Access | | Sharing | | | | Sched. | | Index | | | | 488 | | | | Policy | | Policy | | | | | | | | | | 489 | | | '--------' `----------' | | `--------' `-------' | | | 490 | | `-------------------------' `----------------------' | | 491 | | | ^ | | 492 | `------------ | ----------------- | -------------------' | 493 `-------------- | ----------------- | ---------------------' 494 | | 495 | DECADE | Standard 496 | Resource | Data 497 | Protocol | Transfer 498 | (DRP) | (SDT) 499 v V 501 Figure 3: Application Components 503 5.1.1. Data Assembly 505 A DECADE system is geared towards supporting applications that can 506 distribute content using data objects. To accomplish this, 507 applications can include a component responsible for creating the 508 individual data objects before distribution and then re-assembling 509 data objects at the Content Consumer. We call this component the 510 Application Data Assembly. 512 In producing and assembling the data objects, two important 513 considerations are sequencing and naming. A DECADE system assumes 514 that applications implement this functionality themselves. See 515 Section 6.1 for further discussion. 517 5.1.2. Native Application Protocols 519 In addition to the DECADE DRP/SDT, applications can also support 520 existing native application protocols (e.g., P2P control and data 521 transfer protocols). 523 5.1.3. DECADE Client 525 The client provides the local support to an application, and can be 526 implemented standalone, embedded into the application, or integrated 527 in other entities such as network devices themselves. 529 5.1.3.1. Resource Controller 531 Applications may have different Resource Sharing Policies and Data 532 Access Policies to control their resource and data in DECADE servers. 533 These policies may be existing policies of applications or custom 534 policies. The specific implementation is decided by the application. 536 5.1.3.2. Data Controller 538 A DECADE system decouples the control and the data transfer of 539 applications. A Data Scheduling component schedules data transfers 540 according to network conditions, available servers, and/or available 541 server resources. The Data Index indicates data available at remote 542 servers. The Data Index (or a subset of it) can be advertised to 543 other clients. A common use case for this is to provide the ability 544 to locate data amongst distributed Application End-Points (i.e., a 545 data search mechanism such as a Distributed Hash Table). 547 5.2. DECADE Server 549 Figure 4 illustrates the components discussed in a DECADE server. A 550 server is not necessarily a single physical machine, it can also be 551 implemented as a cluster of machines. 553 | | 554 | DECADE | Standard 555 | Resource | Data 556 | Protocol | Transfer 557 | (DRP) | (SDT) 558 | | 559 .= | ================= | ======================. 560 | | v | 561 | | .----------------. | 562 | |----> | Access Control | <--------. | 563 | | `----------------' | | 564 | | ^ | | 565 | | | | | 566 | | v | | 567 | | .---------------------. | | 568 | `-> | Resource Scheduling | <------| | 569 | `---------------------' | | 570 | ^ | | 571 | | | | 572 | v .------------. | 573 | .-----------------. | User | | 574 | | Data Store | | Delegation | | 575 | `-----------------' | Management | | 576 | DECADE Server `------------' | 577 `==============================================' 579 Figure 4: DECADE Server Components 581 5.2.1. Access Control 583 A client SHALL be able to access its own data or other client's data 584 (provided sufficient authorization) in DECADE servers. Clients MAY 585 also authorize other clients to store data. If an access is 586 authorized by a client, the server SHOULD provide access. Even if a 587 request is authorized, it MAY still fail to complete due to 588 insufficient resources at the server. 590 5.2.2. Resource Scheduling 592 Applications will apply resource sharing policies or use a custom 593 policy. Servers perform resource scheduling according to the 594 resource sharing policies indicated by clients as well as configured 595 User Delegations. 597 5.2.3. Data Store 599 Data from applications will be stored at a DECADE server. Data may 600 be deleted from storage either explicitly or automatically (e.g., 601 after a TTL expiration). 603 5.3. Data Sequencing and Naming 605 The DECADE naming scheme implies no sequencing or grouping of 606 objects, even if this is done at the application layer. 608 5.3.1. Application Usage Example 610 To illustrate these properties, this section presents multiple 611 examples. 613 5.3.1.1. Application with Fixed-Size Chunks 615 Similar to the example in Section 5.1.1, consider an Application in 616 which each individual application-layer segment of data is called a 617 "chunk" and has a name of the form: "CONTENT_ID:SEQUENCE_NUMBER". 618 Furthermore, assume that the application's native protocol uses 619 chunks of size 16 KiB. 621 Now, assume that this application wishes to store data in DECADE 622 servers in data objects of size 64 KiB. To accomplish this, it can 623 map a sequence of 4 chunks into a single data object, as shown in 624 Figure 5. 626 Application Chunks 627 .---------.---------.---------.---------.---------.---------.-------- 628 | | | | | | | 629 | Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6 630 | | | | | | | 631 `---------`---------`---------`---------`---------`---------`-------- 633 DECADE Data Objects 634 .---------------------------------------.---------------------------- 635 | | 636 | Object_0 | Object_1 637 | | 638 `---------------------------------------`---------------------------- 640 Figure 5: Mapping Application Chunks to DECADE Data Objects 642 In this example, the Application maintains a logical mapping that is 643 able to determine the name of a DECADE data object given the chunks 644 contained within that data object. The name may be learned from 645 either the original Content Provider, another End-Point with which 646 the Application is communicating, etc. As long as the data contained 647 within each sequence of chunks is globally unique, the corresponding 648 data objects have globally unique names. 650 5.3.1.2. Application with Continuous Streaming Data 652 Consider an Application whose native protocol retrieves a continuous 653 data stream (e.g., an MPEG2 stream) instead of downloading and 654 redistributing chunks of data. Such an application could segment the 655 continuous data stream to produce either fixed-sized or variable- 656 sized data objects. 658 Figure 6 shows how a video streaming application might produce 659 variable-sized data objects such that each data object contains 10 660 seconds of video data. 662 Application's Video Stream 663 .-------------------------------------------------------------------- 664 | 665 | 666 | 667 `-------------------------------------------------------------------- 668 ^ ^ ^ ^ ^ 669 | | | | | 670 0 Seconds 10 Seconds 20 Seconds 30 Seconds 40 Seconds 671 0 B 400 KiB 900 KiB 1200 KiB 1500 KiB 673 DECADE Data Objects 674 .--------------.--------------.--------------.--------------.-------- 675 | | | | | 676 | Object_0 | Object_1 | Object_2 | Object_3 | 677 | (400 KiB) | (500 KiB) | (300 KiB) | (300 KiB) | 678 `--------------`--------------`--------------`--------------`-------- 680 Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects 682 Similar to the previous example, the Application might maintain a 683 mapping that is able to determine the name of a data object given the 684 time offset of the video chunk. 686 5.4. Token-based Authorization and Resource Control 688 A key feature of a DECADE system is that an application endpoint can 689 authorize other application endpoint to store or retrieve data 690 objects from the in-network storage. An OAuth version 2 691 [RFC6749]based authorization scheme is used to accomplish this. A 692 separate OAuth flow is used for this purpose, 693 a client authenticates (optional and out of the scope of this 694 document) with the application server or the P2P application peer, 695 and request the trusted by the client, and the token contains 696 particular self contained properties (see Section 6.2.2 for details). 697 The client then use the token when sending requests to the DECADE 698 server. Upon receiving a token, the server validates the signature 699 and the operation being performed. 701 This is a simple scheme, but has some important advantages over an 702 alternative approach in which a client explicitly manipulates an 703 Access Control List (ACL) associated with each data object. In 704 particular, it has the following advantages when applied to DECADE 705 target applications: 707 o Authorization policies are implemented within the Application; an 708 Application explicitly controls when tokens are generated and to 709 whom they are distributed and for how long they will be valid. 711 o Fine-grained access and resource control can be applied to data 712 objects; see Section 6.2.2 for the list of restrictions that can 713 be enforced with a token. 715 o There is no messaging between a client and server to manipulate 716 data object permissions. This can simplify, in particular, 717 Applications which share data objects with many dynamic peers and 718 need to frequently adjust access control policies attached to data 719 objects. 721 o Tokens can provide anonymous access, in which a server does not 722 need to know the identity of each client that accesses it. This 723 enables a client to send tokens to clients belonging to other 724 Storage Providers, and allow them to read or write data objects 725 from the storage of its own Storage Provider. 727 In addition to clients applying access control policies to data 728 objects, the server MAY be configured to apply additional policies 729 based on user, object, geographic location, etc. A client might thus 730 be denied access even though it possesses a valid token. 732 There are existing protocols (e.g., OAuth [RFC5849]) that implement 733 similar referral mechanisms using tokens. A protocol specification 734 of this architecture SHOULD endeavor to use existing mechanisms 735 wherever possible. 737 5.5. Discovery 739 A DECADE system SHOULD include a discovery mechanism through which 740 clients locate an appropriate server. [I-D.ietf-decade-reqs] details 741 specific requirements of the discovery mechanism; this section 742 discusses how they relate to other principles outlined in this 743 document. 745 A discovery mechanism SHOULD allow a client to determine an IP 746 address or some other identifier that can be resolved to locate the 747 server for which the client will be authorized to generate tokens 748 (via DRP). (The discovery mechanism might also result in an error if 749 no such servers can be located.) After discovering one or more 750 servers, a client can distribute load and requests across them 751 (subject to resource limitations and policies of the servers 752 themselves) according to the policies of the Application End-Point in 753 which it is embedded. 755 The particular protocol used for discovery is out of scope of this 756 document, but any specification SHOULD re-use standard protocols 757 wherever possible. 759 The discovery mechanism outlined here does not provide the ability to 760 locate arbitrary DECADE servers to which a client might obtain tokens 761 from others. To do so will require application-level knowledge, and 762 it is assumed that this functionality is implemented in the Content 763 Distribution Application. 765 6. DECADE Protocols 767 This section presents the DRP and the SDT protocol in terms of 768 abstract protocol interactions that are intended to be mapped to 769 specific protocols. In general, the DRP/SDT functionality between a 770 DECADE client-server are very similar to the DRP/SDT functionality 771 between server-server. Any differences are highlighted below. 773 DRP will be the protocol used by a DECADE client to configure the 774 resources and authorization used to satisfy requests (reading, 775 writing, and management operations concerning data objects) at a 776 server. SDT will be used to transport data between a client and a 777 server. 779 6.1. DECADE Naming 781 A DECADE system SHOULD use the [I-D.farrell-decade-ni] as the 782 recommended and default naming scheme. Other naming schemes that 783 meet the guidelines in Section 4.3 may alternatively be used. 785 In order to provide a simple and generic interface, the DECADE server 786 will be responsible only for storing and retrieving individual data 787 objects. 789 The DECADE naming format SHOULD NOT attempt to replace any naming or 790 sequencing of data objects already performed by an Application; 791 instead, the naming is intended to apply only to data objects 792 referenced by DECADE-specific purposes. 794 An Application using a DECADE client may use a naming and sequencing 795 scheme independent of DECADE names. The DECADE client SHOULD 796 maintain a mapping from its own data objects and their names to the 797 DECADE-specific data objects and names. Furthermore, the DECADE 798 naming scheme implies no sequencing or grouping of objects, even if 799 this is done at the application layer. 801 6.2. DECADE Resource Protocol (DRP) 803 DRP will provide configuration of access control and resource sharing 804 policies on DECADE servers. A Content Distribution Application, 805 e.g., a live P2P streaming session, can have permission to manage 806 data at several servers, for instance, servers belonging to different 807 Storage Providers, and DRP allows one instance of such an 808 application, e.g., an Application End-Point, to apply access control 809 and resource sharing policies on each of them. 811 6.2.1. Controlled Resources 813 On a single DECADE server, the following resources SHOULD be managed: 815 o Communication resources in terms of bandwidth (upload/download) 816 and also in terms of number of active clients (simultaneous 817 connections). 819 o Storage resources. 821 6.2.2. Access and Resource Control Token 823 As in DECADE system, the resource owner agent is always the same 824 entity or colocated with the authorization server, so we use a 825 separate OAuth 2.0 request and response flow for the access and 826 resource control token. 828 An OAuth request to access the data objects MUST include the 829 following fields (encoding format is TBD, HTML?): 831 response_type: REQUIRED. Value MUST be set to "token". 833 client_id: the client_id indicates either the application that is 834 using the DECADE service or the end user who is using the DECADE 835 service from a DECADE storage service provider. DECADE storage 836 service providers MUST provide the ID distribution and management 837 function, which is out of the scope of this document. 839 scope: data object names that are requested. 841 An OAuth response includes the following information (encoding is 842 TBD, HTML is preferred, are we going to use OAuth Bearer token type 843 as defined in RFC 6750? The concern for bearer token is that it does 844 not associate the token with any client, so that any client can use 845 this token to access the resources. Do we worry about it? The 846 current draft seems explicitly support this behavior.): 848 o token_type: "Bearer"? 850 o expires_in: The lifetime in seconds of the access token. 852 o access_token: a token denotes the following information. 854 o service URI: the server address or URI which is providing the 855 service; 857 o Permitted operations (e.g., read, write); 859 o Permitted objects (e.g., names of data objects that might be read 860 or written); 862 o Priority: optional. If it is presented, value MUST be set to be 863 either "Urgent", "High", "Normal" or "Low". 865 o Bandwidth: bandwidth that is given to requested operation, a 866 weight value used in a weighted bandwidth sharing scheme, or a 867 integer in number of bps; 869 o Amount: data size in number of bytes that might be read or 870 written. 872 o token_signature: the signature of the access token. 874 The tokens SHOULD be generated by an entity trusted by both the 875 DECADE client and server at the request of a DECADE client. For 876 example this entity could be the client, a server trusted by the 877 client, or another server managed by a Storage Provider and trusted 878 by the client. It is important for a server to trust the entity 879 generating the tokens since each token may incur a resource cost on 880 the server when used. Likewise, it is important for a client to 881 trust the entity generating the tokens since the tokens grant access 882 to the data stored at the server. 884 Upon generating a token, a client MAY distribute it to another client 885 (e.g., via their native application protocol). The receiving client 886 MAY then connect to the server specified in the token and perform any 887 operation permitted by the token. The token SHOULD be sent along 888 with the operation. The server SHOULD validate the token to identify 889 the client that issued it and whether the requested operation is 890 permitted by the contents of the token. If the token is successfully 891 validated, the server SHOULD apply the resource control policies 892 indicated in the token while performing the operation. 894 Tokens SHOULD include a unique identifier to allow a server to detect 895 when a token is used multiple times and reject the additional usage 896 attempts. Since usage of a token incurs resource costs to a server 897 (e.g., bandwidth and storage) and a Content Provider may have a 898 limited budget (see Section 4.5), the Content Provider should be able 899 to indicate if a token may be used multiple times. 901 It SHOULD be possible to revoke tokens after they are generated. 902 This could be accomplished by supplying the server the unique 903 identifiers of the tokens which are to be revoked. 905 6.2.3. Status Information 907 DRP SHOULD provide a status request service that clients can use to 908 request status information of a server. 910 6.2.3.1. Status Information on a specific server 912 Access to such status information SHOULD require client 913 authorization; that is, clients need to be authorized to access the 914 requested status information. This authorization is based on the 915 user delegation concept as described in Section 4.5. The following 916 status information elements SHOULD be obtained: 918 o List of associated data objects (with properties); 920 o Resources used/available. 922 The following information elements MAY additionally be available: 924 o List of servers to which data objects have been distributed (in a 925 certain time-frame); 927 o List of clients to which data objects have been distributed (in a 928 certain time-frame). 930 For the list of servers/clients to which data objects have been 931 distributed to, the server SHOULD be able to decide on time bounds 932 for which this information is stored and specify the corresponding 933 time frame in the response to such requests. Some of this 934 information may be used for accounting purposes, e.g., the list of 935 clients to which data objects have been distributed. 937 6.2.3.2. Access information on a specific server 939 Access information MAY be provided for accounting purposes, for 940 example, when Content Providers are interested in access statistics 941 for resources and/or to perform accounting per user. Again, access 942 to such information requires client authorization and SHOULD based on 943 the delegation concept as described in Section 4.5. The following 944 type of access information elements MAY be requested: 946 o What data objects have been accessed by whom and for how many 947 times; 949 o Access tokens that a server as seen for a given data object. 951 The server SHOULD decide on time bounds for which this information is 952 stored and specify the corresponding time frame in the response to 953 such requests. 955 6.2.4. Data Object Attributes 957 Data Objects that are stored on a DECADE server SHOULD have 958 associated attributes (in addition to the object identifier and data 959 object) that relate to the data storage and its management. These 960 attributes may be used by the server (and possibly the underlying 961 storage system) to perform specialized processing or handling for the 962 data object, or to attach related server or storage-layer properties 963 to the data object. These attributes have a scope local to a server. 964 In particular, these attributes SHOULD NOT be applied to a server or 965 client to which a data object is copied. 967 Depending on authorization, clients SHOULD be permitted to get or set 968 such attributes. This authorization is based on the delegation 969 concept as described in Section 4.5. The architecture does not limit 970 the set of permissible attributes, but rather specifies a set of 971 baseline attributes that SHOULD be supported: 973 Expiration Time: Time at which the data object can be deleted; 975 Data Object size: In bytes; 977 Media type Labelling of type as per [RFC4288]; 978 Access statistics: How often the data object has been accessed (and 979 what tokens have been used). 981 The data object attributes defined here are distinct from application 982 metadata (see Section 4.1). Application metadata is custom 983 information that an application might wish to associate with a data 984 object to understand its semantic meaning (e.g., whether it is video 985 and/or audio, its playback length in time, or its index in a stream). 986 If an application wishes to store such metadata persistently, it can 987 be stored within data objects themselves. 989 6.3. Standard Data Transfer (SDT) Protocol 991 A DECADE server will provide a data access interface, and the SDT 992 will be used to write data objects to a server and to read (download) 993 data objects from a server. Semantically, SDT is a client-server 994 protocol; that is, the server always responds to client requests. 996 6.3.1. Writing/Uploading Objects 998 To write a data object, a client first generates the object's name 999 (see Section 6.1), and then uploads the object to a server and 1000 supplies the generated name. The name can be used to access 1001 (download) the object later; for example, the client can pass the 1002 name as a reference to other client that can then refer to the 1003 object. 1005 Data objects can be self-contained objects such as multimedia 1006 resources, files etc., but also chunks, such as chunks of a P2P 1007 distribution protocol that can be part of a containing object or a 1008 stream. 1010 The application that originates the data objects generates DECADE 1011 object names according to the naming specification in Section 6.1. 1012 Clients (as parts of application entities) upload a named object to a 1013 server. If supported, a server can verify the integrity and other 1014 security properties of uploaded objects. 1016 6.3.2. Downloading Data Objects 1018 A client can request named data objects from a server. In a 1019 corresponding request message, a client specifies the object name and 1020 a suitable access and resource control token. The server checks the 1021 validity of the received token and its associated resource usage- 1022 related properties. 1024 If the named data object exists on the server and the token can be 1025 validated, the server delivers the requested object in a response 1026 message. 1028 If the data object cannot be delivered the server provides an 1029 corresponding status/reason information in a response message. 1031 Specifics regarding error handling, including additional error 1032 conditions (e.g., overload), precedence for returned errors and its 1033 relation with server policy, are deferred to eventual protocol 1034 specification. 1036 6.4. Server-to-Server Protocols 1038 An important feature of a DECADE system is the capability for one 1039 server to directly download data objects from another server. This 1040 capability allows Applications to directly replicate data objects 1041 between servers without requiring end-hosts to use uplink capacity to 1042 upload data objects to a different server. 1044 DRP and SDT will support operations directly between servers. 1045 Servers are not assumed to trust each other nor are configured to do 1046 so. All data operations are performed on behalf of clients via 1047 explicit instruction. However, the objects being processed do not 1048 necessarily have to originate or terminate at the client (i.e., the 1049 data object might be limited to being exchanged between servers even 1050 if the instruction is triggered by the client). Clients thus will be 1051 able to indicate to a server the following additional parameters: 1053 o Which remote server(s) to access; 1055 o The operation to be performed; 1057 o The Content Provider at the remote server from which to retrieve 1058 the data object, or in which the object is to be stored; and 1060 o Credentials indicating access and resource control to perform the 1061 operation at the remote server. 1063 Server-to-server support is focused on reading and writing data 1064 objects between servers. The data object referred to at the remote 1065 server is the same as the original data object requested by the 1066 client. Object attributes (see Section 6.2.4) might also be 1067 specified in the request to the remote server. 1069 In this way, a server acts as a proxy for a client, and a client can 1070 instantiate requests via that proxy. The operations will be 1071 performed as if the original requester had its own client co-located 1072 with the server. 1074 When a client sends a request to a server with these additional 1075 parameters, it is giving the server permission to act (proxy) on its 1076 behalf. Thus, it would be prudent for the supplied token to have 1077 narrow privileges (e.g., limited to only the necessary data objects) 1078 or validity time (e.g., a small expiration time). 1080 In the case of a retrieval operation, the server is to retrieve the 1081 data object from the remote server using the specified credentials, 1082 and then optionally return the object to a client. In the case of a 1083 storage operation, the server is to store the object to the remote 1084 server using the specified credentials. The object might optionally 1085 be uploaded from the client or might already exist at the proxy 1086 server. 1088 7. Security Considerations 1090 In general, the security considerations mentioned in [RFC6646] apply 1091 to this document as well. 1093 A DECADE system provides a distributed storage service for content 1094 distribution and similar applications. The system consists of 1095 servers and clients that use these servers to upload data objects, to 1096 request distribution of data objects, and to download data objects. 1097 Such a system is employed in an overall application context -- for 1098 example in a P2P Content Distribution Application, and it is expected 1099 that DECADE clients take part in application-specific communication 1100 sessions. 1102 The security considerations here focus on threats related to the 1103 DECADE system and its communication services, i.e., the DRP/SDT 1104 protocols that have been described in an abstract fashion in this 1105 document. 1107 7.1. Threat: System Denial of Service Attacks 1109 A DECADE network might be used to distribute data objects from one 1110 client to a set of servers using the server-to-server communication 1111 feature that a client can request when uploading an object. Multiple 1112 clients uploading many objects at different servers at the same time 1113 and requesting server-to-server distribution for them could thus 1114 mount massive distributed denial of service (DDOS) attacks, 1115 overloading a network of servers. 1117 This threat is addressed by the server's access control and resource 1118 control framework. Servers can require Application End-Points to be 1119 authorized to store and to download objects, and Application End- 1120 Points can delegate authorization to other Application End-Points 1121 using the token mechanism. 1123 Of course the effective security of this approach depends on the 1124 strength of the token mechanism. See below for a discussion of this 1125 and related communication security threats. 1127 Denial of Service Attacks against a single server (directing many 1128 requests to that server) might still lead to considerable load for 1129 processing requests and invalidating tokens. SDT therefore MUST 1130 provide a redirection mechanism as described as a requirement in 1131 [I-D.ietf-decade-reqs]. 1133 7.2. Threat: Protocol Security 1135 7.2.1. Threat: Authorization Mechanisms Compromised 1137 A DECADE system does not require Application End-Points to 1138 authenticate in order to access a server for downloading objects, 1139 since authorization is not based on End-Point or user identities but 1140 on the delegation-based authorization mechanism. Hence, most 1141 protocol security threats are related to the authorization scheme. 1143 The security of the token mechanism depends on the strength of the 1144 token mechanism and on the secrecy of the tokens. A token can 1145 represent authorization to store a certain amount of data, to 1146 download certain objects, to download a certain amount of data per 1147 time etc. If it is possible for an attacker to guess, construct or 1148 simply obtain tokens, the integrity of the data maintained by the 1149 servers is compromised. 1151 This is a general security threat that applies to authorization 1152 delegation schemes. Specifications of existing delegation schemes 1153 such as OAuth [RFC5849] discuss these general threats in detail. We 1154 can say that the DRP has to specify appropriate algorithms for token 1155 generation. Moreover, authorization tokens should have a limited 1156 validity period that should be specified by the application. Token 1157 confidentiality should be provided by application protocols that 1158 carry tokens, and the SDT and DRP should provide secure 1159 (confidential) communication modes. 1161 7.2.2. Threat: Data Object Spoofing 1163 In a DECADE system, an Application End-Point is referring other 1164 Application End-Points to servers to download a specified data 1165 objects. An attacker could "inject" a faked version of the object 1166 into this process, so that the downloading End-Point effectively 1167 receives a different object (compared to what the uploading End-Point 1168 provided). As result, the downloading End-Point believes that is has 1169 received an object that corresponds to the name it was provided 1170 earlier, whereas in fact it is a faked object. Corresponding attacks 1171 could be mounted against the application protocol (that is used for 1172 referring other End-Points to servers), servers themselves (and their 1173 storage sub-systems), and the SDT by which the object is uploaded, 1174 distributed and downloaded. 1176 A DECADE systems fundamental mechanism against object spoofing is 1177 name-object binding validation, i.e., the ability of a receiver to 1178 check whether the name he was provided and that he used to request an 1179 object, actually corresponds to the bits he received. As described 1180 above, this allows for different forms of name-object binding, for 1181 example using hashes of data objects, with different hash functions 1182 (different algorithms, different digest lengths). For those 1183 application scenarios where hashes of data objects are not applicable 1184 (for example live-streaming) other forms of name-object binding can 1185 be used (see Section 6.1). This flexibility also addresses 1186 cryptographic algorithm evolvability: hash functions might get 1187 deprecated, better alternatives might be invented etc., so that 1188 applications can choose appropriate mechanisms meeting their security 1189 requirements. 1191 DECADE servers MAY perform name-object binding validation on stored 1192 objects, but Application End-Points MUST NOT rely on that. In other 1193 words, Application End-Points SHOULD perform name-object binding 1194 validation on received objects. 1196 8. IANA Considerations 1198 This document does not have any IANA considerations. 1200 9. Acknowledgments 1202 We thank the following people for their contributions to and/or 1203 detailed reviews of this document: 1205 Carsten Bormann 1207 David Bryan 1209 Dave Crocker 1211 Yingjie Gu 1213 David Harrington 1214 Hongqiang (Harry) Liu 1216 David McDysan 1218 Borje Ohlman 1220 Konstantinos Pentikousis 1222 Martin Stiemerling 1224 Richard Woundy 1226 Ning Zong 1228 10. References 1230 10.1. Normative References 1232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1233 Requirement Levels", BCP 14, RFC 2119, March 1997. 1235 [RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 1236 Application Data Enroute (DECADE) Problem Statement", 1237 RFC 6646, July 2012. 1239 [I-D.ietf-decade-reqs] 1240 Yingjie, G., Bryan, D., Yang, Y., Zhang, P., and R. Alimi, 1241 "DECADE Requirements", draft-ietf-decade-reqs-08 (work in 1242 progress), August 2012. 1244 [I-D.farrell-decade-ni] 1245 Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1246 Keraenen, A., and P. Hallam-Baker, "Naming Things with 1247 Hashes", draft-farrell-decade-ni-10 (work in progress), 1248 August 2012. 1250 10.2. Informative References 1252 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1253 Registration Procedures", RFC 4288, December 2005. 1255 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 1256 System (NFS) Version 4 Minor Version 1 Protocol", 1257 RFC 5661, January 2010. 1259 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 1260 April 2010. 1262 [RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- 1263 Network Storage Systems", RFC 6392, October 2011. 1265 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 1266 RFC 6749, October 2012. 1268 [OpenFlow] 1269 "OpenFlow Organization", . 1271 [GoogleFileSystem] 1272 Ghemawat, S., Gobioff, H., and S. Leung, "The Google File 1273 System", SOSP 2003, October 2003. 1275 Appendix A. In-Network Storage Components Mapped to DECADE Architecture 1277 In this section we evaluate how the basic components of an in-network 1278 storage system identified in Section 3 of [RFC6392] map into a DECADE 1279 system. 1281 A.1. Data Access Interface 1283 Clients can read and write objects of arbitrary size through the 1284 client's Data Controller, making use of a SDT. 1286 A.2. Data Management Operations 1288 Clients can move or delete previously stored objects via the client's 1289 Data Controller, making use of a SDT. 1291 A.3. Data Search Capability 1293 Clients can enumerate or search contents of servers to find objects 1294 matching desired criteria through services provided by the Content 1295 Distribution Application (e.g., buffer-map exchanges, a DHT, or peer- 1296 exchange). In doing so, Application End-Points might consult their 1297 local Data Index in the client's Data Controller. 1299 A.4. Access Control Authorization 1301 All methods of access control are supported: public-unrestricted, 1302 public-restricted and private. Access Control Policies are generated 1303 by a Content Distribution Application and provided to the client's 1304 Resource Controller. The server is responsible for implementing the 1305 access control checks. 1307 A.5. Resource Control Interface 1309 Clients can manage the resources (e.g., bandwidth) on the DECADE 1310 server that can be used by other Application End-Points. Resource 1311 Sharing Policies are generated by a Content Distribution Application 1312 and provided to the client's Resource Controller. The server is 1313 responsible for implementing the resource sharing policies. 1315 A.6. Discovery Mechanism 1317 The particular protocol used for discovery is outside the scope of 1318 this document. However, options and considerations have been 1319 discussed in Section 5.5. 1321 A.7. Storage Mode 1323 Servers provide an object-based storage mode. Immutable data objects 1324 might be stored at a server. Applications might consider existing 1325 blocks as data objects, or they might adjust block sizes before 1326 storing in a server. 1328 Appendix B. Hisotry 1330 To RFC Editor: This section is informational for you. Please remove 1331 this section before publication. 1333 Since version 10, this document was modified based on the previous 1334 DECADE WG architecture document , and was extended to be a protocol 1335 specification. It addresses the comments from the WG and the 1336 responsible ADs (David Harrington and then Martin Stiemerling). The 1337 authors now request to publish this document through the independent 1338 stream and get the support of Martin. 1340 Authors' Addresses 1342 Richard Alimi 1343 Google 1345 Email: ralimi@google.com 1347 Akbar Rahman 1348 InterDigital Communications, LLC 1350 Email: akbar.rahman@interdigital.com 1351 Dirk Kutscher 1352 NEC 1354 Email: dirk.kutscher@neclab.eu 1356 Y. Richard Yang 1357 Yale University 1359 Email: yry@cs.yale.edu 1361 Haibin Song 1362 Huawei 1364 Email: haibin.song@huawei.com 1366 Kostas Pentikousis 1367 Huawei 1369 Email: k.pentikousis@huawei.com