idnits 2.17.1 draft-alimi-decade-arch-01.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 : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-decade-problem-statement-00 == Outdated reference: A later version (-06) exists of draft-ietf-decade-survey-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: April 28, 2011 Yale University 6 A. Rahman 7 InterDigital Communications, LLC 8 D. Kutscher 9 NEC 10 L. Chen 11 H. Liu 12 Yale University 13 October 25, 2010 15 DECADE Architecture 16 draft-alimi-decade-arch-01 18 Abstract 20 Peer-to-peer (P2P) applications have become widely used on the 21 Internet today and make up a large portion of the traffic in many 22 networks. One technique to improve the network efficiency of P2P 23 applications is to introduce storage capabilities within the network. 24 The DECADE Working Group has been formed with the goal of developing 25 an architecture to provide this capability. This document presents 26 an architecture, discusses the underlying principles and identifies 27 core components and protocols supporting the architecture. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on April 28, 2011. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1. DECADE Storage Servers . . . . . . . . . . . . . . . . . . 5 72 2.2. DECADE Storage Provider . . . . . . . . . . . . . . . . . 5 73 2.3. DECADE Content Providers . . . . . . . . . . . . . . . . . 5 74 2.4. DECADE Content Consumers . . . . . . . . . . . . . . . . . 5 75 2.5. Content Distribution Application . . . . . . . . . . . . . 5 76 2.6. Application End-Point . . . . . . . . . . . . . . . . . . 6 77 3. Architectural Principles . . . . . . . . . . . . . . . . . . . 6 78 3.1. Decoupled Control and Data Planes . . . . . . . . . . . . 6 79 3.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 7 80 3.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 8 81 3.4. Explicit Control . . . . . . . . . . . . . . . . . . . . . 8 82 3.5. Resource and Data Access Control through User 83 Delegation . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.5.1. Resource Allocation . . . . . . . . . . . . . . . . . 9 85 3.5.2. User Delegations . . . . . . . . . . . . . . . . . . . 9 86 4. System Components . . . . . . . . . . . . . . . . . . . . . . 10 87 4.1. Content Distribution Application . . . . . . . . . . . . . 12 88 4.1.1. Data Sequencing and Naming . . . . . . . . . . . . . . 12 89 4.1.2. Native Protocols . . . . . . . . . . . . . . . . . . . 12 90 4.1.3. DECADE Client . . . . . . . . . . . . . . . . . . . . 13 91 4.2. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 13 92 4.2.1. Access Control . . . . . . . . . . . . . . . . . . . . 13 93 4.2.2. Resource Scheduling . . . . . . . . . . . . . . . . . 14 94 4.2.3. Data Store . . . . . . . . . . . . . . . . . . . . . . 14 95 4.3. Protocols . . . . . . . . . . . . . . . . . . . . . . . . 14 96 4.3.1. DECADE Resource Protocol . . . . . . . . . . . . . . . 14 97 4.3.2. Standard Data Transports . . . . . . . . . . . . . . . 15 98 4.4. DECADE Data Sequencing and Naming . . . . . . . . . . . . 15 99 4.5. In-Network Storage Components Mapped to DECADE 100 Architecture . . . . . . . . . . . . . . . . . . . . . . . 16 101 4.5.1. Data Access Interface . . . . . . . . . . . . . . . . 16 102 4.5.2. Data Management Operations . . . . . . . . . . . . . . 16 103 4.5.3. Data Search Capability . . . . . . . . . . . . . . . . 16 104 4.5.4. Access Control Authorization . . . . . . . . . . . . . 16 105 4.5.5. Resource Control Interface . . . . . . . . . . . . . . 16 106 4.5.6. Discovery Mechanism . . . . . . . . . . . . . . . . . 16 107 4.5.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . 17 108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 110 7. Informative References . . . . . . . . . . . . . . . . . . . . 17 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 113 1. Introduction 115 Peer-to-peer (P2P) applications have become widely used on the 116 Internet today to distribute contents, and they contribute a large 117 portion of the traffic in many networks. The DECADE Working Group 118 has been formed with the goal of developing an architecture to 119 introduce in-network storage to be used by such applications, to 120 achieve more efficient content distribution. Specifically, in many 121 subscriber networks, it is typically more expensive to upgrade 122 network equipment in the "last-mile", because it can involve 123 replacing equipment and upgrading wiring at individual homes, 124 businesses, and devices such as DSLAMs and CMTSs. Thus, it can be 125 cheaper to upgrade core infrastructure involving fewer components 126 that are shared by many subscribers. See 127 [I-D.ietf-decade-problem-statement] for a more complete discussion of 128 the problem domain and general discussion of the capabilities to be 129 provided by DECADE. 131 This document presents a potential architecture of providing in- 132 network 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. In particular, content 136 distribution applications that may split data into smaller pieces for 137 distribution may be able to utilize DECADE. 139 The design philosophy of the DECADE architecture is to provide only 140 the core functionality that is needed for applications to make use of 141 in-network storage. With such core functionality, the protocol may 142 be simple and easier to support by storage providers. If more 143 complex functionality is needed by a certain application or class of 144 applications, it may be layered on top of the DECADE protocol. 146 The DECADE protocol will leverage existing transport and application 147 layer protocols and will be designed to work with a small set of 148 alternative IETF protocols. 150 This document proceeds in two steps. First, it details the core 151 architectural principles that can guide the DECADE design. Next, 152 given these core principles, this document presents the core 153 components of the DECADE architecture and identifies usage of 154 existing protocols and where there is a need for new protocol 155 development. 157 This document will be updated to track the progress of the DECADE 158 survey [I-D.ietf-decade-survey] and requirements [I-D.gu-decade-reqs] 159 drafts. 161 2. Entities 163 2.1. DECADE Storage Servers 165 DECADE storage servers are operated by DECADE storage providers and 166 provide the DECADE functionality as specified in this memo, including 167 mechanisms to store, retrieve and manage data. A storage provider 168 may typically operate multiple storage servers. 170 2.2. DECADE Storage Provider 172 A DECADE in-storage provider deploys and/or manages DECADE servers 173 within a network. A storage provider may also own or manage the 174 network in which the DECADE servers are deployed. 176 A DECADE storage provider, possibly in cooperation with one or more 177 network providers, determines deployment locations for DECADE servers 178 and determines the available resources for each. 180 2.3. DECADE Content Providers 182 DECADE content providers access DECADE storage servers (by way of a 183 DECADE client) to upload and manage data. A content provider can 184 access one or more storage servers. A content provider may be a 185 single process or a distributed application (e.g., in a P2P 186 scenario). 188 2.4. DECADE Content Consumers 190 DECADE content consumers access storage servers (by way of a DECADE 191 client) to download data that has previously been stored by a content 192 provider. A content consumer can access one or more storage servers. 193 A content consumer may be a single process or a distributed 194 application (e.g., in a P2P scenario). An instance of a distributed 195 application, such as a P2P application, may both provide content to 196 and consume content from DECADE storage servers. 198 2.5. Content Distribution Application 200 A content distribution application is a distributed application 201 designed for dissemination of possibly-large data to multiple 202 consumers. Content Distribution Applications typically divide 203 content into smaller immutable blocks for dissemination. 205 The term Application Developer refers to the developer of a 206 particular Content Distribution Application. 208 2.6. Application End-Point 210 An Application End-Point is an instance of a Content Distribution 211 Application that makes use of DECADE server(s). A particular 212 Application End-Point may be a DECADE Content Provider, a DECADE 213 Content Consumer, or both. 215 An Application End-Point need not be an active member of a "swarm" to 216 interact with the DECADE storage system. That is, an End-Point may 217 interact with the DECADE storage servers as an offline activity. 219 3. Architectural Principles 221 We identify the following key principles. 223 3.1. Decoupled Control and Data Planes 225 The DECADE infrastructure is intended to support multiple content 226 distribution applications. A complete content distribution 227 application implements a set of control functions including content 228 search, indexing and collection, access control, ad insertion, 229 replication, request routing, and QoS scheduling. Different content 230 distribution applications can have unique considerations designing 231 the control and signaling functions. For example, a major 232 competitive advantage of many successful P2P systems is their 233 substantial expertise in how to most efficiently utilize peer and 234 infrastructural resources. Many live P2P systems have their specific 235 algorithms in selecting the peers that behave as the more stable, 236 higher-bandwidth sources. They continue to fine-tune such 237 algorithms. In other words, in-network storage should export basic 238 mechanisms and allow as much flexibility as possible to the control 239 planes to implement specific policies. This conforms to the end-to- 240 end systems principle and allows innovation and satisfaction of 241 specific business goals. 243 Specifically, in the DECADE architecture, the control plane focuses 244 on the application-specific, complex, and/or processing intensive 245 functions while the data plane provides storage and data transport 246 functions. 248 o Control plane: Signals details of where the data is to be 249 downloaded from. Also signals the time, quality of service, and 250 receiver of the download. It also provides higher layer meta-data 251 management functions such as defining the sequence of data blocks 252 forming a higher layer content object. These are behaviors 253 designed and implemented by the Application. By Application, we 254 mean the broad sense that include other control plane protocols. 256 o Data plane: Stores and transfers data as instructed by the 257 Application's Control Plane. 259 Decoupling control plane and data plane is not new. For example, 260 OpenFlow is an implementation of this principle for Internet routing, 261 where the computation of the forwarding table and the application of 262 the forwarding table are separated. Google File System applies the 263 principle to file system design, by utilizing the Master to handle 264 the meta-data management, and the chunk servers to handle the data 265 plane (i.e., read and write of chunks of data). NFS4 also implements 266 this principle. 268 Note that applications may have different Data Plane implementations 269 in order to support particular requirements (e.g., low latency). In 270 order to provide interoperability, the DECADE architecture does not 271 intend to enable arbitrary data transport protocols. However, the 272 architecture may allow for multiple data transport protocols to be 273 used. 275 Also note that although an application's existing control plane 276 functions remain implemented within the application, the particular 277 implementation may need to be adjusted to support DECADE. 279 3.2. Immutable Data Objects 281 A property of bulk contents to be distributed is that they typically 282 are immutable -- once a piece of content is generated, it is 283 typically not modified. It is not common that bulk contents such as 284 video frames and images need to be modified after distribution. 286 Many content distribution applications divide content objects into 287 blocks for two reasons: (1) multipath: different blocks may be 288 fetched from different content sources in parallel, and (2) faster 289 recovery and verification: individual blocks may be recovered and 290 verified. Typically, applications use a block size larger than a 291 single packet in order to reduce control overhead. 293 Common applications whose content matches this model include P2P 294 streaming (live and video-on-demand) and P2P file-sharing content. 295 However, other types of applications may additionally match this 296 model. 298 DECADE adopts a design in which immutable data objects may be stored 299 at a storage server. Applications may consider existing blocks as 300 DECADE data objects, or they may adjust block sizes before storing in 301 a DECADE server. 303 Focusing on immutable data blocks in the data plane can substantially 304 simplify the data plane design, since consistency requirements can be 305 relaxed. It also allows effective reuse of data blocks and de- 306 duplication of redundant data. 308 Depending on specific application requirements, data objects can be 309 complete self-contained resources (such as video files) or chunks of 310 such resources. The DECADE architecture and protocols are agnostic 311 to the nature of the data objects and do not specify a fixed size for 312 them. 314 Note that immutable content may still be deleted. Also note that 315 immutable data blocks do not imply that contents cannot be modified. 316 For example, a meta-data management function of the control plane may 317 associate a name with a sequence of immutable blocks. If one of the 318 blocks is modified, the meta-data management function changes the 319 mapping of the name to a new sequence of immutable blocks. 321 3.3. Data Object Identifiers 323 Objects that are stored in a DECADE storage server can be accessed by 324 DECADE content consumers by a resource identifier that has been 325 assigned within a certain application context. 327 Because a DECADE content consumer can access more than one storage 328 server within a single application context, a data object that is 329 replicated across different storage servers managed by a DECADE 330 storage provider, can be accessed by a single identifier. 332 Note that since data objects are immutable, it is possible to support 333 persistent identifiers for data objects. 335 3.4. Explicit Control 337 To support the functions of an application's control plane, 338 applications must be able to know and control which data is stored at 339 particular locations. Thus, in contrast with content caches, 340 applications are given explicit control over the placement (selection 341 of a DECADE server), deletion (or expiration policy), and access 342 control for stored data. 344 Consider deletion/expiration policy as a simple example. 345 Applications may require a DECADE server to store content for a 346 relatively short period of time (e.g. for live-streaming data) or may 347 need to store content long term (e.g., for video-on-demand). 349 3.5. Resource and Data Access Control through User Delegation 351 DECADE provides a shared infrastructure to be used by multiple 352 tenants of multiple content distribution applications. Thus, it 353 needs to provide both resource and data access control. 355 3.5.1. Resource Allocation 357 There are two primary interacting entities in the DECADE 358 architecture. First, Storage Providers control where DECADE storage 359 servers are provisioned and their total available resources. Second, 360 Applications control data transfers amongst available DECADE servers 361 and between DECADE servers and end-points. A form of isolation is 362 required to enable concurrently-running Applications to each 363 explicitly manage their own content and share of resources at the 364 available servers. 366 Management of the resources at a server are delegated by a Storage 367 Provider to one or more applications. Applications are able to 368 explicitly and independently manage their own share of resources. 370 3.5.2. User Delegations 372 Storage providers have the ability to explicitly manage the entities 373 allowed to utilize the resources at a DECADE server. This capability 374 is needed for reasons such as capacity-planning and legal 375 considerations in certain deployment scenarios. 377 To provide a scalable way to manage applications granted resources at 378 a DECADE server, a layer of indirection is added. Instead of 379 granting resources to an application, the DECADE server grants a 380 share of the resources to a user. The user may in turn share the 381 granted resources amongst multiple applications. The share of 382 resources granted by a storage provider is called a User Delegation. 384 A User Delegation may be granted to an end-user (e.g., an ISP 385 subscriber), a Content Provider, or an Application Provider. A 386 particular instance of an application may make use of the storage 387 resources: 389 o granted to the end-user (with the end-user's permission), 391 o granted to the Content Provider (with the Content Provider's 392 permission>, and/or 394 o granted to the Application Provider. 396 4. System Components 398 The current version of the document has primarily focused on the 399 architectural principles. The detailed system components will be 400 discussed in the next document revision. 402 This section presents an overview of the components in the DECADE 403 architecture. 405 .--------------------------------------------------------------. 406 | Application End-Point | 407 | .------------. .-----------------. .----------. | 408 | | App-Layer | ... | App Data Object | | App Data | | 409 | | Algorithms | | Sequencing | | Naming | | 410 | `------------' `-----------------' `----------' | 411 | | 412 | .----------------------------------------------------------. | 413 | | DECADE Client | | 414 | | | | 415 | | .-------------------------. .--------------------------. | | 416 | | | Resource Controller | | Data Controller | | | 417 | | | .--------. .----------. | | .------------. .-------. | | | 418 Native | | | | Data | | Resource | | | | Data | | Data | | | | 419 App | | | | Access | | Sharing | | | | Scheduling | | Index | | | | 420 Protocol(s)| | | | Policy | | Policy | | | | | | | | | | 421 .--> | | | '--------' `----------' | | `------------' `-------' | | | 422 | | | `-------------------------' `--------------------------' | | 423 | | | | ^ | | 424 | | `------------ | ----------------- | -----------------------' | 425 | `-------------- | ----------------- | -------------------------' 426 | | | 427 v | DECADE | Standard 428 .-------------. | Resource | Data 429 | Application | | Protocol (DRP) | Transport (SDT) 430 | End-Point | | | 431 `-------------' | | Content Distribution 432 ^ ^ | | Application 433 = | ===== | ============== | ================= | ========================== 434 | | | | DECADE Server(s) 435 | | | | 436 | | .- | ----------------- | ----------------------. 437 | | | | v | 438 | | | | .----------------. | 439 | | | |----> | Access Control | <--------. | 440 | DRP | SDT | | `----------------' | | 441 | | | | ^ | | 442 | | | | v | | 443 | | | | .---------------------. | | 444 | | | `-> | Resource Scheduling | <------| | 445 v v DRP | `---------------------' | | 446 .------------. <------> | ^ | | 447 | DECADE | | v .------------. | 448 | Server | SDT | .-----------------. | User | | 449 `------------' <------> | | Data Store | | Delegation | | 450 | `-----------------' | Management | | 451 | DECADE Server `------------' | 452 `----------------------------------------------' 454 Figure 1: DECADE Architecture Components 456 A component diagram of the DECADE architecture is displayed in 457 Figure 1. The diagram illustrates the major components of a Content 458 Distribution Application related to DECADE, as well as the functional 459 components of a DECADE Server. 461 To keep the scope narrow, we only discuss the primary components 462 related to protocol development. Particular deployments may require 463 additional components (e.g., monitoring and accounting at a DECADE 464 server), but they are intentionally omitted from the current version 465 of this document. 467 4.1. Content Distribution Application 469 Content Distribution Applications have many functional components. 470 For example, many P2P applications have components to manage overlay 471 topology management, piece selection, etc. In supporting DECADE, it 472 may be advantageous to consider DECADE within some of these 473 components. However, in this architecture document, we focus on the 474 components directly employed to support DECADE. 476 4.1.1. Data Sequencing and Naming 478 DECADE is primarily designed to support applications that can divide 479 distributed contents into immutable data objects. To accomplish 480 this, applications include a component responsible for re-assembling 481 data objects and also creating the individual data objects. We call 482 this component Application Data Sequencing. The specific 483 implementation is entirely decided by the application. 485 In assembling or producing the data objects, an important 486 consideration is the naming of these objects. We call the component 487 responsible for assigning and interpreting application-layer names 488 the Application Data Naming component. The specific implementation 489 is entirely decided by the application. 491 4.1.2. Native Protocols 493 Applications may still use existing protocols. Existing protocols 494 used primarily for control/signaling needed by the application, but 495 may also serve as a data transport as they do today; it is important 496 that applications still be designed to be robust (e.g., if DECADE 497 servers are unavailable). 499 4.1.3. DECADE Client 501 An application may be modified to support DECADE. We call the layer 502 providing the DECADE support to an application the DECADE Client. It 503 is important to note that a DECADE Client need not be embedded into 504 an application. It could be implemented alone, or could be 505 integrated in other entities such as network devices themselves. 507 4.1.3.1. Resource Controller 509 Applications may have different Resource sharing policies and Data 510 access policies to control their resource and data in DECADE servers. 511 These policies can be existing policies of applications (e.g., tit- 512 for-tat) or custom policies adapted for DECADE. The specific 513 implementation is decided by the application. 515 4.1.3.2. Data Controller 517 DECADE is designed to decouple the control and the data transport of 518 applications. Data transport between applications and DECADE servers 519 uses standard data transport protocols. It may need to schedule the 520 data being transferred according to network conditions, available 521 DECADE Servers, and/or available DECADE Server resources. An index 522 indicates data available at remote DECADE servers. The index (or a 523 subset of it) may be advertised to other Application End-Points. 525 4.2. DECADE Server 527 DECADE server is an important functional component of DECADE. It 528 stores data from Application End-Points, and provides control and 529 access of those data to Application End-Points. Note that a DECADE 530 server is not necessarily a single physical machine, it could also be 531 implemented as a cluster of machines. 533 4.2.1. Access Control 535 An Application End-Point can access its own data or other Application 536 End-Point's data (provided sufficient authorization) in DECADE 537 servers. Application End-Points may also authorize other End-Points 538 to store data. If an access is authorized by an Application End- 539 Point, the DECADE Server will provide access. 541 Note that even if an request is authorized, it may still fail to 542 complete due to insufficient resources by either the requesting 543 Application End-Point or the providing Application End-Point. 545 4.2.2. Resource Scheduling 547 Applications may apply their existing resource sharing policies or 548 use a custom policy for DECADE. DECADE servers perform resource 549 scheduling according to the resource sharing policies indicated by 550 Application End-Points as well as configured User Delegations. 552 Access control and resource control are separated in DECADE server. 553 It is possible that an Application End-Point provides only access to 554 its data without any resources. In order to access this data, 555 another Application End-Point may use the granted access along with 556 its own available resources to store or retrieve data from a DECADE 557 Server. 559 4.2.3. Data Store 561 Data from applications may be stored into disks and explicitly or 562 automatically (e.g., after a TTL) deleted from disks. It may be 563 possible to perform optimizations in certain cases, such as avoiding 564 writing temporary data (e.g., live streaming) to disk. 566 4.3. Protocols 568 The DECADE Architecture uses two protocols. First, the DECADE 569 Resource Protocol is responsible for communicating access control and 570 resource scheduling policies to the DECADE Server. Second, standard 571 data transport protocols (e.g., WebDAV or NFS) are used to transfer 572 data objects to and from a DECADE Server. The DECADE architecture 573 will specify a small number of Standard Data Transport instances. 575 Decoupling the protocols in this way allows DECADE to both directly 576 utilize existing standard data transports and to evolve 577 independently. 579 It is also important to note that the two protocols do not need to be 580 separate on the wire. For example, the DECADE Resource Protocol 581 messages may be piggybacked within extension fields provided by 582 certain data transport protocols. However, this document considers 583 them as two separate functional components for clarity. 585 4.3.1. DECADE Resource Protocol 587 The DECADE Resource Protocol is responsible for communicating both 588 access control and resource sharing policies to DECADE Servers used 589 for data transport. 591 The DECADE architecture specification will provide exactly one DECADE 592 Resource Protocol. 594 4.3.2. Standard Data Transports 596 Existing data transport protocols are used to read and write data 597 from a DECADE Server. Protocols under consideration are WebDAV and 598 NFS. 600 4.4. DECADE Data Sequencing and Naming 602 We have discussed above that an Application may have its own behavior 603 for both sequencing and naming data objects. In order to provide a 604 simple and generic interface, the DECADE Server is only responsible 605 for storing and retrieving individual data objects. 607 The issue of naming data objects at the DECADE server would benefit 608 from additional feedback. There are multiple options that have been 609 considered: 611 o Self-certifying Name: The name of a data object may be a hash of 612 its contents. Advantages of this scheme include simplicity and 613 low probability of naming collisions without requiring any 614 identifiers or namespaces to be allocated. Disadvantages of this 615 scheme include collision in identifiers (with low probability) and 616 introduction of an additional distribution delay due to the 617 necessity of reading the full object to compute its hash before 618 advertising its availability. 620 o Application-specified Name: The name of a data object is specified 621 by the application itself. For example, this could be a function 622 of the application's content identifier and index of the data 623 object. To avoid conflicts, identifiers could be assigned to 624 particular applications. An advantage of this scheme is that 625 collisions could be avoided. A disadvantage is that assigning 626 identifiers introduces additional management complexity. 628 o Server-specified Name: The name of a data object is specified by 629 the DECADE server upon initially being stored. An advantage of 630 this approach is that naming conflicts can be completely avoided 631 without requiring particular identifiers to be assigned to 632 applications. A disadvantage is that it introduces additional 633 latency between the time when a application may upload a data 634 object and advertise availability of the data object at the DECADE 635 Server. 637 The current preferred design is to use self-certifying names. 638 However, additional feedback is welcomed. 640 4.5. In-Network Storage Components Mapped to DECADE Architecture 642 In this section we evaluate how the basic components of an in-network 643 storage system identified in Section 3 of [I-D.ietf-decade-survey] 644 map into the DECADE architecture. 646 It is important to note that complex and/or application-specific 647 behavior is delegated to applications instead of tuning the storage 648 system wherever possible. 650 4.5.1. Data Access Interface 652 Users can read and write objects of arbitrary size through the DECADE 653 Client's Data Controller, making use of a standard data transport. 655 4.5.2. Data Management Operations 657 Users can move or delete previously stored objects via the DECADE 658 Client's Data Controller, making use of a standard data transport. 660 4.5.3. Data Search Capability 662 Users can enumerate or search contents of DECADE servers to find 663 objects matching desired criteria through services provided by the 664 Content Distribution Application (e.g., buffer-map exchanges, a DHT, 665 or peer-exchange). In doing so, End-Points may consult their local 666 data index in the DECADE Client's Data Controller. 668 4.5.4. Access Control Authorization 670 All methods of access control are supported: public-unrestricted, 671 public-restricted and private. Access Control Policies are generated 672 by a Content Distribution Application and provided to the DECADE 673 Client's Resource Controller. The DECADE Server is responsible for 674 implementing the access control checks. 676 4.5.5. Resource Control Interface 678 Users can manage the resources (e.g. bandwidth) on the DECADE server 679 that can be used by other Application End-Points. Resource Sharing 680 Policies are generated by a Content Distribution Application and 681 provided to the DECADE Client's Resource Controller. The DECADE 682 Server is responsible for implementing the resource sharing policies. 684 4.5.6. Discovery Mechanism 686 This is outside the scope of the DECADE architecture. However, it is 687 expected that DNS or some other well known protocol will be used for 688 the users to discover the DECADE servers. 690 4.5.7. Storage Mode 692 DECADE Servers provide an object-based storage mode. Immutable data 693 objects may be stored at a DECADE server. Applications may consider 694 existing blocks as DECADE data objects, or they may adjust block 695 sizes before storing in a DECADE server. 697 5. Security Considerations 699 This document currently does not contain any security considerations 700 beyond those mentioned in [I-D.ietf-decade-problem-statement]. 702 6. IANA Considerations 704 This document does not have any IANA considerations. 706 7. Informative References 708 [I-D.ietf-decade-problem-statement] 709 Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled 710 Application Data Enroute (DECADE) Problem Statement", 711 draft-ietf-decade-problem-statement-00 (work in progress), 712 August 2010. 714 [I-D.ietf-decade-survey] 715 Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- 716 network Storage Systems", draft-ietf-decade-survey-01 717 (work in progress), October 2010. 719 [I-D.gu-decade-reqs] 720 Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE 721 Requirements", draft-gu-decade-reqs-05 (work in progress), 722 July 2010. 724 Authors' Addresses 726 Richard Alimi 727 Google 729 Email: ralimi@google.com 730 Y. Richard Yang 731 Yale University 733 Email: yry@cs.yale.edu 735 Akbar Rahman 736 InterDigital Communications, LLC 738 Email: akbar.rahman@interdigital.com 740 Dirk Kutscher 741 NEC 743 Email: dirk.kutscher@neclab.eu 745 Lijiang Chen 746 Yale University 748 Email: lijiang.chen@yale.edu 750 Hongqiang Liu 751 Yale University 753 Email: hongqiang.liu@yale.edu