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]