[要約] RFC 7069は、DECoupled Application Data Enroute（DECADE）プロトコルに関するものであり、データの分散処理とストレージを可能にすることを目的としています。DECADEは、アプリケーションデータの効率的な配信と処理を実現するための枠組みを提供します。
Independent Submission R. Alimi
Request for Comments: 7069 Google
Category: Informational A. Rahman
ISSN: 2070-1721 InterDigital Communications, LLC
D. Kutscher
NEC
Y. Yang
Yale University
H. Song
Huawei Technologies
K. Pentikousis
EICT
November 2013
DECoupled Application Data Enroute (DECADE)
DECoupled Application Data Enroute（DECADE）
Abstract
概要
Content distribution applications, such as those employing peer-to-peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks. Often, however, content distribution applications use network resources inefficiently. One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end-host and in-network content distribution mechanisms. This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document. DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources. This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples.
ピアツーピア（P2P）テクノロジを採用したアプリケーションなどのコンテンツ配信アプリケーションは、インターネットで広く使用されており、多くのネットワークでトラフィックの大部分を占めています。ただし、多くの場合、コンテンツ配信アプリケーションはネットワークリソースを非効率的に使用します。効率を改善する1つの方法は、ネットワーク内にストレージ機能を導入し、エンドホストとネットワーク内のコンテンツ配信メカニズム間の連携を可能にすることです。これは、このドキュメントで紹介されているDECoupled Application Data Enroute（DECADE）システムによって提供される機能です。 DECADEを使用すると、アプリケーションは、エンドツーエンドのリソースだけを使用するのではなく、データオブジェクトを分散するときにネットワーク内ストレージを利用できます。このドキュメントでは、このようなシステムの基本的な原理と主要な機能を紹介し、一連の例を通じて操作を説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7069.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7069で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Architectural Principles . . . . . . . . . . . . . . . . . . 8
4.1. Data- and Control-Plane Decoupling . . . . . . . . . . . 8
4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . 9
4.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 10
4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . 11
4.5. Resource and Data Access Control through Delegation . . . 11
5. System Components . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Application Endpoint . . . . . . . . . . . . . . . . . . 13
5.2. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 14
5.3. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Data Sequencing and Naming . . . . . . . . . . . . . . . 15
5.5. Token-Based Authorization and Resource Control . . . . . 17
5.6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 18
6. DECADE Protocol Considerations . . . . . . . . . . . . . . . 19
6.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Resource Protocol . . . . . . . . . . . . . . . . . . . . 19
6.3. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 22
6.4. Server-Server Protocols . . . . . . . . . . . . . . . . . 23
6.5. Potential DRP/SDT Candidates . . . . . . . . . . . . . . 23
7. How In-Network Storage Components Map to DECADE . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8.1. Threat: System Denial-of-Service Attacks . . . . . . . . 25
8.2. Threat: Authorization Mechanisms Compromised . . . . . . 25
8.3. Threat: Spoofing of Data Objects . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Evaluation of Candidate Protocols for DECADE DRP/SDT 29
A.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. CDMI . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Content distribution applications, such as peer-to-peer (P2P) applications, are widely used on the Internet to distribute data objects and make up a large portion of the traffic in many networks. Said applications can often introduce performance bottlenecks in otherwise well-provisioned networks. In some cases, operators are forced to invest substantially in infrastructure to accommodate the use of such applications. For instance, in many subscriber networks, it can be expensive to upgrade network equipment in the "last mile", because it can involve replacing equipment and upgrading wiring and devices at individual homes, businesses, DSLAMs (Digital Subscriber Line Access Multiplexers), and CMTSs (Cable Modem Termination Systems) in remote locations. It may be more practical and economical to upgrade the core infrastructure, instead of the "last mile" of the network, as this involves fewer components that are shared by many subscribers. See [RFC6646] and [RFC6392] for a more complete discussion of the problem domain and general discussions of the capabilities envisioned for a DECADE system. As a historical point, it should be noted that [RFC6646] and [RFC6392] came out of the now closed DECADE Working Group. This document aims to advance some of the valuable concepts from that now closed Working Group.
ピアツーピア（P2P）アプリケーションなどのコンテンツ配信アプリケーションは、インターネット上でデータオブジェクトを配信し、多くのネットワークでトラフィックの大部分を構成するために広く使用されています。上記のアプリケーションは、多くの場合、適切にプロビジョニングされたネットワークにパフォーマンスのボトルネックをもたらす可能性があります。場合によっては、事業者はそのようなアプリケーションの使用に対応するために、インフラストラクチャへの実質的な投資を余儀なくされます。たとえば、多くの加入者ネットワークでは、個々の家、企業、DSLAM（デジタル加入者回線アクセスマルチプレクサ）で機器の交換や配線とデバイスのアップグレードが必要になるため、「ラストマイル」でネットワーク機器をアップグレードするとコストがかかる可能性があります。離れた場所にあるCMTS（ケーブルモデムターミネーションシステム）。多くの加入者が共有するコンポーネントの数が少ないため、ネットワークの「ラストマイル」ではなく、コアインフラストラクチャをアップグレードする方が実用的で経済的です。 DECADEシステムで想定される問題ドメインの詳細と機能の一般的な説明については、[RFC6646]および[RFC6392]を参照してください。歴史的なポイントとして、[RFC6646]と[RFC6392]は、現在閉鎖されているDECADEワーキンググループから出たことに注意してください。このドキュメントは、現在閉鎖されているワーキンググループからいくつかの価値ある概念を進めることを目的としています。
This document presents mechanisms for providing in-network storage that can be integrated into content distribution applications. The primary focus is P2P-based content distribution, but DECADE may be useful to other applications with similar characteristics and requirements (e.g., Content Distribution Networks (CDNs) or hybrid P2P/CDNs). The approach we adopt in this document is to define the core functionalities and protocol functions that are needed to support a DECADE system. This document provides illustrative examples so that implementers can understand the main concepts in DECADE, but it is generally assumed that readers are also familiar with the terms and concepts used in [RFC6646] and [RFC6392].
このドキュメントでは、コンテンツ配信アプリケーションに統合できるネットワーク内ストレージを提供するメカニズムを紹介します。主な焦点はP2Pベースのコンテンツ配信ですが、DECADEは同様の特性と要件を持つ他のアプリケーション（たとえば、コンテンツ配信ネットワーク（CDN）またはハイブリッドP2P / CDN）に役立つ場合があります。このドキュメントで採用するアプローチは、DECADEシステムをサポートするために必要なコア機能とプロトコル機能を定義することです。このドキュメントでは、実装者がDECADEの主要な概念を理解できるように、例を示しますが、一般に読者は[RFC6646]と[RFC6392]で使用される用語と概念にも精通していることを前提としています。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses the following terminology.
このドキュメントでは、次の用語を使用しています。
Application Endpoint A host that includes a DECADE client along with other application functionalities (e.g., peer-to-peer (P2P) client, video streaming client).
アプリケーションエンドポイント他のアプリケーション機能（ピアツーピア（P2P）クライアント、ビデオストリーミングクライアントなど）とともにDECADEクライアントを含むホスト。
Content Distribution Application A specific type of application that may exist in an Application Endpoint. A content distribution application is an application (e.g., P2P) designed for dissemination of large amounts of content (e.g., files or video streams) to multiple peers. Content distribution applications may divide content into smaller blocks for dissemination.
コンテンツ配布アプリケーションアプリケーションエンドポイントに存在する可能性がある特定のタイプのアプリケーション。コンテンツ配信アプリケーションは、大量のコンテンツ（ファイルやビデオストリームなど）を複数のピアに配布するために設計されたアプリケーション（P2Pなど）です。コンテンツ配布アプリケーションは、配布のためにコンテンツをより小さなブロックに分割する場合があります。
Data Object A data object is the unit of data stored and retrieved from a DECADE server. The data object is a sequence of raw bytes. The server maintains metadata associated with each data object, but the metadata is physically and logically separate from the data object.
データオブジェクトデータオブジェクトは、DECADEサーバーに格納され、DECADEサーバーから取得されるデータの単位です。データオブジェクトは、生のバイトのシーケンスです。サーバーは各データオブジェクトに関連付けられたメタデータを維持しますが、メタデータは物理的および論理的にデータオブジェクトから分離されています。
DECADE Client A DECADE client uploads and/or retrieves data from a DECADE server.
DECADEクライアントDECADEクライアントは、DECADEサーバーからデータをアップロードまたは取得します。
DECADE Resource Protocol (DRP) A logical protocol for communication of access control and resource-scheduling policies from a DECADE client to a DECADE server, or between DECADE servers. In practice, the functionality of the DRP may be distributed over one or more actual protocols.
DECADE Resource Protocol（DRP）DECADEクライアントからDECADEサーバーへ、またはDECADEサーバー間でアクセス制御およびリソーススケジューリングポリシーを通信するための論理プロトコル。実際には、DRPの機能は1つ以上の実際のプロトコルに分散される場合があります。
DECADE Server A DECADE server stores data inside the network for a DECADE client or another DECADE server, and thereafter it manages both the stored data and access to that data by other DECADE clients.
DECADEサーバーDECADEサーバーは、DECADEクライアントまたは別のDECADEサーバーのネットワーク内にデータを格納し、その後、格納されたデータと他のDECADEクライアントによるそのデータへのアクセスの両方を管理します。
DECADE Storage Provider A DECADE storage provider deploys and/or manages DECADE servers within a network.
DECADEストレージプロバイダーDECADEストレージプロバイダーは、ネットワーク内でDECADEサーバーを展開または管理します。
DECADE System An in-network storage system that is composed of DECADE clients and DECADE servers. The DECADE servers may be deployed by one or more DECADE storage providers.
DECADEシステムDECADEクライアントとDECADEサーバーで構成されるネットワーク内ストレージシステム。 DECADEサーバーは、1つ以上のDECADEストレージプロバイダーによって展開できます。
In-Network Storage A service inside a network that provides storage to applications. In-network storage may reduce upload/transit/backbone traffic and improve application performance. In-network storage may, for example, be co-located with the border router (network-attached storage) or inside a data center. A DECADE system is an example of an in-network storage system.
ネットワーク内ストレージアプリケーション内にストレージを提供するネットワーク内のサービス。ネットワーク内ストレージは、アップロード/トランジット/バックボーントラフィックを削減し、アプリケーションのパフォーマンスを向上させる可能性があります。ネットワーク内ストレージは、たとえば、境界ルーター（ネットワーク接続ストレージ）と同じ場所に配置したり、データセンター内に配置したりできます。 DECADEシステムは、ネットワーク内ストレージシステムの例です。
Standard Data Transfer (SDT) Protocol A logical protocol used to transfer data objects between a DECADE client and DECADE server, or between DECADE servers. The intent is that in practice the SDT should map to an existing, well-known protocol already in use over the Internet for transporting data.
標準データ転送（SDT）プロトコルDECADEクライアントとDECADEサーバー間、またはDECADEサーバー間でデータオブジェクトを転送するために使用される論理プロトコル。その目的は、実際には、SDTがデータの転送にインターネットを介して既に使用されている既存の既知のプロトコルにマップすることです。
A DECADE system provides a distributed storage service for content distribution applications (e.g., P2P). The system consists of clients and servers. A client first uploads data objects to one or more selected servers and optionally requests distribution of these data objects to other servers. The client then selectively authorizes other clients to download these data objects. Such a system is employed in an overall application context (e.g., P2P file sharing), and it is expected that DECADE clients take part in application-specific communication sessions.
DECADEシステムは、コンテンツ配信アプリケーション（P2Pなど）に分散ストレージサービスを提供します。システムはクライアントとサーバーで構成されます。クライアントは最初に1つ以上の選択されたサーバーにデータオブジェクトをアップロードし、オプションでこれらのデータオブジェクトの配布を他のサーバーに要求します。次に、クライアントは、これらのデータオブジェクトをダウンロードすることを他のクライアントに選択的に許可します。このようなシステムは、全体的なアプリケーションコンテキスト（P2Pファイル共有など）で使用され、DECADEクライアントがアプリケーション固有の通信セッションに参加することが期待されています。
Figure 1 is a schematic of a simple DECADE system with two DECADE clients and two DECADE servers. As illustrated, a DECADE client, which is part of an Application Endpoint, uses the DECADE Resource Protocol (DRP) to convey to a server information related to access control and resource-scheduling policies. DRP can also be used between servers for exchanging this type of information. A DECADE system employs the Standard Data Transfer (SDT) protocol to transfer data objects to and from a server, as we will explain later.
図1は、2つのDECADEクライアントと2つのDECADEサーバーを持つ単純なDECADEシステムの概略図です。図に示すように、アプリケーションエンドポイントの一部であるDECADEクライアントは、DECADE Resource Protocol（DRP）を使用して、アクセス制御とリソーススケジューリングポリシーに関連する情報をサーバーに伝えます。 DRPは、このタイプの情報を交換するためにサーバー間で使用することもできます。 DECADEシステムは、標準データ転送（SDT）プロトコルを使用して、後で説明するように、サーバーとの間でデータオブジェクトを転送します。
Native Application
Protocol(s)
.-------------. (e.g., P2P) .-------------.
| Application | <------------------> | Application |
| Endpoint | | Endpoint |
| | | |
| .--------. | | .--------. |
| | DECADE | | | | DECADE | |
| | Client | | | | Client | |
| `--------' | | `--------' |
`-------------' `-------------'
| ^ | ^
DECADE | | Standard | |
Resource | | Data DRP | | SDT
Protocol | | Transfer | |
(DRP) | | (SDT) | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
v v v v
.=============. DRP .=============.
| DECADE | <------------------> | DECADE |
| Server | <------------------> | Server |
`=============' SDT `============='
Figure 1: DECADE Overview
図1：DECADEの概要
With Figure 1 at hand, assume that Application Endpoint B requests a data object from Application Endpoint A using their native application protocols (e.g., P2P protocol) as in Figure 2. In this case, Endpoint A will act as the sender, and Endpoint B as the receiver for said data object. S(A) is the DECADE storage server which is access controlled. This means, first, that Endpoint A has a right to store the data object in S(A). Secondly, Endpoint B needs to obtain authorization before being able to retrieve the data object from S(A).
図1を手元に、アプリケーションエンドポイントBが、図2のようにネイティブアプリケーションプロトコル（P2Pプロトコルなど）を使用してアプリケーションエンドポイントAにデータオブジェクトを要求するとします。この場合、エンドポイントAは送信者として機能し、エンドポイントBは前記データオブジェクトのレシーバとして。 S（A）は、アクセス制御されるDECADEストレージサーバーです。これは、最初に、エンドポイントAがデータオブジェクトをS（A）に格納する権利を持つことを意味します。次に、エンドポイントBは、S（A）からデータオブジェクトを取得する前に承認を取得する必要があります。
The four steps involved in a DECADE session are illustrated in Figure 2. The sequence starts with the initial contact between Endpoint B and Endpoint A, where Endpoint B requests a data object using their native application protocol (e.g., P2P). Next, Endpoint A uses DRP to obtain a token corresponding to the data object that was requested by Endpoint B. There may be several ways for Endpoint A to obtain such a token, e.g., compute it locally or request one from its DECADE storage server, S(A). Once obtained, Endpoint A then provides the token to Endpoint B (again, using their native application protocol). Finally, Endpoint B provides the received token to S(A) via DRP, and subsequently requests and downloads the data object via SDT. Again, it is assumed that DECADE is employed in an overall application context (e.g., P2P file-sharing session).
DECADEセッションに含まれる4つのステップを図2に示します。シーケンスは、エンドポイントBとエンドポイントAの間の最初の接続から始まります。エンドポイントBは、ネイティブアプリケーションプロトコル（P2Pなど）を使用してデータオブジェクトを要求します。次に、エンドポイントAはDRPを使用して、エンドポイントBから要求されたデータオブジェクトに対応するトークンを取得します。エンドポイントAがそのようなトークンを取得するには、ローカルで計算するか、DECADEストレージサーバーからトークンを要求するなど、いくつかの方法があります。 S（A）。取得後、エンドポイントAはトークンをエンドポイントBに提供します（ここでも、ネイティブアプリケーションプロトコルを使用します）。最後に、エンドポイントBは受信したトークンをDRP経由でS（A）に提供し、続いてSDT経由でデータオブジェクトを要求してダウンロードします。繰り返しになりますが、DECADEはアプリケーションコンテキスト全体（P2Pファイル共有セッションなど）で使用されることが前提となっています。
For completeness, note that there is an important prerequisite step (not shown) to Figure 2, where Endpoint A first discovers and then stores the data object(s) of interest in S(A).
完全を期すために、エンドポイントAが最初にS（A）で目的のデータオブジェクトを検出して格納する図2には、重要な前提条件ステップ（図には示されていない）があることに注意してください。
.----------.
2. Obtain --------> | S(A) | <------
Token / `----------' \ 4. Request and
(DRP) / \ Download
Locally / \ Data Object
or From / \ (DRP + SDT)
S(A) v 1. App Request v
.-------------. <--------------------------- .-------------.
| Application | | Application |
| Endpoint A | | Endpoint B |
`-------------' ---------------------------> `-------------'
3. App Response (token)
Figure 2: Download from Storage Server
図2：ストレージサーバーからのダウンロード
This section presents the key principles followed by any DECADE system.
このセクションでは、DECADEシステムが従う主要な原則を示します。
DECADE SDT and DRP can be classified as belonging to data-plane functionality. The algorithms and signaling for a P2P application, for example, would belong to control-plane functionality.
DECADE SDTおよびDRPは、データプレーン機能に属するものとして分類できます。たとえば、P2Pアプリケーションのアルゴリズムとシグナリングは、コントロールプレーン機能に属します。
A DECADE system aims to be application independent and should support multiple content distribution applications. Typically, a complete content distribution application implements a set of control-plane functions including content search, indexing and collection, access control, replication, request routing, and QoS scheduling. Implementers of different content distribution applications may have unique considerations when designing the control-plane functions. For example, with respect to the metadata management scheme, traditional file systems provide a standard metadata abstraction: a recursive structure of directories to offer namespace management where each file is an opaque byte stream. Content distribution applications may use different metadata management schemes. For instance, one application might use a sequence of blocks (e.g., for file sharing), while another application might use a sequence of frames (with different sizes) indexed by time.
DECADEシステムは、アプリケーションに依存しないことを目的としており、複数のコンテンツ配信アプリケーションをサポートする必要があります。通常、完全なコンテンツ配信アプリケーションは、コンテンツ検索、インデックス作成と収集、アクセス制御、レプリケーション、リクエストルーティング、QoSスケジューリングなどの一連のコントロールプレーン機能を実装します。さまざまなコンテンツ配信アプリケーションの実装者は、コントロールプレーン機能を設計するときに独自の考慮事項を持っている場合があります。たとえば、メタデータ管理スキームに関して、従来のファイルシステムは標準のメタデータ抽象化を提供します。ディレクトリの再帰的な構造により、各ファイルが不透明なバイトストリームであるネームスペース管理を提供します。コンテンツ配信アプリケーションは、異なるメタデータ管理スキームを使用する場合があります。たとえば、1つのアプリケーションが一連のブロックを使用する場合（ファイル共有など）、別のアプリケーションが時間のインデックスが付けられた一連のフレーム（サイズが異なる）を使用する場合があります。
With respect to resource-scheduling algorithms, a major advantage of many successful P2P systems is their substantial expertise in achieving efficient utilization of peer resources. For instance, many streaming P2P systems include optimization algorithms for constructing overlay topologies that can support low-latency, high-bandwidth streaming. The research community as well as implementers of such systems continuously fine-tune existing algorithms and invent new ones. A DECADE system should be able to accommodate and benefit from all new developments.
リソーススケジューリングアルゴリズムに関して、多くの成功したP2Pシステムの主な利点は、ピアリソースの効率的な利用を実現する上での実質的な専門知識です。たとえば、多くのストリーミングP2Pシステムには、低遅延、高帯域幅のストリーミングをサポートできるオーバーレイトポロジを構築するための最適化アルゴリズムが含まれています。研究コミュニティとそのようなシステムの実装者は、既存のアルゴリズムを継続的に微調整し、新しいアルゴリズムを発明しています。 DECADEシステムは、すべての新しい開発に対応し、その恩恵を受けることができる必要があります。
In short, given the diversity of control-plane functions, a DECADE system should allow for as much flexibility as possible to the control plane to implement specific policies (and be decoupled from data-plane DRP/SDT). Decoupling the control plane from the data plane is not new, of course. For example, OpenFlow [OpenFlow] is an implementation of this principle for Internet routing, where the computation of the forwarding table and the application of the forwarding table are separated. The Google File System [GoogleFileSystem] applies the same principle to file system design by utilizing a Master to handle metadata management and several Chunk servers to handle data-plane functions (i.e., read and write of chunks of data). Finally, NFSv4.1's parallel NFS (pNFS) extension [RFC5661] also adheres to this principle.
要するに、コントロールプレーン機能の多様性を考えると、DECADEシステムは、コントロールプレーンに特定のポリシーを実装する（そして、データプレーンDRP / SDTから切り離される）ために、可能な限り多くの柔軟性を可能にする必要があります。もちろん、データプレーンからコントロールプレーンを分離することは、新しいことではありません。たとえば、OpenFlow [OpenFlow]は、インターネットルーティングのこの原則の実装であり、転送テーブルの計算と転送テーブルのアプリケーションが分離されています。 Googleファイルシステム[GoogleFileSystem]は、マスターを使用してメタデータ管理を処理し、いくつかのチャンクサーバーを使用してデータプレーン機能（つまり、データのチャンクの読み取りと書き込み）を処理することにより、同じ原理をファイルシステム設計に適用します。最後に、NFSv4.1の並列NFS（pNFS）拡張[RFC5661]もこの原則に準拠しています。
A common property of bulk content to be broadly distributed is that it is immutable -- once content is generated, it is typically not modified. For example, once a movie has been edited and released for distribution, it is very uncommon that the corresponding video frames and images need to be modified. The same applies to document distribution, such as RFCs; audio files, such as podcasts; and program patches. Focusing on immutable data can substantially simplify data-plane design, since consistency requirements can be relaxed. It also simplifies data reuse and the removal of duplicates.
広く配布されるバルクコンテンツの一般的なプロパティは、不変であるということです。いったんコンテンツが生成されると、通常は変更されません。たとえば、映画を編集して配布用にリリースした後、対応するビデオフレームと画像を変更する必要があることはほとんどありません。 RFCなどのドキュメント配布にも同じことが当てはまります。ポッドキャストなどのオーディオファイル。プログラムのパッチ。不変データに焦点を合わせると、一貫性の要件を緩和できるため、データプレーンの設計を大幅に簡略化できます。また、データの再利用と重複の削除も簡単になります。
Depending on its specific requirements, an application may store immutable data objects in DECADE servers such that each data object is completely self-contained (e.g., a complete, independently decodable video segment). An application may also divide data into data objects that require application-level assembly. Many content distribution applications divide bulk content into data objects for multiple reasons, including (a) fetching different data objects from different sources in parallel and (b) faster recovery and verification as individual data objects might be recovered and verified. Typically, applications use a data object size larger than a single packet in order to reduce control overhead.
特定の要件に応じて、アプリケーションは不変のデータオブジェクトをDECADEサーバーに格納して、各データオブジェクトが完全に自己完結するようにします（たとえば、完全に独立してデコード可能なビデオセグメント）。アプリケーションは、アプリケーションレベルのアセンブリを必要とするデータオブジェクトにデータを分割することもできます。多くのコンテンツ配信アプリケーションは、（a）異なるソースから異なるデータオブジェクトを並行してフェッチすること、（b）個々のデータオブジェクトが回復および検証される可能性があるため、より高速な回復と検証を含む複数の理由で、バルクコンテンツをデータオブジェクトに分割します。通常、アプリケーションは、制御オーバーヘッドを削減するために、単一パケットよりも大きいデータオブジェクトサイズを使用します。
A DECADE system should be agnostic to the nature of the data objects and should not specify a fixed size for them. A protocol specification based on this architecture may prescribe requirements on minimum and maximum sizes for compliant implementations.
DECADEシステムは、データオブジェクトの性質にとらわれず、固定サイズを指定しないでください。このアーキテクチャに基づくプロトコル仕様では、準拠した実装の最小サイズと最大サイズの要件が規定されている場合があります。
Note that immutable data objects can still be deleted. Applications can support modification of existing data stored at a DECADE server through a combination of storing new data objects and deleting existing data objects. For example, a metadata management function of the control plane might associate a name with a sequence of immutable data objects. If one of the data objects is modified, the meta-data management function changes the mapping of the name to a new sequence of immutable data objects.
不変データオブジェクトは引き続き削除できることに注意してください。アプリケーションは、新しいデータオブジェクトの格納と既存のデータオブジェクトの削除を組み合わせることにより、DECADEサーバーに格納されている既存のデータの変更をサポートできます。たとえば、コントロールプレーンのメタデータ管理機能は、名前を一連の不変データオブジェクトに関連付けます。データオブジェクトの1つが変更されると、メタデータ管理機能は、名前のマッピングを新しい一連の不変データオブジェクトに変更します。
A data object stored in a DECADE server shall be accessed by DECADE clients via a data object identifier. Each DECADE client may be able to access more than one storage server. A data object that is replicated across different storage servers managed by a storage provider may be accessed through a single identifier. Since data objects are immutable, it shall be possible to support persistent identifiers for data objects.
DECADEサーバーに格納されたデータオブジェクトは、データオブジェクト識別子を介してDECADEクライアントからアクセスされます。各DECADEクライアントは、複数のストレージサーバーにアクセスできる場合があります。ストレージプロバイダーが管理するさまざまなストレージサーバー間で複製されるデータオブジェクトには、単一の識別子を使用してアクセスできます。データオブジェクトは不変であるため、データオブジェクトの永続的な識別子をサポートすることが可能です。
Data object identifiers should be created by DECADE clients when uploading the corresponding objects to a DECADE server. The scheme for the assignment/derivation of the data object identifier to a data object depends as the data object naming scheme and is out of scope of this document. One possibility is to name data objects using hashes as described in [RFC6920]. Note that [RFC6920] describes naming schemes on a semantic level only, but specific SDTs and DRPs use specific representations.
データオブジェクト識別子は、対応するオブジェクトをDECADEサーバーにアップロードするときに、DECADEクライアントによって作成される必要があります。データオブジェクト識別子のデータオブジェクトへの割り当て/派生のスキームは、データオブジェクトの命名スキームによって異なり、このドキュメントの範囲外です。 1つの可能性は、[RFC6920]で説明されているように、ハッシュを使用してデータオブジェクトに名前を付けることです。 [RFC6920]はセマンティックレベルでの命名方式のみを説明していますが、特定のSDTとDRPは特定の表現を使用しています。
In particular, for some applications, it is important that clients and servers be able to validate the name-object binding, i.e., by verifying that a received object really corresponds to the name (identifier) that was used for requesting it (or that was provided by a sender). If a specific application requires name-object binding validation, the data object identifiers can support it by providing message digests or so-called self-certifying naming information.
特に、一部のアプリケーションでは、クライアントとサーバーが名前とオブジェクトのバインディングを検証できることが重要です。つまり、受信したオブジェクトが、それを要求するために使用された（または送信者が提供）。特定のアプリケーションが名前オブジェクトバインディング検証を必要とする場合、データオブジェクト識別子は、メッセージダイジェストまたはいわゆる自己認証ネーミング情報を提供することにより、それをサポートできます。
Different name-object binding validation mechanisms may be supported in a single DECADE system. Content distribution applications can decide what mechanism to use, or to not provide name-object validation (e.g., if authenticity and integrity can by ascertained by alternative means). We expect that applications may be able to construct unique names (with high probability) without requiring a registry or other forms of coordination. Names may be self-describing so that a receiving DECADE client understands, for example, which hash function to use for validating name-object binding.
単一のDECADEシステムでは、異なる名前オブジェクトバインディング検証メカニズムがサポートされる場合があります。コンテンツ配信アプリケーションは、使用するメカニズムを決定するか、名前オブジェクト検証を提供しないかを決定できます（たとえば、信頼性と整合性が代替手段で確認できる場合）。アプリケーションは、レジストリやその他の形式の調整を必要とせずに、一意の名前を（高い確率で）構築できる可能性があると予想しています。たとえば、名前とオブジェクトのバインディングの検証に使用するハッシュ関数を受信側のDECADEクライアントが理解できるように、名前は自己記述型である場合があります。
Some content distribution applications will derive the name of a data object from the hash over the data object; this is made possible by the fact that DECADE objects are immutable. But there may be other applications such as live streaming where object names will not based on hashes but rather on an enumeration scheme. The naming scheme will also enable those applications to construct unique names.
一部のコンテンツ配信アプリケーションは、データオブジェクトのハッシュからデータオブジェクトの名前を導出します。これは、DECADEオブジェクトが不変であるという事実によって可能になります。ただし、ライブストリーミングなどの他のアプリケーションでは、オブジェクト名がハッシュではなく列挙方式に基づいている場合があります。命名スキームにより、これらのアプリケーションは一意の名前を作成することもできます。
In order to enable the uniqueness, flexibility and self-describing properties, the naming scheme used in a DECADE system should provide a "type" field that indicates the name-object validation function type (for example, "sha-256" [RFC5754]) and the cryptographic data (such as an object hash) that corresponds to the type information. Moreover, the naming scheme may additionally provide application or publisher information.
一意性、柔軟性、自己記述的なプロパティを有効にするために、DECADEシステムで使用される命名スキームは、名前オブジェクト検証関数のタイプを示す「タイプ」フィールドを提供する必要があります（たとえば、「sha-256」[RFC5754] ）およびタイプ情報に対応する暗号化データ（オブジェクトハッシュなど）。さらに、命名方式は、アプリケーションまたは発行者の情報をさらに提供する場合があります。
To support the functions of an application's control plane, applications should be able to keep track and coordinate which data is stored at particular servers. Thus, in contrast with traditional caches, applications are given explicit control over the placement (selection of a DECADE server), deletion (or expiration policy), and access control for stored data objects. Consider deletion/expiration policy as a simple example. An application might require that a DECADE server stores data objects for a relatively short period of time (e.g., for live-streaming data). Another application might need to store data objects for a longer duration (e.g., for video on demand), and so on.
アプリケーションのコントロールプレーンの機能をサポートするには、アプリケーションが特定のサーバーに格納されているデータを追跡および調整できる必要があります。したがって、従来のキャッシュとは対照的に、格納されたデータオブジェクトの配置（DECADEサーバーの選択）、削除（または有効期限ポリシー）、およびアクセス制御に対する明示的な制御がアプリケーションに与えられます。簡単な例として、削除/有効期限ポリシーを検討してください。アプリケーションでは、DECADEサーバーが比較的短い期間（たとえば、ライブストリーミングデータの場合）にデータオブジェクトを保存する必要がある場合があります。別のアプリケーションでは、データオブジェクトをより長い期間（ビデオオンデマンドなど）格納する必要がある場合があります。
A DECADE system provides a shared infrastructure to be used by multiple Application Endpoints. Thus, it needs to provide both resource and data access control, as discussed in the following subsections.
DECADEシステムは、複数のアプリケーションエンドポイントで使用される共有インフラストラクチャを提供します。したがって、次のサブセクションで説明するように、リソースとデータの両方のアクセス制御を提供する必要があります。
There are two primary interacting entities in a DECADE system. First, storage providers coordinate DECADE server provisioning, including their total available resources. Second, applications coordinate data transfers amongst available DECADE servers and between servers and clients. A form of isolation is required to enable each of the concurrently running applications to explicitly manage its own data objects and share of resources at the available servers. Therefore, a storage provider should delegate resource management on a DECADE server to uploading DECADE clients, enabling them to explicitly and independently manage their own share of resources on a server.
DECADEシステムには2つの主要な相互作用エンティティがあります。まず、ストレージプロバイダーは、利用可能なリソース全体を含め、DECADEサーバーのプロビジョニングを調整します。次に、アプリケーションは、利用可能なDECADEサーバー間およびサーバーとクライアント間のデータ転送を調整します。同時に実行されている各アプリケーションが、使用可能なサーバーで自身のデータオブジェクトとリソースの共有を明示的に管理できるようにするために、分離の形式が必要です。したがって、ストレージプロバイダーは、DECADEサーバー上のリソース管理をDECADEクライアントのアップロードに委任し、サーバー上のリソースの独自の共有を明示的かつ独立して管理できるようにする必要があります。
DECADE storage providers will have the ability to explicitly manage the entities allowed to utilize the resources available on a DECADE server. This is needed for reasons such as capacity-planning and legal considerations in certain deployment scenarios. The DECADE server should grant a share of the resources to a DECADE client. The client can in turn share the granted resources amongst its (possibly) multiple applications. The share of resources granted by a server is called a User Delegation. As a simple example, a DECADE server operated by an ISP might be configured to grant each ISP subscriber 1.5 Mbit/s of network capacity and 1 GB of memory. The ISP subscriber might in turn divide this share of resources amongst a video-streaming application and file-sharing application that are running concurrently.
DECADEストレージプロバイダーは、DECADEサーバーで利用可能なリソースの利用を許可されたエンティティを明示的に管理することができます。これは、特定の展開シナリオでのキャパシティプランニングや法的な考慮事項などの理由で必要です。 DECADEサーバーは、リソースの共有をDECADEクライアントに許可する必要があります。次に、クライアントは許可されたリソースをその（場合によっては）複数のアプリケーション間で共有できます。サーバーによって付与されたリソースの共有は、ユーザー委任と呼ばれます。簡単な例として、ISPが運用するDECADEサーバーは、各ISPサブスクライバーに1.5 Mbit / sのネットワーク容量と1 GBのメモリを付与するように構成できます。 ISPサブスクライバーは、同時にこのリソース共有を、同時に実行されているビデオストリーミングアプリケーションとファイル共有アプリケーションの間で分割する場合があります。
As noted earlier, the primary focus of this document is the architectural principles and the system components that implement them. While specific system components might differ between implementations, this document details the major components and their overall roles in the architecture. To keep the scope narrow, we only discuss the primary components related to protocol development. Particular deployments will require additional components (e.g., monitoring and accounting at a server), but they are intentionally omitted from this document.
前述のように、このドキュメントの主な焦点は、アーキテクチャの原則とそれらを実装するシステムコンポーネントです。特定のシステムコンポーネントは実装によって異なる場合がありますが、このドキュメントでは、主要なコンポーネントとアーキテクチャにおけるそれらの全体的な役割について詳しく説明します。範囲を狭くするために、プロトコル開発に関連する主要コンポーネントのみを説明します。特定の展開では追加のコンポーネント（サーバーでの監視やアカウンティングなど）が必要になりますが、このドキュメントでは意図的に省略しています。
Content distribution applications have many functional components. For example, many P2P applications have components and algorithms to manage overlay topology, rate allocation, piece selection, and so on. In this document, we focus on the components directly engaged in a DECADE system. Figure 3 illustrates the components discussed in this section from the perspective of a single Application Endpoint.
コンテンツ配信アプリケーションには、多くの機能コンポーネントがあります。たとえば、多くのP2Pアプリケーションには、オーバーレイトポロジ、レート割り当て、ピースの選択などを管理するためのコンポーネントとアルゴリズムがあります。このドキュメントでは、DECADEシステムに直接関与するコンポーネントに焦点を当てます。図3は、このセクションで説明するコンポーネントを単一のアプリケーションエンドポイントの観点から示しています。
Native Application Protocol(s)
(with other Application Endpoints)
.--------------------->
|
V
.----------------------------------------------------------------.
| Application Endpoint |
| .-------------------. .-------------------. |
| | Application-Layer | ... | App Data Assembly | |
| | Algorithms | | Sequencing | |
| `-------------------' `-------------------' |
| |
| .==========================================================. |
| | DECADE Client | |
| | .-------------------------. .--------------------------. | |
| | | Resource Controller | | Data Controller | | |
| | | .--------. .----------. | | .------------. .-------. | | |
| | | | Data | | Resource-| | | | Data | | Data | | | |
| | | | Access | | Sharing | | | | Scheduling | | Index | | | |
| | | | Policy | | Policy | | | | | | | | | |
| | | `--------' `----------' | | `------------' `-------' | | |
| | `-------------------------' `--------------------------' | |
| | | ^ | |
| `== | ============================== | ====================' |
`----- | ------------------------------ | -----------------------'
| |
| DECADE Resource Protocol | Standard Data Transfer
| (DRP) | (SDT)
v V
Figure 3: Application and DECADE Client Components
図3：アプリケーションおよびDECADEクライアントコンポーネント
A DECADE system is geared towards supporting applications that can distribute content using data objects (e.g., P2P). To accomplish this, applications can include a component responsible for creating the individual data objects before distribution and for reassembling them later. We call this component Application Data Assembly. In producing and assembling data objects, two important considerations are sequencing and naming. A DECADE system assumes that applications implement this functionality themselves. In addition to DECADE DRP/SDT, applications will most likely also support other, native application protocols (e.g., P2P control and data transfer protocols).
DECADEシステムは、データオブジェクト（P2Pなど）を使用してコンテンツを配信できるアプリケーションをサポートするように設計されています。これを実現するために、アプリケーションには、配布前に個々のデータオブジェクトを作成し、後でそれらを再構成するコンポーネントを含めることができます。このコンポーネントをアプリケーションデータアセンブリと呼びます。データオブジェクトの作成とアセンブルでは、2つの重要な考慮事項がシーケンスと命名です。 DECADEシステムは、アプリケーションがこの機能自体を実装していることを前提としています。 DECADE DRP / SDTに加えて、アプリケーションは他のネイティブアプリケーションプロトコル（P2P制御やデータ転送プロトコルなど）もサポートする可能性が高いです。
The DECADE client provides the local support to an application, and it can be implemented standalone, embedded into the application, or integrated in other software entities within network devices (i.e., hosts). In general, applications may have different resource-sharing policies and data access policies with regard to DECADE servers. These policies may be existing policies of applications or custom policies. The specific implementation is decided by the application.
DECADEクライアントは、アプリケーションにローカルサポートを提供し、スタンドアロンで実装したり、アプリケーションに組み込んだり、ネットワークデバイス（ホストなど）内の他のソフトウェアエンティティに統合したりできます。一般に、アプリケーションには、DECADEサーバーに関して異なるリソース共有ポリシーとデータアクセスポリシーがある場合があります。これらのポリシーは、アプリケーションの既存のポリシーまたはカスタムポリシーの場合があります。具体的な実装はアプリケーションによって決定されます。
Recall that DECADE decouples the control and the data transfer of applications. A data-scheduling component schedules data transfers according to network conditions, available servers, and/or available server resources. The Data Index indicates data available at remote servers. The Data Index (or a subset of it) can be advertised to other clients. A common use case for this is to provide the ability to locate data amongst distributed Application Endpoints (i.e., a data search mechanism such as a Distributed Hash Table (DHT)).
DECADEはアプリケーションの制御とデータ転送を分離することを思い出してください。データスケジューリングコンポーネントは、ネットワークの状態、使用可能なサーバー、使用可能なサーバーリソース、あるいはその両方に従ってデータ転送をスケジュールします。データインデックスは、リモートサーバーで使用可能なデータを示します。データインデックス（またはそのサブセット）を他のクライアントにアドバタイズできます。これの一般的な使用例は、分散アプリケーションエンドポイント（つまり、分散ハッシュテーブル（DHT）などのデータ検索メカニズム）間でデータを検索する機能を提供することです。
Figure 4 illustrates the primary components of a DECADE server. Note that the description below does not assume a single-host or centralized implementation -- a DECADE server is not necessarily a single physical machine; it can also be implemented in a distributed manner on a cluster of machines.
図4は、DECADEサーバーの主要コンポーネントを示しています。以下の説明では、単一ホストまたは集中型の実装を想定していないことに注意してください。DECADEサーバーは必ずしも単一の物理マシンではありません。また、マシンのクラスターに分散して実装することもできます。
| DECADE Resource | Standard Data
| Protocol (DRP) | Transfer (SDT)
| |
.= | ================= | ===========================.
| | v DECADE Server |
| | .----------------. |
| |----> | Access Control | <--------. |
| | `----------------' | |
| | ^ | |
| | | | |
| | v | |
| | .---------------------. | |
| `-> | Resource Scheduling | <------| |
| `---------------------' | |
| ^ | |
| | | |
| v .-----------------. |
| .-----------------. | User Delegation | |
| | Data Store | | Management | |
| `-----------------' `-----------------' |
`==================================================='
Figure 4: DECADE Server Components
図4：DECADEサーバーコンポーネント
Provided sufficient authorization, a client shall be able to access its own data or other client's data in a DECADE server. Clients may also authorize other clients to store data. If access is authorized by a client, the server should provide access. Applications may apply resource-sharing policies or use a custom policy. DECADE servers will then perform resource scheduling according to the resource-sharing policies indicated by the client as well as any other previously configured User Delegations. Data from applications will be stored at a DECADE server. Data may be deleted from storage either explicitly or automatically (e.g., after a Time To Live (TTL) expiration).
十分な権限が与えられれば、クライアントはDECADEサーバー内の自身のデータまたは他のクライアントのデータにアクセスできます。クライアントは、他のクライアントにデータの保存を許可することもできます。アクセスがクライアントによって承認されている場合、サーバーはアクセスを提供する必要があります。アプリケーションは、リソース共有ポリシーを適用するか、カスタムポリシーを使用できます。その後、DECADEサーバーは、クライアントおよび他の以前に構成されたユーザー委任によって示されたリソース共有ポリシーに従ってリソーススケジューリングを実行します。アプリケーションからのデータは、DECADEサーバーに格納されます。データは、明示的または自動的に（たとえば、存続可能時間（TTL）の有効期限が切れた後に）ストレージから削除される場合があります。
The DECADE naming scheme implies no sequencing or grouping of objects, even if this is done at the application layer. To illustrate these properties, this section presents several examples of use.
DECADE命名スキームは、たとえこれがアプリケーション層で行われたとしても、オブジェクトの順序付けやグループ化を意味しません。これらのプロパティを説明するために、このセクションではいくつかの使用例を示します。
Consider an application in which each individual application-layer segment of data is called a "chunk" and has a name of the form: "CONTENT_ID:SEQUENCE_NUMBER". Furthermore, assume that the application's native protocol uses chunks of size 16 KB. Now, assume that this application wishes to store data in a DECADE server in data objects of size 64 KB. To accomplish this, it can map a sequence of 4 chunks into a single data object, as shown in Figure 5.
データの個々のアプリケーション層セグメントが「チャンク」と呼ばれ、「CONTENT_ID：SEQUENCE_NUMBER」という形式の名前を持つアプリケーションを考えます。さらに、アプリケーションのネイティブプロトコルがサイズ16 KBのチャンクを使用すると想定します。ここで、このアプリケーションがDECADEサーバーの64 KBサイズのデータオブジェクトにデータを格納するとします。これを実現するために、図5に示すように、4つのチャンクのシーケンスを単一のデータオブジェクトにマッピングできます。
Application Chunks
.---------.---------.---------.---------.---------.---------.--------
| | | | | | |
| Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6
| | | | | | |
`---------`---------`---------`---------`---------`---------`--------
DECADE Data Objects
.---------------------------------------.----------------------------
| |
| Object_0 | Object_1
| |
`---------------------------------------`----------------------------
Figure 5: Mapping Application Chunks to DECADE Data Objects
図5：アプリケーションチャンクのDECADEデータオブジェクトへのマッピング
In this example, the application maintains a logical mapping that is able to determine the name of a DECADE data object given the chunks contained within that data object. The name may be conveyed from either the original uploading DECADE client, another Endpoint with which the application is communicating, etc. As long as the data contained within each sequence of chunks is globally unique, the corresponding data objects have globally unique names.
この例では、アプリケーションは、データオブジェクト内に含まれるチャンクを指定して、DECADEデータオブジェクトの名前を決定できる論理マッピングを維持します。名前は、元のアップロードDECADEクライアント、アプリケーションが通信している別のエンドポイントなどから伝達されます。チャンクの各シーケンスに含まれるデータがグローバルに一意である限り、対応するデータオブジェクトはグローバルに一意の名前を持ちます。
Consider an application whose native protocol retrieves a continuous data stream (e.g., an MPEG2 stream) instead of downloading and redistributing chunks of data. Such an application could segment the continuous data stream to produce either fixed-sized or variable-sized data objects. Figure 6 depicts how a video streaming application might produce variable-sized data objects such that each data object contains 10 seconds of video data. In a manner similar to the previous example, the application may maintain a mapping that is able to determine the name of a data object given the time offset of the video chunk.
データのチャンクをダウンロードして再配布する代わりに、ネイティブプロトコルが連続的なデータストリーム（MPEG2ストリームなど）を取得するアプリケーションを考えてみましょう。このようなアプリケーションは、連続データストリームをセグメント化して、固定サイズまたは可変サイズのデータオブジェクトを生成できます。図6は、各データオブジェクトに10秒のビデオデータが含まれるように、ビデオストリーミングアプリケーションが可変サイズのデータオブジェクトを生成する方法を示しています。前の例と同様に、アプリケーションは、ビデオチャンクの時間オフセットが与えられた場合にデータオブジェクトの名前を決定できるマッピングを維持できます。
Application's Video Stream
.--------------------------------------------------------------------
|
|
|
`--------------------------------------------------------------------
^ ^ ^ ^ ^
| | | | |
0 seconds 10 seconds 20 seconds 30 seconds 40 seconds
0 B 400 KB 900 KB 1200 KB 1500 KB
DECADE Data Objects
.--------------.--------------.--------------.--------------.--------
| | | | |
| Object_0 | Object_1 | Object_2 | Object_3 |
| (400 KB) | (500 KB) | (300 KB) | (300 KB) |
`--------------`--------------`--------------`--------------`--------
Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects
図6：連続データストリームのDECADEデータオブジェクトへのマッピング
A key feature of a DECADE system is that an Application Endpoint can authorize other Application Endpoints to store or retrieve data objects from its in-network storage via tokens. The peer client then uses the token when sending requests to the DECADE server. Upon receiving a token, the server validates the signature and the operation being performed.
DECADEシステムの重要な機能は、アプリケーションエンドポイントが他のアプリケーションエンドポイントに、トークンを介してそのネットワーク内ストレージからデータオブジェクトを格納または取得することを許可できることです。ピアクライアントは、DECADEサーバーに要求を送信するときにトークンを使用します。トークンを受信すると、サーバーは署名と実行中の操作を検証します。
This is a simple scheme, but has some important advantages over an alternative approach, for example, in which a client explicitly manipulates an Access Control List (ACL) associated with each data object. In particular, it has the following advantages when applied to DECADE systems. First, authorization policies are implemented within the application, thus the Application Endpoint explicitly controls when tokens are generated, to whom they are distributed, and for how long they will be valid. Second, fine-grained access and resource control can be applied to data objects. Third, there is no messaging between a client and server to manipulate data object permissions. This can simplify, in particular, applications that share data objects with many dynamic peers and need to frequently adjust access control policies attached to data objects. Finally, tokens can provide anonymous access, in which a server does not need to know the identity of each client that accesses it. This enables a client to send tokens to clients belonging to other storage providers, and to allow them to read or write data objects from the storage of its own storage provider. In addition to clients' ability to apply access control policies to data objects, the server may be configured to apply additional policies based on user, object properties, geographic location, etc. A client might thus be denied access even though it possesses a valid token.
これは単純なスキームですが、たとえば、クライアントが各データオブジェクトに関連付けられたアクセス制御リスト（ACL）を明示的に操作するなど、別のアプローチに比べていくつかの重要な利点があります。特にDECADEシステムに適用すると、次のような利点があります。まず、承認ポリシーはアプリケーション内に実装されます。したがって、アプリケーションエンドポイントは、トークンがいつ生成され、誰に配布され、トークンが有効である期間を明示的に制御します。次に、きめ細かいアクセスとリソース制御をデータオブジェクトに適用できます。 3番目に、データオブジェクトの権限を操作するためのクライアントとサーバー間のメッセージングはありません。これにより、特に、多くの動的ピアとデータオブジェクトを共有し、データオブジェクトにアタッチされているアクセス制御ポリシーを頻繁に調整する必要があるアプリケーションを簡略化できます。最後に、トークンは匿名アクセスを提供することができ、サーバーはそれにアクセスする各クライアントのIDを知る必要がありません。これにより、クライアントは他のストレージプロバイダーに属するクライアントにトークンを送信し、クライアントが自身のストレージプロバイダーのストレージからデータオブジェクトを読み書きできるようになります。アクセス制御ポリシーをデータオブジェクトに適用するクライアントの機能に加えて、サーバーは、ユーザー、オブジェクトのプロパティ、地理的位置などに基づいて追加のポリシーを適用するように構成できます。したがって、クライアントは、有効なトークンを所有していてもアクセスを拒否される場合があります。
A DECADE system should include a discovery mechanism through which DECADE clients locate an appropriate DECADE server. A discovery mechanism should allow a client to determine an IP address or some other identifier that can be resolved to locate the server for which the client will be authorized to generate tokens (via DRP). (The discovery mechanism might also result in an error if no such servers can be located.) After discovering one or more servers, a DECADE client can distribute load and requests across them (subject to resource limitations and policies of the servers themselves) according to the policies of the Application Endpoint in which it is embedded. The discovery mechanism outlined here does not provide the ability to locate arbitrary DECADE servers to which a client might obtain tokens from others. To do so will require application-level knowledge, and it is assumed that this functionality is implemented in the content distribution application.
DECADEシステムには、DECADEクライアントが適切なDECADEサーバーを見つけるための検出メカニズムが含まれている必要があります。検出メカニズムにより、クライアントは、クライアントが（DRPを介して）トークンの生成を許可されるサーバーを特定するために解決できるIPアドレスまたはその他の識別子を特定できるようになります。 （そのようなサーバーが見つからない場合、検出メカニズムもエラーになる可能性があります。）1つ以上のサーバーを検出した後、DECADEクライアントは（サーバー自体のリソース制限とポリシーに従って）負荷と要求をそれらに分散できます埋め込まれているアプリケーションエンドポイントのポリシーここで説明する検出メカニズムは、クライアントが他のサーバーからトークンを取得する可能性のある任意のDECADEサーバーを見つける機能を提供しません。そのためにはアプリケーションレベルの知識が必要であり、この機能はコンテンツ配信アプリケーションに実装されていると想定されます。
As noted above, the discovered DECADE server should be authorized to allow the client to store data objects and then generate tokens to allow other clients to retrieve these data objects. This authorization may be:
上記のように、検出されたDECADEサーバーは、クライアントがデータオブジェクトを格納し、次にトークンを生成して他のクライアントがこれらのデータオブジェクトを取得することを許可する必要があります。この承認は次のとおりです。
- a result of off-line administrative procedures;
- オフラインの管理手順の結果。
- access network dependent (e.g., all the subscribers to a particular ISP may be allowed by the ISP);
- アクセスネットワークに依存します（たとえば、特定のISPへのすべての加入者がISPによって許可される場合があります）;
- due to a prior subscription;
- 以前のサブスクリプションのため
- etc.
- 等
The particular protocol used for discovery is out of scope of this document, but any specification should reuse well-known protocols wherever possible.
発見に使用される特定のプロトコルはこのドキュメントの範囲外ですが、仕様は可能な限りよく知られているプロトコルを再利用する必要があります。
This section presents the DRP and the SDT protocol in terms of abstract protocol interactions that are intended to be mapped to specific protocols in an implementation. In general, the DRP/SDT functionality for DECADE client-server interaction is very similar to that for server-server interaction. Any differences are highlighted below. DRP is used by a DECADE client to configure the resources and authorization used to satisfy requests (reading, writing, and management operations concerning data objects) at a server. SDT will be used to transport data between a client and a server, as illustrated in Figure 1.
このセクションでは、実装で特定のプロトコルにマップすることを目的とした抽象プロトコル相互作用の観点から、DRPおよびSDTプロトコルを示します。一般に、DECADEクライアント/サーバー相互作用のDRP / SDT機能は、サーバー/サーバー相互作用の機能とよく似ています。違いは以下で強調表示されています。 DRPは、サーバーでの要求（データオブジェクトに関する読み取り、書き込み、および管理操作）を満たすために使用されるリソースと承認を構成するために、DECADEクライアントによって使用されます。 SDTは、図1に示すように、クライアントとサーバーの間でデータを転送するために使用されます。
A DECADE system SHOULD use [RFC6920] as the recommended and default naming scheme. Other naming schemes that meet the guidelines in Section 4.3 MAY alternatively be used. In order to provide a simple and generic interface, the DECADE server will be responsible only for storing and retrieving individual data objects.
DECADEシステムは、推奨およびデフォルトの命名方式として[RFC6920]を使用する必要があります（SHOULD）。セクション4.3のガイドラインを満たす他の命名規則を代わりに使用してもよい（MAY）。シンプルで汎用的なインターフェースを提供するために、DECADEサーバーは、個々のデータオブジェクトの格納と取得のみを担当します。
The DECADE naming format SHOULD NOT attempt to replace any naming or sequencing of data objects already performed by an application. Instead, naming is intended to apply only to data objects referenced by DECADE-specific purposes. An application using a DECADE client may use a naming and sequencing scheme independent of DECADE names. The DECADE client SHOULD maintain a mapping from its own data objects and their names to the DECADE-specific data objects and names. Furthermore, the DECADE naming scheme implies no sequencing or grouping of objects, even if this is done at the application layer.
DECADEネーミングフォーマットは、アプリケーションによってすでに実行されているデータオブジェクトのネーミングまたはシーケンスの置き換えを試みるべきではありません（SHOULD NOT）。代わりに、命名は、DECADE固有の目的で参照されるデータオブジェクトにのみ適用されることを意図しています。 DECADEクライアントを使用するアプリケーションは、DECADE名に依存しない命名および順序付けスキームを使用できます。 DECADEクライアントは、自身のデータオブジェクトとその名前からDECADE固有のデータオブジェクトと名前へのマッピングを維持する必要があります（SHOULD）。さらに、DECADE命名スキームは、たとえアプリケーション層で行われたとしても、オブジェクトの順序付けやグループ化を意味しません。
DRP will provide configuration of access control and resource-sharing policies on DECADE servers. A content distribution application (e.g., a live P2P streaming session) can have permission to manage data at several servers, for instance, servers belonging to different storage providers. DRP allows one instance of such an application, i.e., an Application Endpoint, to apply access control and resource-sharing policies on each of them.
DRPは、DECADEサーバーでのアクセス制御とリソース共有ポリシーの構成を提供します。コンテンツ配信アプリケーション（ライブP2Pストリーミングセッションなど）は、複数のサーバー（異なるストレージプロバイダーに属するサーバーなど）でデータを管理する権限を持つことができます。 DRPを使用すると、そのようなアプリケーションの1つのインスタンス、つまりアプリケーションエンドポイントが、それぞれにアクセス制御およびリソース共有ポリシーを適用できます。
On a single DECADE server, the following resources SHOULD be managed: a) communication resources in terms of bandwidth (upload/download) and also in terms of number of active clients (simultaneous connections); and b) storage resources.
単一のDECADEサーバーでは、次のリソースを管理する必要があります（SHOULD）。a）帯域幅（アップロード/ダウンロード）およびアクティブクライアントの数（同時接続）に関する通信リソース。およびb）ストレージリソース。
The tokens SHOULD be generated by an entity trusted by both the DECADE client and the server at the request of a DECADE client. For example, this entity could be the client, a server trusted by the client, or another server managed by a storage provider and trusted by the client. It is important for a server to trust the entity generating the tokens since each token may incur a resource cost on the server when used. Likewise, it is important for a client to trust the entity generating the tokens since the tokens grant access to the data stored at the server.
トークンは、DECADEクライアントの要求に応じて、DECADEクライアントとサーバーの両方が信頼するエンティティによって生成される必要があります（SHOULD）。たとえば、このエンティティは、クライアント、クライアントによって信頼されたサーバー、またはストレージプロバイダーによって管理され、クライアントによって信頼された別のサーバーである可能性があります。各トークンを使用するとサーバーでリソースコストが発生する可能性があるため、サーバーはトークンを生成するエンティティを信頼することが重要です。同様に、トークンはサーバーに格納されているデータへのアクセスを許可するため、トークンを生成するエンティティをクライアントが信頼することが重要です。
The token does not normally include information about the identity of the authorized client (i.e., it is typically an anonymous token). However, it is not prohibited to have a binding of the token to an identity if desired (e.g., binding of the token to the IP address of the authorized party).
トークンには通常、承認されたクライアントのIDに関する情報は含まれていません（つまり、通常は匿名トークンです）。ただし、必要に応じて、トークンをIDにバインドすること（たとえば、許可された当事者のIPアドレスへのトークンのバインド）は禁止されていません。
Upon generating a token, a DECADE client can distribute it to another client. Token confidentiality SHOULD be provided by whatever protocol it is carried in (i.e., Application Protocol, DRP, or SDT). The receiving client can then connect to the server specified in the token and perform any operation permitted by the token. The token SHOULD be sent along with the operation. The server SHOULD validate the token to identify the client that issued it and whether the requested operation is permitted by the contents of the token. If the token is successfully validated, the server SHOULD apply the resource control policies indicated in the token while performing the operation.
トークンを生成すると、DECADEクライアントはそれを別のクライアントに配布できます。トークンの機密性は、それが運ばれるプロトコル（つまり、アプリケーションプロトコル、DRP、またはSDT）によって提供される必要があります（SHOULD）。受信側のクライアントは、トークンで指定されたサーバーに接続して、トークンで許可されている操作を実行できます。トークンは操作とともに送信する必要があります（SHOULD）。サーバーは、トークンを検証して、それを発行したクライアントを識別し、要求された操作がトークンの内容によって許可されているかどうかを確認する必要があります。トークンが正常に検証された場合、サーバーは、操作の実行中にトークンに示されたリソース制御ポリシーを適用する必要があります（SHOULD）。
Tokens SHOULD include a unique identifier to allow a server to detect when a token is used multiple times and reject the additional usage attempts. Since usage of a token incurs resource costs to a server (e.g., bandwidth and storage) and an uploading DECADE client may have a limited budget, the uploading DECADE client should be able to indicate if a token may be used multiple times.
トークンには、一意の識別子を含めて、トークンが複数回使用されたことをサーバーが検出し、追加の使用試行を拒否できるようにする必要があります。トークンの使用はサーバーへのリソースコスト（帯域幅やストレージなど）を発生させ、アップロードするDECADEクライアントの予算は限られている可能性があるため、アップロードするDECADEクライアントはトークンが複数回使用される可能性があるかどうかを示すことができます。
It SHOULD be possible to revoke tokens after they are generated. This could be accomplished by supplying the server the unique identifiers of the tokens that are to be revoked.
トークンが生成された後、それを取り消すことが可能であるべきです。これは、取り消されるトークンの一意の識別子をサーバーに提供することで実現できます。
DRP SHOULD provide a status request service that clients can use to request status information of a server. Access to such status information SHOULD require client authorization; that is, clients need to be authorized to access the requested status information. This authorization is based on the user delegation concept as described in Section 4.5. The following status information elements SHOULD be obtained: a) list of associated data objects (with properties); and b) resources used/available. In addition, the following information elements MAY be available: c) list of servers to which data objects have been distributed (in a certain time frame); and d) list of clients to which data objects have been distributed (in a certain time frame).
DRPは、クライアントがサーバーのステータス情報を要求するために使用できるステータス要求サービスを提供する必要があります（SHOULD）。このようなステータス情報にアクセスするには、クライアントの承認が必要です（SHOULD）。つまり、クライアントは、要求されたステータス情報へのアクセスを承認される必要があります。この承認は、セクション4.5で説明されているユーザー委任の概念に基づいています。次のステータス情報要素を取得する必要があります（SHOULD）。a）関連するデータオブジェクトのリスト（プロパティ付き）。 b）使用/利用可能なリソース。さらに、次の情報要素が利用可能になる場合があります：c）データオブジェクトが配布されたサーバーのリスト（特定の時間枠内）。およびd）データオブジェクトが配布されたクライアントのリスト（特定の時間枠内）。
For the list of servers/clients to which data objects have been distributed to, the server SHOULD be able to decide on time bounds for which this information is stored and specify the corresponding time frame in the response to such requests. Some of this information may be used for accounting purposes, e.g., the list of clients to which data objects have been distributed.
データオブジェクトが配布されたサーバー/クライアントのリストの場合、サーバーは、この情報が保存される時間の境界を決定し、そのような要求への応答で対応する時間枠を指定できる必要があります（SHOULD）。この情報の一部は、データオブジェクトが配布されたクライアントのリストなど、会計目的で使用される場合があります。
Access information MAY be provided for accounting purposes, for example, when uploading DECADE clients are interested in access statistics for resources and/or to perform accounting per user. Again, access to such information requires client authorization and SHOULD be based on the delegation concept as described in Section 4.5. The following type of access information elements MAY be requested: a) what data objects have been accessed by whom and how many times; and b) access tokens that a server has seen for a given data object.
アクセス情報は、たとえばDECADEクライアントのアップロードがリソースのアクセス統計に関心がある場合や、ユーザーごとにアカウンティングを実行する場合など、アカウンティングの目的で提供される場合があります。この場合も、そのような情報へのアクセスにはクライアントの承認が必要であり、セクション4.5で説明されている委任の概念に基づいている必要があります（SHOULD）。次のタイプのアクセス情報要素が要求される場合があります：a）どのデータオブジェクトが誰によって、何回アクセスされたか。 b）サーバーが特定のデータオブジェクトに対して認識したアクセストークン。
The server SHOULD decide on time bounds for which this information is stored and specify the corresponding time frame in the response to such requests.
サーバーは、この情報が格納される時間の境界を決定し、そのような要求への応答で対応する時間枠を指定する必要があります。
Data objects that are stored on a DECADE server SHOULD have associated attributes (in addition to the object identifier) that relate to the data storage and its management. These attributes may be used by the server (and possibly the underlying storage system) to perform specialized processing or handling for the data object, or to attach related server or storage-layer properties to the data object. These attributes have a scope local to a server. In particular, these attributes SHOULD NOT be applied to a server or client to which a data object is copied.
DECADEサーバーに格納されているデータオブジェクトには、オブジェクト識別子に加えて、データストレージとその管理に関連する属性が関連付けられている必要があります（SHOULD）。これらの属性は、サーバー（および場合によっては基になるストレージシステム）によって使用され、データオブジェクトの特殊な処理または処理を実行したり、関連するサーバーまたはストレージレイヤーのプロパティをデータオブジェクトにアタッチしたりできます。これらの属性には、サーバーに対してローカルなスコープがあります。特に、これらの属性は、データオブジェクトのコピー先のサーバーまたはクライアントには適用しないでください。
Depending on authorization, clients SHOULD be permitted to get or set such attributes. This authorization is based on the delegation as per Section 4.5. DECADE does not limit the set of permissible attributes, but rather specifies a set of baseline attributes that SHOULD be supported: Expiration Time: time at which the data object can be deleted
認可に応じて、クライアントはそのような属性を取得または設定することが許可されるべきです。この承認は、セクション4.5の委任に基づいています。 DECADEは、許可される属性のセットを制限するのではなく、サポートする必要があるベースライン属性のセットを指定します：有効期限：データオブジェクトを削除できる時間
Data Object size: in bytes
データオブジェクトサイズ：バイト単位
Media type: labeling of type as per [RFC6838]
メディアタイプ：[RFC6838]によるタイプのラベル付け
Access statistics: how often the data object has been accessed (and what tokens have been used)
アクセス統計：データオブジェクトがアクセスされた頻度（および使用されたトークン）
The data object attributes defined here are distinct from application metadata. Application metadata is custom information that an application might wish to associate with a data object to understand its semantic meaning (e.g., whether it is video and/or audio, its playback length in time, or its index in a stream). If an application wishes to store such metadata persistently, it can be stored within data objects themselves.
ここで定義されるデータオブジェクト属性は、アプリケーションメタデータとは異なります。アプリケーションメタデータは、アプリケーションがデータオブジェクトに関連付けてその意味論的意味を理解するために必要とする可能性のあるカスタム情報です（たとえば、ビデオやオーディオかどうか、再生時間の長さ、ストリーム内のインデックスなど）。アプリケーションがこのようなメタデータを永続的に保存したい場合は、データオブジェクト自体に保存できます。
A DECADE server will provide a data access interface, and SDT will be used to write data objects to a server and to read (download) data objects from a server. Semantically, SDT is a client-server protocol; that is, the server always responds to client requests.
DECADEサーバーはデータアクセスインターフェイスを提供し、SDTはサーバーへのデータオブジェクトの書き込みとサーバーからのデータオブジェクトの読み取り（ダウンロード）に使用されます。意味的には、SDTはクライアントサーバープロトコルです。つまり、サーバーは常にクライアント要求に応答します。
To write a data object, a client first generates the object's name (see Section 6.1), and then uploads the object to a server and supplies the generated name. The name can be used to access (download) the object later; for example, the client can pass the name as a reference to other clients that can then refer to the object. Data objects can be self-contained objects such as multimedia resources, files, etc., but also chunks, such as chunks of a P2P distribution protocol that can be part of a containing object or a stream. If supported, a server can verify the integrity and other security properties of uploaded objects.
データオブジェクトを書き込むために、クライアントはまずオブジェクトの名前を生成し（セクション6.1を参照）、次にオブジェクトをサーバーにアップロードし、生成された名前を提供します。この名前は、後でオブジェクトにアクセス（ダウンロード）するために使用できます。たとえば、クライアントは名前を他のクライアントへの参照として渡すことができ、そのオブジェクトはオブジェクトを参照できます。データオブジェクトは、マルチメディアリソースやファイルなどの自己完結型オブジェクトのほか、包含オブジェクトまたはストリームの一部となるP2P配信プロトコルのチャンクなどのチャンクでもかまいません。サポートされている場合、サーバーはアップロードされたオブジェクトの整合性やその他のセキュリティプロパティを確認できます。
A client can request named data objects from a server. In a corresponding request message, a client specifies the object name and a suitable access and resource control token. The server checks the validity of the received token and its associated properties related to resource usage. If the named data object exists on the server and the token can be validated, the server delivers the requested object in a response message. If the data object cannot be delivered, the server provides a corresponding status/reason information in a response message. Specifics regarding error handling, including additional error conditions (e.g., overload), precedence for returned errors and its relation with server policy, are deferred to eventual protocol specification.
クライアントはサーバーから名前付きデータオブジェクトを要求できます。対応する要求メッセージで、クライアントはオブジェクト名と適切なアクセスおよびリソース制御トークンを指定します。サーバーは、受信したトークンの有効性と、リソースの使用に関連するその関連プロパティをチェックします。名前付きデータオブジェクトがサーバー上に存在し、トークンを検証できる場合、サーバーは要求されたオブジェクトを応答メッセージで配信します。データオブジェクトを配信できない場合、サーバーは対応するステータス/理由情報を応答メッセージで提供します。追加のエラー条件（オーバーロードなど）、返されたエラーの優先順位、サーバーポリシーとの関係など、エラー処理に関する詳細は、最終的なプロトコル仕様に委ねられます。
An important feature of a DECADE system is the capability for one server to directly download data objects from another server. This capability allows applications to directly replicate data objects between servers without requiring end-hosts to use uplink capacity to upload data objects to a different server.
DECADEシステムの重要な機能は、あるサーバーが別のサーバーからデータオブジェクトを直接ダウンロードできることです。この機能により、エンドホストがアップリンク容量を使用してデータオブジェクトを別のサーバーにアップロードする必要なく、アプリケーションはサーバー間でデータオブジェクトを直接複製できます。
DRP and SDT SHOULD support operations directly between servers. Servers are not assumed to trust each other nor are they configured to do so. All data operations are performed on behalf of clients via explicit instruction. However, the objects being processed do not necessarily have to originate or terminate at the client (i.e., the data object might be limited to being exchanged between servers even if the instruction is triggered by the client). Clients thus will be able to indicate to a server which remote server(s) to access, what operation is to be performed, or in which server the object is to be stored, and the credentials indicating access and resource control to perform the operation at the remote server.
DRPとSDTは、サーバー間の操作を直接サポートする必要があります（SHOULD）。サーバーは相互に信頼しているとは見なされず、信頼するように構成されていません。すべてのデータ操作は、明示的な指示を介してクライアントに代わって実行されます。ただし、処理されるオブジェクトは必ずしもクライアントで生成または終了する必要はありません（つまり、データオブジェクトは、クライアントによって命令がトリガーされた場合でも、サーバー間での交換に制限される場合があります）。したがって、クライアントは、サーバーにアクセスするリモートサーバー、実行する操作、またはオブジェクトを格納するサーバー、および操作を実行するためのアクセスとリソース制御を示す資格情報をサーバーに示すことができます。リモートサーバー。
Server-server support is focused on reading and writing data objects between servers. The data object referred to at the remote server is the same as the original data object requested by the client. Object attributes might also be specified in the request to the remote server. In this way, a server acts as a proxy for a client, and a client can instantiate requests via that proxy. The operations will be performed as if the original requester had its own client co-located with the server. When a client sends a request to a server with these additional parameters, it is giving the server permission to act (proxy) on its behalf. Thus, it would be prudent for the supplied token to have narrow privileges (e.g., limited to only the necessary data objects) or validity time (e.g., a small expiration time).
サーバー/サーバーのサポートは、サーバー間のデータオブジェクトの読み取りと書き込みに重点を置いています。リモートサーバーで参照されるデータオブジェクトは、クライアントによって要求された元のデータオブジェクトと同じです。リモートサーバーへのリクエストでオブジェクト属性を指定することもできます。このようにして、サーバーはクライアントのプロキシとして機能し、クライアントはそのプロキシを介してリクエストをインスタンス化できます。操作は、元のリクエスターが独自のクライアントをサーバーと同じ場所に配置しているかのように実行されます。クライアントがこれらの追加パラメーターを使用してサーバーに要求を送信すると、サーバーに代わって動作（プロキシー）する許可がサーバーに与えられます。したがって、提供されるトークンが狭い特権（たとえば、必要なデータオブジェクトのみに制限される）または有効期間（たとえば、有効期限が短い）を持っていることが賢明です。
In the case of a retrieval operation, the server is to retrieve the data object from the remote server using the specified credentials, and then optionally return the object to a client. In the case of a storage operation, the server is to store the object to the remote server using the specified credentials. The object might optionally be uploaded from the client or might already exist at the server.
取得操作の場合、サーバーは、指定された資格情報を使用してリモートサーバーからデータオブジェクトを取得し、オプションでオブジェクトをクライアントに返します。ストレージ操作の場合、サーバーは指定された資格情報を使用してオブジェクトをリモートサーバーに保存します。オブジェクトは、オプションでクライアントからアップロードされるか、サーバーにすでに存在する場合があります。
Having covered the key DRP/SDT functionalities above, it is useful to consider some potential DRP/SDT candidates as guidance for future DECADE protocol implementations. To recap, the DRP is a protocol for communication of access control and resource-scheduling policies from a DECADE client to a DECADE server, or between DECADE servers. The SDT is a protocol used to transfer data objects between a DECADE client and DECADE server, or between DECADE servers. An evaluation of existing protocols for their suitability for DRP and SDT is given in Appendix A. Also, [INTEGRATION-EX] provides some experimental examples of how to integrate DECADE-like in-network storage infrastructure into P2P applications.
上記の主要なDRP / SDT機能をカバーしたので、将来のDECADEプロトコル実装のガイダンスとしていくつかの潜在的なDRP / SDT候補を検討することは有用です。要約すると、DRPは、DECADEクライアントからDECADEサーバーへ、またはDECADEサーバー間でアクセス制御およびリソーススケジューリングポリシーを通信するためのプロトコルです。 SDTは、DECADEクライアントとDECADEサーバー間、またはDECADEサーバー間でデータオブジェクトを転送するために使用されるプロトコルです。 DRPおよびSDTへの適合性に関する既存のプロトコルの評価は、付録Aに記載されています。また、[INTEGRATION-EX]は、DECADEのようなネットワーク内ストレージインフラストラクチャをP2Pアプリケーションに統合する方法の実験例をいくつか提供します。
This section evaluates how the basic components of an in-network storage system (see Section 3 of [RFC6392]) map into a DECADE system.
このセクションでは、ネットワーク内ストレージシステムの基本コンポーネント（[RFC6392]のセクション3を参照）がDECADEシステムにどのようにマッピングされるかを評価します。
With respect to the data access interface, DECADE clients can read and write objects of arbitrary size through the client's Data Controller, making use of standard data transfer (SDT). With respect to data management operations, clients can move or delete previously stored objects via the client's Data Controller, making use of SDT. Clients can enumerate or search contents of servers to find objects matching desired criteria through services provided by the content distribution application (e.g., buffer-map exchanges, a DHT, or peer exchange). In doing so, Application Endpoints might consult their local Data Index in the client's Data Controller (Data Search Capability).
データアクセスインターフェイスに関しては、DECADEクライアントは、標準データ転送（SDT）を利用して、クライアントのデータコントローラーを介して任意のサイズのオブジェクトを読み書きできます。データ管理操作に関して、クライアントは、SDTを利用して、クライアントのデータコントローラーを介して以前に保存されたオブジェクトを移動または削除できます。クライアントは、サーバーのコンテンツを列挙または検索して、コンテンツ配信アプリケーションによって提供されるサービス（バッファーマップ交換、DHT、ピア交換など）を通じて目的の基準に一致するオブジェクトを見つけることができます。そうすることで、アプリケーションエンドポイントは、クライアントのデータコントローラー（データ検索機能）でローカルデータインデックスを調べる場合があります。
With respect to access control authorization, all methods of access control are supported: public-unrestricted, public-restricted, and private. Access control policies are generated by a content distribution application and provided to the client's Resource Controller. The server is responsible for implementing the access control checks. Clients can manage the resources (e.g., bandwidth) on the DECADE server that can be used by other Application Endpoints (Resource Control Interface). Resource-sharing policies are generated by a content distribution application and provided to the client's Resource Controller. The server is responsible for implementing the resource-sharing policies.
アクセス制御の承認に関しては、アクセス制御のすべてのメソッドがサポートされています：public-unrestricted、public-restricted、およびprivate。アクセス制御ポリシーは、コンテンツ配布アプリケーションによって生成され、クライアントのリソースコントローラーに提供されます。サーバーは、アクセス制御チェックの実装を担当します。クライアントは、他のアプリケーションエンドポイント（リソース制御インターフェース）で使用できるDECADEサーバー上のリソース（帯域幅など）を管理できます。リソース共有ポリシーは、コンテンツ配信アプリケーションによって生成され、クライアントのリソースコントローラーに提供されます。サーバーは、リソース共有ポリシーの実装を担当します。
Although the particular protocol used for discovery is outside the scope of this document, different options and considerations have been discussed in Section 5.6. Finally, with respect to the storage mode, DECADE servers provide an object-based storage mode. Immutable data objects might be stored at a server. Applications might consider existing blocks as data objects, or they might adjust block sizes before storing in a server.
検出に使用される特定のプロトコルはこのドキュメントの範囲外ですが、セクション5.6ではさまざまなオプションと考慮事項について説明されています。最後に、ストレージモードに関して、DECADEサーバーはオブジェクトベースのストレージモードを提供します。不変データオブジェクトはサーバーに格納される場合があります。アプリケーションは、既存のブロックをデータオブジェクトと見なしたり、サーバーに格納する前にブロックサイズを調整したりする場合があります。
In general, the security considerations mentioned in [RFC6646] apply to this document as well. A DECADE system provides a distributed storage service for content distribution and similar applications. The system consists of servers and clients that use these servers to upload data objects, to request distribution of data objects, and to download data objects. Such a system is employed in an overall application context (for example, in a P2P application), and it is expected that DECADE clients take part in application-specific communication sessions. The security considerations here focus on threats related to the DECADE system and its communication services, i.e., the DRP/SDT protocols that have been described in an abstract fashion in this document.
一般に、[RFC6646]で言及されているセキュリティの考慮事項は、このドキュメントにも適用されます。 DECADEシステムは、コンテンツ配信および同様のアプリケーションのための分散ストレージサービスを提供します。システムは、データオブジェクトのアップロード、データオブジェクトの配布の要求、およびデータオブジェクトのダウンロードにこれらのサーバーを使用するサーバーとクライアントで構成されます。このようなシステムは、全体的なアプリケーションコンテキスト（P2Pアプリケーションなど）で使用され、DECADEクライアントがアプリケーション固有の通信セッションに参加することが期待されています。ここでのセキュリティの考慮事項は、DECADEシステムとその通信サービスに関連する脅威、つまり、このドキュメントで抽象的な方法で説明されているDRP / SDTプロトコルに焦点を当てています。
A DECADE network might be used to distribute data objects from one client to a set of servers using the server-server communication feature that a client can request when uploading an object. Multiple clients uploading many objects at different servers at the same time and requesting server-server distribution for them could thus mount massive distributed denial-of-service (DDOS) attacks, overloading a network of servers. This threat is addressed by the server's access control and resource control framework. Servers can require Application Endpoints to be authorized to store and to download objects, and Application Endpoints can delegate authorization to other Application Endpoints using the token mechanism. Of course the effective security of this approach depends on the strength of the token mechanism. See below for a discussion of this and related communication security threats.
DECADEネットワークは、オブジェクトをアップロードするときにクライアントが要求できるサーバー間通信機能を使用して、1つのクライアントから一連のサーバーにデータオブジェクトを配布するために使用できます。複数のクライアントが異なるサーバーに同時に多くのオブジェクトをアップロードし、それらのサーバー/サーバー分散を要求することで、サーバーのネットワークに過負荷をかける大規模な分散型サービス拒否（DDOS）攻撃を仕掛けることができます。この脅威は、サーバーのアクセス制御およびリソース制御フレームワークによって対処されます。サーバーは、アプリケーションエンドポイントにオブジェクトの保存とダウンロードを承認することを要求でき、アプリケーションエンドポイントはトークンメカニズムを使用して他のアプリケーションエンドポイントに承認を委任できます。もちろん、このアプローチの効果的なセキュリティは、トークンメカニズムの強度に依存します。これおよび関連する通信セキュリティの脅威については、以下を参照してください。
Denial-of-service attacks against a single server (directing many requests to that server) might still lead to considerable load for processing requests and invalidating tokens. SDT therefore MUST provide a redirection mechanism to allow requests to other servers. Analogous to how an HTTP reverse proxy can redirect and load balance across multiple HTTP origin servers [RFC2616].
単一のサーバーに対するサービス拒否攻撃（そのサーバーに多数の要求を送信）しても、要求の処理とトークンの無効化にかなりの負荷がかかる可能性があります。したがって、SDTは、他のサーバーへの要求を許可するリダイレクトメカニズムを提供する必要があります。 HTTPリバースプロキシがリダイレクトし、複数のHTTPオリジンサーバー間で負荷を分散する方法に似ています[RFC2616]。
A DECADE system does not require Application Endpoints to authenticate in order to access a server for downloading objects, since authorization is not based on Endpoint or user identities but on a delegation-based authorization mechanism. Hence, most protocol security threats are related to the authorization scheme. The security of the token mechanism depends on the strength of the token mechanism and on the secrecy of the tokens. A token can represent authorization to store a certain amount of data, to download certain objects, to download a certain amount of data per time, etc. If it is possible for an attacker to guess, construct, or simply obtain tokens, the integrity of the data maintained by the servers is compromised.
DECADEシステムでは、オブジェクトをダウンロードするためにサーバーにアクセスするためにアプリケーションエンドポイントを認証する必要はありません。これは、承認はエンドポイントまたはユーザーIDではなく、委任ベースの承認メカニズムに基づいているためです。したがって、ほとんどのプロトコルセキュリティの脅威は、認可スキームに関連しています。トークンメカニズムのセキュリティは、トークンメカニズムの強度とトークンの機密性に依存します。トークンは、一定量のデータの保存、一定のオブジェクトのダウンロード、一定時間ごとの一定量のデータのダウンロードなどの承認を表すことができます。攻撃者がトークンを推測、構築、または単に取得することが可能な場合、サーバーによって維持されているデータは危険にさらされています。
This is a general security threat that applies to authorization delegation schemes. Specifications of existing delegation schemes such as [RFC6749] discuss these general threats in detail. We can say that the DRP has to specify appropriate algorithms for token generation. Moreover, authorization tokens should have a limited validity period that should be specified by the application. Token confidentiality should be provided by application protocols that carry tokens, and the SDT and DRP should provide secure (confidential) communication modes.
これは、承認の委任スキームに適用される一般的なセキュリティの脅威です。 [RFC6749]などの既存の委任スキームの仕様では、これらの一般的な脅威について詳しく説明しています。 DRPはトークン生成に適切なアルゴリズムを指定する必要があると言えます。さらに、認証トークンには、アプリケーションによって指定される有効期間が制限されている必要があります。トークンの機密性は、トークンを運ぶアプリケーションプロトコルによって提供される必要があり、SDTおよびDRPは安全な（機密）通信モードを提供する必要があります。
In a DECADE system, an Application Endpoint is referring other Application Endpoints to servers to download a specified data object. An attacker could "inject" a faked version of the object into this process, so that the downloading Endpoint effectively receives a different object (compared to what the uploading Endpoint provided). As a result, the downloading Endpoint believes that is has received an object that corresponds to the name it was provided earlier, whereas in fact it is a faked object. Corresponding attacks could be mounted against the application protocol (that is used for referring other Endpoints to servers), servers themselves (and their storage subsystems), and the SDT by which the object is uploaded, distributed, and downloaded.
DECADEシステムでは、アプリケーションエンドポイントは他のアプリケーションエンドポイントをサーバーに参照して、指定されたデータオブジェクトをダウンロードします。攻撃者はこのプロセスに偽のバージョンのオブジェクトを「挿入」する可能性があるため、ダウンロードするエンドポイントは、（アップロードするエンドポイントが提供するものとは異なる）異なるオブジェクトを効果的に受け取ります。その結果、ダウンロードエンドポイントは、それが以前に提供された名前に対応するオブジェクトを受け取ったと信じていますが、実際にはそれは偽のオブジェクトです。対応する攻撃は、アプリケーションプロトコル（他のエンドポイントをサーバーに参照するために使用される）、サーバー自体（およびそれらのストレージサブシステム）、およびオブジェクトのアップロード、配布、ダウンロードに使用されるSDTに対して行われる可能性があります。
A DECADE systems fundamental mechanism against object spoofing is name-object binding validation, i.e., the ability of a receiver to check whether the name it was provided and that it used to request an object actually corresponds to the bits it received. As described above, this allows for different forms of name-object binding, for example, using hashes of data objects, with different hash functions (different algorithms, different digest lengths). For those application scenarios where hashes of data objects are not applicable (for example, live streaming), other forms of name-object binding can be used. This flexibility also addresses cryptographic algorithm evolution: hash functions might get deprecated, better alternatives might be invented, etc., so that applications can choose appropriate mechanisms that meet their security requirements.
オブジェクトスプーフィングに対するDECADEシステムの基本的なメカニズムは、名前とオブジェクトのバインディング検証です。つまり、提供された名前と、オブジェクトを要求するために使用された名前が実際に受信したビットに対応しているかどうかを確認するレシーバーの機能です。上記のように、これにより、たとえば、異なるハッシュ関数（異なるアルゴリズム、異なるダイジェスト長）を使用して、データオブジェクトのハッシュを使用するなど、異なる形式の名前オブジェクトバインディングが可能になります。データオブジェクトのハッシュが適用できないアプリケーションシナリオ（たとえば、ライブストリーミング）では、他の形式の名前オブジェクトバインディングを使用できます。この柔軟性は、暗号アルゴリズムの進化にも対応します。ハッシュ関数が非推奨になったり、より優れた代替案が考案されたりする場合があるため、アプリケーションはセキュリティ要件を満たす適切なメカニズムを選択できます。
DECADE servers MAY perform name-object binding validation on stored objects, but Application Endpoints MUST NOT rely on that. In other words, Application Endpoints SHOULD perform name-object binding validation on received objects.
DECADEサーバーは、保存されたオブジェクトに対して名前とオブジェクトのバインディング検証を実行できますが、アプリケーションエンドポイントはこれに依存してはいけません。つまり、アプリケーションエンドポイントは、受信したオブジェクトに対して名前オブジェクトバインディング検証を実行する必要があります（SHOULD）。
We thank the following people for their contributions to and/or detailed reviews of this document or earlier drafts of this document: Carlos Bernardos, Carsten Bormann, David Bryan, Dave Crocker, Yingjie Gu, David Harrington, Hongqiang (Harry) Liu, David McDysan, Borje Ohlman, Martin Stiemerling, Richard Woundy, and Ning Zong.
このドキュメントまたはこのドキュメントの以前のドラフトへの貢献および/または詳細なレビューに対して、次の人々に感謝します：Carlos Bernardos、Carsten Bormann、David Bryan、Dave Crocker、Yingjie Gu、David Harrington、Hongqiang（Harry）Liu、David McDysan 、Borje Ohlman、Martin Stiemerling、Richard Woundy、Ning Zong。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
[RFC5661] Shepler、S.、Eisler、M。、およびD. Noveck、「Network File System（NFS）Version 4 Minor Version 1 Protocol」、RFC 5661、2010年1月。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[RFC5754]ターナーS.、「暗号化メッセージ構文でのSHA2アルゴリズムの使用」、RFC 5754、2010年1月。
[RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-Network Storage Systems", RFC 6392, October 2011.
[RFC6392] Alimi、R.、Rahman、A。、およびY. Yang、「A Survey of In-Network Storage Systems」、RFC 6392、2011年10月。
[RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", RFC 6646, July 2012.
[RFC6646] Song、H.、Zong、N.、Yang、Y。、およびR.Alimi、「DECoupled Application Data Enroute（DECADE）Problem Statement」、RFC 6646、2012年7月。
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
[RFC6749] Hardt、D。、「The OAuth 2.0 Authorization Framework」、RFC 6749、2012年10月。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、2013年1月。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Naming Things with Hashes」、RFC 6920、2013年4月。
[INTEGRATION-EX] Zong, N., Ed., Chen, X., Huang, Z., Chen, L., and H. Liu, "Integration Examples of DECADE System", Work in Progress, August 2013.
[INTEGRATION-EX] Zong、N.、Ed。、Chen、X.、Huang、Z.、Chen、L.、and H. Liu、 "Integration Examples of DECADE System"、Work in Progress、2013年8月。
[GoogleFileSystem] Ghemawat, S., Gobioff, H., and S. Leung, "The Google File System", SOSP '03, Proceedings of the 19th ACM Symposium on Operating Systems Principles, October 2003.
[GoogleFileSystem] Ghemawat、S.、Gobioff、H。、およびS. Leung、「The Google File System」、SOSP '03、Proceedings of the 19th ACM Symposium on Operating Systems Principles、2003年10月。
[GoogleStorageDevGuide] Google, "Google Cloud Storage - Developer's Guide", <https://developers.google.com/storage/docs/ concepts-techniques>.
[GoogleStorageDevGuide] Google、「Google Cloud Storage-Developer's Guide」、<https://developers.google.com/storage/docs/ concepts-techniques>。
[OpenFlow] Open Networking Foundation, "Software-Defined Networking: The New Norm for Networks", April 2013, <https://www.opennetworking.org/images/stories/downloads/ sdn-resources/white-papers/wp-sdn-newnorm.pdf>.
[OpenFlow] Open Networking Foundation、「Software-Defined Networking：The New Norm for Networks」、2013年4月、<https://www.opennetworking.org/images/stories/downloads/ sdn-resources / white-papers / wp- sdn-newnorm.pdf>。
[CDMI] Storage Networking Industry Association (SNIA), "Cloud Data Management Interface (CDMI (TM)), Version 1.0.2", June 2012, <http://snia.org/sites/default/files/CDMI%20v1.0.2.pdf>.
[CDMI] Storage Networking Industry Association（SNIA）、「Cloud Data Management Interface（CDMI（TM））、Version 1.0.2」、2012年6月、<http://snia.org/sites/default/files/CDMI%20v1 .0.2.pdf>。
Appendix A. Evaluation of Candidate Protocols for DECADE DRP/SDT
付録A. DECADE DRP / SDTの候補プロトコルの評価
In this section we evaluate how well the abstract protocol interactions specified in this document for DECADE DRP and SDT can be fulfilled by the existing protocols of HTTP, CDMI, and OAuth.
このセクションでは、このドキュメントでDECADE DRPおよびSDTに指定されている抽象プロトコルの相互作用が、HTTP、CDMI、およびOAuthの既存のプロトコルによってどれだけうまく満たされるかを評価します。
HTTP [RFC2616] is a key protocol for the Internet in general and especially for the World Wide Web. HTTP is a request-response protocol. A typical transaction involves a client (e.g., web browser) requesting content (resources) from a web server. Another example is when a client stores or deletes content from a server.
HTTP [RFC2616]は、インターネット全体、特にWorld Wide Webの主要なプロトコルです。 HTTPは要求/応答プロトコルです。典型的なトランザクションには、Webサーバーからコンテンツ（リソース）を要求するクライアント（Webブラウザーなど）が含まれます。別の例は、クライアントがサーバーからコンテンツを保存または削除する場合です。
DRP provides configuration of access control and resource-sharing policies on DECADE servers.
DRPは、DECADEサーバーでのアクセス制御とリソース共有ポリシーの構成を提供します。
Access control requires mechanisms for defining the access policies for the server and then checking the authorization of a user before it stores or retrieves content. HTTP supports a rudimentary access control via "HTTP Secure" (HTTPS). HTTPS is a combination of HTTP with SSL/TLS. The main use of HTTPS is to authenticate the server and encrypt all traffic between the client and the server. There is also a mode to support client authentication, though this is less frequently used.
アクセス制御には、サーバーのアクセスポリシーを定義し、コンテンツを保存または取得する前にユーザーの承認を確認するメカニズムが必要です。 HTTPは、 "HTTPセキュア"（HTTPS）による基本的なアクセス制御をサポートしています。 HTTPSは、HTTPとSSL / TLSの組み合わせです。 HTTPSの主な用途は、サーバーを認証し、クライアントとサーバー間のすべてのトラフィックを暗号化することです。クライアント認証をサポートするモードもありますが、これはあまり使用されません。
Communication resources include bandwidth (upload/download) and the number of simultaneously connected clients (connections). HTTP supports bandwidth control indirectly through "persistent" HTTP connections. Persistent HTTP connections allows a client to keep open the underlying TCP connection to the server to allow streaming and pipelining (multiple simultaneous requests for a given client).
通信リソースには、帯域幅（アップロード/ダウンロード）と同時接続クライアント数（接続）が含まれます。 HTTPは、「永続的な」HTTP接続を介して間接的に帯域幅制御をサポートします。永続的なHTTP接続により、クライアントは、サーバーへの基になるTCP接続を開いたままにして、ストリーミングとパイプライン処理（特定のクライアントに対する複数の同時要求）を許可できます。
HTTP does not have direct support for controlling the communication resources for a given client. However, servers typically perform this function via implementation algorithms.
HTTPは、特定のクライアントの通信リソースの制御を直接サポートしていません。ただし、サーバーは通常、実装アルゴリズムを介してこの機能を実行します。
Storage resources include the amount of memory and lifetime of storage. HTTP does not allow direct control of storage at the server endpoint. However, HTTP supports caching at intermediate points such as a web proxy. For this purpose, HTTP defines cache control mechanisms that define how long and in what situations the intermediate point may store and use the content.
ストレージリソースには、メモリの量とストレージの寿命が含まれます。 HTTPでは、サーバーエンドポイントでストレージを直接制御することはできません。ただし、HTTPはWebプロキシなどの中間ポイントでのキャッシュをサポートしています。この目的のために、HTTPは、中間ポイントがコンテンツを格納して使用する期間と状況を定義するキャッシュ制御メカニズムを定義します。
SDT is used to write objects and read (download) objects from a DECADE server. The object can be either a self-contained object such as a multimedia file or a chunk from a P2P system.
SDTは、オブジェクトを書き込んだり、DECADEサーバーからオブジェクトを読み取ったり（ダウンロード）するために使用されます。オブジェクトは、マルチメディアファイルなどの自己完結型オブジェクトか、P2Pシステムのチャンクのいずれかです。
Writing involves uploading objects to the server. HTTP supports two methods of writing called PUT and POST. In HTTP, the object is called a resource and is identified by a URI. PUT uploads a resource to a specific location on the server. POST, on the other hand, submits the object to the server, and the server decides whether to update an existing resource or to create a new resource.
書き込みには、サーバーへのオブジェクトのアップロードが含まれます。 HTTPは、PUTおよびPOSTと呼ばれる2つの書き込み方法をサポートしています。 HTTPでは、オブジェクトはリソースと呼ばれ、URIによって識別されます。 PUTは、サーバー上の特定の場所にリソースをアップロードします。一方、POSTはオブジェクトをサーバーに送信し、サーバーは既存のリソースを更新するか、新しいリソースを作成するかを決定します。
For DECADE, the choice of whether to use PUT or POST will be influenced by which entity is responsible for the naming. If the client performs the naming, then PUT is appropriate. If the server performs the naming, then POST should be used (to allow the server to define the URI).
DECADEの場合、PUTまたはPOSTを使用するかどうかの選択は、ネーミングを担当するエンティティーに影響されます。クライアントがネーミングを実行する場合、PUTが適切です。サーバーがネーミングを実行する場合は、POSTを使用する必要があります（サーバーがURIを定義できるようにするため）。
Downloading involves fetching of an object from the server. HTTP supports downloading through the GET and HEAD methods. GET fetches a specific resource as identified by the URL. HEAD is similar but only fetches the metadata ("header") associated with the resource, not the resource itself.
ダウンロードには、サーバーからのオブジェクトのフェッチが含まれます。 HTTPは、GETおよびHEADメソッドを介したダウンロードをサポートしています。 GETは、URLで識別される特定のリソースをフェッチします。 HEADも同様ですが、リソース自体ではなく、リソースに関連付けられたメタデータ（「ヘッダー」）のみをフェッチします。
To challenge a remote entity for an object, the DECADE server should provide a seed number, which is generated by the server randomly, and ask the remote entity to return a hash calculated from the seed number and the content of the object. The server may also specify the hash function that the remote entity should use. HTTP supports the challenge message through the GET methods. The message type ("challenge"), the seed number, and the hash function name are put in a URL. In the reply, the hash is sent in an Entity Tag (ETag) header.
オブジェクトのリモートエンティティにチャレンジするには、DECADEサーバーはサーバーによってランダムに生成されるシード番号を提供し、シード番号とオブジェクトのコンテンツから計算されたハッシュを返すようリモートエンティティに要求する必要があります。サーバーは、リモートエンティティが使用するハッシュ関数を指定することもできます。 HTTPは、GETメソッドを通じてチャレンジメッセージをサポートします。メッセージタイプ（「チャレンジ」）、シード番号、およびハッシュ関数名がURLに配置されます。応答では、ハッシュはエンティティタグ（ETag）ヘッダーで送信されます。
HTTP supports deleting of content on the server through the DELETE method.
HTTPは、DELETEメソッドによるサーバー上のコンテンツの削除をサポートしています。
HTTP can provide a rudimentary DRP and SDT for some aspects of DECADE, but it will not be able to satisfy all the DECADE requirements. For example, HTTP does not provide a complete access control mechanism nor does it support storage resource controls at the endpoint server.
HTTPは、DECADEの一部の側面に対して基本的なDRPおよびSDTを提供できますが、すべてのDECADE要件を満たすことはできません。たとえば、HTTPは完全なアクセス制御メカニズムを提供せず、エンドポイントサーバーでのストレージリソース制御もサポートしません。
It is possible, however, to envision combining HTTP with a custom suite of other protocols to fulfill most of the DECADE requirements for DRP and SDT. For example, Google Storage for Developers is built using HTTP (with extensive proprietary extensions such as custom HTTP headers). Google Storage also uses OAuth [RFC6749] (for access control) in combination with HTTP [GoogleStorageDevGuide]. An example of using OAuth for DRP is given in Appendix A.3.
ただし、HTTPを他のプロトコルのカスタムスイートと組み合わせて、DRPおよびSDTのDECADE要件のほとんどを満たすことを想定することは可能です。たとえば、Google Storage for DevelopersはHTTPを使用して構築されています（カスタムHTTPヘッダーなどの独自の拡張機能を備えています）。 Google Storageは、HTTP [GoogleStorageDevGuide]と組み合わせてOAuth [RFC6749]（アクセス制御用）も使用します。 DRPにOAuthを使用する例を付録A.3に示します。
The Cloud Data Management Interface (CDMI) specification defines a functional interface through which applications can store and manage data objects in a cloud storage environment. The CDMI interface for reading/writing data is based on standard HTTP requests, with CDMI-specific encodings using JavaScript Object Notation (JSON). CDMI is specified by the Storage Networking Industry Association (SNIA) [CDMI].
クラウドデータ管理インターフェース（CDMI）仕様は、アプリケーションがクラウドストレージ環境でデータオブジェクトを保存および管理できる機能インターフェースを定義します。データの読み取り/書き込み用のCDMIインターフェースは、JavaScript Object Notation（JSON）を使用したCDMI固有のエンコーディングを使用した標準のHTTPリクエストに基づいています。 CDMIは、Storage Networking Industry Association（SNIA）[CDMI]によって指定されています。
DRP provides configuration of access control and resource-sharing policies on DECADE servers.
DRPは、DECADEサーバーでのアクセス制御とリソース共有ポリシーの構成を提供します。
Access control includes mechanisms for defining the access policies for the server and then checking the authorization of a user before allowing content storage or retrieval. CDMI defines an Access Control List (ACL) per data object and thus supports access control (read and/or write) at the granularity of data objects. An ACL contains a set of Access Control Entries (ACEs), where each ACE specifies a principal (i.e., user or group of users) and a set of privileges that are granted to that principal.
アクセス制御には、サーバーのアクセスポリシーを定義し、コンテンツの保存または取得を許可する前にユーザーの承認をチェックするメカニズムが含まれます。 CDMIは、データオブジェクトごとにアクセス制御リスト（ACL）を定義し、データオブジェクトの粒度でのアクセス制御（読み取りまたは書き込み、あるいはその両方）をサポートします。 ACLには一連のアクセス制御エントリ（ACE）が含まれ、各ACEはプリンシパル（つまり、ユーザーまたはユーザーのグループ）とそのプリンシパルに付与される一連の特権を指定します。
CDMI requires that an HTTP authentication mechanism be available for the server to validate the identity of a principal (client). Specifically, CDMI requires that either HTTP Basic Authentication or HTTP Digest Authentication be supported. CDMI recommends that HTTP over TLS (HTTPS) is supported to encrypt the data sent over the network.
CDMIでは、サーバーがプリンシパル（クライアント）のIDを検証するためにHTTP認証メカニズムを使用できる必要があります。具体的には、CDMIでは、HTTP基本認証またはHTTPダイジェスト認証のいずれかがサポートされている必要があります。 CDMIでは、ネットワーク経由で送信されるデータを暗号化するためにHTTP over TLS（HTTPS）をサポートすることを推奨しています。
Communication resources include bandwidth (upload/download) and the number of simultaneously connected clients (connections). CDMI supports two key data attributes that provide control over the communication resources to a client: "cdmi_max_throughput" and "cdmi_max_latency". These attributes are defined in the metadata for data objects and indicate the desired bandwidth or delay for transmission of the data object from the cloud server to the client.
通信リソースには、帯域幅（アップロード/ダウンロード）と同時接続クライアント数（接続）が含まれます。 CDMIは、クライアントへの通信リソースを制御する2つの主要なデータ属性、「cdmi_max_throughput」と「cdmi_max_latency」をサポートしています。これらの属性は、データオブジェクトのメタデータで定義され、クラウドサーバーからクライアントへのデータオブジェクトの送信に必要な帯域幅または遅延を示します。
Storage resources include amount of quantity and lifetime of storage. CDMI defines metadata for individual data objects and general storage system configuration that can be used for storage resource control. In particular, CDMI defines the following metadata fields:
ストレージリソースには、ストレージの量と寿命が含まれます。 CDMIは、ストレージリソースの制御に使用できる個々のデータオブジェクトと一般的なストレージシステム構成のメタデータを定義します。特に、CDMIは次のメタデータフィールドを定義します。
-cdmi_data_redundancy: desired number of copies to be maintained
-cdmi_data_redundancy：維持するコピーの希望数
-cdmi_geographic_placement: region where object is permitted to be stored
-cdmi_geographic_placement：オブジェクトの保存が許可されている領域
-cdmi_retention_period: time interval object is to be retained
-cdmi_retention_period：時間間隔オブジェクトが保持されます
-cdmi_retention_autodelete: whether object should be automatically deleted after retention period
-cdmi_retention_autodelete：保存期間後にオブジェクトを自動的に削除するかどうか
SDT is used to write objects and read (download) objects from a DECADE server. The object can be either a self-contained object such as a multimedia file or a chunk from a P2P system.
SDTは、オブジェクトを書き込んだり、DECADEサーバーからオブジェクトを読み取ったり（ダウンロード）するために使用されます。オブジェクトは、マルチメディアファイルなどの自己完結型オブジェクトか、P2Pシステムのチャンクのいずれかです。
Writing involves uploading objects to the server. CDMI supports standard HTTP methods for PUT and POST as described in Appendix A.1.2.1.
書き込みには、サーバーへのオブジェクトのアップロードが含まれます。 CDMIは、付録A.1.2.1で説明されているように、PUTおよびPOSTの標準HTTPメソッドをサポートしています。
Downloading involves fetching of an object from the server. CDMI supports the standard HTTP GET method as described in Appendix A.1.2.2.
ダウンロードには、サーバーからのオブジェクトのフェッチが含まれます。 CDMIは、付録A.1.2.2で説明されているように、標準のHTTP GETメソッドをサポートしています。
CDMI supports DELETE as described in Appendix A.1.4. CDMI also supports COPY and MOVE operations.
CDMIは、付録A.1.4で説明されているDELETEをサポートしています。 CDMIは、COPYおよびMOVE操作もサポートしています。
CDMI supports the concept of containers of data objects to support joint operations on related objects. For example, GET may be done on a single data object or an entire container.
CDMIは、データオブジェクトのコンテナーの概念をサポートして、関連するオブジェクトの共同操作をサポートします。たとえば、GETは単一のデータオブジェクトまたはコンテナ全体に対して実行できます。
CDMI supports a global naming scheme. Every object stored within a CDMI system will have a globally unique object string identifier (ObjectID) assigned at creation time.
CDMIは、グローバルな命名スキームをサポートしています。 CDMIシステム内に格納されているすべてのオブジェクトには、作成時に割り当てられたグローバルに一意のオブジェクト文字列識別子（ObjectID）があります。
CDMI has a rich array of features that can provide a good base for DRP and SDT for DECADE. An initial analysis finds that the following CDMI features may be useful for DECADE:
CDMIには、DRPおよびDECADEのSDTの優れた基盤を提供できる豊富な機能が備わっています。最初の分析では、以下のCDMI機能がDECADEに役立つ可能性があることがわかりました。
- access control
- アクセス制御
- storage resource control
- ストレージリソース制御
- communication resource control
- 通信リソース制御
- COPY/MOVE operations
- コピー/移動操作
- data containers
- データコンテナ
- naming scheme
- 命名スキーム
As mentioned in Appendix A.1, OAuth [RFC6749] may be used as part of the access and resource control of a DECADE system. In this section, we provide an example of how to configure OAuth requests and responses for DRP.
付録A.1で述べたように、OAuth [RFC6749]は、DECADEシステムのアクセスおよびリソース制御の一部として使用できます。このセクションでは、DRPのOAuth要求と応答を構成する方法の例を示します。
An OAuth request to access DECADE data objects should include the following fields:
DECADEデータオブジェクトにアクセスするOAuthリクエストには、次のフィールドを含める必要があります。
response_type: Value should be set to "token".
response_type：値は "token"に設定する必要があります。
client_id: The client_id indicates either the application that is using the DECADE service or the end user who is using the DECADE service from a DECADE storage service provider. DECADE storage service providers should provide the ID distribution and management function.
client_id：client_idは、DECADEサービスを使用しているアプリケーション、またはDECADEストレージサービスプロバイダーのDECADEサービスを使用しているエンドユーザーを示します。 DECADEストレージサービスプロバイダーは、IDの配布および管理機能を提供する必要があります。
scope: Data object names that are requested.
スコープ：要求されるデータオブジェクト名。
An OAuth response should include the following information:
OAuth応答には、次の情報が含まれている必要があります。
token_type: "Bearer"
token_type： "ベアラー"
expires_in: The lifetime in seconds of the access token.
expires_in：アクセストークンの有効期間（秒単位）。
access_token: A token denotes the following information.
access_token：トークンは次の情報を示します。
service_uri: The server address or URI which is providing the service;
service_uri：サービスを提供しているサーバーアドレスまたはURI。
permitted_operations (e.g., read, write) and objects (e.g., names of data objects that might be read or written);
allowed_operations（例：読み取り、書き込み）およびオブジェクト（例：読み取りまたは書き込みされる可能性のあるデータオブジェクトの名前）;
priority: Value should be set to be either "Urgent", "High", "Normal" or "Low".
優先度：値は「緊急」、「高」、「通常」、「低」のいずれかに設定する必要があります。
bandwidth: Given to requested operation, a weight value used in a weighted bandwidth sharing scheme, or an integer in number of bits per second;
帯域幅：要求された操作に与えられた、加重帯域幅共有方式で使用される加重値、またはビット/秒の整数。
amount: Data size in number of bytes that might be read or written.
量：読み書きされる可能性のあるバイト数でのデータサイズ。
token_signature: The signature of the access token.
token_signature：アクセストークンの署名。
Authors' Addresses
著者のアドレス
Richard Alimi Google
リチャードアリミグーグル
EMail: ralimi@google.com
Akbar Rahman InterDigital Communications, LLC
Akbar Rahman InterDigital Communications、LLC
EMail: akbar.rahman@interdigital.com
Dirk Kutscher NEC
ダーククッチャーNEC
EMail: dirk.kutscher@neclab.eu
Y. Richard Yang Yale University
Y.リチャードヤンイェール大学
EMail: yry@cs.yale.edu
Haibin Song Huawei Technologies
H AI bin Songhua Weiテクノロジー
EMail: haibin.song@huawei.com
Kostas Pentikousis EICT
Kostas Pentikousis EICT
EMail: k.pentikousis@eict.de