Network Working Group Y. Gu Internet-Draft H. Song Intended status: Standards Track Huawei Expires: April 24, 2010 Y. Yang R. Alimi Yale University October 21, 2009 DECoupled Application Data Enroute (DECADE) Requirements draft-gu-decade-reqs-01 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 24, 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. Gu, et al. Expires April 24, 2010 [Page 1] Internet-Draft DECADE Requirements October 2009 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 the resource to/from the in-network storage. This document enumerates requirements that should be considered during the design and implementation of this protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 3 3. DECADE Requirements . . . . . . . . . . . . . . . . . . . . . . 3 3.1. 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.3. Transport Requirements . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Gu, et al. Expires April 24, 2010 [Page 2] Internet-Draft DECADE Requirements October 2009 1. Introduction This document itemizes the following requirements: General system requirements; Access to In-network storage; Control of In-network storage; Error handling and security. This document will be updated to be aligned with problem statement. 2. Terminology 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 [I-D.song-decade-problem-statement]. 3. DECADE Requirements 3.1. General Requirements DRv00-1: A In-network storage Access protocol (IAP) MUST be developed to support data read and write from DECADE client to In-network storage. DRv00-2: The In-network storage Access protocol (IAP) MAY support data read and write between In-network storages. DRv00-3: The In-network storage Access protocol (IAP) SHOULD be based on the end-to-end principle; that is, it allows the users to decide on how to manage their shares of resources. DRv00-4: In-network storage Access protocol SHOULD provide a resource control mechanism to support resource control from DECADE client to In-network storage. Gu, et al. Expires April 24, 2010 [Page 3] Internet-Draft DECADE Requirements October 2009 3.2. In-network Storage Access Protocol 3.2.1. In-network Storage Access DRv00-5: DECADE client MUST be able to initiate a session with the in-network storage using In-network storage Access Protocol (IAP). DRv00-6: In-network storage MUST implement the In-network storage Access Protocol (IAP) for receiving messages including content storage and deletion, and for sending corresponding response. DRv00-7: Client that uses DECADE in-network storage MUST implement IAP for handling messages including content storage and deletion, and for receiving corresponding response. DRv00-8: In-network storage SHOULD support concurrent transfer. For example, an in-network storage MUST support upload to /download from multiple in-network storages or DECADE clients. DRv00-9: IAP SHOULD enable a client to make decisions on whether to download content directly to itself or to its in-network storage, or first to its in-network storage and then to itself. 3.2.2. Authorization DRv00-10: DECADE Client SHOULD be able to authorize individual peers to retrieve the content stored on its in-network storage. DRv00-11: DECADE Client SHOULD be able to authorize individual peers to store content into its in-network storage. DRv00-12: In-network storage MUST check the authorization of a client before it stores or retrieves content. 3.2.3. Management and Resource Control DRv00-13: A DECADE client SHOULD be able to retrieve current resource usage and quota on its in-network storage. DRv00-14: A DECADE client is RECOMMENDED to assign priority, bandwidth and connections quota to peers accessing the content in its in-network storage. Gu, et al. Expires April 24, 2010 [Page 4] Internet-Draft DECADE Requirements October 2009 DRv00-15: A DECADE client is RECOMMENDED to assign priority, bandwidth, connections and storage quota to peers storing content in its in-network storage. DRv00-16: A DECADE server implementing in-network storage MAY support a time to live value for stored content. DRv00-17: A DECADE client MUST be able to delete content stored on its in-network storage when it no longer wants the content to be distributed. However, it's up to the client to decide whether to delete the content or to leave it alone until the content is expired. 3.2.4. Error Handling and Overload Protection DRv00-18: Any application designed to use DECADE SHOULD be designed to handle the scenarios that no in-network storage can be found or the in-network storage rejects its requests, e.g., due to connectivity problems or in an overload situation. DRv00-19: In-network storage, which is operating close to its capacity limit, SHOULD be able to reject requests. DRv00-20: 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, SHOULD try to reply with a status message to requesting DECADE clients about its overloading state. 3.3. Transport Requirements DRv00-21: DECADE MAY contain options to support application-type specific optimizations for data transmissions between DECADE clients and in-network storage, or between in- network storage. The types include streaming, file- sharing, and web browsing. 4. Security Considerations In-network storage can be a target of Denial of service (DoS) attacks. Thus, 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 safe transmission of authorization messages. Gu, et al. Expires April 24, 2010 [Page 5] Internet-Draft DECADE Requirements October 2009 5. Discussion Sometimes, several logical in-network storages could be deployed on the same physical network device. In this case, in-network storages on 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 provide fairness among clients, in-network storage should assign storage/bandwidth/connection quota for users. Or else a few clients might occupy large amounts of resources on the in-network storage, while others starve. 6. IANA Considerations There is no IANA consideration with this document. 7. Acknowledgments We would like to thank the following people for contributing to the discussion of this document: Ning Zong, Richard Alimi, Richard Yang. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.song-decade-problem-statement] Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", draft-song-decade-problem-statement-00 (work in progress), October 2009. Gu, et al. Expires April 24, 2010 [Page 6] Internet-Draft DECADE Requirements October 2009 Authors' Addresses Yingjie Gu Huawei Baixia Road No. 91 Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-84565868 Email: guyingjie@huawei.com Song Haibin Huawei Baixia Road No. 91 Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-84565867 Email: melodysong@huawei.com Y. Richard Yang Yale University Email: yry@cs.yale.edu Richard Alimi Yale University Email: richard.alimi@yale.edu Gu, et al. Expires April 24, 2010 [Page 7]