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]