draft-ietf-decade-arch-06.txt   draft-ietf-decade-arch-07.txt 
DECADE R. Alimi DECADE R. Alimi
Internet-Draft Google Internet-Draft Google
Intended status: Informational A. Rahman Intended status: Informational A. Rahman
Expires: December 2, 2012 InterDigital Communications, LLC Expires: December 16, 2012 InterDigital Communications, LLC
D. Kutscher D. Kutscher
NEC NEC
Y. Yang Y. Yang
Yale University Yale University
May 31, 2012 June 14, 2012
DECADE Architecture DECADE Architecture
draft-ietf-decade-arch-06 draft-ietf-decade-arch-07
Abstract Abstract
Content Distribution Applications (e.g., P2P applications) are widely Content Distribution Applications (e.g., Peer-to-Peer applications)
used on the Internet and make up a large portion of the traffic in are widely used on the Internet and make up a large portion of the
many networks. One technique to improve the network efficiency of traffic in many networks. One technique to improve the network
these applications is to introduce storage capabilities within the efficiency of these applications is to introduce storage capabilities
networks; this is the capability provided by a DECADE (DECoupled within the networks; this is the capability provided by a DECADE
Application Data Enroute) compatible system. This document presents (DECoupled Application Data Enroute) compatible system. This
an architecture, discusses the underlying principles, and identifies document presents an architecture, discusses the underlying
key functionalities required for introducing a DECADE-compatible in- principles, and identifies key functionalities required for
network storage system. In addition, some examples are given to introducing a DECADE-compatible in-network storage system. In
illustrate these concepts. addition, some examples are given to illustrate these concepts.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 2, 2012. This Internet-Draft will expire on December 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 5 2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 5
2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 5 2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 6
2.3. Content Provider . . . . . . . . . . . . . . . . . . . . . 6 2.3. Content Provider . . . . . . . . . . . . . . . . . . . . . 6
2.4. Content Consumer . . . . . . . . . . . . . . . . . . . . . 6 2.4. Content Consumer . . . . . . . . . . . . . . . . . . . . . 6
2.5. Storage Provider . . . . . . . . . . . . . . . . . . . . . 6 2.5. Storage Provider . . . . . . . . . . . . . . . . . . . . . 6
2.6. Content Distribution Application . . . . . . . . . . . . . 6 2.6. Content Distribution Application . . . . . . . . . . . . . 6
2.7. Application End-Point . . . . . . . . . . . . . . . . . . 6 2.7. Application End-Point . . . . . . . . . . . . . . . . . . 6
2.8. Data Object . . . . . . . . . . . . . . . . . . . . . . . 6 2.8. Data Object . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Architectural Principles . . . . . . . . . . . . . . . . . . . 9 4. Architectural Principles . . . . . . . . . . . . . . . . . . . 9
4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 9 4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 9
4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 10 4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 10
4.3. Data Objects With Identifiers . . . . . . . . . . . . . . 10 4.3. Data Objects With Identifiers . . . . . . . . . . . . . . 11
4.4. Data Object Naming Scheme . . . . . . . . . . . . . . . . 11 4.4. Data Object Naming Scheme . . . . . . . . . . . . . . . . 11
4.5. Explicit Control . . . . . . . . . . . . . . . . . . . . . 12 4.5. Explicit Control . . . . . . . . . . . . . . . . . . . . . 13
4.6. Resource and Data Access Control . . . . . . . . . . . . . 13 4.6. Resource and Data Access Control . . . . . . . . . . . . . 13
5. System Components . . . . . . . . . . . . . . . . . . . . . . 14 5. System Components . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Content Distribution Application . . . . . . . . . . . . . 14 5.1. Content Distribution Application . . . . . . . . . . . . . 14
5.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 18 5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 18
5.4. Token-based Authentication and Resource Control . . . . . 20 5.4. Token-based Authentication and Resource Control . . . . . 20
5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21 5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21
6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 22 6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 22 6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 22
6.2. Standard Data Transfer (SDT) Protocol . . . . . . . . . . 25 6.2. Standard Data Transfer (SDT) Protocol . . . . . . . . . . 25
skipping to change at page 5, line 42 skipping to change at page 5, line 42
The approach of this document is to define the core functionalities The approach of this document is to define the core functionalities
and protocol behaviour that are needed to support in-network storage and protocol behaviour that are needed to support in-network storage
in a DECADE-compatible system. The protocol themselves are not in a DECADE-compatible system. The protocol themselves are not
selected or designed in this document. Some illustrative examples selected or designed in this document. Some illustrative examples
are given to help the reader understand certain concepts. These are given to help the reader understand certain concepts. These
examples are purely informational and are not meant to constrain examples are purely informational and are not meant to constrain
future protocol design or selection. future protocol design or selection.
2. Terminology 2. Terminology
This document assumes readers are familiar with the terms and
concepts that are used in [I-D.ietf-decade-problem-statement]. In
addition, this document defines the following terminology.
2.1. DECADE-compatible Client 2.1. DECADE-compatible Client
A DECADE-compatible client uploads and/or retrieves data from DECADE- A DECADE-compatible client uploads and/or retrieves data from DECADE-
compatible servers. We simply use the term "client" if there is no compatible servers. We simply use the term "client" if there is no
ambiguity. ambiguity.
2.2. DECADE-compatible Server 2.2. DECADE-compatible Server
A DECADE-compatible server stores data inside the network, and A DECADE-compatible server stores data inside the network, and
thereafter manages both the stored data and access to that data. We thereafter manages both the stored data and access to that data. We
skipping to change at page 12, line 50 skipping to change at page 13, line 9
finished storing the object. finished storing the object.
If object names are not based on hashes of the data objects If object names are not based on hashes of the data objects
themselves, names can also be used in scenarios where a client knows themselves, names can also be used in scenarios where a client knows
the name of a data object before it is locally created. the name of a data object before it is locally created.
4.5. Explicit Control 4.5. Explicit Control
To support the functions of an application's control plane, To support the functions of an application's control plane,
applications SHOULD be able to know and coordinate which data is applications SHOULD be able to know and coordinate which data is
stored at particular servers. Thus, in contrast with traditional stored at particular servers. Applications are given explicit
caches, applications are given explicit control over the placement control over the placement (selection of a DECADE-compatible server),
(selection of a DECADE-compatible server), deletion (or expiration deletion (or expiration policy), and access control for stored data.
policy), and access control for stored data.
Consider deletion/expiration policy as a simple example. An Consider deletion/expiration policy as a simple example. An
application might require that a server store data objects for a application might require that a server store data objects for a
relatively short period of time (e.g., for live-streaming data). relatively short period of time (e.g., for live-streaming data).
Another application might need to store data objects for a longer Another application might need to store data objects for a longer
duration (e.g., for video-on-demand). duration (e.g., for video-on-demand).
4.6. Resource and Data Access Control 4.6. Resource and Data Access Control
A DECADE-compatible system will provide a shared infrastructure to be A DECADE-compatible system will provide a shared infrastructure to be
skipping to change at page 21, line 12 skipping to change at page 21, line 12
o Authorization policies are implemented within the Application; an o Authorization policies are implemented within the Application; an
Application explicitly controls when tokens are generated and to Application explicitly controls when tokens are generated and to
whom they are distributed. whom they are distributed.
o Fine-grained access and resource control can be applied to data o Fine-grained access and resource control can be applied to data
objects; see Section 6.1.2 for the list of restrictions that can objects; see Section 6.1.2 for the list of restrictions that can
be enforced with a token. be enforced with a token.
o There is no messaging between a client and server to manipulate o There is no messaging between a client and server to manipulate
data object permissions. This can simplify, in particular, data object permissions. This can simplify, in particular,
Applications which share data objects with many dynamic peers and Applications which share data objects with many dynamic clients
need to frequently adjust access control policies attached to data and need to frequently adjust access control policies attached to
objects. data objects.
o Tokens can provide anonymous access, in which a server does not o Tokens can provide anonymous access, in which a server does not
need to know the identity of each client that accesses it. This need to know the identity of each client that accesses it. This
enables a client to send tokens to clients in other administrative enables a client to send tokens to clients in other administrative
or security domains, and allow them to read or write data objects or security domains, and allow them to read or write data objects
from its storage. from its storage.
In addition to clients applying access control policies to data In addition to clients applying access control policies to data
objects, the server MAY be configured to apply additional policies objects, the server MAY be configured to apply additional policies
based on user, object, geographic location, etc. A client might thus based on user, object, geographic location, etc. A client might thus
skipping to change at page 26, line 51 skipping to change at page 26, line 51
Specifics regarding error handling, including additional error Specifics regarding error handling, including additional error
conditions (e.g. overload), precedence for returned errors and its conditions (e.g. overload), precedence for returned errors and its
relation with server policy, are deferred to eventual protocol relation with server policy, are deferred to eventual protocol
specification. specification.
6.3. Server-to-Server Protocols 6.3. Server-to-Server Protocols
An important feature of a DECADE-compatible system is the capability An important feature of a DECADE-compatible system is the capability
for one server to directly download objects from another server. for one server to directly download objects from another server.
This capability allows Applications to directly replicate data This capability allows Applications to directly replicate data
objects between servers without requiring end-hosts to use uplink objects between servers without requiring clients to use uplink
capacity to upload data objects to a different server. capacity to upload data objects to a different server.
DRP and SDT will support operations directly between servers. DRP and SDT will support operations directly between servers.
Servers are not assumed to trust each other nor are configured to do Servers are not assumed to trust each other nor are configured to do
so. All data operations are performed on behalf of clients via so. All data operations are performed on behalf of clients via
explicit instruction. However, the objects being processed do not explicit instruction. However, the objects being processed do not
necessarily have to originate or terminate at the client (i.e. the necessarily have to originate or terminate at the client (i.e. the
object might be limited to being exchanged between servers even if object might be limited to being exchanged between servers even if
the instruction is triggered by the client). Clients thus will be the instruction is triggered by the client). Clients thus will be
able to indicate to a server the following additional parameters: able to indicate to a server the following additional parameters:
skipping to change at page 29, line 31 skipping to change at page 29, line 31
servers is compromised. servers is compromised.
This is a general security threat that applies to authorization This is a general security threat that applies to authorization
delegation schemes. Specifications of existing delegation schemes delegation schemes. Specifications of existing delegation schemes
such as OAuth [RFC5849] discuss these general threats in detail. We such as OAuth [RFC5849] discuss these general threats in detail. We
can say that the DRP has to specify appropriate algorithms for token can say that the DRP has to specify appropriate algorithms for token
generation. Moreover, authorization tokens should have a limited generation. Moreover, authorization tokens should have a limited
validity period that should be specified by the application. Token validity period that should be specified by the application. Token
confidentiality should be provided by application protocols that confidentiality should be provided by application protocols that
carry tokens, and the SDT and DRP should provide secure carry tokens, and the SDT and DRP should provide secure
(confidential) communication modes. (confidential) communication.
7.2.2. Threat: Object Spoofing 7.2.2. Threat: Object Spoofing
In a DECADE-compatible system, an Application End-Point is referring In a DECADE-compatible system, an Application End-Point is referring
other Application End-Points to servers to download a specified data other Application End-Points to servers to download a specified data
objects. An attacker could "inject" a faked version of the object objects. An attacker could "inject" a faked version of the object
into this process, so that the downloading End-Point effectively into this process, so that the downloading End-Point effectively
receives a different object (compared to what the uploading End-Point receives a different object (compared to what the uploading End-Point
provided). As result, the downloading End-Point believes that is has provided). As result, the downloading End-Point believes that is has
received an object that corresponds to the name it was provided received an object that corresponds to the name it was provided
skipping to change at page 30, line 28 skipping to change at page 30, line 28
8. IANA Considerations 8. IANA Considerations
This document does not have any IANA considerations. This document does not have any IANA considerations.
9. Acknowledgments 9. Acknowledgments
We thank the following people for their contributions to this We thank the following people for their contributions to this
document: document:
Carsten Bormann
David Bryan David Bryan
Hongqiang (Harry) Liu Dave Crocker
David Harrington
Yingjie Gu Yingjie Gu
Hongqiang (Harry) Liu
David McDysan David McDysan
Borje Ohlman Borje Ohlman
Haibin Song Haibin Song
Martin Stiemerling Martin Stiemerling
Richard Woundy Richard Woundy
Ning Zong Ning Zong
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 10.2. Informative References
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
 End of changes. 19 change blocks. 
29 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/