DECADE Y. Gu Internet-Draft H. Song Intended status: Standards Track Huawei Expires: April 22, 2010 October 19, 2009 DECoupled Application Data Enroute (DECADE) Requirements draft-gu-decade-reqs-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract DECoupled Application Data Enroute (DECADE) is going to develop a protocol that is used by a P2P application client to control its shared resource in the in-network storage, as well as store/retrieve Gu & Song Expires April 22, 2010 [Page 1] Internet-Draft Decade reqs October 2009 the resource to/from the in-network storage. This document enumerates requirements for this protocol, which should be considered when designing and implementation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 3 3. DECADE requirements . . . . . . . . . . . . . . . . . . . . . . 3 3.1. The general requirements . . . . . . . . . . . . . . . . . 3 3.2. In-network Storage Access Protocol . . . . . . . . . . . . 4 3.2.1. In-network Storage Access . . . . . . . . . . . . . . . 4 3.2.2. Authorization . . . . . . . . . . . . . . . . . . . . . 4 3.2.3. Management and Resource Control . . . . . . . . . . . . 4 3.2.4. Error handling and overload protection . . . . . . . . 5 3.2.5. Transport requirements . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Gu & Song Expires April 22, 2010 [Page 2] Internet-Draft Decade reqs October 2009 1. Introduction This document itemizes requirements for the following components. 1 The overall requirements 2 Access of In-network storage 3 Control of In-network storage 4 other relevant requirements This document will be updated align with problem statement. 2. Terminologies and concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses terms defined in [draft-song-decade-problem- statement]. 3. DECADE requirements 3.1. The general requirements Req. DRv00-01: A In-network storage Access protocol (IAP) MUST be developed to support data read and write from DECADE client to In- network storage. Req. DRv00-02: The In-network storage Access protocol (IAP) MAY also . support data read and write between In-network storages. Req. DRv00-03: The In-network storage Access protocol (IAP) SHOULD be based on an end-to-end principle. In other words, it is mainly the users' decisions on how to manage their shares of resources. Req. DRv00-04: In-network storage Access protocol SHOULD also provide resource control mechanism to support resource control from DECADE client to In-network storage. Gu & Song Expires April 22, 2010 [Page 3] Internet-Draft Decade reqs October 2009 3.2. In-network Storage Access Protocol 3.2.1. In-network Storage Access Req. DRv00-05: DECADE client MUST be able to initiate a session with the in-network storage using In-network storage Access Protocol (IAP). Req. DRv00-06: In-network storage MUST implement In-network storage Access Protocol (IAP) for receiving messages including content Storage, delete and request, and for sending corresponding response. Req. DRv00-07: Client which wants to use DECADE in-network storage MUST implement in-network storage Access protocol for sending message including content storage, delete and request, and for receiving corresponding response. Req. DRv00-08: In-network storage SHOULD support concurrent transfer, e.g. the in-network storage uploads to /downloads from multiple in-network storages or DECADE clients. Req. DRv00-9: IAP SHOULD enable clients to make decision on whether to download content directly to itself or to its in- network storage, or first to its in-network storage then to itself. 3.2.2. Authorization Req. DRv00-10: DECADE Client SHOULD be able to authorize individual peers to retrieve the content stored on its In-network storage. Req. DRv00-11: In-network storage MUST check the authorization of a client before it stores or retrieves content. 3.2.3. Management and Resource Control Req. DRv00-12: DECADE client SHOULD be able to retrieve current resource usage and quota on its in-network storage. Req. DRv00-13: DECADE client is RECOMMENDED to assign priority, bandwidth and connections quota to peers accessing the content in its In-network storage. Req. DRv00-14: DECADE client is RECOMMENDED to assign priority, bandwidth, connections and storage quota to peers storing content in its In-network storage. Gu & Song Expires April 22, 2010 [Page 4] Internet-Draft Decade reqs October 2009 Req. DRv00-15: DECADE Server MAY support a time to live value for each content. Req. DRv00-16: Client MUST be able to delete the content stored on its In-network storage when it no longer wants the content to be distributed. However, it's up to Client whether to delete the content or to leave it alone until the content is expired. 3.2.4. Error handling and overload protection Req. DRv00-17: Any application designed to use DECADE SHOULD also work reasonably if no In-network storage can be found or if In- network storage reject the requests, e.g., due to connectivity problems or overload situation. Req. DRv00-18: In-network storage, which is operating close to its capacity limit, MUST be able to inform its client about its impending overload situation, and reject subsequent requests. Req. DRv00-19: In-network storage, which is operating close to its capacity limit, and is not able to provide DECADE service for the content that is already stored on it, MUST be able to inform the corresponding DECADE client about its impending overload situation. 3.2.5. Transport requirements Req. DRv00-20: Data Transmission between Decade client and in- network storage, or between In-network storages MUST satisfy distinguished transmission requirements of various applications, e.g. streaming, file-sharing, web browsing, etc.. 4. Security Considerations In-network storage can be a victim of Denial of service (DoS), so that access control and resource control should be considered. In- network storage can also be a complicity of content stealing if there is no authorization and authentication. There should be a mechanism to guarantee a safe transmission of authorization messages. 5. Discussion Sometimes, several logical in-network storages could be deployed on same physical network device. In this case, In-network storages on Gu & Song Expires April 22, 2010 [Page 5] Internet-Draft Decade reqs October 2009 the same physical network device can communicate and transfer data through internal communication messages. However in-network storages deployed on different physical network devices should communicate with In-network storage Access Protocol (IAP). To guarantee fairness among clients, In-network storage should assign storage/ bandwidth/connection quota for users. Or else a few clients might occupy large amount of resource on the in-network storage, while others starved. 6. Acknowledgments We would like to thank the following people for contributing to the discussion of this document: Ning Zong, Richard Alimi, Richard Yang, (to be added). 7. References 7.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 7.2. Informative References [draft-song-decade-problem-statement] Song, H., "draft-song-decade-problem-statement", Oct. 2009. Authors' Addresses Gu Yingjie Huawei Baixia Road No. 91 Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-84565868 Fax: +86-25-84565888 Email: guyingjie@huawei.com Gu & Song Expires April 22, 2010 [Page 6] Internet-Draft Decade reqs October 2009 Song Haibin Huawei Baixia Road No. 91 Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-84565867 Fax: +86-25-84565888 Email: melodysong@huawei.com Gu & Song Expires April 22, 2010 [Page 7]