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//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//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/ 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/ 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/ 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]