Internet DRAFT - draft-wang-decade-drp

draft-wang-decade-drp






Network Working Group                                            D. Wang
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                  H. Liu
Expires: September 13, 2011                                      Y. Yang
                                                         Yale University
                                                           July 16, 2012


                 An HTTP-based Decade Resource Protocol
                        draft-wang-decade-drp-04

Abstract

   This document explorers the design of an HTTP-based DECADE Resource
   Protocol (DRP), which can be used for content and resource management
   between a DECADE Client and a DECADE Server, or between two DECADE
   Servers.  We identify the function entities, and present initial
   protocol message flow and syntax design.  The purpose of this
   document is to get design discussion started, not to provide a
   complete solution.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 13, 2011.

Copyright Notice

   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Wang, et al.           Expires September 13, 2011               [Page 1]

Internet-Draft                     DRP                          Mar 2011


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminologies and concepts . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Function Entities  . . . . . . . . . . . . . . . . . . . .  4
     3.3.  Protocol Architecture  . . . . . . . . . . . . . . . . . .  4
     3.4.  Object Naming  . . . . . . . . . . . . . . . . . . . . . .  4
     3.5.  Protocol Operations  . . . . . . . . . . . . . . . . . . .  4
   4.  Access and Resource Control  . . . . . . . . . . . . . . . . .  5
   5.  Token Structure/HTTP Authentication Format . . . . . . . . . .  6
   6.  Message Syntax and Processing  . . . . . . . . . . . . . . . .  7
     6.1.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.2.  Common Message Processing  . . . . . . . . . . . . . . . .  7
     6.3.  DECADE Messages  . . . . . . . . . . . . . . . . . . . . .  8
       6.3.1.  Transport_Query Message  . . . . . . . . . . . . . . .  8
       6.3.2.  Access_Token Message . . . . . . . . . . . . . . . . .  9
       6.3.3.  Server_States_Query Message  . . . . . . . . . . . . . 10
       6.3.4.  Object_Property_Query Message  . . . . . . . . . . . . 12
       6.3.5.  Object_Property_Set Message  . . . . . . . . . . . . . 14
       6.3.6.  Delete_Data Message  . . . . . . . . . . . . . . . . . 15
     6.4.  Error Response Messages  . . . . . . . . . . . . . . . . . 16
   7.  Integration with an HTTP-based SDT . . . . . . . . . . . . . . 17
     7.1.  Put_Object Message . . . . . . . . . . . . . . . . . . . . 17
     7.2.  Get_Object Message . . . . . . . . . . . . . . . . . . . . 18
   8.  Remote_Get_Object Message  . . . . . . . . . . . . . . . . . . 19
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.1. Normative Reference  . . . . . . . . . . . . . . . . . . . 21
     12.2. Informative Reference  . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21











Wang, et al.           Expires September 13, 2011               [Page 2]

Internet-Draft                     DRP                          Mar 2011


1.  Introduction

   The DECADE Architecture document [I-D.ietf-decade-arch-03] identifies
   a DECADE architecture that consists of two logically independent
   protocols: the DECADE Resource Protocol (DRP) and the Standard Data
   Transport (SDT).  The former provides access control and resource
   scheduling between two DECADE peers, while the latter is used to
   transfer data objects to and from a DECADE Server.  The architecture
   document observes that the two protocols may be realized on the same
   wire.

   In this document, we present an initial design of a DRP based on
   HTTP.  We use the DECADE requirements [I-D.ietf-decade-reqs-04] to
   guide our design.  The purpose of this document is to get design
   discussions started, not to provide a complete solution.

   Specifically, the DRP we present provides a signaling layer for
   transport negotiation, content management, access control and
   resource control.  The SDT is responsible for data put, retrieve,
   delete, and metadata update, and the implementation of access control
   and resource control policies.

   We also show that the HTTP based DRP may be extended to include an
   HTTP based SDT, achieving a same-wire design, although it is also
   possible to use another SDT.


2.  Terminologies and concepts

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "MAY", "MAY NOT" and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This draft uses the terms defined in [I-D.ietf-decade-reqs-04] and in
   [I-D.ietf-decade-arch-03].

   DECADE peers: Entities involved in the DRP, such as a DECADE Server
   or a DECADE Client.


3.  Protocol Overview

3.1.  Overview

   The DECADE Protocol is spoken between a DECADE Client and a DECADE
   Server or between two DECADE Servers to manage, store, and retrieve
   data objects for data distribution.  A DECADE Client can be an
   application server, or embedded in a web browser, etc.



Wang, et al.           Expires September 13, 2011               [Page 3]

Internet-Draft                     DRP                          Mar 2011


   We use the scheme where DECADE uses a data-derived naming scheme to
   achieve content security and de-duplication.  In this initial design,
   we assume that the name space is flat for simplicity.  We anticipate
   that the naming scheme may allow for group operations on a set of
   data objects with a similar/same attribute.

3.2.  Function Entities

   We consider two primary function entities involved in DECADE: the
   DECADE Server and the DECADE Client.

   DECADE Server: A DECADE Server stores DECADE data inside the network,
   and thereafter manages both the stored data and access to that data
   [I-D.ietf-decade-arch-02].

   DECADE Client: A DECADE Client stores and retrieves data at DECADE
   Servers [I-D.ietf-decade-arch-02].

3.3.  Protocol Architecture

   Figure 1 presents the simple protocol architecture.
     +------+      DRP        +------+
     |DECADE|<--------------->|DECADE|
     |Server|<--------------->|Server|
     +------+      SDT        +------+
       ^  ^                     ^  ^
       |  |                     |  |
    DRP|  | SDT              DRP|  |SDT
       |  |                     |  |
       v  v                     v  v
     +------+                  +------+
     |DECADE|                  |DECADE|
     |Client|                  |Client|
     +------+                  +------+
      Figure1 Protocol Architecture

3.4.  Object Naming

   (To be added...)

3.5.  Protocol Operations

   The DRP we present is a request-response protocol.  Requests and
   corresponding responses are exchanged between a DECADE Client and a
   DECADE Server or between two DECADE Servers.  A request includes an
   Access Token, which allows the DECADE Server to limit access and
   implement resource control.  In particular, a token specifies
   permitted operations to permitted objects by permitted clients during



Wang, et al.           Expires September 13, 2011               [Page 4]

Internet-Draft                     DRP                          Mar 2011


   permitted period, as well as priority for bandwidth given to
   requested operation, and so on.

   In particular, we identify the following management requests:

      Query Server Status (from the system's view): This operation
      allows a DECADE Client to query statue information of a specific
      DECADE Server from the server view, e.g., lists of associated
      objects, resource used/available, and so on.

      Query Server Status (from the user's view): This operation allows
      a DECADE Client to query status specific to itself, e.g., list of
      associated objects that the DECADE Client stored in the Server,
      the Client's available resources, and so on.

      Query Object Property: This operation allows a DECADE Client to
      query object properties, including TTL of objects, object sizes.

      Set Object Property: This operation allows a DECADE Client to set
      data object properties.

      Delete Data Object: This operation is used to delete data objects
      from a DECADE Server.

   Complementing the preceding DRP operations, we define the following
   SDT operations archieve a complete DECADE Protocol:

      Put Data Object: This operation is used to write data objects to a
      DECADE Server.

      Get Data Object: This operation is used to download data objects
      from a DECADE Server.


4.  Access and Resource Control

   We start with a brief evaluation on the feasibility of using an
   existing IETF protocol for resource control in DECADE.  In
   particular, we evaluate the feasibility of extending an existing
   protocol for granting a third party access to the resource and data
   objects owned by a resource/data owner.  We consider the
   applicability of OAuth, AAA, and Kerberos.

   In Kerberos [RFC4120], a client obtains Tickets to obtain services.
   Specifically, in Kerberos, a client first obtains a Client/TGS
   session key and a Ticket-Granting-Ticket from an authentication
   server.  An issue of this approach, however, is that it requires a
   client to authenticate with the system.  Hence, it may work well in a



Wang, et al.           Expires September 13, 2011               [Page 5]

Internet-Draft                     DRP                          Mar 2011


   single DECADE domain system where each client has an account at a
   DECADE provider.  On the other hand, DECADE should also work in an
   inter-domain setting, where a client may not have an account on a
   Wang, et al.  Expires September 13, 2012 [Page 5] Internet-Draft DRP
   Mar 2012 DECADE server.  Hence, extensions could be challenging.

   Radius [RFC 2865] [RFC 2866] and its successor Diameter [RFC 3588]
   are the base AAA protocols.  Although extending the binary attribute-
   value-pairs (AVPs) may be possible to grant network resources for
   data access, the resource control communication points in the DECADE
   environment are application clients/servers and DECADE servers, and
   hence a text-based protocol may be preferred by the application
   clients.  However, this should not prevent that the Diameter protocol
   be used between a DECADE server and an application server for AAA
   purposes.

   OAuth v2 [draft-ietf-oauth-protocol-v2-23] is used to grant access to
   the resource owner's resources from a third party without explicitly
   exposing the resource owner's credentials.  It currently focuses on
   the context of HTTP [RFC2616].  The three-leg-style access assumption
   is different from the access requirement in the DECADE system
   environment.  Howerver, some grant types may be adopted (such as
   implicit grant) and extensions can be added for resource control.


5.  Token Structure/HTTP Authentication Format

   A primary use case for DECADE is that a DECADE Client authorizes
   other DECADE Clients to store or retrieve data objects from its
   DECADE storage.  Therefore, we explore a DECADE protocol using a
   token-based authorization scheme instead of explicitly manipulating
   an Access Control List (ACL) for each DECADE data object.

   Tokens can be generated by a DECADE Client itself or any of its
   trusted parties/entities.  After a token has been generated, it can
   be distributed to other DECADE Clients for them to request for access
   to the DECADE Server.  In this way, token can support anonymous
   access, and a DECADE Server does not need to know the identity of
   each DECADE Client that accesses it.

   In order to provide a complete authorization scheme, the token MUST
   carry the following information: Permitted operations, Permitted
   objects, Permitted Clients, Expiration time, Priority for bandwidth
   given to requested operation, and Amount of data that may be read or
   written.

   The token can be carried with the request message.  A possibility of
   a header for signature is:



Wang, et al.           Expires September 13, 2011               [Page 6]

Internet-Draft                     DRP                          Mar 2011


   X-DECADE-TOKEN: DECADE keyID;signature

   The "signature" represents alphanumeric or numeric data to be
   inserted, which includes necessary authentication information
   described before.  A design is that the siganture is calculated based
   on HMAC-SHA1.

   signature = Base64(HMAC-SHA1(UTF-8-Encoding-Of(StringToSign)))

   StringToSign = PermittedOperation1 + "\n" + ... + PermittedOperationm
   + "\n" + PermittedObject1 + "\n" + ... + PermittedObjectn + "\n" +
   TTL + "\n" + Priority for bandwidth given to requested operation +
   "\n" + Amount of data that may be read or written + "\n"key

   After the DECADE Server receives a request, it verifies the
   authorization by checking the token.  If the token is valid, the
   request/certain operations will be authenticated, otherwise, it will
   be rejected.  If the token is successfully validated, the DECADE
   Server applies the resources control policies indicated in the token
   while performing the operation.


6.  Message Syntax and Processing

   We now present the encoding and processing.

6.1.  Encoding

   The DRP in this document follows the standard request and response
   formats for HTTP Request and Response messages [RFC2616].

   Specifically, the header fields in both request and response messages
   follows the standard rules for HTTP/1.1 Header fields, which MAY be
   included in the messages if necessary.

   We use JSON to encode the bodies for both request and response
   messages.

   In the following messages, both *** and XXX represent data to be
   insert, either numeric data or alphanumeric data.

6.2.  Common Message Processing

   After receiving a DECADE protocol message, a DECADE server performs
   some basic processing, regardless of the message type and the
   receiving entity.

   Specifically, upon receiving a message, the DECADE server ensures



Wang, et al.           Expires September 13, 2011               [Page 7]

Internet-Draft                     DRP                          Mar 2011


   that the message is properly formed.  If not, appropriate standard
   HTTP errors MUST be generated.  Below are some examples.

   If the message is found to be incorrectly formed or the length does
   not match the length encoded in the header, the receiver MUST reply
   with an HTTP 400 response.

   If the version number is not supported by the receiver, the receiver
   MUST reply with an HTTP 400 response.

   If the receiver is unable to process the message temporarily because
   it is in an overloaded state, the receiver SHOULD reply with an HTTP
   503 response.

   If the receiver encounters an internal error while attempting to
   process the message, the receiver MUST generate an HTTP 500 response.

6.3.  DECADE Messages

   DECADE protocol can be divided into two layers, the signaling layer
   and the transport layer.  The signaling layer is responsible for
   transport negotiation, data management, access control and resource
   control.  The Transport layer is responsible for data put, retrieve,
   delete, metadata update, and the implementation of access control and
   resource control policies.  Therefore, SDT messages must be extended
   to include tokens.

6.3.1.  Transport_Query Message

   A Transport_Query message is used to query a DECADE server about its
   supported transports.  A DECADE client will send a request to the
   DECADE server to ask for the transport protocols supported by the
   server.  And then the DECADE server will send back a reply with the
   supported transport protocols.  A DECADE server must listen on the
   server ports of the supported protocols (e.g.  NFS).  By that, the
   DECADE client (active) can impose data operations on the DECADE
   server using either one of the supported transport protocols
   supported by the DECADE server.  Below is an example Transport_Query
   message:
      GET /decade/transport/ HTTP/1.1
      Host:  example.com
      Content-Length: ***
      Content-Type: application/decade-transport-req+json
      X-DECADE-Protocol-Version: 1.0

   If the query message is valid, the DECADE Server sends back a
   response listing the supported SDT protocols.  An example is shown
   below:



Wang, et al.           Expires September 13, 2011               [Page 8]

Internet-Draft                     DRP                          Mar 2011


      HTTP/1.1 200 OK
      Content-Length: ***
      Content-Type: application/decade-transport-ans+json
      X-DECADE-Protocol-Version: 1.0

      {
      "transport-protocol":
              {
                      "HTTP": true;
                      "NFS": true;
                      "WebDAV": true;
              }
      }

      JSON Object:
      Object {
              JSONBool HTTP;     [OPTIONAL]
              JSONBool NFS;      [OPTIONAL]
              JSONBool WebDav;   [OPTIONAL]
      } TransportProtocol;

      Object {
          TransportProtocol transport-protocol;
      }

   When the DECADE Client receives the response from the Server, it will
   choose a protocol that it supports and communicates with the Server
   via the chosen protocol.

6.3.2.  Access_Token Message

   It is possible for a client to ask a DECADE server to generate a key,
   instead of generating locally.  An example message is as following:
      POST /decade/token HTTP/1.1
      Host: example.com
      Content-Length: ***
      Content-Type: application/decade-access-token-req+json
      X-DECADE-Protocol-Version: 1.0

      {
          JSONString: DECADEClientId;
          token parameters
      }

   If the DECADE Client identifier is valid and the request message is
   successfully proceeded, the DECADE Server will reply with the
   authenticate token.  An example of the response message is as below:




Wang, et al.           Expires September 13, 2011               [Page 9]

Internet-Draft                     DRP                          Mar 2011


      HTTP/1.1 200 OK
      Content-Type: application/decade-access-token-ans+json
      X-DECADE-Protocol-Version: 1.0

      {
          JSONString: token;
      }

6.3.3.  Server_States_Query Message

   This operation allows state query.  The state can be either system-
   wide or on a particular user.  An example message is:
      POST /decade/state HTTP/1.1
      Host: example.com
      Content-Length: ***
      Content-Type: application/decade-stat-req+json
      X-DECADE-Protocol-Version: 1.0
      X-DECADE-TOKEN: DECADE signature

      {
              "state-request":
              {
                      "StorageUsed": true;
                      "StorageAvailable": true;
                      "BandwidthUsed": true;
                      "BandwidthAvailable": true;
                      "ObjectNum": true;
                      "ObjectList": true;
              }

              "user-type":
              {
                      "System": true;
              }

              "token":XXX;
      }

      JSON Object:
      Object{
              JSONBool StorageUsed;           [OPTIONAL]
              JSONBool StorageAvailable;      [OPTIONAL]
              JSONBool BandwidthUsed;         [OPTIONAL]
              JSONBool BandwidthAvailable;    [OPTIONAL]
              JSONBool ObjectNum;             [OPTIONAL]
              JSONBool ObjectList;            [OPTIONAL]
      }ServerState;




Wang, et al.           Expires September 13, 2011              [Page 10]

Internet-Draft                     DRP                          Mar 2011


      Object{
              JSONBool System;        [OPTIONAL]
              JSONBool User;          [OPTIONAL]
      }UserType;

      Object{
              ObjectOperation permitted-operations<0..*>;
              JSONObject permitted-objects;
              JSONObject permitted-clients;
              JSONNumber expiration-time;
              JSONNumber priority;
      }AuthToken;

      Object{
              ServerState server-state;
      }

      Object{
              UserType user-type;
      }

      Object{
              AuthToken token;
      }

   If a state query message is valid, the DECADE Server responses with
   corresponding server state.  If the "user-type" in the message body
   is "System", then the server should return the status of resource
   consumption on this server after verifying the user's access right.
   Usually the right will be authorized to the system administrator.  If
   the "user-type" in the message body is "User", then the server should
   return the status of resource consumption of this particular user on
   this server after verifying the user's access right.  An example of
   the Response is as following:

















Wang, et al.           Expires September 13, 2011              [Page 11]

Internet-Draft                     DRP                          Mar 2011


      HTTP/1.1 200 OK
      Content-Length: ***
      Content-Type: application/decade-stat-ans+json
      X-DECADE-Protocol-Version: 1.0

      {
              "server-state":
              {
                      "storage-used": ***;
                      "storage-available": ***;
                      "bandwidth-used": ***;
                      "bandwidth-available": ***;
                      "object-number": ***;

                      "object-list":
                      [
                              "data-object":
                              {
                                      "object-name":XXX;
                              }
                      ]
              }
      }

      JSON Object:
      Object{
              JSONNumber storage-used;                [OPTIONAL]
              JSONNumber storage-available;           [OPTIONAL]
              JSONNumber bandwidth-used;              [OPTIONAL]
              JSONNumber object-number;               [OPTIONAL]
              JSONArray object-list["DataObject"];    [OPTIONAL]
      }ServerState;

      Object{
              JSONString object-name;
      }DataObject;

      Object{
              DataObject data-object;
      }

6.3.4.  Object_Property_Query Message

   This operation allows a DECADE Client to query object properties with
   certain authentication, including TTL of object, object size, and
   object type.  The request message is as following:





Wang, et al.           Expires September 13, 2011              [Page 12]

Internet-Draft                     DRP                          Mar 2011


      POST /decade/object/<obj-name>/property HTTP/1.1
      Host: example.com
      Content-Length: ***
      Content-Type: application/decade-objprop-query-req+json
      X-DECADE-Protocol-Version: 1.0
      X-DECADE-TOKEN: DECADE signature

      {
              "token": XXX;
      }

      JSON Object:
      Object{
              ObjectOperation permitted-operations<0..*>;
              JSONObject permitted-objects;
              JSONObject permitted-clients;
              JSONNumber expiration-time;
              JSONNumber priority;
      }AuthToken;

      Object{
              AuthToken token;
      }

   If the object property query message is valid and successfully
   proceeded, the DECADE Server replies the request info.  An example of
   the response message is as below:
























Wang, et al.           Expires September 13, 2011              [Page 13]

Internet-Draft                     DRP                          Mar 2011


      HTTP/1.1 200 OK
      Content-Length: ***
      Content-Type: application/decade-objprop-query-ans+json
      X-DECADE-Protocol-Version: 1.0

      {
              "object-property":
              {
                      "object-type": XXX;
                      "object-size": ***;
                      "owner": XXX;
                      "TTL": ***;
              }
      }

      JSON Object:
      Object{
              JSONString object-type; [OPTIONAL]
              JSONNumber object-size; [OPTIONAL]
              JSONString owner;       [OPTIONAL]
              JSONNumber TTL;         [OPTIONAL]
      }ObjectProperty;

      Object{
              ObjectProperty object-property;
      }

6.3.5.  Object_Property_Set Message

   This operation allows a DECADE Client to set object properties
   (metadata).  The request message is as following:




















Wang, et al.           Expires September 13, 2011              [Page 14]

Internet-Draft                     DRP                          Mar 2011


      PUT /decade/<obj-name>/property HTTP/1.1
      Host: example.com
      Content-Length: ***
      Content-Type: application/decade-objprop-set-req+json
      X-DECADE-Protocol-Version: 1.0
      X-DECADE-TOKEN: DECADE signature

      {
              "object-property":
              {
                      "TTL": ***;
              }

              "token": XXX;
      }

      JSON Object:
      Object{
              JSONNumber TTL;         [OPTIONAL]
      }ObjectProperty;

      Object{
              ObjectOperation permitted-operations<0..*>;
              JSONObject permitted-objects;
              JSONObject permitted-clients;
              JSONNumber expiration-time;
              JSONNumber priority;
      }AuthToken;

      Object{
              ObjectProperty object-property;
      }

      Object{
              AuthToken token;
      }

   If the object property set message is valid, the DECADE Server
   replies with the following message:
      HTTP/1.1 204 NO CONTENT
      Content-Length: ***
      Content-Type: application/decade-objprop-set-req-ans+json
      X-DECADE-Protocol-Version: 1.0

6.3.6.  Delete_Data Message

   This operation is used to delete objects from a DECADE Server.  An
   example of the request message is as following:



Wang, et al.           Expires September 13, 2011              [Page 15]

Internet-Draft                     DRP                          Mar 2011


      DELETE /decade/<obj-name> HTTP/1.1
      Host: example.com
      Content-Length: ***
      Content-Type: application/decade-deledata-req+json
      X-DECADE-Protocol-Version: 1.0
      X-DECADE-TOKEN: DECADE signature

      {
              "token": XXX;
      }

      Object{
              ObjectOperation permitted-operations<0..*>;
              JSONObject permitted-objects;
              JSONObject permitted-clients;
              JSONNumber expiration-time;
              JSONNumber priority;
      }AuthToken;

      Object{
              AuthToken token;
      }

   An example of the response message is as following:
      HTTP/1.1 204 NO CONTENT
      Content-Length: ***
      Content-Type: application/decade-deledata-req+json
      X-DECADE-Protocol-Version: 1.0

6.4.  Error Response Messages

   The error response messages for the DECADE protocol are described
   below:

   SUCCESSFUL (200 OK): a message has been processed properly and the
   desired operation has completed.  If the message is a request for
   information, the body will also include the requested information.

   NO CONTENT (204 NO CONTENT): The server successfully processed the
   request, but is not returning any content.

   INVALID SYNTAX (400 Bad Request): Indicates an error in the format of
   the message/message body.

   VERSION NOT SUPPORTED (400 Bad Request): Invalid version of the
   protocol or message bodies.

   AUTHENTICATION REQUIRED (401 UNAUTHORIZED): Authentication is



Wang, et al.           Expires September 13, 2011              [Page 16]

Internet-Draft                     DRP                          Mar 2011


   required to access this information.

   MESSAGE FORBIDDEN (403 FORBIDDEN): The requester is not allowed to
   make this request.

   OBJECT NOT FOUND (404 NOT FOUND): The requested object cannot be
   found.

   SERVER NOT FOUND (404 NOT FOUND): The requested server cannot be
   found.


7.  Integration with an HTTP-based SDT

7.1.  Put_Object Message

   This operation is used to write objects to a DECADE Server.  An
   example of the request message is as following:
      PUT /decade/<obj-name> HTTP/1.1
      Host: example.com
      Content-Length: ***
      Content-Type: application/decade-putdata-req+json
      X-DECADE-Protocol-Version: 1.0
      X-DECADE-TOKEN: DECADE signature

      {
              "object-list":
              [
                      "data-object":
                      {
                              "object-size": ***;
                              "object-type": XXX;

                              "object-metadata":
                              {
                                      "object-type": XXX;
                                      "object-size": ***;
                                      "TTL": ***;
                              }
                      }
              ]

              "token": XXX;
      }

      JSON Object:

      Object{



Wang, et al.           Expires September 13, 2011              [Page 17]

Internet-Draft                     DRP                          Mar 2011


              JSONNumber object-size;         [OPTIONAL]
              JSONString object-type;          [OPTIONAL]
              JSONObject object-metadata:     [OPTIONAL]
              {
                      JSONString owner;
                      JSONNumber TTL;         [OPTIONAL]
              }
      }DataObject;

      Object{
              JSONArray object-list["DataObject"];
      }

      Object{
              ObjectOperation permitted-operations<0..*>;
              JSONObject permitted-objects;
              JSONObject permitted-clients;
              JSONNumber expiration-time;
              JSONNumber priority;
      }AuthToken;

      Object{
              AuthToken token;
      }

   An example of response message is as below:
      HTTP/1.1 204 NO CONTENT
      Content-Length: ***
      Content-Type: application/decade-putdata-ans+json
      X-DECADE-Protocol-Version: 1.0

7.2.  Get_Object Message

   This operation is used to download objects from a DECADE Server.  An
   example of the request message is as following:
















Wang, et al.           Expires September 13, 2011              [Page 18]

Internet-Draft                     DRP                          Mar 2011


      POST /decade/<obj-name> HTTP/1.1
      Host: example.com
      Content-Length: ***
      Content-Type: application/decade-getdata-req+json
      X-DECADE-Protocol-Version: 1.0
      X-DECADE-TOKEN: DECADE signature

      {
              "token": XXX;
      }

      Object{
              ObjectOperation permitted-operations<0..*>;
              JSONObject permitted-objects;
              JSONObject permitted-clients;
              JSONNumber expiration-time;
              JSONNumber priority;
      }AuthToken;

      Object{
              AuthToken token;
      }

   An example of the response message is as following:
      HTTP/1.1 200 OK
      Host: example.com
      Content-Length: ***
      Content-Type: application/decade-getdata-req+json
      X-DECADE-Protocol-Version: 1.0
      X-DECADE-TOKEN: DECADE signature


8.  Remote_Get_Object Message

   This operation is used to download objects from a remote DECADE
   server via another DECADE server.  The basic idea is to leverage the
   base functionality of a "non-transparent proxy" in DECADE.  In this
   model, the local DECADE Server would act as a non-transparent caching
   proxy (with additional functionality) in order to reach the remote
   DECADE server and cache the contents of the reply in DECADE storage.
   A general call flow among the DECADE Client, local DECADE Server, and
   remote DECADE Server is shown in Figure 2.









Wang, et al.           Expires September 13, 2011              [Page 19]

Internet-Draft                     DRP                          Mar 2011


   DECADE Client           Local DECADE Server       Remote DECADE Server
                         (non-transparent proxy)
          |      HTTP Get/Post      |                          |
          |------------------------>|       HTTP Get/Post      |
          |                         |------------------------->|
          |                         |                          |
          |                         |<-------------------------|
          |                         |       HTTP Response      |
          |<------------------------|                          |
          |      HTTP Response      |                          |
          |                         |                          |
             Figure2 Call Flow in Remote_Get_Object Message

   If DECADE is using HTTP URI types that existing proxies understand,
   HTTP-Get should be used.  If the non-HTTP URI types are used, it'd
   better to use POST and to provide DECADE request parameters such as
   the object name in form data parameters.  It can cache responses to
   those requests using cache-control headers.

   As for server-server communications (without a DECADE Client
   involved), standard HTTP GET, PUT, POST could be used.  Figure 3
   gives a simple call flow between two DECADE Servers for server-server
   communications.
     DECADE Server-1              DECADE Server-2
            |                            |
            |    HTTP Get/Post/Put       |
            |--------------------------->|
            |                            |
            |<---------------------------|
            |      HTTP Response         |
            |                            |
    Figure3 Call Flow in Server-Server Communications


9.  Security Considerations

   The security considerations described in both [I-D.ietf-decade-arch]
   and [I-D.ieft-decade-problem-statement] apply to this draft as well.


10.  IANA Considerations

   This draft does not have any IANA considerations.


11.  Acknowledgements

   We would like to express our sincere thanks and appreciation to Zhou



Wang, et al.           Expires September 13, 2011              [Page 20]

Internet-Draft                     DRP                          Mar 2011


   Hong for his valuable suggestions and support.


12.  References

12.1.  Normative Reference

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn , "The
              Kerberos Network Authentication Service (V5)", July 2005.

   [RFC2865]  Rigney, C., Willens, S., Rubens A., A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", June 2000.

   [RFC3588]  Calhoun , P., Loughney , J., Rubens A., E., Zorn , G., and
              J. Arkko, "Diameter Base Protocol", September 2003.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", June 1999.

12.2.  Informative Reference

   [I-D.ietf-decade-reqs]
              Gu, Y., Bryan, D., Yang, Y., and R. Alimi, "DECADE
              Requirements", September 2011.

   [I-D.ietf-decade-arch]
              Alimi , R., Yang, Y., Rahman, A., Kutscher, D., and H.
              Liu, "DECADE Architecture", July 2011.

   [I-D.ietf-decade-problem-statement]
              Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
              Application Data Enroute (DECADE) Problem Statement".

   [I-D.ietf-oauth-protocol-v2-23]
              Recordon, D. and D. Hardt, "The OAuth 2.0 Authorization
              Protocol", January 2012.








Wang, et al.           Expires September 13, 2011              [Page 21]

Internet-Draft                     DRP                          Mar 2011


Authors' Addresses

   Wang Danhua
   Huawei Technologies
   No. 101 Software Avenue
   Nanjing, Jiangsu Province  210001
   P.R.China

   Phone: +86-25-56624734
   Fax:   +86-25-56624702
   Email: wangdanhua@huawei.com


   Harry Liu
   Yale University

   Email: hongqiang.liu@yale.edu


   Y.Richard Yang
   Yale University

   Email: yry@cs.yale.edu




























Wang, et al.           Expires September 13, 2011              [Page 22]