RFC 6392 - A Survey of In-Network Storage Systems 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6392
タイトル : RFC 6392 - ネットワーク内のストレージシステムの調査
翻訳編集 : 自動生成

[要約] RFC 6392は、ネットワーク内ストレージシステムに関する調査であり、その目的は、既存のシステムの概要と課題を把握し、将来の研究や開発に役立つ情報を提供することです。

Internet Engineering Task Force (IETF)                     R. Alimi, Ed.
Request for Comments: 6392                                        Google
Category: Informational                                   A. Rahman, Ed.
ISSN: 2070-1721                         InterDigital Communications, LLC
                                                            Y. Yang, Ed.
                                                         Yale University
                                                            October 2011

A Survey of In-Network Storage Systems

ネットワーク内のストレージシステムの調査

Abstract

概要

This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture.

このドキュメント調査は、展開および実験的なネットワーク内のストレージシステムと、10年間の適用可能性（分離されたアプリケーションデータ）アーキテクチャについて説明しています。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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/rfc6392.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6392で取得できます。

著作権表示

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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

Table of Contents

   1. Introduction ....................................................3
   2. Survey Overview .................................................3
      2.1. Terminology and Concepts ...................................3
      2.2. Historical Context .........................................3
   3. In-Network Storage System Components ............................5
      3.1. Data Access Interface ......................................5
      3.2. Data Management Operations .................................5
      3.3. Data Search Capability .....................................6
      3.4. Access Control Authorization ...............................6
      3.5. Resource Control Interface .................................6
      3.6. Discovery Mechanism ........................................7
      3.7. Storage Mode ...............................................7
   4. In-Network Storage Systems ......................................7
      4.1. Amazon S3 ..................................................7
      4.2. BranchCache ................................................9
      4.3. Cache-and-Forward Architecture ............................11
      4.4. Cloud Data Management Interface ...........................12
      4.5. Content Delivery Network ..................................14
      4.6. Delay-Tolerant Network ....................................16
      4.7. Named Data Networking .....................................18
      4.8. Network of Information ....................................19
      4.9. Network Traffic Redundancy Elimination ....................22
      4.10. OceanStore ...............................................23
      4.11. P2P Cache ................................................24
      4.12. Photo Sharing ............................................26
      4.13. Usenet ...................................................28
      4.14. Web Cache ................................................29
      4.15. Observations Regarding In-Network Storage Systems ........31
   5. Storage and Other Related Protocols ............................32
      5.1. HTTP ......................................................32
      5.2. iSCSI .....................................................33
      5.3. NFS .......................................................34
      5.4. OAuth .....................................................36
      5.5. WebDAV ....................................................37
      5.6. Observations Regarding Storage and Related Protocols ......39
   6. Conclusions ....................................................40
   7. Security Considerations ........................................40
   8. Contributors ...................................................40
   9. Acknowledgments ................................................41
   10. Informative References ........................................41

1. Introduction

1. はじめに

DECADE (DECoupled Application Data Enroute) is an architecture that provides applications with access to provider-based in-network storage for content distribution (hereafter referred to as only "in-network storage" in this document). With access to in-network storage, content distribution applications can be designed to place less load on network infrastructure. As a simple example, a peer of a Peer-to-Peer (P2P) application may upload to other peers through its in-network storage, saving its usage of last-mile uplink bandwidth. See [1] for further discussion.

Decade（Decoupled Application Data anute）は、コンテンツ配信用のプロバイダーベースのネットワーク内ストレージへのアクセスを提供するアーキテクチャです（以下、このドキュメントでは「ネットワーク内のストレージ」のみと呼ばれます）。ネットワーク内のストレージにアクセスすることで、コンテンツ配信アプリケーションは、ネットワークインフラストラクチャへの負荷を少なくするように設計できます。簡単な例として、ピアツーピア（P2P）アプリケーションのピアは、ネットワーク内のストレージを介して他のピアにアップロードし、ラストマイルのアップリンク帯域幅の使用を節約できます。詳細については、[1]を参照してください。

A major motivation for DECADE is the substantial increase in capacity and reduction in cost offered by storage systems. For example, over the last two decades, there has been at least a 30-fold increase in the amount of storage that a customer can get for a given price (for flash memory and hard disk drives) [2] [3] [4].

10年間の大きな動機は、ストレージシステムが提供する容量の大幅な増加とコストの削減です。たとえば、過去20年間で、顧客が特定の価格で取得できるストレージの量が少なくとも30倍増加しました（フラッシュメモリとハードディスクドライブの場合）[2] [3] [4]。

High-capacity and low-cost in-network storage devices introduce substantial opportunities. One example of in-network storage is content caches supporting Web and P2P content. DECADE differs from existing content caches whose control fully resides with the owners of the caching devices in that DECADE also allows applications to control access to their allocated in-network storage, as well as the resources consumed while accessing that storage (bandwidth, connections, storage space). While designed in the context of P2P applications, DECADE may be useful to other applications as well. This document provides details on deployed and experimental in-network storage solutions, and evaluates their suitability for DECADE.

大容量および低コストのネットワーク内のストレージデバイスは、大きな機会をもたらします。ネットワーク内のストレージの1つの例は、WebおよびP2Pコンテンツをサポートするコンテンツキャッシュです。10年は、その10年間でキャッシュデバイスの所有者と完全に存在する既存のコンテンツキャッシュとは異なります。また、アプリケーションは割り当てられたネットワーク内のストレージへのアクセスを制御できます。スペース）。P2Pアプリケーションのコンテキストで設計されていますが、10年も他のアプリケーションにも役立つ場合があります。このドキュメントは、展開および実験的なネットワーク内のストレージソリューションに関する詳細を提供し、10年間の適合性を評価します。

We note that the survey presented in this document is only representative of the research in this area. Rather than trying to enumerate an exhaustive list, we have chosen some typical techniques that lead to derivative works.

このドキュメントで提示された調査は、この分野の研究のみを代表していることに注意してください。徹底的なリストを列挙しようとするのではなく、派生作品につながるいくつかの典型的なテクニックを選択しました。

2. Survey Overview

2. 調査の概要

2.1. Terminology and Concepts

2.1. 用語と概念

This document uses terms defined in [1].

このドキュメントでは、[1]で定義されている用語を使用します。

2.2. Historical Context

2.2. 歴史的背景

In-network storage has been used previously in numerous scenarios to reduce network traffic and enable more efficient content distribution. This section presents a brief history of content distribution techniques and illustrates how DECADE relates to past

ネットワーク内のストレージは、ネットワークトラフィックを削減し、より効率的なコンテンツ分布を可能にするために、多くのシナリオで以前に使用されています。このセクションでは、コンテンツ配信技術の簡単な履歴を示し、10年が過去にどのように関連しているかを示しています

approaches. Systems have been developed with particular use cases in mind. Thus, this survey is not meant to point out shortcomings of existing solutions, but rather to indicate where certain capabilities required in DECADE [5] are not provided by existing systems.

アプローチ。特定のユースケースを念頭に置いてシステムが開発されています。したがって、この調査は、既存のソリューションの欠点を指摘することではなく、10年で必要な特定の機能[5]が既存のシステムによって提供されていない場所を示すためのものです。

In the early stage of Internet development, most Web content was stored at a central server, and clients requested Web content from the central server. In this architecture, the central server was required to provide a large amount of bandwidth. As more and more users access Web content, a central server can become overloaded. The use of Web caches is one technique to reduce load on a central server. Web caches store frequently requested content and provide bandwidth for serving the content to clients.

インターネット開発の初期段階では、ほとんどのWebコンテンツが中央サーバーに保存され、クライアントはセントラルサーバーからWebコンテンツを要求しました。このアーキテクチャでは、大量の帯域幅を提供するために中央サーバーが必要でした。ますます多くのユーザーがWebコンテンツにアクセスするにつれて、中央サーバーがオーバーロードされる可能性があります。Webキャッシュの使用は、中央サーバーの負荷を減らすための1つの手法です。Web Cachesは、頻繁にコンテンツを要求し、クライアントにコンテンツを提供するための帯域幅を提供します。

The ongoing growth of broadband technology in the worldwide market has been driven by the hunger of customers for new multimedia services as well as Web content. In particular, the use of audio and video streaming formats has become common for delivery of rich information to the public, both residential and business.

世界市場でのブロードバンドテクノロジーの継続的な成長は、新しいマルチメディアサービスとWebコンテンツに対する顧客の飢えによって推進されています。特に、オーディオおよびビデオストリーミング形式の使用は、住宅とビジネスの両方で豊富な情報を一般に提供するために一般的になりました。

To overcome this challenge of massive multimedia consumption, just installing more Web caches will not be enough. Moving content closer to the consumer results in greater network efficiency, improved Quality of Service (QoS), and lower latency, while facilitating personalization of content through broadband content applications. In these edge technologies, Content Delivery Networks (CDNs) are a representative technique. CDNs are based on a large-scale distributed network of servers located closer to customers for efficient delivery of digital content, including various forms of multimedia content.

大規模なマルチメディア消費というこの課題を克服するには、より多くのWebキャッシュをインストールするだけでは十分ではありません。コンテンツを消費者に近づけると、ネットワーク効率が向上し、サービス品質（QOS）が向上し、レイテンシが低くなり、ブロードバンドコンテンツアプリケーションを通じてコンテンツのパーソナライズが促進されます。これらのエッジテクノロジーでは、コンテンツ配信ネットワーク（CDN）が代表的な技術です。CDNは、さまざまな形式のマルチメディアコンテンツを含むデジタルコンテンツを効率的に配信するために、顧客に近いサーバーの大規模な分散ネットワークに基づいています。

Although CDNs are an effective means of information access and delivery, there are two barriers to making CDNs a more common service: cost and replication integrity. Deploying a CDN with its associated infrastructure is expensive. A CDN also requires administrative control over nodes with large storage capacity at geographically dispersed locations with adequate connectivity. CDNs can be scalable, but due to this administrative and cost overhead, they are not rapidly deployable for the common user.

CDNは情報アクセスと配信の効果的な手段ですが、CDNをより一般的なサービスにすることには2つの障壁があります：コストと複製の整合性。関連するインフラストラクチャを使用してCDNを展開するのは高価です。また、CDNには、適切な接続性を備えた地理的に分散した場所で大きなストレージ容量を持つノードを管理する必要があります。CDNはスケーラブルになる可能性がありますが、この管理とコストのオーバーヘッドにより、一般的なユーザーには迅速に展開できません。

The emergence and maturation of P2P has allowed improvements to many network applications. P2P allows the use of client resources, such as CPU, memory, storage, and bandwidth, for serving content. This can reduce the amount of resources required by a content provider. Multimedia content delivery using various P2P or peer-assisted frameworks has been shown to greatly reduce the dependence on CDNs and central content servers. However, the popularity of P2P applications has resulted in increased traffic on ISP networks. P2P

P2Pの出現と成熟により、多くのネットワークアプリケーションの改善が可能になりました。P2Pを使用すると、コンテンツを提供するために、CPU、メモリ、ストレージ、帯域幅などのクライアントリソースを使用できます。これにより、コンテンツプロバイダーが必要とするリソースの量を減らすことができます。さまざまなP2Pまたはピアアシストフレームワークを使用したマルチメディアコンテンツの配信は、CDNSおよび中央コンテンツサーバーへの依存を大幅に減らすことが示されています。ただし、P2Pアプリケーションの人気により、ISPネットワークのトラフィックが増加しています。p2p

caches (both transparent and non-transparent) have been introduced as a way to reduce the burden. Though they can be effective in reducing traffic in certain areas of ISP networks, P2P caches have their shortcomings. In particular, they are application-dependent and thus difficult to keep up to date with new and evolving P2P application protocols. Second, applications may benefit from explicit control of in-network storage, which P2P caches do not provide. See [1] for further discussion.

キャッシュ（透明性と非透明の両方）が、負担を軽減する方法として導入されています。ISPネットワークの特定の領域でトラフィックを減らすのに効果的ですが、P2Pキャッシュには欠点があります。特に、それらはアプリケーションに依存しているため、新しく進化するP2Pアプリケーションプロトコルを最新の状態に保つことは困難です。第二に、アプリケーションはネットワーク内のストレージを明示的に制御することで恩恵を受ける可能性があります。これは、P2Pキャッシュが提供していないものです。詳細については、[1]を参照してください。

DECADE aims to provide a standard protocol allowing P2P applications (including content providers) to make use of in-network storage to reduce the traffic burden on ISP networks, while enabling P2P applications to control access to content they have placed in in-network storage.

Decadeの目的は、P2Pアプリケーション（コンテンツプロバイダーを含む）がネットワーク内のストレージを利用してISPネットワークの交通負担を軽減できる標準プロトコルを提供することを目的としています。

3. In-Network Storage System Components

3. ネットワーク内のストレージシステムコンポーネント

Before surveying individual technologies, we describe the basic components of in-network storage. For consistency and for ease of comparison, we use the same model to evaluate each storage technology in this document.

個々の技術を調査する前に、ネットワーク内のストレージの基本的なコンポーネントについて説明します。一貫性と比較のために、同じモデルを使用して、このドキュメントの各ストレージテクノロジーを評価します。

Note that the network protocol(s) used by a given storage system are also an important part of the design. We omit details of particular protocol choices in this document.

特定のストレージシステムで使用されるネットワークプロトコルも設計の重要な部分であることに注意してください。このドキュメントでは、特定のプロトコルの選択の詳細を省略します。

3.1. Data Access Interface

3.1. データアクセスインターフェイス

A set of operations is made available to a user for accessing data in the in-network storage system. Solutions typically allow both read and write operations, though the mechanisms for doing so can differ drastically.

ネットワーク内のストレージシステムでデータにアクセスするために、ユーザーが一連の操作を利用できるようにします。ソリューションは通常、読み取り操作と書き込み操作の両方を許可しますが、そうするためのメカニズムは劇的に異なる場合があります。

3.2. Data Management Operations

3.2. データ管理操作

Storage systems may provide users the ability to manage stored content. For example, operations such as delete and move may be provided to users. In this survey, we focus on data management operations that are provided to users and omit those provided to system administrators.

ストレージシステムは、ユーザーに保存されたコンテンツを管理する機能を提供する場合があります。たとえば、削除や移動などの操作がユーザーに提供される場合があります。この調査では、ユーザーに提供されるデータ管理操作に焦点を当て、システム管理者に提供されるものを省略します。

3.3. Data Search Capability

3.3. データ検索機能

Some storage systems may provide the capability to search or enumerate content that has been stored. In this survey, we focus on search capabilities that are provided to users and omit those provided to system administrators. An example of a search would be to find the list of items stored by a given user over a given period of time.

一部のストレージシステムは、保存されているコンテンツを検索または列挙する機能を提供する場合があります。この調査では、ユーザーに提供される検索機能に焦点を当て、システム管理者に提供されるものを省略します。検索の例は、特定のユーザーが特定の期間にわたって保存しているアイテムのリストを見つけることです。

3.4. Access Control Authorization

3.4. アクセス制御承認

Storage systems typically allow a user, content owner, or some other entity to define the access policies for the in-network storage system. The in-network storage system then checks the authorization of a user before it stores or retrieves content. We define three types of access control authorization: public-unrestricted, public-restricted, and private.

通常、ストレージシステムでは、ユーザー、コンテンツ所有者、または他のエンティティがネットワーク内のストレージシステムのアクセスポリシーを定義できます。ネットワーク内のストレージシステムは、コンテンツを保存または取得する前に、ユーザーの承認をチェックします。3種類のアクセス制御承認を定義します：公共の領土、公共制限、プライベート。

"Public-unrestricted" refers to content on an in-network storage system that is widely available to all clients (i.e., without restrictions). An example is accessing Wikipedia on the Web, or anonymous access to FTP sites.

「公開されていない」とは、すべてのクライアントが広く利用できるネットワーク内のストレージシステムのコンテンツを指します（つまり、制限なし）。例は、Web上のWikipediaにアクセスするか、FTPサイトへの匿名アクセスです。

"Public-restricted" refers to content on an in-network storage system that is available to a restricted (though still potentially large) set of clients, but that does not require any confidential credentials from the client. An example is some content (e.g., a TV show episode) on the Internet that can only be viewable in selected countries or networks (i.e., white/black lists or black-out areas).

「公開された」とは、制限付き（潜在的には潜在的には大きい）セットのクライアントが利用できるネットワーク内のストレージシステム上のコンテンツを指しますが、クライアントからの機密資格情報は必要ありません。例としては、選択した国やネットワークでのみ表示できるインターネット上のコンテンツ（テレビ番組エピソードなど）（つまり、白/黒のリストまたはブラックアウトエリア）です。

"Private" refers to content on an in-network storage system that is only made available to one or more clients presenting the required confidential credentials (e.g., password or key). This content is not available to anyone without the proper confidential access credentials.

「プライベート」とは、必要な機密資格情報（パスワードやキーなど）を提示する1つ以上のクライアントのみが利用できるようになるネットワーク内のストレージシステムのコンテンツを指します。このコンテンツは、適切な機密アクセス資格情報なしで誰にも利用できません。

Note that a combination of access control types may be applicable for a given scenario. For example, the retrieval (read) of content from an in-network storage system may be public-unrestricted, but the storage (write) to the same system may be private.

アクセス制御タイプの組み合わせは、特定のシナリオに適用できることに注意してください。たとえば、ネットワーク内のストレージシステムからのコンテンツの検索（読み取り）は公開されていない場合がありますが、同じシステムのストレージ（書き込み）はプライベートである可能性があります。

3.5. Resource Control Interface

3.5. リソース制御インターフェイス

This is the interface through which users manage the resources on in-network storage systems that can be used by other peers, e.g., the bandwidth or connections. The storage system may also allow users to indicate a time for which resources are granted.

これは、ユーザーが他のピア、たとえば帯域幅や接続で使用できるネットワーク内のストレージシステムのリソースを管理するインターフェイスです。ストレージシステムにより、ユーザーはリソースが付与される時間を示すこともできます。

3.6. Discovery Mechanism

3.6. 発見メカニズム

Users use the discovery mechanism to find the location of in-network storage, find an access interface or resource control interface, or find other interfaces of in-network storage.

ユーザーはディスカバリーメカニズムを使用して、ネットワーク内のストレージの場所を見つけたり、アクセスインターフェイスまたはリソース制御インターフェイスを見つけたり、ネットワーク内のストレージの他のインターフェイスを見つけたりします。

3.7. Storage Mode

3.7. ストレージモード

Storage systems may use the following modes of storage: file system, object-based, or block-based.

ストレージシステムは、ファイルシステム、オブジェクトベース、またはブロックベースのストレージモードを使用する場合があります。

A file system typically organizes files into a hierarchical tree structure. Each level of the hierarchy normally contains zero or more directories, each with zero or more files. A file system may also be flat or use some other organizing principle.

ファイルシステムは通常、ファイルを階層ツリー構造に整理します。階層の各レベルには通常、ゼロ以上のディレクトリが含まれており、それぞれがゼロ以上のファイルを備えています。ファイルシステムは、フラットな場合もあれば、他の組織化の原則を使用する場合もあります。

We define an object-based storage mode as one that stores discrete chunks of data (e.g., IP datagrams or another type of aggregation useful to an application) without a pre-defined hierarchy or meta-structure.

オブジェクトベースのストレージモードを、事前に定義された階層やメタ構造なしでデータの離散チャンク（例：アプリケーションに役立つ別のタイプの集約）を保存するものとして定義します。

We define a block-based storage mode as one that stores a raw sequence of bytes, with a client being able to read and/or write data at offsets within that sequence. Data is typically accessed in blocks for efficiency. A common example for this storage mode is raw access to a hard disk.

ブロックベースのストレージモードを、一連のバイトシーケンスを保存するものとして定義し、クライアントはそのシーケンス内のオフセットでデータを読み取りおよび/または書き込むことができます。データは通常、効率のためにブロックでアクセスされます。このストレージモードの一般的な例は、ハードディスクへの生のアクセスです。

In this survey, we define "storage mode" to refer to how data is structured within the system, which may not be the same as how it is accessed by a client. For example, a caching system may cache objects with hierarchical names, but may internally use an object-based storage mode.

この調査では、「ストレージモード」を定義して、システム内でデータが構造化される方法を参照します。これは、クライアントがアクセスする方法と同じではない場合があります。たとえば、キャッシュシステムは、階層名でオブジェクトをキャッシュする場合がありますが、オブジェクトベースのストレージモードを内部的に使用する場合があります。

4. In-Network Storage Systems

4. ネットワーク内のストレージシステム

This section surveys in-network storage systems using the methodology defined above. The survey includes some systems that are widely deployed today, some systems that are just being deployed, and some experimental systems. The survey covers both traditional client-server architectures and P2P architectures. The surveyed systems are listed in alphabetical order. Also, for each system, a brief explanation of the relevance to DECADE is given.

このセクションでは、上記の方法論を使用してネットワーク内のストレージシステムを調査します。調査には、今日広く展開されている一部のシステム、展開されているばかりのシステム、およびいくつかの実験システムが含まれています。この調査では、従来のクライアントサーバーアーキテクチャとP2Pアーキテクチャの両方をカバーしています。調査対象のシステムは、アルファベット順にリストされています。また、各システムについて、10年との関連性の簡単な説明が示されています。

4.1. Amazon S3

Amazon S3 (Simple Storage Service) [6] provides an online storage service using Web (HTTP) interfaces. Users create buckets, and each bucket can contain stored objects. Users are provided an interface

Amazon S3（Simple Storage Service）[6]は、Web（HTTP）インターフェイスを使用してオンラインストレージサービスを提供しています。ユーザーはバケツを作成し、各バケットには保存されたオブジェクトを含めることができます。ユーザーにはインターフェイスが提供されます

through which they can manage their buckets. Amazon S3 is a popular backend storage service for other services. Other related storage services are the Blob Service provided by Windows Azure [7], Google Storage for Developers [8], and Dropbox [9].

彼らはバケツを管理することができます。Amazon S3は、他のサービスに人気のバックエンドストレージサービスです。その他の関連するストレージサービスは、Windows Azure [7]、開発者向けのGoogleストレージ[8]、およびDropbox [9]が提供するBLOBサービスです。

4.1.1. Applicability to DECADE

4.1.1. 10年への適用性

Amazon S3 is a very widely used (deployed) example of in-network storage. Amazon S3 leases the storage to third-party companies for disparate services. In particular, Amazon S3 has a rich model for authorization (using signed queries) to integrate with a wide variety of use cases. A focus for Amazon S3 is scalability. Particular simplifications that were made are the absence of a general, hierarchical namespace and the inability to update the contents of existing data.

Amazon S3は、ネットワーク内のストレージの非常に広く使用されている（展開された）例です。Amazon S3は、さまざまなサービスのためにサードパーティ企業にストレージをリースしています。特に、Amazon S3には、さまざまなユースケースと統合するための承認（署名済みクエリを使用）のための豊富なモデルがあります。Amazon S3の焦点はスケーラビリティです。作成された特定の単純化は、一般的な階層的な名前空間がないこと、および既存のデータの内容を更新できないことです。

4.1.2. Data Access Interface

4.1.2. データアクセスインターフェイス

Users can read and write objects.

ユーザーはオブジェクトを読み書きできます。

4.1.3. Data Management Operations

4.1.3. データ管理操作

Users can delete previously stored objects.

ユーザーは、以前に保存されたオブジェクトを削除できます。

4.1.4. Data Search Capability

4.1.4. データ検索機能

Users can list contents of buckets to find objects matching desired criteria.

ユーザーは、バケットのコンテンツをリストして、目的の基準に一致するオブジェクトを見つけることができます。

4.1.5. Access Control Authorization

4.1.5. アクセス制御承認

All methods of access control are supported for clients: public-unrestricted, public-restricted, and private.

アクセス制御のすべての方法は、クライアントにサポートされています：公共の領土、公共制限、プライベート。

For example, access to stored objects can be restricted by an owner, a list of other Amazon S3 Web Service users, or all Amazon S3 Web Service users; or can be open to all users (anonymous access). Another option is for the owner to generate and sign a query (e.g., a query to read an object) that can be used by any user until an owner-defined expiration time.

たとえば、保存されたオブジェクトへのアクセスは、所有者、他のAmazon S3 Webサービスユーザーのリスト、またはすべてのAmazon S3 Webサービスユーザーによって制限される可能性があります。または、すべてのユーザー（匿名アクセス）にオープンすることができます。別のオプションは、所有者がクエリ（オブジェクトを読み取るためのクエリなど）を生成して署名することです。

4.1.6. Resource Control Interface

4.1.6. リソース制御インターフェイス

Not provided.

提供されていない。

4.1.7. Discovery Mechanism

4.1.7. 発見メカニズム

Users are provided a well-known DNS name (either a default provided by Amazon S3, or one customized by a particular user). Users accessing S3 storage use DNS to discover an IP address where S3 requests can be sent.

ユーザーには、よく知られているDNS名が提供されます（Amazon S3が提供するデフォルト、または特定のユーザーによってカスタマイズされたデフォルト）。S3ストレージにアクセスするユーザーは、DNSを使用して、S3リクエストを送信できるIPアドレスを見つけます。

4.1.8. Storage Mode

4.1.8. ストレージモード

Object-based, with the extension that objects can be organized into user-defined buckets.

オブジェクトベースのオブジェクトを使用して、オブジェクトをユーザー定義のバケットに編成できます。

4.2. BranchCache

BranchCache [10] is a feature integrated into Windows (Windows 7 and Windows Server 2008R2) that aims to optimize enterprise branch office file access over WAN links. The main goals are to reduce WAN link utilization and improve application responsiveness by caching and sharing content within a branch while still maintaining end-to-end security. BranchCache allows files retrieved from the Web servers and file servers located in headquarters or data centers to be cached in remote branch offices, and shared among users in the same branch accessing the same content. BranchCache operates transparently by instrumenting the HTTP and Server Message Block (SMB) components of the networking stack. It provides two modes of operation: Distributed Cache and Hosted Cache.

BranchCache [10]は、WANリンクを介したエンタープライズブランチオフィスファイルアクセスを最適化することを目的とするWindows（Windows 7およびWindows Server 2008R2）に統合された機能です。主な目標は、エンドツーエンドのセキュリティを維持しながら、ブランチ内のコンテンツをキャッシュおよび共有することにより、WANリンクの使用率を削減し、アプリケーションの応答性を向上させることです。BranchCacheを使用すると、本部またはデータセンターにあるWebサーバーおよびファイルサーバーから取得されたファイルを使用して、リモートブランチオフィスにキャッシュされ、同じブランチのユーザー間で同じコンテンツにアクセスするユーザー間で共有できます。BranchCacheは、ネットワークスタックのHTTPおよびサーバーメッセージブロック（SMB）コンポーネントを計装することにより、透過的に操作します。分散キャッシュとホストキャッシュの2つの操作モードを提供します。

In both modes, a client always contacts a BranchCache-enabled content server first to get the content identifiers for local search. If the content is cached locally, the client then retrieves the content within the branch. Otherwise, the client will go back to the original content server to request the content. The two modes differ in how the content is shared.

両方のモードで、クライアントは常にBranchCache対応のコンテンツサーバーに連絡し、ローカル検索のコンテンツ識別子を取得します。コンテンツがローカルでキャッシュされている場合、クライアントはブランチ内のコンテンツを取得します。それ以外の場合、クライアントは元のコンテンツサーバーに戻ってコンテンツをリクエストします。2つのモードは、コンテンツの共有方法が異なります。

In the Hosted Cache mode, a locally provisioned server acts as a cache for files retrieved from the servers. After getting the content identifiers, the client first consults the cache for the desired file. If it is not present in the cache, the client retrieves it from the content server and sends it to the cache for storage.

ホストされたキャッシュモードでは、ローカルでプロビジョニングされたサーバーは、サーバーから取得されたファイルのキャッシュとして機能します。コンテンツ識別子を取得した後、クライアントは最初に目的のファイルについてキャッシュを相談します。キャッシュに存在しない場合、クライアントはコンテンツサーバーからそれを取得し、ストレージのためにキャッシュに送信します。

In the Distributed Cache mode, a client first queries other clients in the same network using the Web Services Discovery multicast protocol [11]. As in the Hosted Cache mode, the client retrieves the file from the content server if it is not available locally. After retrieving the file (either from another client or the content server), the client stores the file locally.

4.4. クラウドデータ管理インターフェイス

The Cloud Data Management Interface (CDMI) is a specification to access and manage cloud storage. CDMI is specified by the Storage Networking Industry Association (SNIA).

クラウドデータ管理インターフェイス（CDMI）は、クラウドストレージにアクセスして管理するための仕様です。CDMIは、ストレージネットワーキング産業協会（SNIA）によって指定されています。

CDMI is a functional interface that applications can use to create, retrieve, update, and delete data elements from the cloud. As part of this interface, the client will be able to discover the capabilities of the cloud storage offering and use this interface to manage containers and the data that is placed in them. In addition, metadata can be set on containers and their contained data elements through this interface [13].

CDMIは、アプリケーションがクラウドからデータ要素を作成、取得、更新、削除するために使用できる機能的なインターフェイスです。このインターフェイスの一部として、クライアントはクラウドストレージの提供の機能を発見し、このインターフェイスを使用してコンテナとそれらに配置されたデータを管理できます。さらに、メタデータは、このインターフェイス[13]を介してコンテナとその含まれたデータ要素に設定できます。

CDMI follows a traditional client-server model, and operates over an HTTP interface using the Representational State Transfer (REST) model. Similar to Amazon S3 buckets (see Section 4.1), users may create containers in which data objects may be stored. Even though data objects may be accessed via a user-defined name within a container, it is also possible to access data objects via a storage-defined Object ID, which is provided in the response upon creation of a data object.

CDMIは、従来のクライアントサーバーモデルに従い、表現状態転送（REST）モデルを使用してHTTPインターフェイスを操作します。Amazon S3バケット（セクション4.1を参照）と同様に、ユーザーはデータオブジェクトが保存される可能性のあるコンテナを作成する場合があります。データオブジェクトは、コンテナ内のユーザー定義の名前を介してアクセスできますが、データオブジェクトの作成時に応答で提供されるストレージ定義オブジェクトIDを介してデータオブジェクトにアクセスすることもできます。

4.4.1. Applicability to DECADE

4.4.1. 10年への適用性

CDMI is an important initiative to standardize storage interfaces for cloud services, which are rapidly becoming an important type of storage service. In particular, it specifies a set of operations for creating, reading, writing, and managing data objects at a remote server (or set of servers) via HTTP.

CDMIは、クラウドサービスのストレージインターフェイスを標準化するための重要なイニシアチブであり、急速に重要なタイプのストレージサービスになりつつあります。特に、HTTPを介してリモートサーバー（またはサーバーのセット）でデータオブジェクトを作成、読み取り、書き込み、および管理するための一連の操作を指定します。

4.4.2. Data Access Interface

4.4.2. データアクセスインターフェイス

Users can read and write data objects, and also update data in existing data objects. CDMI data objects are sent on the wire embedded as a field in a JavaScript Object Notation (JSON) object. The protocol also defines interfaces in which the contents of data objects can be written via simple HTTP GET/PUT operations.

ユーザーは、データオブジェクトを読み取り、書き込み、既存のデータオブジェクトのデータを更新できます。CDMIデータオブジェクトは、JavaScriptオブジェクト表記（JSON）オブジェクトのフィールドとして埋め込まれたワイヤーに送信されます。プロトコルは、データオブジェクトの内容を単純なHTTP get/put操作を介して記述できるインターフェイスも定義します。

4.4.3. Data Management Operations

4.4.3. データ管理操作

Users can delete already-existing data objects. The create operation also supports modes in which the created object is copied or moved from an existing data object.

ユーザーは、既存のデータオブジェクトを削除できます。作成操作は、作成されたオブジェクトが既存のデータオブジェクトからコピーまたは移動されるモードもサポートします。

Data system metadata also allows users to configure policies regarding time-to-live, after which a data object is automatically deleted, as well as the redundancy with which a data object is stored.

また、データシステムメタデータを使用すると、ユーザーは時間の時間に関するポリシーを構成することもできます。その後、データオブジェクトが自動的に削除され、データオブジェクトが保存される冗長性が削除されます。

4.4.4. Data Search Capability

4.4.4. データ検索機能

Users may list the contents of containers to locate data objects matching any desired criteria.

ユーザーは、コンテナの内容をリストして、目的の基準に一致するデータオブジェクトを見つけることができます。

4.4.5. Access Control Authorization

4.4.5. アクセス制御承認

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private.

クライアントのアクセス制御のすべての方法がサポートされています：公共の領土、公共制限、プライベート。

In particular, CDMI allows access to data objects to be protected by Access Control Lists (ACLs) that can allow or restrict access based on user name, group, administrative status, or whether a user is authenticated or anonymous.

特に、CDMIでは、ユーザー名、グループ、管理ステータス、またはユーザーが認証されているか匿名であるかに基づいてアクセスを許可または制限できるアクセス制御リスト（ACL）によってデータオブジェクトへのアクセスを保護できます。

4.4.6. Resource Control Interface

4.4.6. リソース制御インターフェイス

CDMI supports attributes 'cdmi_max_latency' and 'cdmi_max_throughput' (set at either the level of containers, or a specific data object), which control the level of service offered to any users accessing a particular data object.

CDMIは、特定のデータオブジェクトにアクセスするユーザーに提供されるサービスレベルを制御する属性「CDMI_MAX_LATENCY」および「CDMI_MAX_THROULPPUT」（コンテナのレベルまたは特定のデータオブジェクトのいずれかに設定）をサポートしています。

4.4.7. Discovery Mechanism

4.4.7. 発見メカニズム

Users are provided a well-known DNS name. The DNS name is resolved to determine the IP address to which requests may be sent.

ユーザーにはよく知られているDNS名が提供されます。DNS名は、リクエストが送信される可能性のあるIPアドレスを決定するために解決されます。

4.4.8. Storage Mode

4.4.8. ストレージモード

Object-based, with the extension that objects can be organized into user-defined containers.

オブジェクトベースのオブジェクトを使用して、オブジェクトをユーザー定義のコンテナに編成できます。

4.5. Content Delivery Network

4.5. コンテンツ配信ネットワーク

A CDN provides services that improve performance by minimizing the amount of data transmitted through the network, improving accessibility, and maintaining correctness through content replication. CDNs offer fast and reliable applications and services by distributing content to cache or edge servers located close to users. See [14] for an additional taxonomy and survey.

CDNは、ネットワークを介して送信されるデータの量を最小限に抑え、アクセシビリティを改善し、コンテンツの複製を介して正確性を維持することにより、パフォーマンスを改善するサービスを提供します。CDNは、ユーザーの近くにあるキャッシュまたはエッジサーバーにコンテンツを配布することにより、高速で信頼できるアプリケーションとサービスを提供します。追加の分類法と調査については、[14]を参照してください。

A CDN has some combination of content delivery, request routing, distribution, and accounting infrastructures. The content-delivery infrastructure consists of a set of edge servers (also called surrogates) that deliver copies of content to end users. The request-routing infrastructure is responsible for directing client requests to appropriate edge servers. It also interacts with the distribution infrastructure to keep an up-to-date view of the content stored in the CDN caches. The distribution infrastructure moves content from the origin server to the CDN edge servers and ensures consistency of content in the caches. The accounting infrastructure maintains logs of client accesses and records the usage of the CDN servers. This information is used for traffic reporting and usage-based billing.

CDNには、コンテンツ配信、リクエストルーティング、流通、会計インフラストラクチャの組み合わせがあります。コンテンツ配信インフラストラクチャは、エンドユーザーにコンテンツのコピーを配信する一連のエッジサーバー（代理人とも呼ばれます）で構成されています。リクエストルーティングインフラストラクチャは、クライアントリクエストを適切なエッジサーバーに指示する責任があります。また、Distribution Infrastructureと対話して、CDNキャッシュに保存されているコンテンツの最新ビューを維持します。分布インフラストラクチャは、Origin ServerからCDN Edgeサーバーにコンテンツを移動し、キャッシュ内のコンテンツの一貫性を保証します。会計インフラストラクチャは、クライアントアクセスのログを維持し、CDNサーバーの使用を記録します。この情報は、トラフィックレポートと使用法ベースの請求に使用されます。

In practice, a CDN typically hosts static content including images, video, media clips, advertisements, and other embedded objects for Web viewing. A focus for CDNs is the ability to publish and deliver content to end users in a reliable and timely manner. A CDN focuses on building its network infrastructure to provide the following services and functionalities: storage and management of content; distribution of content among surrogates; cache management; delivery of static, dynamic, and streaming content; backup and disaster recovery solutions; and monitoring, performance measurement, and reporting.

実際には、CDNは通常、画像、ビデオ、メディアクリップ、広告、その他の組み込みオブジェクトなどの静的コンテンツをホストします。CDNSの焦点は、信頼できるタイムリーな方法でエンドユーザーにコンテンツを公開および配信できることです。CDNは、ネットワークインフラストラクチャの構築に焦点を当て、次のサービスと機能を提供します。コンテンツのストレージと管理。代理人間のコンテンツの分布。キャッシュ管理。静的、動的、およびストリーミングコンテンツの配信。バックアップおよび災害復旧ソリューション。監視、パフォーマンス測定、およびレポート。

Examples of existing CDNs are Akamai, Limelight, and CloudFront.

既存のCDNの例は、Akamai、Limelight、およびCloudFrontです。

The following description uses the term "content provider" to refer to the entity purchasing a CDN service, and the term "client" to refer to the subscriber requesting content via the CDN from the content provider.

次の説明では、「コンテンツプロバイダー」という用語を使用して、CDNサービスを購入するエンティティと「クライアント」という用語を参照して、コンテンツプロバイダーからCDNを介してコンテンツを要求するサブスクライバーを参照します。

4.5.1. Applicability to DECADE

4.5.1. 10年への適用性

CDNs are a very widely used (deployed) example of in-network storage for multimedia content. The existence and operation of the storage system are totally transparent to the end user. CDNs typically require a strong business relationship between the content providers and content distributors, and often the business relationship extends to the ISPs.

CDNは、マルチメディアコンテンツのネットワーク内ストレージの非常に広く使用されている（展開された）例です。ストレージシステムの存在と動作は、エンドユーザーに対して完全に透過的です。通常、CDNにはコンテンツプロバイダーとコンテンツディストリビューターとの間の強力なビジネス関係が必要であり、多くの場合、ビジネス関係はISPにまで及びます。

4.5.2. Data Access Interface

4.5.2. データアクセスインターフェイス

A CDN is typically a closed system, and generally provides only a read (retrieve) access interface to clients. A CDN typically does not provide a write (store) access interface to clients. The content provider can access network edge servers and store content on them, or edge servers can retrieve content from content providers. Client nodes can only retrieve content from edge servers.

通常、CDNは閉じたシステムであり、通常、クライアントに読み取り（取得）アクセスインターフェイスのみを提供します。通常、CDNはクライアントに書き込み（ストア）アクセスインターフェイスを提供しません。コンテンツプロバイダーは、ネットワークエッジサーバーにアクセスしてコンテンツを保存するか、エッジサーバーがコンテンツプロバイダーからコンテンツを取得できます。クライアントノードは、エッジサーバーからコンテンツのみを取得できます。

4.5.3. Data Management Operations

4.5.3. データ管理操作

A content provider can manage the data distributed in different cache nodes, such as moving popular data objects from one cache node to another cache node, or deleting rarely accessed data objects in cache nodes. User nodes, however, have no right to perform these operations.

コンテンツプロバイダーは、人気のあるデータオブジェクトをあるキャッシュノードから別のキャッシュノードに移動したり、キャッシュノードではめったにアクセスされないデータオブジェクトを削除したりするなど、さまざまなキャッシュノードで配布されたデータを管理できます。ただし、ユーザーノードには、これらの操作を実行する権利はありません。

4.5.4. Data Search Capability

4.5.4. データ検索機能

A content provider can search or enumerate the data each cache node stores. User nodes cannot perform search operations.

コンテンツプロバイダーは、各キャッシュノードが保存するデータを検索または列挙できます。ユーザーノードは検索操作を実行できません。

4.5.5. Access Control Authorization

4.5.5. アクセス制御承認

All methods of access control (for reading) are supported for clients: public-unrestricted, public-restricted, and private. Some CDN edge servers allow usage of HTTP basic authentication with the origin server or restrictions by IP address, or they can use a token-based technique to allow the origin server to apply its own authorization criteria.

アクセス制御のすべての方法（読書用）は、クライアントにサポートされています：公共の領土、公共制限、プライベート。一部のCDNエッジサーバーでは、Origin ServerまたはIPアドレスによる制限を使用したHTTP Basic認証の使用を可能にします。または、トークンベースの手法を使用してOrigin Serverが独自の認証基準を適用できるようにすることができます。

As mentioned previously, clients typically cannot write to the CDN. Writing is typically a private operation for the content providers.

前述のように、クライアントは通常、CDNに書き込むことができません。執筆は通常、コンテンツプロバイダーのプライベート操作です。

4.5.6. Resource Control Interface

4.5.6. リソース制御インターフェイス

Not provided.

提供されていない。

4.5.7. Discovery Mechanism

4.5.7. 発見メカニズム

Content providers can directly find internal CDN cache nodes to store content, since they typically have an explicit business relationship. Clients can locate CDN nodes through DNS or other redirection mechanisms.

コンテンツプロバイダーは、通常、明示的なビジネス関係を持っているため、コンテンツを保存するための内部CDNキャッシュノードを直接見つけることができます。クライアントは、DNSまたは他のリダイレクトメカニズムを介してCDNノードを見つけることができます。

4.5.8. Storage Mode

4.5.8. ストレージモード

Though the addressing of objects uses URLs that typically refer to objects in a hierarchical fashion, the storage mode is typically object-based.

オブジェクトのアドレス指定は、通常、階層的な方法でオブジェクトを指すURLを使用しますが、ストレージモードは通常、オブジェクトベースです。

4.6. Delay-Tolerant Network

4.6. 遅延耐性ネットワーク

The Delay-Tolerant Network (DTN) [15] is an evolution of an architecture originally designed for the Interplanetary Internet. The Interplanetary Internet is a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. The DTN architecture can be utilized in various operational environments characterized by severe communication disruptions, disconnections, and high delays (e.g., a month-long loss of connectivity between two planetary networks because of high solar radiation due to sun spots). The DTN architecture is thus suitable for environments including deep space networks, sensor-based networks, certain satellite networks, and underwater acoustic networks.

遅延耐性ネットワーク（DTN）[15]は、惑星間インターネット向けに設計されたアーキテクチャの進化です。惑星間インターネットは、ディープスペース探査をサポートする惑星間距離全体でインターネットのようなサービスを提供することを想定している通信システムです。DTNアーキテクチャは、深刻なコミュニケーションの混乱、切断、および高い遅延を特徴とするさまざまな運用環境で利用できます（たとえば、太陽スポットによる太陽放射のために2つの惑星ネットワーク間で1か月にわたる接続性の損失）。したがって、DTNアーキテクチャは、ディープスペースネットワーク、センサーベースのネットワーク、特定の衛星ネットワーク、水中音響ネットワークなどの環境に適しています。

A key aspect of the DTN is a store-and-forward overlay layer called the "Bundle Protocol" or "Bundle Layer", which exists between the transport and application layers [16]. The Bundle Layer forms a logical overlay that employs persistent storage to help combat long-term network interruptions by providing a store-and-forward service. While traditional IP networks are also based on store-and-forward principles, the amount of time of a packet being kept in "storage" at a traditional IP router is typically on the order of milliseconds (or less). In contrast, the DTN architecture assumes that most Bundle Layer nodes will use some form of persistent storage (e.g., hard disk, flash memory, etc.) for DTN packets because of the nature of the DTN environment.

DTNの重要な側面は、「バンドルプロトコル」または「バンドルレイヤー」と呼ばれるストアアンドフォワードオーバーレイレイヤーで、輸送層とアプリケーション層の間に存在します[16]。バンドルレイヤーは、ストアアンドフォワードサービスを提供することにより、長期的なネットワーク中断と戦うのに役立つ永続的なストレージを使用する論理オーバーレイを形成します。従来のIPネットワークは、ストアアンドフォワードの原則にも基づいていますが、従来のIPルーターで「ストレージ」に保持されるパケットの時間の量は、通常、ミリ秒（またはそれ以下）にあります。対照的に、DTNアーキテクチャは、DTN環境の性質のため、ほとんどのバンドルレイヤーノードがDTNパケットに何らかの形の永続的なストレージ（ハードディスク、フラッシュメモリなど）を使用すると想定しています。

4.6.1. Applicability to DECADE

4.6.1. 10年への適用性

The DTN is an example of an experimental in-network storage system that would require fundamental changes to the Internet protocols.

DTNは、インターネットプロトコルの根本的な変更を必要とする実験的なネットワークストレージシステムの例です。

4.6.2. Data Access Interface

4.6.2. データアクセスインターフェイス

Users implicitly cause content to be stored (until successfully forwarded) at Bundle Layer nodes by initiating/terminating any transaction that traverses the DTN.

ユーザーは、DTNを横断するトランザクションを開始/終了することにより、バンドルレイヤーノードにコンテンツを（正常に転送するまで）暗黙的に保存します。

4.6.3. Data Management Operations

4.6.3. データ管理操作

Users can implicitly cause deletion of content stored at Bundle Layer nodes via a "time-to-live" type of parameter that the user can control (for transactions originating from the user).

ユーザーは、ユーザーが制御できる「時間から寿命までの」タイプのパラメーターを介して、バンドルレイヤーノードに保存されたコンテンツの削除を暗黙的に引き起こすことができます（ユーザーからのトランザクションの場合）。

4.6.4. Data Search Capability

4.6.4. データ検索機能

Not provided.

提供されていない。

4.6.5. Access Control Authorization

4.6.5. アクセス制御承認

The access control method is public-restricted (to any client that is part of the DTN) or private.

アクセス制御方法は、（DTNの一部であるクライアントに）公開されているか、プライベートです。

4.6.6. Resource Control Interface

4.6.6. リソース制御インターフェイス

Not provided.

提供されていない。

4.6.7. Discovery Mechanism

4.6.7. 発見メカニズム

A Uniform Resource Identifier (URI) approach is used as the basis of the addressing scheme for DTN transactions (and subsequent store-and-forward routing through the DTN network).

均一なリソース識別子（URI）アプローチは、DTNトランザクションのアドレス指定スキームの基礎として使用されます（およびDTNネットワークを介した後続のストアアンドフォワードルーティング）。

4.6.8. Storage Mode

4.6.8. ストレージモード

Object-based. DTN applications send data to the Bundle Layer, which then breaks the data into segments. These segments are then routed through the DTN network, and stored in Bundle Layer nodes as required (before being forwarded).

オブジェクトベース。DTNアプリケーションは、データをバンドルレイヤーに送信し、データをセグメントに分割します。これらのセグメントは、DTNネットワークを介してルーティングされ、必要に応じてバンドル層ノードに保存されます（転送される前に）。

4.7. Named Data Networking

4.7. 名前付きデータネットワーキング

Named Data Networking (NDN) [17] is a research initiative that proposes to move to a new model of addressing and routing for the Internet. NDN uses "named data"-based routing and forwarding, to replace the current IP-address-based model. NDN also uses name-based data caching in the routers.

名前付きデータネットワーキング（NDN）[17]は、インターネットのアドレス指定とルーティングの新しいモデルに移行することを提案する研究イニシアチブです。NDNは、「名前付きデータ」ベースのルーティングと転送を使用して、現在のIPアドレスベースのモデルを置き換えます。NDNは、ルーターでの名前ベースのデータキャッシュも使用します。

Each NDN Data packet will be assigned a content name and will be cryptographically signed. Data delivery is driven by the requesting end. Routers disseminate name-based prefix announcements by using routing protocols such as Intermediate System to Intermediate System (IS-IS) or the Border Gateway Protocol (BGP). The requester will send out an "Interest" packet, which identifies the name of the data that it wants. Routers that receive this Interest packet will remember the interface it came from and will then forward it on a name-based routing protocol. Once an Interest packet reaches a node that has the desired data, a named Data packet is sent back, which carries both the name and content of the data, along with a digital signature of the producer. This named Data packet is then forwarded back to the original requester on the reverse path of the Interest packet [18].

各NDNデータパケットにはコンテンツ名が割り当てられ、暗号化されて署名されます。データ配信は、要求の終わりによって駆動されます。ルーターは、中間システムなどのルーティングプロトコルを使用して、中間システム（IS-IS）または境界ゲートウェイプロトコル（BGP）を使用して、名前ベースのプレフィックスアナウンスを広めます。リクエスターは、「利息」パケットを送信します。これは、必要なデータの名前を識別します。この関心のあるパケットを受け取るルーターは、それが来たインターフェイスを覚えており、その後、名前ベースのルーティングプロトコルでそれを転送します。目的パケットが目的のデータを持つノードに到達すると、名前付きデータパケットが送信され、データの名前とコンテンツの両方がプロデューサーのデジタル署名とともに送信されます。この名前付きデータパケットは、関心パケットの逆パスで元のリクエスターに転送されます[18]。

A key aspect of NDN is that routers have the capability to cache the named data. If a request for the same data (i.e., same name) comes to the router, then the NDN router will forward the named data stored locally to fulfill the request. The proponents of NDN believe that the network can be designed naturally, matching data delivery characteristics instead of communication between endpoints, because data delivery has become the primary use of the network.

NDNの重要な側面は、ルーターが指定されたデータをキャッシュする機能を備えていることです。同じデータ（つまり、同じ名前）のリクエストがルーターに届くと、NDNルーターは、リクエストを満たすためにローカルに保存されている指名されたデータを転送します。NDNの支持者は、データ提供がネットワークの主要な使用になっているため、エンドポイント間の通信ではなくデータ配信特性を一致させるネットワークを自然に設計できると考えています。

4.7.1. Applicability to DECADE

4.7.1. 10年への適用性

NDN is an example of an experimental in-network storage system that would require storage space on a large number of routers in the Internet. Named Data packets would be kept in storage in the NDN routers and provided to new requesters of the same data.

NDNは、インターネット内の多数のルーターのストレージスペースを必要とする実験的なネットワークストレージシステムの例です。名前付きデータパケットは、NDNルーターにストレージに保持され、同じデータの新しい要求者に提供されます。

4.7.2. Data Access Interface

4.7.2. データアクセスインターフェイス

Users implicitly store content at NDN routers by requesting content (the named Data packets) from the network. Subsequent requests by different users for the same content will cause the named Data packets to be read from the NDN routers' in-network storage.

ユーザーは、ネットワークからコンテンツ（名前付きデータパケット）を要求することにより、NDNルーターにコンテンツを暗黙的に保存します。同じコンテンツに対して異なるユーザーによるその後のリクエストにより、指名されたデータパケットがNDNルーターのネットワーク内ストレージから読み取られます。

4.7.3. Data Management Operations

4.7.3. データ管理操作

Users do not have the direct ability to delete content stored in the NDN routers. However, there will be some type of time-to-live parameter associated with the named Data packets, though this has not yet been specified.

ユーザーは、NDNルーターに保存されているコンテンツを削除する直接的な機能を持っていません。ただし、指定されたデータパケットに関連付けられたタイプの時間パラメーターがありますが、これはまだ指定されていません。

4.7.4. Data Search Capability

4.7.4. データ検索機能

Not provided.

提供されていない。

4.7.5. Access Control Authorization

4.7.5. アクセス制御承認

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private.

クライアントのアクセス制御のすべての方法がサポートされています：公共の領土、公共制限、プライベート。

The basic security mechanism in NDN is for the sender to digitally sign the content (the named Data packets) that it sends. It is envisioned that a complete access control system can be built on top of NDN, though this has not yet been specified.

NDNの基本的なセキュリティメカニズムは、送信者が送信するコンテンツ（指定されたデータパケット）にデジタル的に署名することです。NDNの上に完全なアクセス制御システムを構築できることは想定されていますが、これはまだ指定されていません。

4.7.6. Resource Control Interface

4.7.6. リソース制御インターフェイス

Not provided.

提供されていない。

4.7.7. Discovery Mechanism

4.7.7. 発見メカニズム

Names are used as the basis of the addressing and discovery scheme for NDN (and subsequent store-and-forward routing through the NDN network). NDN names are assumed to be hierarchical and to be able to be deterministically constructed. This is still an active area of research.

名前は、NDNのアドレス指定および発見スキームの基礎として使用されます（およびNDNネットワークを介したその後のストアアンドフォワードルーティング）。NDN名は階層的であり、決定論的に構築できると想定されています。これは依然として研究の積極的な分野です。

4.7.8. Storage Mode

4.7.8. ストレージモード

Object-based. NDN sends named Data packets through the network. These Data packets are routed through the NDN network and stored in NDN routers.

オブジェクトベース。NDNは、ネットワークを介して名前のデータパケットを送信します。これらのデータパケットは、NDNネットワークを介してルーティングされ、NDNルーターに保存されます。

4.8. Network of Information

4.8. 情報のネットワーク

Similar to NDN (see Section 4.7), Network of Information (NetInf) [19] is another information-centric approach in which the named data objects are the basic component of the networking architecture. NetInf is thus moving away from today's host-centric networking

NDN（セクション4.7を参照）と同様に、情報のネットワーク（NetInf）[19]は、指定されたデータオブジェクトがネットワーキングアーキテクチャの基本コンポーネントである別の情報中心のアプローチです。したがって、NetInfは今日のホスト中心のネットワーキングから離れています

architecture where the nodes in the network are the primary objects. In today's network, the information objects are named relative to the hosts they are stored on (e.g., http://www.example.com/information-object.txt).

ネットワーク内のノードが主要なオブジェクトであるアーキテクチャ。今日のネットワークでは、情報オブジェクトは、保存されているホスト（例：http://www.example.com/information-object.txtなど）に関連しています。

The NetInf naming and security framework builds the foundation for an information-centric security model that integrates security deeply into the architecture. In this model, trust is based on the information itself. Information objects (IOs) are given a unique name with cryptographic properties. Together with additional metadata, the name can be used to verify the data integrity as well as several other security properties, such as self-certification, name persistency, and owner authentication and identification. The approach also gives some benefits over the security model in today's host-centric networks, as it minimizes the need for trust in the infrastructure, including the hosts providing the data, the channel, or the resolution service.

NetInfの命名とセキュリティフレームワークは、セキュリティをアーキテクチャに深く統合する情報中心のセキュリティモデルの基盤を構築します。このモデルでは、信頼は情報自体に基づいています。情報オブジェクト（iOS）には、暗号化プロパティを備えた一意の名前が付けられています。追加のメタデータとともに、この名前を使用して、データの整合性と、自己認証、名前の永続性、所有者の認証と識別など、他のいくつかのセキュリティプロパティを検証できます。また、このアプローチは、データ、チャネル、または解像度サービスを提供するホストを含むインフラストラクチャへの信頼の必要性を最小限に抑えるため、今日のホスト中心のネットワークのセキュリティモデルにいくつかの利点をもたらします。

In NetInf, the information objects are published into the network. They are registered with a Name Resolution Service (NRS). The NRS is also used to register network locators that can be used to retrieve data objects that represent the published IOs. When a receiver wants to retrieve an IO, the request for the IO is resolved by the NRS into a set of locators. These locators are then used to retrieve a copy of the data object from the "best" available source(s). NetInf is open to use any type of underlying transport network. The locators can thus be a heterogeneous set, e.g., IPv4, IPv6, Medium Access Control (MAC), etc.

NetInfでは、情報オブジェクトがネットワークに公開されます。それらは、名前解像度サービス（NRS）に登録されています。NRSは、公開されているiOSを表すデータオブジェクトを取得するために使用できるネットワークロケーターの登録にも使用されます。受信者がIOを取得したい場合、IOの要求はNRSによってロケーターのセットに解決されます。これらのロケーターは、「最適な」利用可能なソースからデータオブジェクトのコピーを取得するために使用されます。NetInfは、あらゆるタイプの基礎となる輸送ネットワークを使用することができます。したがって、ロケーターは、IPv4、IPv6、Medium Access Control（MAC）など、不均一なセットになります。

NetInf will make extensive use of caching of information objects in the network and will provide network functionality that is similar to what overlay solutions such as CDNs and P2P distribution networks (e.g., BitTorrent) provide today.

NetInfは、ネットワーク内の情報オブジェクトのキャッシングを広範囲に使用し、CDNSやP2Pディストリビューションネットワーク（BitTorrentなど）などのオーバーレイソリューション（BitTorrentなど）が今日提供するものと同様のネットワーク機能を提供します。

4.8.1. Applicability to DECADE

4.8.1. 10年への適用性

NetInf is an example of an experimental information-centric network architecture that will require storage space for storage and caching of information objects on a large number of NetInf nodes in the Internet.

NetInfは、インターネット内の多数のNetINFノードで情報オブジェクトのストレージとキャッシュのためのストレージスペースを必要とする実験的な情報中心のネットワークアーキテクチャの例です。

4.8.2. Data Access Interface

4.8.2. データアクセスインターフェイス

Users will publish IOs with specific IDs into the network. This is done by the client sending a register message to the NRS stating that the IO with the specific ID is available. When another user wishes to retrieve the IO, they will use the given ID to make a request for the IO. The ID is then resolved by the NRS, and the IO is delivered from a nearby in-network storage location.

ユーザーは、特定のIDを持つiOSをネットワークに公開します。これは、特定のIDを含むIOが利用可能であることを示すNRSにレジスタメッセージを送信するクライアントによって行われます。別のユーザーがIOを取得したい場合、指定されたIDを使用してIOをリクエストします。その後、IDはNRSによって解決され、IOは近くのネットワーク内のストレージ場所から配信されます。

4.8.3. Data Management Operations

4.8.3. データ管理操作

Users do not have the direct ability to delete content stored in the NetInf nodes. However, there can be some type of time-to-live parameter associated with the information objects, though this has not yet been specified.

ユーザーは、NetInfノードに保存されているコンテンツを削除する直接的な機能を持っていません。ただし、情報オブジェクトに関連付けられた時間のパラメーターのタイプがある場合がありますが、これはまだ指定されていません。

4.8.4. Data Search Capability

4.8.4. データ検索機能

Not provided.

提供されていない。

4.8.5. Access Control Authorization

4.8.5. アクセス制御承認

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private. The basic security mechanism in NetInf is for the publisher to digitally sign the content of the information object that it publishes. It is envisioned that a complete access control system can be built on top of NetInf, though this has not yet been specified.

クライアントのアクセス制御のすべての方法がサポートされています：公共の領土、公共制限、プライベート。NetInfの基本的なセキュリティメカニズムは、パブリッシャーが公開する情報オブジェクトのコンテンツをデジタル的に署名することです。これはまだ指定されていませんが、NetInfの上に完全なアクセス制御システムを構築できることが想定されています。

4.8.6. Resource Control Interface

4.8.6. リソース制御インターフェイス

Not provided.

提供されていない。

4.8.7. Discovery Mechanism

4.8.7. 発見メカニズム

NetInf IDs are used for naming and accessing information objects. The IDs are resolved by the NRS into locators that are used for routing and transport of data through the transport networks. This is still an active area of research.

NetInf IDは、情報オブジェクトへの名前の命名とアクセスに使用されます。IDは、NRSによって、輸送ネットワークを介したデータのルーティングと輸送に使用されるロケーターに解決されます。これは依然として研究の積極的な分野です。

4.8.8. Storage Mode

4.8.8. ストレージモード

Object-based. From an application perspective, NetInf can be used for publishing entire files or chunks of files. NetInf is agnostic to the application perspective and treats everything as information objects.

オブジェクトベース。アプリケーションの観点から、NetInfはファイル全体またはファイルのチャンクを公開するために使用できます。NetInfはアプリケーションの観点に不可知論され、すべてを情報オブジェクトとして扱います。

4.9. Network Traffic Redundancy Elimination

4.9. ネットワークトラフィックの冗長性の排除

Redundancy Elimination (RE) is used for identifying and removing repeated content from network transfers. This technique has been proposed to improve network performance in many types of networks, such as ISP backbones and enterprise access links. One example of an RE proposal is SmartRE [20], proposed by Anand et al., which focuses on network-wide RE. In packet-level RE, forwarding elements are equipped with additional storage that can be used to cache data from forwarded packets. Upstream routers may replace packet data with a fingerprint that tells a downstream router how to decode and reconstruct the packet based on cached data.

冗長性除去（RE）は、ネットワーク転送から繰り返しコンテンツを識別および削除するために使用されます。この手法は、ISPバックボーンやエンタープライズアクセスリンクなど、多くのタイプのネットワークでネットワークパフォーマンスを改善するために提案されています。RE提案の1つの例は、Anand et al。によって提案されたSmartre [20]です。パケットレベルのREでは、転送要素には、転送されたパケットからのデータのキャッシュに使用できる追加のストレージが装備されています。上流のルーターは、キャッシュされたデータに基づいてパケットをデコードして再構築する方法を下流のルーターに伝える指紋にパケットデータを置き換える場合があります。

4.9.1. Applicability to DECADE

4.9.1. 10年への適用性

RE is an example of an experimental in-network storage system that would require a large amount of associated packet processing at routers if it was ever deployed.

REは、ルーターが展開された場合に大量の関連パケット処理を必要とする実験的なネットワーク内のストレージシステムの例です。

4.9.2. Data Access Interface

4.9.2. データアクセスインターフェイス

RE is typically transparent to the user. Writing into storage is done by transferring data that has not already been cached. Storage is read when users transmit data identical to previously transmitted data.

REは通常、ユーザーに対して透過的です。ストレージへの書き込みは、まだキャッシュされていないデータを転送することによって行われます。ストレージは、ユーザーが以前に送信されたデータと同じデータを送信するときに読み取られます。

4.9.3. Data Management Operations

4.9.3. データ管理操作

Not provided.

提供されていない。

4.9.4. Data Search Capability

4.9.4. データ検索機能

Not provided.

提供されていない。

4.9.5. Access Control Authorization

4.9.5. アクセス制御承認

The access control method is public-restricted (to any client that is part of the RE network). Note that the content provider still retains control over which peers receive the requested data. The returned data is "compressed" as it is transferred within the network.

アクセス制御方法は公開されています（REネットワークの一部であるクライアントにとって）。コンテンツプロバイダーは、どのピアが要求されたデータを受信するかについての制御を引き続き保持していることに注意してください。返されたデータは、ネットワーク内で転送されるため、「圧縮」されます。

4.9.6. Resource Control Interface

4.9.6. リソース制御インターフェイス

Not provided. The content provider still retains control over the rate at which packets are sent to a peer. The packet size within the network may be reduced.

提供されていない。コンテンツプロバイダーは、パケットがピアに送信されるレートの制御を保持しています。ネットワーク内のパケットサイズが縮小される場合があります。

4.9.7. Discovery Mechanism

4.9.7. 発見メカニズム

No discovery mechanism is necessary. Routers can use RE without the users' knowledge.

発見メカニズムは必要ありません。ルーターは、ユーザーの知識なしでREを使用できます。

4.9.8. Storage Mode

4.9.8. ストレージモード

Object-based, with "objects" being data from packets transmitted within the network.

オブジェクトベース。「オブジェクト」は、ネットワーク内で送信されるパケットからのデータです。

4.10. OceanStore

4.10. オーシャンストア

OceanStore [21] is a storage platform developed at the University of California, Berkeley, that provides globally distributed storage. OceanStore implements a model where multiple storage providers can pool resources together. Thus, a major focus is on resiliency, self-organization, and self-maintenance.

OceanStore [21]は、カリフォルニア大学バークレー校で開発されたストレージプラットフォームで、世界的に分散したストレージを提供しています。OceanStoreは、複数のストレージプロバイダーがリソースを一緒にプールできるモデルを実装しています。したがって、主要な焦点は、回復力、自己組織化、および自己メンテナンスにあります。

The protocol is resilient to some storage nodes being compromised by utilizing Byzantine agreement and erasure codes to store data at primary replicas.

このプロトコルは、ビザンチンの合意と消去コードを利用してプライマリレプリカにデータを保存することにより、一部のストレージノードが侵害されているために回復力があります。

4.10.1. Applicability to DECADE

4.10.1. 10年への適用性

OceanStore is an example of an experimental in-network storage system that provides a high degree of network resilience to failure scenarios.

OceanStoreは、障害シナリオに対する高度なネットワークの回復力を提供する実験的なネットワークストレージシステムの例です。

4.10.2. Data Access Interface

4.10.2. データアクセスインターフェイス

Users may read and write objects.

ユーザーはオブジェクトを読み書きすることができます。

4.10.3. Data Management Operations

4.10.3. データ管理操作

Objects may be replaced by newer versions, and multiple versions of an object may be maintained.

オブジェクトは新しいバージョンに置き換えられ、オブジェクトの複数のバージョンが維持される場合があります。

4.10.4. Data Search Capability

4.10.4. データ検索機能

Not provided.

提供されていない。

4.10.5. Access Control Authorization

4.10.5. アクセス制御承認

Provided, but specifics for clients are unclear from the available references.

提供されますが、クライアントの詳細は利用可能な参照から不明です。

4.10.6. Resource Control Interface

4.10.6. リソース制御インターフェイス

Not provided.

提供されていない。

4.10.7. Discovery Mechanism

4.10.7. 発見メカニズム

Users require an entry point into the system in the form of one storage node that is part of OceanStore. If a hostname is provided, the address of a storage node may be determined via DNS.

ユーザーは、オーシャンストアの一部である1つのストレージノードの形でシステムへのエントリポイントを必要とします。ホスト名が提供されている場合、ストレージノードのアドレスがDNSを介して決定される場合があります。

4.10.8. Storage Mode

4.10.8. ストレージモード

Object-based.

オブジェクトベース。

4.11. P2P Cache

4.11. P2Pキャッシュ

Caching of P2P traffic is a useful approach to reduce P2P network traffic, because objects in P2P systems are mostly immutable and the traffic is highly repetitive. In addition, making use of P2P caches does not require changes to P2P protocols and can be deployed transparently from clients.

P2Pシステムのオブジェクトはほとんど不変であり、トラフィックが非常に反復的であるため、P2PトラフィックのキャッシュはP2Pネットワークトラフィックを減らすための有用なアプローチです。さらに、P2Pキャッシュを使用しても、P2Pプロトコルの変更は必要ありません。クライアントから透過的に展開できます。

P2P caches operate similarly to Web caches (Section 4.14) in that they temporarily store frequently requested content. Requests for content already stored in the cache can be served from local storage instead of requiring the data to be transmitted over expensive network links.

P2Pキャッシュは、頻繁に要求されたコンテンツを一時的に保存するという点で、Webキャッシュ（セクション4.14）と同様に動作します。キャッシュに既に保存されているコンテンツのリクエストは、高価なネットワークリンクを介してデータを送信する必要がある代わりに、ローカルストレージから提供できます。

Two types of P2P caches exist: transparent P2P caches and non-transparent P2P caches.

2種類のP2Pキャッシュが存在します：透明なP2Pキャッシュと非透明P2Pキャッシュ。

For a transparent cache, once a P2P cache is established, the network will transparently redirect P2P traffic to the cache, which either serves the file directly or passes the request on to a remote P2P user and simultaneously caches that data. Transparency is typically implemented using Deep Packet Inspection (DPI). DPI products identify and pass P2P packets to the P2P caching system so it can cache and accelerate the traffic.

透明なキャッシュの場合、P2Pキャッシュが確立されると、ネットワークはP2Pトラフィックをキャッシュに透過的にリダイレクトします。キャッシュはファイルを直接提供するか、リクエストをリモートP2Pユーザーに渡し、同時にそのデータをキャッシュします。通常、透明度は、深いパケット検査（DPI）を使用して実装されます。DPI製品は、P2PパケットをP2Pキャッシュシステムに識別して渡し、トラフィックをキャッシュして加速させることができます。

A non-transparent cache appears as a super peer; it explicitly peers with other P2P clients.

非透明なキャッシュは、スーパーピアとして表示されます。他のP2Pクライアントと明示的に仲間です。

To enable operation with existing P2P software, P2P caches directly support P2P application protocols. A large number of P2P protocols are used by P2P software and hence are supported by caches, leading to higher complexity. Additionally, these protocols evolve over time, and new protocols are introduced.

既存のP2Pソフトウェアで操作を有効にするために、P2PキャッシュはP2Pアプリケーションプロトコルを直接サポートします。多数のP2PプロトコルがP2Pソフトウェアで使用されるため、キャッシュによってサポートされているため、複雑さが高まります。さらに、これらのプロトコルは時間とともに進化し、新しいプロトコルが導入されます。

4.11.1. Applicability to DECADE

4.11.1. 10年への適用性

A P2P cache is an example of in-network storage for P2P systems. However, unlike DECADE, the existence and operation of the storage system are totally transparent to the end user.

P2Pキャッシュは、P2Pシステムのネットワーク内ストレージの例です。ただし、10年とは異なり、ストレージシステムの存在と動作はエンドユーザーに対して完全に透過的です。

4.11.2. Transparent P2P Caches

DPIの使用は、P2Pユーザーに発見メカニズムが提供されないことを意味します。P2Pユーザーに透明です。DPIはP2Pアプリケーションのプライベートプロトコルを認識するために使用されるため、新しいアプリケーションが追加され、既存のプロトコルが進化するにつれて、P2Pキャッシュの実装を更新する必要があります。

4.11.2.7. Storage Mode

4.11.2.7. ストレージモード

Object-based. Chunks (typically, the unit of transfer among P2P clients) of content are stored in the cache.

オブジェクトベース。チャンク（通常、P2Pクライアント間の転送単位）のコンテンツは、キャッシュに保存されます。

4.11.3. Non-Transparent P2P Caches

P2Pキャッシュノードは、P2Pオーバーレイネットワークに参加するために通常のピアであるかのように動作します。他のP2Pユーザーは、オーバーレイルーティングメカニズムを介してこのようなキャッシュノードを見つけることができ、通常の隣接ノードであるかのように対話できます。

4.11.3.7. Storage Mode

4.11.3.7. ストレージモード

Object-based. Chunks (typically, the unit of transfer among P2P clients) of content are stored in the cache.

オブジェクトベース。チャンク（通常、P2Pクライアント間の転送単位）のコンテンツは、キャッシュに保存されます。

4.12. 写真共有

There are a growing number of popular online photo-sharing (storing) systems. For example, the Kodak Gallery system [22] serves over 60 million users and stores billions of images [23]. Other well-known examples of photo-sharing systems include Flickr [24] and ImageShack [25]. There are also a number of popular blogging

人気のあるオンライン写真共有（保存）システムが増えています。たとえば、Kodak Gallery System [22]は6,000万人以上のユーザーにサービスを提供し、数十億の画像を保存しています[23]。写真共有システムの他のよく知られている例には、Flickr [24]とImageshack [25]が含まれます。人気のあるブログもたくさんあります

services, such as Tumblr [26], that specialize in sharing large numbers of photos as well as other multimedia content (e.g., video, text, audio, etc.) as part of their service. All of these in-network storage systems utilize both free and paid subscription models.

Tumblr [26]などのサービスは、サービスの一部として多数の写真やその他のマルチメディアコンテンツ（ビデオ、テキスト、オーディオなど）を共有することを専門としています。これらのネットワーク内のストレージシステムはすべて、無料のサブスクリプションモデルと有料のサブスクリプションモデルの両方を利用しています。

Most photo-sharing systems are based on a traditional client-server architecture. However, a minority of systems also offer a P2P mode of operation. The client-server architecture is typically based on HTTP, with a browser client and a Web server.

ほとんどの写真共有システムは、従来のクライアントサーバーアーキテクチャに基づいています。ただし、少数のシステムでは、P2P動作モードも提供しています。クライアントサーバーアーキテクチャは、通常、ブラウザークライアントとWebサーバーを備えたHTTPに基づいています。

4.12.1. Applicability to DECADE

4.12.1. 10年への適用性

Photo sharing is a very widely used (deployed) example of in-network storage where the end user has direct visibility and extensive control of the system. The typical end-user interface is through an HTTP-based Web browser.

写真共有は、エンドユーザーがシステムの直接的な可視性と広範な制御を持っているネットワーク内のストレージの非常に広く使用されている（展開された）例です。典型的なエンドユーザーインターフェイスは、HTTPベースのWebブラウザーを使用しています。

4.12.2. Data Access Interface

4.12.2. データアクセスインターフェイス

Users can read (view) and write (store) photos.

ユーザーは写真を読み取り（表示）し、写真を書くことができます。

4.12.3. Data Management Operations

4.12.3. データ管理操作

Users can delete previously stored photos.

ユーザーは、以前に保存された写真を削除できます。

4.12.4. Data Search Capability

4.12.4. データ検索機能

Users can tag photos and/or organize them using sophisticated Web photo album generators. Users can then search for objects (photos) matching desired criteria.

ユーザーは、洗練されたWebフォトアルバムジェネレーターを使用して、写真にタグを付けたり、整理したりできます。ユーザーは、目的の基準に一致するオブジェクト（写真）を検索できます。

4.12.5. Access Control Authorization

4.12.5. アクセス制御承認

The access control method for clients is typically either private or public-unrestricted. For example, writing (storing) to a photo blog is typically private to the owner of the account. However, all other clients can view (read) the contents of the blog (i.e., public-unrestricted). Some photo-sharing Websites provide private access to read photos to allow sharing with a limited set of friends.

クライアント向けのアクセス制御方法は、通常、プライベートまたは公開されていないものです。たとえば、写真ブログへの執筆（保存）は、通常、アカウントの所有者にとってプライベートです。ただし、他のすべてのクライアントは、ブログの内容（つまり、公開されていない）を表示（読み取る）ことができます。写真共有ウェブサイトの中には、写真を読むためのプライベートアクセスを提供して、限られた友人と共有できるようになります。

4.12.6. Resource Control Interface

4.12.6. リソース制御インターフェイス

Not provided.

提供されていない。

4.12.7. Discovery Mechanism

4.12.7. 発見メカニズム

Clients usually log on manually to a central Web page for the service and enter the appropriate information to access the desired information. The address to which the client connects is usually determined by DNS using the hostname from the provided URL.

クライアントは通常、サービスの中央のWebページに手動でログオンし、適切な情報を入力して目的の情報にアクセスします。クライアントが接続するアドレスは、通常、提供されたURLのホスト名を使用してDNSによって決定されます。

4.12.8. Storage Mode

4.12.8. ストレージモード

File system (file-based). Photos are usually stored as files. They can then be organized into meta-structures (e.g., albums, galleries, etc.) using sophisticated Web photo album generators.

ファイルシステム（ファイルベース）。写真は通常、ファイルとして保存されます。その後、洗練されたWebフォトアルバムジェネレーターを使用して、メタ構造（アルバム、ギャラリーなど）に整理できます。

4.13. Usenet

4.13. usenet

Usenet is a distributed Internet-based discussion (message) system. The Usenet messages are arranged as a set of "newsgroups" that are classified hierarchically by subject. Usenet information is distributed and stored among a large conglomeration of servers that store and forward messages to one another in so-called news feeds. Individual users may read messages from, and post messages to, a local news server typically operated by an ISP. This local server communicates with other servers and exchanges articles with them. In this fashion, the message is copied from server to server and eventually reaches every server in the network [27].

USENETは、分散インターネットベースのディスカッション（メッセージ）システムです。USENETメッセージは、主題によって階層的に分類される「ニュースグループ」のセットとして配置されます。USENET情報は、いわゆるニュースフィードで互いにメッセージを保存および転送するサーバーの大規模な集合体に配布および保存されます。個々のユーザーは、通常ISPによって動作するローカルニュースサーバーからのメッセージを読み取り、メッセージを投稿することができます。このローカルサーバーは、他のサーバーと通信し、記事を交換します。この方法で、メッセージはサーバーからサーバーにコピーされ、最終的にネットワーク内のすべてのサーバーに到達します[27]。

Traditional Usenet as described above operates as a P2P network between the servers, and in a client-server architecture between the user and their local news server. The user requires a Usenet client to be installed on their computer and a Usenet server account (through their ISP). However, with the rise of Web browsers, the Usenet architecture is evolving to be Web-based. The most popular example of this is Google Groups, where Google hosts all the newsgroups and client access is via a standard HTTP-based Web browser [28].

上記の従来のUSENETは、サーバー間のP2Pネットワークとして動作し、ユーザーとローカルニュースサーバー間のクライアントサーバーアーキテクチャで動作します。ユーザーは、USENETクライアントをコンピューターにインストールし、USENETサーバーアカウント（ISPを介して）にインストールする必要があります。ただし、Webブラウザーの台頭により、UsenetアーキテクチャはWebベースになるように進化しています。この最も一般的な例はGoogleグループです。Googleがすべてのニュースグループをホストし、クライアントアクセスは標準のHTTPベースのWebブラウザー[28]を介して行われます。

4.13.1. Applicability to DECADE

4.13.1. 10年への適用性

Usenet is a historically very important and widely used (deployed) example of in-network storage in the Internet. The use of this system is rapidly declining, but efforts have been made to preserve the stored content for historical purposes.

USENETは、インターネットでのネットワーク内ストレージの歴史的に非常に重要で広く使用されている（展開されている）例です。このシステムの使用は急速に減少していますが、歴史的な目的のために保存されたコンテンツを維持する努力がなされています。

4.13.2. Data Access Interface

4.13.2. データアクセスインターフェイス

Users can read and post (store) messages.

ユーザーはメッセージを読んで投稿できます。メッセージを投稿できます。

4.13.3. Data Management Operations

4.13.3. データ管理操作

Users sometimes have limited ability to delete messages that they previously posted.

ユーザーは、以前に投稿したメッセージを削除する能力が限られている場合があります。

4.13.4. Data Search Capability

4.13.4. データ検索機能

Traditionally, users could manually search through the newsgroups, as they are classified hierarchically by subject. In the newer Web-based systems, there is also an automatic search capability based on key-word matches.

従来、ユーザーは被写体によって階層的に分類されているため、ニュースグループを手動で検索できます。新しいWebベースのシステムでは、キーワードマッチに基づいた自動検索機能もあります。

4.13.5. Access Control Authorization

4.13.5. アクセス制御承認

The access control method is either public-unrestricted or private (to client members of that newsgroup).

アクセス制御方法は、公開されていないまたはプライベートです（そのニュースグループのクライアントメンバーにとって）。

4.13.6. Resource Control Interface

4.13.6. リソース制御インターフェイス

Not provided.

提供されていない。

4.13.7. Discovery Mechanism

4.13.7. 発見メカニズム

Clients usually log on manually to their Usenet accounts. DNS may be used to resolve hostnames to their corresponding addresses.

クライアントは通常、usenetアカウントに手動でログオンします。DNSを使用して、ホスト名を対応するアドレスに解決できます。

4.13.8. Storage Mode

4.13.8. ストレージモード

File system. Messages are usually stored as files that are then organized hierarchically by subject into newsgroups.

ファイルシステム。メッセージは通常、ファイルとして保存され、その後、サブジェクトによって階層的にニュースグループに編成されます。

4.14. Web Cache

4.14. Webキャッシュ

Web cache [29] has been widely deployed by many ISPs to reduce bandwidth consumption and Web access latency since the late 1990s. A Web cache can cache the Web documents (e.g., HTML pages, images) between server and client to reduce bandwidth usage, server load, and perceived lag. A Web cache server is typically shared by many clients, and stores copies of documents passing through it; subsequent requests may be satisfied from the cache if certain conditions are met.

Webキャッシュ[29]は、1990年代後半以降、帯域幅の消費とWebアクセスの遅延を減らすために、多くのISPによって広く展開されています。Webキャッシュは、サーバーとクライアントの間のWebドキュメント（HTMLページ、画像など）をキャッシュして、帯域幅の使用量、サーバーの負荷、および知覚された遅延を削減できます。通常、Webキャッシュサーバーは多くのクライアントが共有し、それを通過するドキュメントのコピーを保存します。特定の条件が満たされている場合、後続の要求はキャッシュから満たされる場合があります。

Another form of cache is a client-side cache, typically implemented in Web browsers. A client-side cache can keep a local copy of all pages recently displayed by a browser, and when the user returns to one of these Web pages, the local cached copy is reused.

4.15. ネットワーク内のストレージシステムに関する観察

The following observations about the surveyed in-network storage systems are made in the context of DECADE as defined by [1].

調査対象のネットワーク内ストレージシステムに関する次の観察結果は、[1]で定義されているように、10年のコンテキストで作成されます。

The majority of the surveyed systems were designed for client-server architectures and do not support P2P. However, there are some important exceptions, especially for some of the newer technologies such as BranchCache and P2P cache, that do support a P2P mode of operation.

調査対象システムの大部分は、クライアントサーバーアーキテクチャ向けに設計されており、P2Pをサポートしていません。ただし、特にP2P動作モードをサポートするBranchCacheやP2Pキャッシュなどの新しいテクノロジーのいくつかについては、いくつかの重要な例外があります。

The P2P cache systems are interesting, since they do not require changes to the P2P applications themselves. However, this is also a limitation in that they are required to support each application protocol.

P2Pキャッシュシステムは、P2Pアプリケーション自体の変更を必要としないため、興味深いものです。ただし、これは各アプリケーションプロトコルをサポートするために必要であるという点でも制限です。

Many of the surveyed systems were designed for caching as opposed to long-term network storage. Thus, during DECADE protocol design, it should be carefully considered whether a caching mode should be supported in addition to a long-term network storage mode. There is typically a trade-off between providing a caching mode and long-term (and usually also reliable) storage with regards to some performance metrics. Note that [1] identifies issues with classical caching from a DECADE perspective, such as the fact that P2P caches typically do not allow users to explicitly control content stored in the cache.

調査対象システムの多くは、長期的なネットワークストレージとは対照的に、キャッシュ用に設計されています。したがって、10年のプロトコル設計中に、長期的なネットワークストレージモードに加えて、キャッシュモードをサポートする必要があるかどうかを慎重に検討する必要があります。通常、一部のパフォーマンスメトリックに関して、キャッシュモードと長期的な（通常は信頼できる）ストレージを提供することとの間にはトレードオフがあります。[1]は、P2Pキャッシュが通常、ユーザーがキャッシュに保存されているコンテンツを明示的に制御できないという事実など、10年の観点からの古典的なキャッシュに関する問題を特定していることに注意してください。

Certain components of the surveyed systems are outside of the scope of DECADE. For example, a protocol used for searching across multiple DECADE servers is out of scope. However, applications may still be able to implement such functionality if DECADE exposes the appropriate primitives. This has the benefit of keeping the core in-network storage systems simple, while permitting diverse applications to design mechanisms that meet their own requirements.

調査対象システムの特定のコンポーネントは、10年の範囲外です。たとえば、数十年のサーバーで検索するために使用されるプロトコルは範囲外です。ただし、10年が適切なプリミティブを公開している場合、アプリケーションはそのような機能を実装できる可能性があります。これには、コアインネットワーク内のストレージシステムをシンプルに保つという利点があり、独自の要件を満たす設計メカニズムに多様なアプリケーションを許可します。

Today, most in-network storage systems follow some variant of the authorization model of public-unrestricted, public-restricted, and private. For DECADE, we may need to evolve the authorization model to support a resource owner (e.g., end user) authorization, in addition to the network authorization.

今日、ほとんどのネットワーク内のストレージシステムは、公的、公的制限、プライベートの認可モデルのいくつかのバリアントに従っています。10年間、ネットワーク認証に加えて、リソース所有者（エンドユーザー）認証をサポートするために、認可モデルを進化させる必要がある場合があります。

5. ストレージおよびその他の関連プロトコル

This section surveys existing storage and other related protocols, as well as comments on the usage of these protocols to satisfy DECADE's use cases. The surveyed protocols are listed alphabetically.

このセクションでは、既存のストレージやその他の関連するプロトコル、およびこれらのプロトコルの使用に関するコメントを調査して、10年のユースケースを満たします。調査対象のプロトコルはアルファベット順にリストされています。

5.1. HTTP

5.1. http

HTTP [31] is a key protocol for the World Wide Web. It is a stateless client-server protocol that allows applications to be designed using the REST model. HTTP is often associated with downloading (reading) content from Web servers to Web browsers, but it also has support for uploading (writing) content to Web servers. It has been used as the underlying protocol for other protocols, such as Web Distributed Authoring and Versioning (WebDAV).

HTTP [31]は、World Wide Webの重要なプロトコルです。これは、RESTモデルを使用してアプリケーションを設計できるステートレスクライアントサーバープロトコルです。HTTPは、多くの場合、WebサーバーからWebブラウザーへのダウンロード（読み取り）コンテンツに関連付けられていますが、Webサーバーへのアップロード（書き込み）コンテンツもサポートしています。これは、Web分散オーサリングやバージョン（WebDAV）など、他のプロトコルの基礎となるプロトコルとして使用されています。

HTTP is used in some of the most popular in-network storage systems surveyed previously, including CDNs, photo sharing, and Web cache. Usage of HTTP by a storage protocol implies that no extra software is required in the client (i.e., Web-based client), as all standard Web browsers are based on HTTP.

HTTPは、CDN、写真共有、Webキャッシュなど、以前に調査された最も人気のあるネットワークストレージシステムのいくつかで使用されています。ストレージプロトコルによるHTTPの使用は、すべての標準WebブラウザーがHTTPに基づいているため、クライアント（つまり、Webベースのクライアント）に追加のソフトウェアが不要であることを意味します。

5.1.1. Data Access Interface

5.1.1. データアクセスインターフェイス

Basic read and write operations are supported (using HTTP GET, PUT, and POST methods).

基本的な読み取りおよび書き込み操作がサポートされています（HTTP Get、Put、およびPost Methodを使用）。

5.1.2. Data Management Operations

5.1.2. データ管理操作

Not provided.

提供されていない。

5.1.3. Data Search Capability

5.1.3. データ検索機能

Not provided.

提供されていない。

5.1.4. Access Control Authorization

5.1.4. アクセス制御承認

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private.

クライアントのアクセス制御のすべての方法がサポートされています：公共の領土、公共制限、プライベート。

The majority of Web pages are public-unrestricted in terms of reading but do not allow any uploading of content. In-network storage systems range from private or public-unrestricted for photo sharing (described in Section 4.12.5) to public-unrestricted for Web caching (described in Section 4.14.5).

Webページの大部分は、読書の点で公開されていませんが、コンテンツのアップロードを許可していません。ネットワーク内のストレージシステムは、写真共有のためにプライベートまたはパブリックのない公開（セクション4.12.5で説明）から、Webキャッシングの公共の領域（セクション4.14.5で説明）にまで及びます。

5.1.5. Resource Control Interface

5.1.5. リソース制御インターフェイス

Not provided.

提供されていない。

5.1.6. Discovery Mechanism

5.1.6. 発見メカニズム

Manual configuration is typically used. Clients typically address HTTP servers by providing a hostname, which is resolved to an address using DNS.

通常、手動構成が使用されます。通常、クライアントは、DNSを使用してアドレスに解決されるホスト名を提供することにより、HTTPサーバーに対応します。

5.1.7. Storage Mode

5.1.7. ストレージモード

HTTP is a protocol; it thus does not define a storage mode. However, a non-collection resource can typically be thought of as a "file". These files may be organized into collections, which typically map onto the HTTP path hierarchy, creating the illusion of a file system.

HTTPはプロトコルです。したがって、ストレージモードを定義しません。ただし、非収集リソースは通常、「ファイル」と考えることができます。これらのファイルはコレクションに編成される場合があります。コレクションは通常、HTTPパス階層にマッピングされ、ファイルシステムの錯覚を作成します。

5.1.8. Comments

5.1.8. コメント

HTTP is based on a client-server architecture and thus is not directly applicable for the DECADE focus on P2P. Also, HTTP offers only a rudimentary toolset for storage operations compared to some of the other storage protocols.

HTTPはクライアントサーバーアーキテクチャに基づいているため、P2Pに焦点を当てた10年には直接適用できません。また、HTTPは、他のストレージプロトコルの一部と比較して、ストレージ操作のための初歩的なツールセットのみを提供します。

5.2. iSCSI

5.2. iscsi

Small Computer System Interface (SCSI) is a set of protocols enabling communication with storage devices such as disk drives and tapes; Internet SCSI (iSCSI) [32] is a protocol enabling SCSI commands to be sent over TCP. As in SCSI, iSCSI allows an Initiator to send commands to a Target. These commands operate on the device level as opposed to individual data objects stored on the device.

Small Computer System Interface（SCSI）は、ディスクドライブやテープなどのストレージデバイスとの通信を可能にする一連のプロトコルです。インターネットSCSI（ISCSI）[32]は、SCSIコマンドをTCPを介して送信できるプロトコルです。SCSIのように、ISCSIはイニシエーターがターゲットにコマンドを送信することを許可します。これらのコマンドは、デバイスに保存されている個々のデータオブジェクトとは対照的に、デバイスレベルで動作します。

5.2.1. Data Access Interface

5.2.1. データアクセスインターフェイス

Read and write commands indicate which data is to be read or written by specifying the offset (using Logical Block Addressing) into the storage device. The size of data to be read or written is an additional parameter in the command.

読み取りおよび書き込みコマンドは、ストレージデバイスにオフセット（論理ブロックアドレス指定を使用）を指定することにより、どのデータを読み取るか書かれるかを示します。読み取られるデータのサイズは、コマンド内の追加パラメーターです。

5.2.2. Data Management Operations

5.2.2. データ管理操作

Since commands operate at the device level, management operations are different than with traditional file systems. Management commands for SCSI/iSCSI include explicit device control commands, such as starting, stopping, and formatting the device.

コマンドはデバイスレベルで動作するため、管理操作は従来のファイルシステムとは異なります。SCSI/ISCSIの管理コマンドには、デバイスの開始、停止、フォーマットなど、明示的なデバイス制御コマンドが含まれます。

5.2.3. Data Search Capability

5.2.3. データ検索機能

SCSI/iSCSI does not provide the ability to search for particular data within a device. Note that such capabilities can be implemented outside of iSCSI.

SCSI/ISCSIは、デバイス内の特定のデータを検索する機能を提供しません。このような機能は、ISCSIの外部で実装できることに注意してください。

5.2.4. Access Control Authorization

5.2.4. アクセス制御承認

With respect to access to devices, the access control method is private. iSCSI uses the Challenge Handshake Authentication Protocol (CHAP) [33] to authenticate Initiators and Targets when accessing storage devices. However, since SCSI/iSCSI operates at the device level, neither authentication nor authorization is provided for individual data objects. Note that such capabilities can be implemented outside of iSCSI.

デバイスへのアクセスに関しては、アクセス制御方法はプライベートです。ISCSIは、チャレンジハンドシェイク認証プロトコル（CHAP）[33]を使用して、ストレージデバイスにアクセスするときにイニシエーターとターゲットを認証します。ただし、SCSI/ISCSIはデバイスレベルで動作するため、個々のデータオブジェクトに対して認証も承認も提供されていません。このような機能は、ISCSIの外部で実装できることに注意してください。

5.2.5. Resource Control Interface

5.2.5. リソース制御インターフェイス

Not provided.

提供されていない。

5.2.6. Discovery Mechanism

5.2.6. 発見メカニズム

Manual configuration may be used. An alternative is the Internet Storage Name Service (iSNS) [34], which provides the ability to discover available storage resources.

手動構成を使用できます。別の方法は、インターネットストレージ名サービス（ISNS）[34]で、利用可能なストレージリソースを発見する機能を提供します。

5.2.7. Storage Mode

5.2.7. ストレージモード

As a protocol, iSCSI does not explicitly have a storage mode. However, it provides block-based access to clients. SCSI/iSCSI provides an Initiator with block-level access to the storage device.

プロトコルとして、ISCSIには明示的にストレージモードがありません。ただし、クライアントへのブロックベースのアクセスを提供します。SCSI/ISCSIは、ストレージデバイスへのブロックレベルのアクセスを備えたイニシエーターを提供します。

5.3. NFS

The Network File System (NFS) is designed to allow users to access files over a network in a manner similar to how local storage is accessed. NFS is typically used in local area networks or in enterprise settings, though changes made in later versions of NFS (e.g., [35]) make it easier to operate over the Internet.

ネットワークファイルシステム（NFS）は、ローカルストレージのアクセス方法と同様の方法で、ユーザーがネットワークを介してファイルにアクセスできるように設計されています。NFSは通常、ローカルエリアネットワークまたはエンタープライズ設定で使用されますが、NFSの後のバージョン（[35]など）で行われた変更により、インターネット経由で操作が容易になります。

5.3.1. Data Access Interface

5.3.1. データアクセスインターフェイス

Traditional file-system operations such as read, write, and update (overwrite) are provided. Locking is provided to support concurrent access by multiple clients.

読み取り、書き込み、更新（上書き）などの従来のファイルシステム操作が提供されます。ロックは、複数のクライアントによる同時アクセスをサポートするために提供されます。

5.3.2. Data Management Operations

5.3.2. データ管理操作

Traditional file-system operations such as move and delete are provided.

移動や削除などの従来のファイルシステム操作が提供されます。

5.3.3. Data Search Capability

5.3.3. データ検索機能

The user has the ability to list contents of directories to find filenames matching desired criteria.

ユーザーには、ディレクトリのコンテンツをリストして、希望の基準を一致させるファイル名を見つける機能があります。

5.3.4. Access Control Authorization

5.3.4. アクセス制御承認

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private. For example, files and directories can be protected using read, write, and execute permissions for the files' owner and group, and for the public (others). Also, NFSv4.1 has a rich ACL model allowing a list of Access Control Entries (ACEs) to be configured for each file or directory. The ACEs can specify per-user read/write access to file data, file/directory attributes, creation/deletion of files in a directory, etc.

クライアントのアクセス制御のすべての方法がサポートされています：公共の領土、公共制限、プライベート。たとえば、ファイルとディレクトリは、ファイルの所有者とグループ、および一般の（その他）の読み取り、書き込み、および実行を使用して保護できます。また、NFSV4.1にはリッチなACLモデルがあり、各ファイルまたはディレクトリにアクセス制御エントリ（ACES）のリストを構成できます。ACESは、ファイルデータ、ファイル/ディレクトリ属性、ディレクトリ内のファイルの作成/削除へのユーザーごとの読み取り/書き込みアクセスを指定できます。

5.3.5. Resource Control Interface

5.3.5. リソース制御インターフェイス

While disk space quotas can be configured, administrative policy typically limits the total amount of storage allocated to a particular user. User control of bandwidth and connections used by remote peers is not provided.

ディスクスペースの割り当てを構成できますが、管理ポリシーは通常、特定のユーザーに割り当てられたストレージの総額を制限します。リモートピアが使用する帯域幅と接続のユーザー制御は提供されていません。

5.3.6. Discovery Mechanism

5.3.6. 発見メカニズム

Manual configuration is typically used. Clients address NFS servers by providing a hostname and a directory that should be mounted. DNS may be used to look up an address for the provided hostname.

通常、手動構成が使用されます。クライアントは、ホスト名と取り付けられるディレクトリを提供することにより、NFSサーバーにアドレスを与えます。DNSは、提供されたホスト名のアドレスを検索するために使用できます。

5.3.7. Storage Mode

5.3.7. ストレージモード

As a protocol, there is no defined internal storage mode. However, implementations typically use the underlying file-system storage. Note that extensions have been defined for alternate storage modes (e.g., block-based [36] and object-based [37]).

プロトコルとして、定義された内部ストレージモードはありません。ただし、実装は通常、基礎となるファイルシステムストレージを使用します。エクステンションは、代替ストレージモード（例：ブロックベース[36]およびオブジェクトベース[37]）に対して定義されていることに注意してください。

5.3.8. Comments

5.3.8. コメント

The efficiency and scalability of the NFS access control method are concerns in the context of DECADE. In particular, Section 6.2.1 of [35] states that:

NFSアクセス制御方法の効率とスケーラビリティは、10年のコンテキストでの懸念事項です。特に、[35]のセクション6.2.1は次のように述べています。

Only ACEs that have a "who" that matches the requester are considered.

要求者に一致する「WHO」を持つエースのみが考慮されます。

Thus, in the context of DECADE, to specify per-peer access control policies for an object, a client would need to explicitly configure the ACL for the object for each individual peer. A concern with this approach is scalability when a client's peers may change frequently, and ACLs for many small objects need to be updated constantly during participation in a swarm.

したがって、10年のコンテキストでは、オブジェクトのピアごとのアクセス制御ポリシーを指定するには、クライアントは個々のピアごとにオブジェクトのACLを明示的に構成する必要があります。このアプローチの懸念は、クライアントのピアが頻繁に変更される可能性があり、多くの小さなオブジェクトのACLを群れへの参加中に絶えず更新する必要がある場合のスケーラビリティです。

Note that NFSv4.1's usage of RPCSEC_GSS provides support for multiple security mechanisms. Kerberos V5 is required, but others, such as X.509 certificates, are also supported by way of the Generic Security Service Application Program Interface (GSS-API). Note, however, that NFSv4.1's usage of such security mechanisms is limited to linking a requesting user to a particular account maintained by the NFS server.

NFSV4.1のRPCSEC_GSSの使用は、複数のセキュリティメカニズムのサポートを提供することに注意してください。Kerberos V5が必要ですが、X.509証明書などのその他は、ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）によってサポートされています。ただし、NFSV4.1のこのようなセキュリティメカニズムの使用は、要求ユーザーをNFSサーバーが管理する特定のアカウントにリンクすることに限定されていることに注意してください。

5.4. OAuth

5.4. oauth

Open Authorization (OAuth) [38] is a protocol that enriches the traditional client-server authentication model for Web resources. In particular, OAuth distinguishes the "client" from the "resource owner", thus enabling a resource owner to authorize a particular client for access (e.g., for a particular lifetime) to private resources.

Open Authorization（OAUTH）[38]は、Webリソースの従来のクライアントサーバー認証モデルを濃縮するプロトコルです。特に、OAuthは「クライアント」を「リソース所有者」と識別し、リソース所有者が特定のクライアントにプライベートリソースへのアクセス（特定の生涯）を許可することを可能にします。

We include OAuth in this survey so that its authentication model can be evaluated in the context of DECADE. OAuth itself, however, is not a network storage protocol.

この調査にはOAuthを含めて、その認証モデルを10年のコンテキストで評価できるようにします。ただし、OAuth自体はネットワークストレージプロトコルではありません。

5.4.1. Data Access Interface

5.4.1. データアクセスインターフェイス

Not provided.

提供されていない。

5.4.2. Data Management Operations

5.4.2. データ管理操作

Not provided.

提供されていない。

5.4.3. Data Search Capability

5.4.3. データ検索機能

Not provided.

提供されていない。

5.4.4. Access Control Authorization

5.4.4. アクセス制御承認

Not provided. While similar in spirit to the WebDAV ticketing extensions [39], OAuth instead uses the following process: (1) a client constructs a delegation request, (2) the client forwards the request to the resource owner for authorization, (3) the resource owner authorizes the request, and finally (4) a callback is made to the client indicating that its request has been authorized.

5.5.4. アクセス制御承認

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private.

クライアントのアクセス制御のすべての方法がサポートされています：公共の領土、公共制限、プライベート。

For example, an ACL extension [42] is provided for WebDAV. ACLs allow both user-based and group-based access control policies (relating to reading, writing, properties, locking, etc.) to be defined for objects and collections.

たとえば、ACL拡張[42]がWebDavに提供されます。ACLは、ユーザーベースとグループベースのアクセス制御ポリシー（読み取り、書き込み、プロパティ、ロックなど）をオブジェクトとコレクションに対して定義することを可能にします。

A ticketing extension [39] has also been proposed, but has not progressed since 2001. This extension allows a client to request the WebDAV server to create a "ticket" (e.g., for reading an object) that can be distributed to other clients. Tickets may be given expiration times, or may only allow for a fixed number of uses. The proposed extension requires the server to generate tickets and maintain state for outstanding tickets.

チケット拡張機能[39]も提案されていますが、2001年以来進行していません。この拡張機能により、クライアントはWebDavサーバーに他のクライアントに配布できる「チケット」（たとえば、オブジェクトを読むために）を作成するように要求できます。チケットには有効期限が与えられる場合があります。また、固定数の用途のみを許可する場合があります。提案された拡張機能では、サーバーがチケットを生成し、未払いのチケットの状態を維持する必要があります。

5.5.5. Resource Control Interface

5.5.5. リソース制御インターフェイス

An extension [43] allows disk space quotas to be configured for collections. The extension also allows WebDAV clients to query current disk space usage. User control of bandwidth and connections used by remote peers is not provided.

拡張機能[43]を使用すると、コレクション用にディスクスペースクォータを構成できます。また、この拡張機能により、WebDavクライアントは現在のディスクスペースの使用を照会することができます。リモートピアが使用する帯域幅と接続のユーザー制御は提供されていません。

5.5.6. Discovery Mechanism

5.5.6. 発見メカニズム

Manual configuration is typically used. Clients address WebDAV servers by providing a hostname, which can be resolved to an address using DNS.

通常、手動構成が使用されます。クライアントは、DNSを使用してアドレスに解決できるホスト名を提供することにより、WebDAVサーバーに対応します。

5.5.7. Storage Mode

5.5.7. ストレージモード

Though no storage mode is explicitly defined, WebDAV can be thought of as providing file system (file-based) storage to a client. A non-collection resource can typically be thought of as a "file". Files may be organized into collections, which typically map onto the HTTP path hierarchy.

ストレージモードは明示的に定義されていませんが、WebDavは、クライアントにファイルシステム（ファイルベース）ストレージを提供すると考えることができます。非収集リソースは、通常、「ファイル」と考えることができます。ファイルはコレクションに編成される場合があります。コレクションは、通常、HTTPパス階層にマッピングされます。

5.5.8. Comments

5.5.8. コメント

The efficiency and scalability of the WebDAV access control method are concerns in the context of DECADE, for reasons similar to those stated in Section 5.3.8 for NFS. The proposed WebDAV ticketing extension partially alleviates these concerns, but the particular technique may need further evaluation before being applied to DECADE. In particular, since DECADE clients may continuously upload/download a large number of small-size objects, and a single DECADE server may need to scale to many concurrent DECADE clients, requiring the server to maintain ticket state and generate tickets may not be the best design choice. Server-generated tickets can also increase latency for data transport operations, depending on the message flow used by DECADE.

WebDAVアクセス制御方法の効率とスケーラビリティは、NFSのセクション5.3.8に記載されている理由と同様の理由により、10年のコンテキストでは懸念事項です。提案されたWebDAVチケット延長はこれらの懸念を部分的に軽減しますが、特定の手法では、10年に適用される前にさらに評価が必要になる場合があります。特に、10年のクライアントは多数の小型オブジェクトを継続的にアップロード/ダウンロードする可能性があるため、1年間のサーバーは多くの同時10年のクライアントにスケーリングする必要がある場合があります。デザインの選択。サーバーで生成されたチケットは、10年で使用されるメッセージフローに応じて、データ輸送操作の遅延を増加させる可能性があります。

5.6. ストレージおよび関連プロトコルに関する観察

The following observations about the surveyed storage and related protocols are made in the context of DECADE as defined by [1].

調査対象のストレージおよび関連プロトコルに関する次の観察結果は、[1]で定義されているように、10年のコンテキストで行われます。

All of the surveyed protocols were primarily designed for client-server architectures and not for P2P. However, it is conceivable that some of the protocols could be adapted to work in a P2P architecture.

調査対象のすべてのプロトコルは、主にP2Pではなく、クライアントサーバーアーキテクチャ向けに設計されています。ただし、一部のプロトコルがP2Pアーキテクチャで動作するように適応できると考えられます。

Several popular in-network storage systems today use HTTP as their key protocol, even though it is not classically considered as a storage protocol. HTTP is a stateless protocol that is used to design RESTful applications. HTTP is a well-supported and widely implemented protocol that can provide important insights for DECADE.

現在、いくつかの人気のあるネットワークストレージシステムは、ストレージプロトコルとは古典的には見なされていないにもかかわらず、HTTPを主要なプロトコルとして使用しています。HTTPは、Restfulアプリケーションの設計に使用されるステートレスプロトコルです。HTTPは、10年間で重要な洞察を提供できる、よくサポートされ広く実装されたプロトコルです。

The majority of the surveyed protocols do not support low-latency access for applications such as live streaming. This was one of the key general requirements for DECADE.

調査対象のプロトコルの大部分は、ライブストリーミングなどのアプリケーションの低遅延アクセスをサポートしていません。これは、10年間の重要な一般的な要件の1つでした。

The majority of the surveyed protocols do not support any form of resource control interface. Resource control is required for users to manage the resources on in-network storage systems, e.g., the bandwidth or connections, that can be used by other peers. Resource control is a key capability required for DECADE.

調査対象のプロトコルの大部分は、リソース制御インターフェイスの形式をサポートしていません。リソース制御は、他のピアが使用できるネットワーク内のストレージシステム、たとえば帯域幅や接続のリソースを管理するために必要です。リソース制御は、10年間に必要な重要な機能です。

Nearly all surveyed protocols did, however, support the following capabilities required for DECADE: ability of the user to read/write content, some form of access control, some form of error indication, and the ability to traverse firewalls and NATs.

ただし、調査対象のプロトコルのほぼすべてが、10年間に必要な次の機能をサポートしていました。ユーザーがコンテンツを読み取り/書き込む能力、何らかの形のアクセス制御、何らかのエラー表示、ファイアウォールとNATを通過する能力。

6. Conclusions

6. 結論

Though there have been many successful in-network storage systems, they have been designed for use cases different from those defined in DECADE. For example, many of the surveyed in-network storage systems and protocols were designed for client-server architectures and not P2P. No surveyed system or protocol has the functionality and features to fully meet the set of requirements defined for DECADE. DECADE aims to provide a standard protocol for P2P applications and content providers to access and control in-network storage, resulting in increased network efficiency while retaining control over content shared with peers. Additionally, defining a standard protocol can reduce the complexity of in-network storage, since multiple P2P application protocols no longer need to be implemented by in-network storage systems.

ネットワーク内のストレージシステムが多く成功していますが、10年で定義されたケースとは異なるユースケース向けに設計されています。たとえば、調査対象のネットワーク内ストレージシステムとプロトコルの多くは、P2Pではなくクライアントサーバーアーキテクチャ用に設計されています。調査対象のシステムまたはプロトコルには、10年間定義された一連の要件を完全に満たす機能と機能がありません。Decadeの目的は、P2Pアプリケーションとコンテンツプロバイダーにネットワーク内のストレージにアクセスおよび制御するための標準プロトコルを提供することを目指しており、ピアと共有されたコンテンツの制御を維持しながらネットワーク効率が向上します。さらに、複数のP2Pアプリケーションプロトコルをネットワーク内のストレージシステムで実装する必要がなくなったため、標準プロトコルを定義すると、ネットワーク内のストレージの複雑さを軽減できます。

7. Security Considerations

7. セキュリティに関する考慮事項

This document is a survey of existing in-network storage systems, and does not introduce any security considerations beyond those of the surveyed systems.

このドキュメントは、既存のネットワーク内のストレージシステムの調査であり、調査対象システムのセキュリティに関する考慮事項を導入していません。

For more information on security considerations of DECADE, see [1].

10年のセキュリティに関する考慮事項の詳細については、[1]を参照してください。

8. Contributors

8. 貢献者

The editors would like to thank the following people for contributing to the development of this document:

編集者は、このドキュメントの開発に貢献してくれた次の人々に感謝したいと思います。

- ZhiHui Lv

- Zhihui lv

- Borje Ohlman

- ボルジェ・オルマン

- Pang Tao

- パンタオ

- Lucy Yong

- ルーシー・ヨン

- Juan Carlos Zuniga

- フアン・カルロス・ズニガ

9. Acknowledgments

9. 謝辞

The editors would like to thank the following people for providing valuable comments to various draft versions of this document: David Bryan, Tao Mao, Haibin Song, Ove Strandberg, Yu-Shun Wang, Richard Woundy, Yunfei Zhang, and Ning Zong.

編集者は、このドキュメントのさまざまなドラフトバージョンに貴重なコメントを提供してくれた次の人々に感謝したいと思います：David Bryan、Tao Mao、Haibin Song、Ove Strandberg、Yu-Shun Wang、Richard Wundy、Yunfei Zhang、Ning Zong。

10. Informative References

10. 参考引用

[1] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", Work in Progress, October 2011.

[1] Song、H.、Zong、N.、Yang、Y.、およびR. Alimi、「分離アプリケーションデータatoute（10年）問題声明」、2011年10月の作業。

[2] Storage Search, "Flash Memory vs. Hard Disk Drives -- Which Will Win?", <http://www.storagesearch.com/semico-art1.html>.

[2] ストレージ検索、「フラッシュメモリ対ハードディスクドライブ - どちらが勝ちますか？」、<http://www.storagesearch.com/semico-art1.html>。

[3] Brisken, W., "Hard Drive Price Trends", US VLBI Technical Meeting, May 2008.

[3] Brisken、W。、「ハードドライブ価格動向」、米国VLBI技術会議、2008年5月。

[4] Woundy, R., "TSV P2P Efforts -- From an ISP's Perspective", IETF 81, Quebec, Canada, July 2011, <http://www.ietf.org/proceedings/81/slides/tsvarea-3.pdf>.

[4] 傷、R。、「TSV P2Pの取り組み - ISPの観点から」、IETF 81、カナダ、ケベック、2011年7月<http://www.ietf.org/proceedings/81/slides/tsvarea-3.pdf>。

[5] Gu, Y., Bryan, D., Yang, Y., and R. Alimi, "DECADE Requirements", Work in Progress, September 2011.

[5] Gu、Y.、Bryan、D.、Yang、Y。、およびR. Alimi、「Decade Recomission」、2011年9月、進行中の作業。

[6] Amazon Web Services, "Amazon Simple Storage Service (Amazon S3)", <http://aws.amazon.com/s3/>.

[6] Amazon Web Services、「Amazon Simple Storage Service（Amazon S3）」、<http://aws.amazon.com/s3/>。

[7] Calder, B., Wang, T., Mainali, S., and J. Wu, "Windows Azure Blob -- Programming Blob Storage", May 2009, <http://www.microsoft.com/windowsazure/whitepapers/>.

[7] Calder、B.、Wang、T.、Mainali、S。、およびJ. Wu、「Windows Azure Blob-プログラミングブロブストレージ」、2009年5月、<http://www.microsoft.com/windowsazure/whitepapers/>。

[8] Google, "Google Storage for Developers", <http://code.google.com/apis/storage>.

[8] Google、「開発者向けのGoogleストレージ」、<http://code.google.com/apis/storage>。

[9] Dropbox, "Dropbox Features", <http://www.dropbox.com/features>.

[9] dropbox、 "dropbox feature"、<http://www.dropbox.com/features>。

[10] Microsoft Corporation, "BranchCache", <http://technet.microsoft.com/en-us/network/dd425028.aspx>.

[10] Microsoft Corporation、「BranchCache」、<http://technet.microsoft.com/en-us/network/dd425028.aspx>。

[11] Microsoft Corporation, "Web Services Dynamic Discovery (WS-Discovery)", April 2005, <http://specs.xmlsoap.org/ ws/2005/04/discovery/ws-discovery.pdf>.

[11] Microsoft Corporation、「Web Services Dynamic Discovery（WS-Discovery）」、2005年4月、<http://specs.xmlsoap.org/ ws/2005/04/discovery/ws-discovery.pdf>。

[12] Paul, S., Yates, R., Raychaudhuri, D., and J. Kurose, "The Cache-and-Forward Network Architecture for Efficient Mobile Content Delivery Services in the Future Internet", Innovations in NGN: Future Network and Services, 2008.

[12] Paul、S.、Yates、R.、Raychaudhuri、D。、およびJ. Kurose、「将来のインターネットでの効率的なモバイルコンテンツ配信サービスのためのキャッシュアンドフォワードネットワードアーキテクチャ」、NGNのイノベーション：将来のネットワークとサービス、2008年。

[13] SNIA, "Cloud Data Management Interface (CDMI)", <http://www.snia.org/cdmi>.

[13] SNIA、「クラウドデータ管理インターフェイス（CDMI）」、<http://www.snia.org/cdmi>。

[14] Pathan, A.K. and Buyya, R., "A Taxonomy and Survey of Content Delivery Networks", Grid Computing and Distributed Systems Laboratory, University of Melbourne, Technical Report, February 2007.

[14] パタン、別およびBuyya、R。、「コンテンツ配信ネットワークの分類法と調査」、グリッドコンピューティングおよび分散システム研究所、メルボルン大学、テクニカルレポート、2007年2月。

[15] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007.

[15] Cerf、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K.、およびH. Weiss、「遅延耐性ネットワークアーキテクチャ」、RFC 4838、2007年4月。

[16] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.

[16] Scott、K。およびS. Burleigh、「バンドルプロトコル仕様」、RFC 5050、2007年11月。

[17] Named Data Networking, "Named Data Networking Home Page", <http://www.named-data.net/>.

[17] 名前付きデータネットワーキング、「名前付きデータネットワークホームページ」、<http://www.named-data.net/>。

[18] Named Data Networking, "Named Data Networking (NDN) Project", <http://www.named-data.net/ndn-proj.pdf>.

[18] 名前付きデータネットワーキング、「名前付きデータネットワーク（NDN）プロジェクト」、<http://www.named-data.net/ndn-proj.pdf>。

[19] Network of Information, "NetInf Overview", <http://www.netinf.org/home/overview/>.

[19] 情報のネットワーク、「NetInf概要」、<http://www.netinf.org/home/overview/>。

[20] Anand, A., Sekar, V., and A. Akella, "SmartRE: An Architecture for Coordinated Network-wide Redundancy Elimination", SIGCOMM 2009.

[20] Anand、A.、Sekar、V。、およびA. Akella、「Smartre：An Coordated Network全体の冗長性除去のためのアーキテクチャ」、Sigcomm 2009。

[21] Rhea, S., Eaton, P., Geels, D., Weatherspoon, H., Zhao, B., and J. Kubiatowicz, "Pond: the OceanStore Prototype", FAST 2003.

[21] Rhea、S.、Eaton、P.、Geels、D.、Weatherspoon、H.、Zhao、B。、およびJ. Kubiatowicz、「Pond：The Oceanstore Prototype」、Fast 2003。

[22] Kodak, "Kodak Gallery Home Page", <http://www.kodakgallery.com/gallery/welcome.jsp>.

[22] Kodak、「Kodak Gallery Home Page」、<http://www.kodakgallery.com/gallery/welcome.jsp>。

[23] Wikipedia, "Kodak Gallery", <http://en.wikipedia.org/wiki/Kodak_Gallery>.

[23] ウィキペディア、「コダックギャラリー」、<http://en.wikipedia.org/wiki/kodak_gallery>。

[24] Flickr, "Flickr Home Page", <http://www.flickr.com>.

[24] Flickr、「Flickrホームページ」、<http://www.flickr.com>。

[25] ImageShack, "ImageShack Home Page", <http://imageshack.us>.

[25] ImagesHack、「ImagesHackホームページ」、<http://imageshack.us>。

[26] Tumblr, "Tumblr Home Page", <http://www.tumblr.com>.

[26] Tumblr、「Tumblrホームページ」、<http://www.tumblr.com>。

[27] Wikipedia, "Usenet", <http://en.wikipedia.org/wiki/Usenet>.

[27] wikipedia、 "usenet"、<http://en.wikipedia.org/wiki/usenet>。

[28] Google, "Google Groups", <http://groups.google.com>.

[28] Google、「Google Groups」、<http://groups.google.com>。

[29] Huston, G., Telstra, "Web Caching", The Internet Protocol Journal Volume 2, No. 3.

[29] Huston、G.、Telstra、「Web Caching」、The Internet Protocol Journal Volume 2、No。3。

[30] Shen, G., Wang, Y., Xiong, Y., Zhao, B., and Z-L. Zhang, "HPTP: Relieving the Tension between ISPs and P2P", 6th International Workshop on Peer-To-Peer Systems (IPTPS2007).

[30] Shen、G.、Wang、Y.、Xiong、Y.、Zhao、B。、およびZ-L。Zhang、「HPTP：ISPとP2Pの間の緊張を緩和する」、ピアツーピアシステムに関する第6回国際ワークショップ（IPTPS2007）。

[31] 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.

[31] 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月。

[32] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.

[32] Satran、J.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M。、およびE. Zeidner、「Internet Small Computer Systems Interface（ISCSI）」、RFC 3720、2004年4月。

[33] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

[33] シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。

[34] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.

[34] Tseng、J.、Gibbons、K.、Travostino、F.、Du Laney、C。、およびJ. Souza、「インターネットストレージ名サービス（ISNS）」、RFC 4171、2005年9月。

[35] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.

[35] Shepler、S.、ed。、Eisler、M.、ed。、およびD. Noveck、ed。、「ネットワークファイルシステム（NFS）バージョン4マイナーバージョン1プロトコル」、RFC 5661、2010年1月。

[36] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS (pNFS) Block/Volume Layout", RFC 5663, January 2010.

[36] Black、D.、Fridella、S。、およびJ. Glasgow、「並列NFS（PNFS）ブロック/ボリュームレイアウト」、RFC 5663、2010年1月。

[37] Halevy, B., Welch, B., and J. Zelenka, "Object-Based Parallel NFS (pNFS) Operations", RFC 5664, January 2010.

[37] Halevy、B.、Welch、B。、およびJ. Zelenka、「オブジェクトベースの並列NFS（PNFS）操作」、RFC 5664、2010年1月。

[38] Hammer-Lahav, E., Ed., "The OAuth 1.0 Protocol", RFC 5849, April 2010.

[38] Hammer-Lahav、E.、ed。、「The Oauth 1.0 Protocol」、RFC 5849、2010年4月。

[39] Ito, K., "Ticket-Based Access Control Extension to WebDAV", Work in Progress, October 2001.

[39] Ito、K。、「WebDavへのチケットベースのアクセス制御拡張式」、2001年10月、進行中の作業。

[40] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

[40] Dusseault、L.、ed。、「Web分散オーサリングおよびバージョン（WebDav）のHTTP拡張機能」、RFC 4918、2007年6月。

[41] Reschke, J., Ed., Reddy, S., Davis, J., and A. Babich, "Web Distributed Authoring and Versioning (WebDAV) SEARCH", RFC 5323, November 2008.

[41] Reschke、J.、ed。、Reddy、S.、Davis、J。、およびA. Babich、「Web分散オーサリングおよびバージョン（WebDAV）検索」、RFC 5323、2008年11月。

[42] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.

[42] Clemm、G.、Reschke、J.、Sedlar、E。、およびJ. Whitehead、「Web分散オーサリングおよびバージョン（WebDAV）アクセス制御プロトコル」、RFC 3744、2004年5月。

[43] Korver, B. and L. Dusseault, "Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections", RFC 4331, February 2006.

[43] Korver、B。およびL. Dusseault、「分散オーサリングおよびバージョン（DAV）コレクションのクォータとサイズのプロパティ」、RFC 4331、2006年2月。

Authors' Addresses

著者のアドレス

Richard Alimi (editor) Google

リチャード・アリミ（編集者）Google

   EMail: ralimi@google.com

Akbar Rahman (editor) InterDigital Communications, LLC

Akbar Rahman（編集者）Interdigital Communications、LLC

   EMail: Akbar.Rahman@InterDigital.com

Yang Richard Yang (editor) Yale University

ヤン・リチャード・ヤン（編集者）イェール大学

   EMail: yry@cs.yale.edu