[要約] RFC 3466は、コンテンツインターネットワーキング(CDI)のモデルについての要約です。その目的は、異なるネットワーク間でのコンテンツの効率的な配信と管理を実現するためのフレームワークを提供することです。

Network Working Group                                             M. Day
Request for Comments: 3466                                         Cisco
Category: Informational                                          B. Cain
                                                                Storigen
                                                            G. Tomlinson
                                                         Tomlinson Group
                                                              P. Rzewski
                                                   Media Publisher, Inc.
                                                           February 2003
        

A Model for Content Internetworking (CDI)

コンテンツインターネットワークのモデル(CDI)

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2003). All Rights Reserved.

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

Abstract

概要

Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called "content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary.

コンテンツ(分布)インターネットワーク(CDI)は、コンテンツネットワークを相互接続するためのテクノロジーであり、以前は「コンテンツピアリング」または「CDNピアリング」と呼ばれることもあります。一般的な語彙は、そのような相互接続と相互操作について議論するプロセスに役立ちます。このドキュメントでは、コンテンツネットワークとコンテンツインターネットワークを紹介し、そのような一般的な語彙の要素を定義します。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Content Networks . . . . . . . . . . . . . . . . . . . . . .  2
       2.1   Problem Description  . . . . . . . . . . . . . . . . .  3
       2.2   Caching Proxies. . . . . . . . . . . . . . . . . . . .  4
       2.3   Server Farms . . . . . . . . . . . . . . . . . . . . .  5
       2.4   Content Distribution Networks. . . . . . . . . . . . .  6
             2.4.1 Historic Evolution of CDNs . . . . . . . . . . .  8
             2.4.2 Describing CDN Value: Scale and Reach. . . . . .  8
   3.  Content Network Model Terms  . . . . . . . . . . . . . . . .  9
   4.  Content Internetworking  . . . . . . . . . . . . . . . . . . 12
   5.  Content Internetworking Model Terms  . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Normative References . . . . . . . . . . . . . . . . . . . . 16
      9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
   10. Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
        
1. Introduction
1. はじめに

Content networks are of increasing importance to the overall architecture of the Web. This document presents a vocabulary for use in developing technology for interconnecting content networks, or "content internetworking".

コンテンツネットワークは、Webの全体的なアーキテクチャにとって重要性が高まっています。このドキュメントでは、コンテンツネットワークを相互接続するためのテクノロジーまたは「コンテンツインターネットワーキング」を開発するために使用するための語彙を提示します。

The accepted name for the technology of interconnecting content networks is "content internetworking". For historical reasons, we abbreviate this term using the acronym CDI (from "content distribution internetworking"). Earlier names relied on analogy with peering and interconnection of IP networks; thus we had "content peering" and "CDN peering". All of these other names are now deprecated, and we have worked to establish consistent usage of "content internetworking" and "CDI" throughout the documents of the IETF CDI group.

相互接続コンテンツネットワークのテクノロジーの認められた名前は、「コンテンツインターネットワーク」です。歴史的な理由から、頭字語CDI(「コンテンツ配信インターネットワーク」から)を使用してこの用語を略します。以前の名前は、IPネットワークの覗き見と相互接続との類推に依存していました。したがって、「コンテンツピアリング」と「CDNピアリング」がありました。これらの他のすべての名前はすべて拒否されており、IETF CDIグループのドキュメント全体で「コンテンツインターネットワーク」と「CDI」の一貫した使用法を確立するために取り組んできました。

The terminology in this document builds from the previous taxonomy of web caching and replication in RFC 3040 [3]. In particular, we have attempted to avoid the use of the common terms "proxies" or "caches" in favor of more specific terms defined by that document, such as "caching proxy".

このドキュメントの用語は、RFC 3040のWebキャッシュと複製の以前の分類法から構築されています[3]。特に、「キャッシングプロキシ」など、そのドキュメントによって定義されたより具体的な用語を支持して、一般的な用語「プロキシ」または「キャッシュ」の使用を回避しようとしました。

Section 2 provides background on content networks. Section 3 introduces the terms used for elements of a content network and explains how those terms are used. Section 4 provides additional background on interconnecting content networks, following which Section 5 introduces additional terms and explains how those internetworking terms are used.

セクション2では、コンテンツネットワークの背景を説明します。セクション3では、コンテンツネットワークの要素に使用される用語を紹介し、それらの用語の使用方法について説明します。セクション4では、相互接続コンテンツネットワークの追加の背景を示します。これに続いて、セクション5では追加の用語を紹介し、これらのインターネットワーキング用語の使用方法について説明します。

2. Content Networks
2. コンテンツネットワーク

The past several years have seen the evolution of technologies centered around "content". Protocols, appliances, and entire markets have been created exclusively for the location, download, and usage tracking of content. Some sample technologies in this area have included web caching proxies, content management tools, intelligent "web switches", and advanced log analysis tools.

過去数年間、「コンテンツ」を中心とした技術の進化が見られました。プロトコル、アプライアンス、および市場全体は、コンテンツの場所、ダウンロード、および使用の追跡専用に作成されています。この分野の一部のサンプルテクノロジーには、Webキャッシュプロキシ、コンテンツ管理ツール、インテリジェントな「Webスイッチ」、および高度なログ分析ツールが含まれています。

When used together, these tools form new types of networks, dubbed "content networks". Whereas network infrastructures have traditionally processed information at layers 1 through 3 of the OSI stack, content networks include network infrastructure that exists in layers 4 through 7. Whereas lower-layer network infrastructures centered on the routing, forwarding, and switching of frames and packets, content networks deal with the routing and forwarding of requests and responses for content. The units of transported data in content networks, such as images, movies, or songs, are often very large and may span hundreds or thousands of packets.

一緒に使用すると、これらのツールは「コンテンツネットワーク」と呼ばれる新しいタイプのネットワークを形成します。ネットワークインフラストラクチャは従来、OSIスタックのレイヤー1〜3で情報を処理していましたが、コンテンツネットワークにはレイヤー4〜7に存在するネットワークインフラストラクチャが含まれますが、フレームとパケットのルーティング、転送、切り替えを中心とした低層ネットワークインフラストラクチャが含まれます。コンテンツネットワークは、コンテンツのリクエストと応答のルーティングと転送を扱います。画像、映画、曲などのコンテンツネットワーク内の輸送データの単位は、多くの場合非常に大きく、数百または数千のパケットにまたがる可能性があります。

Alternately, content networks can be seen as a new virtual overlay to the OSI stack: a "content layer", to enable richer services that rely on underlying elements from all 7 layers of the stack. Whereas traditional applications, such as file transfer (FTP), relied on underlying protocols such as TCP/IP for transport, overlay services in content networks rely on layer 7 protocols such as HTTP or RTSP for transport.

あるいは、コンテンツネットワークは、OSIスタックへの新しい仮想オーバーレイ:「コンテンツレイヤー」と見なすことができ、スタックの7層すべての基礎となる要素に依存するより豊富なサービスを可能にします。ファイル転送(FTP)などの従来のアプリケーションは、輸送用のTCP/IPなどの基礎となるプロトコルに依存していますが、コンテンツネットワークのオーバーレイサービスは、輸送用のHTTPやRTSPなどのレイヤー7プロトコルに依存しています。

The proliferation of content networks and content networking capabilities gives rise to interest in interconnecting content networks and finding ways for distinct content networks to cooperate for better overall service.

コンテンツネットワークとコンテンツネットワーク機能の急増により、コンテンツネットワークの相互接続と、個別のコンテンツネットワークがより良い全体的なサービスのために協力する方法を見つけることに関心が寄せられます。

2.1 Problem Description
2.1 問題の説明

Content networks typically play some role in solving the "content distribution problem". Abstractly, the goal in solving this problem is to arrange a rendezvous between a content source at an origin server and a content sink at a viewer's user agent. In the trivial case, the rendezvous mechanism is that every user agent sends every request directly to the origin server named in the host part of the URL identifying the content.

コンテンツネットワークは通常、「コンテンツ配信の問題」を解決する上で何らかの役割を果たします。抽象的には、この問題を解決する目標は、Origin ServerのコンテンツソースとViewerのユーザーエージェントのコンテンツシンクの間にランデブーを配置することです。些細な場合、ランデブーメカニズムは、すべてのユーザーエージェントが、コンテンツを識別するURLのホスト部分に指定されたOrigin Serverにすべてのリクエストを直接送信することです。

As the audience for the content source grows, so do the demands on the origin server. There are a variety of ways in which the trivial system can be modified for better performance. The apparent single logical server may in fact be implemented as a large "farm" of server machines behind a switch. Both caching proxies and reverse caching proxies can be deployed between the client and server, so that requests can be satisfied by some cache instead of by the server.

コンテンツソースの視聴者が成長するにつれて、Origin Serverの要求も成長します。より良いパフォーマンスのために、些細なシステムを変更できるさまざまな方法があります。実際、見かけの単一の論理サーバーは、スイッチの背後にあるサーバーマシンの大規模な「ファーム」として実装される場合があります。キャッシュプロキシと逆キャッシュプロキシの両方をクライアントとサーバーの間に展開できます。そのため、サーバーではなくキャッシュによってリクエストが満たされるようにすることができます。

For the sake of background, several sample content networks are described in the following sections that each attempt to address this problem.

背景のために、いくつかのサンプルコンテンツネットワークについて、次のセクションで説明します。それぞれがこの問題に対処しようとします。

2.2 Caching Proxies
2.2 キャッシュプロキシ

A type of content network that has been in use for several years is a caching proxy deployment. Such a network might typically be employed by an ISP for the benefit of users accessing the Internet, such as through dial or cable modem.

数年間使用されてきたコンテンツネットワークの種類は、キャッシュプロキシの展開です。このようなネットワークは、通常、ユーザーがダイヤルモデムやケーブルモデムなど、インターネットにアクセスするためにISPによって採用される場合があります。

In the interest of improving performance and reducing bandwidth utilization, caching proxies are deployed close to the users. These users are encouraged to send their web requests through the caches rather than directly to origin servers, such as by configuring their browsers to do so. When this configuration is properly done, the user's entire browsing session goes through a specific caching proxy. That caching proxy will therefore contain the "hot set" of all Internet content being viewed by all of the users of that caching proxy.

パフォーマンスを改善し、帯域幅の利用を減らすために、キャッシュプロキシがユーザーの近くに展開されます。これらのユーザーは、ブラウザを設定するなど、オリジンサーバーに直接ではなく、キャッシュを介してWebリクエストを送信することをお勧めします。この構成が適切に完了すると、ユーザーのブラウジングセッション全体が特定のキャッシュプロキシを実行します。したがって、キャッシュプロキシには、そのキャッシュプロキシのすべてのユーザーが表示されているすべてのインターネットコンテンツの「ホットセット」が含まれます。

When a request is being handled at a caching proxy on behalf of a user, other decisions may be made, such as:

ユーザーに代わってキャッシュプロキシでリクエストが処理されている場合、次のような他の決定が下される場合があります。

o A provider that deploys caches in many geographically diverse locations may also deploy regional parent caches to further aggregate user requests and responses. This may provide additional performance improvement and bandwidth savings. When parents are included, this is known as hierarchical caching.

o 多くの地理的に多様な場所でキャッシュを展開するプロバイダーは、地域の親キャッシュを展開して、ユーザーのリクエストと応答をさらに集約することもできます。これにより、パフォーマンスの向上と帯域幅の節約が追加される場合があります。親が含まれている場合、これは階層キャッシングとして知られています。

o Using rich parenting protocols, redundant parents may be deployed such that a failure in a primary parent is detected and a backup is used instead.

o 豊富な子育てプロトコルを使用して、冗長な親が展開され、一次親の障害が検出され、代わりにバックアップが使用されます。

o Using similar parenting protocols, requests may be partitioned such that requests for certain content domains are sent to a specific primary parent. This can help to maximize the efficient use of caching proxy resources.

o 同様の子育てプロトコルを使用して、特定のコンテンツドメインのリクエストが特定のプライマリ親に送信されるように、リクエストが分割される場合があります。これは、キャッシュプロキシリソースの効率的な使用を最大化するのに役立ちます。

The following diagram depicts a hierarchical cache deployment as described above:

次の図は、上記の階層キャッシュの展開を示しています。

                     ^        ^
                     |        |   requests to
                     |        |   origin servers
                     |        |
                 --------   --------
                 |parent|   |parent|
                 |cache |   |cache |
                 |proxy |   |proxy |
                 --------   --------
                      ^         ^
          requests for \       / requests for
               foo.com  \     /  bar.com
               content   \   /   content
                          \ /
      -------  -------  -------  -------
      |edge |  |edge |  |edge |  |edge |
      |cache|  |cache|  |cache|  |cache|
      |proxy|  |proxy|  |proxy|  |proxy|
      -------  -------  -------  -------
                          ^
                          | all content
                          | requests
                          | for this
                          | client
                          |
                       --------
                       |client|
                       --------
        

Note that this diagram shows only one possible configuration, but many others are also useful. In particular, the client may be able to communicate directly with multiple caching proxies. RFC 3040 [3] contains additional examples of how multiple caching proxies may be used.

この図は1つの可能な構成のみを示していることに注意してくださいが、他の多くの構成も有用です。特に、クライアントは複数のキャッシュプロキシと直接通信できる場合があります。RFC 3040 [3]には、複数のキャッシュプロキシを使用する方法の追加の例が含まれています。

2.3 Server Farms
2.3 サーバーファーム

Another type of content network that has been in widespread use for several years is a server farm. A typical server farm makes use of a so-called "intelligent" or "content" switch (i.e., one that uses information in OSI layers 4-7). The switch examines content requests and dispatches them among a (potentially large) group of servers.

数年間広く使用されている別のタイプのコンテンツネットワークは、サーバーファームです。典型的なサーバーファームは、いわゆる「インテリジェント」または「コンテンツ」スイッチ(つまり、OSI層4-7で情報を使用するもの)を使用します。スイッチは、コンテンツリクエストを調べ、サーバーの(潜在的に大規模な)グループ間でそれらを発送します。

Some of the goals of a server farm include:

サーバーファームの目標の一部は次のとおりです。

o Creating the impression that the group of servers is actually a single origin site.

o サーバーのグループが実際に単一の原点サイトであるという印象を作成します。

o Load-balancing of requests across all servers in the group.

o グループ内のすべてのサーバーにわたるリクエストのロードバランス。

o Automatic routing of requests away from servers that fail.

o 失敗したサーバーから離れた要求の自動ルーティング。

o Routing all requests for a particular user agent's session to the same server, in order to preserve session state.

o セッション状態を維持するために、特定のユーザーエージェントのセッションのすべての要求を同じサーバーにルーティングします。

The following diagram depicts a simple server farm deployment:

次の図は、単純なサーバーファームの展開を示しています。

      ---------  ---------  ---------  ---------
      |content|  |content|  |content|  |content|
      |server |  |server |  |server |  |server |
      |       |  |       |  |       |  |       |
      ---------  ---------  ---------  ---------
                     ^          ^
         request from \        / request from
            client A   \      /    client B
                        \    /
                     -------------
                     |  L4-L7    |
                     |  switch   |
                     -------------
                        ^     ^
                       /       \
                      /         \
                     /           \
             request from     request from
               client A         client B
        

A similar style of content network (that is, deployed close to servers) may be constructed with surrogates [3] instead of a switch.

同様のスタイルのコンテンツネットワーク(つまり、サーバーの近くに展開される)は、スイッチの代わりにサロゲート[3]で構築できます。

2.4 Content Distribution Networks
2.4 コンテンツ配信ネットワーク

Both hierarchical caching and server farms are useful techniques, but have limits. Server farms can improve the scalability of the origin server. However, since the multiple servers and other elements are typically deployed near the origin server, they do little to improve performance problems that are due to network congestion. Caching proxies can improve performance problems due to network congestion (since they are situated near the clients) but they cache objects based on client demand. Caching based on client demand performs poorly if the requests for a given object, while numerous in aggregate, are spread thinly among many different caching proxies. (In the worst case, an object could be requested n times via n distinct caching proxies, causing n distinct requests to the origin server -- or exactly the same behavior that would occur without any caching proxies in place.)

階層的なキャッシングとサーバーファームの両方は、有用なテクニックですが、制限があります。サーバーファームは、Origin Serverのスケーラビリティを改善できます。ただし、複数のサーバーやその他の要素は通常、Origin Serverの近くに展開されるため、ネットワークの輻輳によるパフォーマンスの問題を改善することはほとんどありません。キャッシュプロキシは、ネットワークの輻輳のためにパフォーマンスの問題を改善する可能性があります(クライアントの近くにあるため)が、クライアントの需要に基づいてオブジェクトをキャッシュします。特定のオブジェクトのリクエストが多数集約されている場合、多くの異なるキャッシュプロキシの間で薄く拡散している場合、クライアントの需要に基づくキャッシュのパフォーマンスが低下します。(最悪の場合、n個の異なるキャッシングプロキシを介してオブジェクトをn回要求することができ、オリジンサーバーにn個の異なる要求を引き起こすか、キャッシュプロキシを所定の位置にキャッシュすることなく発生するまったく同じ動作を引き起こす可能性があります。)

Thus, a content provider with a popular content source can find that it has to invest in large server farms, load balancing, and high-bandwidth connections to keep up with demand. Even with those investments, the user experience may still be relatively poor due to congestion in the network as a whole.

したがって、人気のあるコンテンツソースを備えたコンテンツプロバイダーは、需要に対応するために、大規模なサーバーファーム、ロードバランス、および高帯域幅接続に投資する必要があることがわかります。これらの投資を使用しても、ネットワーク全体の混雑により、ユーザーエクスペリエンスは依然として比較的低い場合があります。

To address these limitations, another type of content network that has been deployed in increasing numbers in recent years is the CDN (Content Distribution Network or Content Delivery Network). A CDN essentially moves server-farm-like configurations out into network locations more typically occupied by caching proxies. A CDN has multiple replicas of each content item being hosted. A request from a browser for a single content item is directed to a "good" replica, where "good" usually means that the item is served to the client quickly compared to the time it would take fetch it from the origin server, with appropriate integrity and consistency. Static information about geographic locations and network connectivity is usually not sufficient to do a good job of choosing a replica. Instead, a CDN typically incorporates dynamic information about network conditions and load on the replicas, directing requests so as to balance the load.

これらの制限に対処するために、近年増加する数で展開されている別のタイプのコンテンツネットワークは、CDN(コンテンツ配信ネットワークまたはコンテンツ配信ネットワーク)です。CDNは、基本的にサーバーファームのような構成を、通常、キャッシュプロキシによってより一般的に占有されているネットワークの場所に移動します。CDNには、ホストされている各コンテンツアイテムの複数のレプリカがあります。単一のコンテンツアイテムのブラウザからのリクエストは「良い」レプリカに向けられます。ここで、「良い」ということは、通常、アイテムがクライアントに迅速に提供されることを意味します。整合性と一貫性。地理的な場所とネットワーク接続に関する静的情報は、通常、レプリカを選択するのに適した仕事をするのに十分ではありません。代わりに、CDNには通常、ネットワーク条件とレプリカの負荷に関する動的な情報が組み込まれており、負荷のバランスをとるためにリクエストを指示します。

Compared to using servers and surrogates in a single data center, a CDN is a relatively complex system encompassing multiple points of presence, in locations that may be geographically far apart. Operating a CDN is not easy for a content provider, since a content provider wants to focus its resources on developing high-value content, not on managing network infrastructure. Instead, a more typical arrangement is that a network service provider builds and operates a CDN, offering a content distribution service to a number of content providers.

単一のデータセンターでサーバーやサロゲートを使用するのと比較して、CDNは、地理的に遠く離れている可能性のある場所で、複数の存在点を網羅する比較的複雑なシステムです。コンテンツプロバイダーは、ネットワークインフラストラクチャの管理ではなく、価値の高いコンテンツの開発にリソースを集中させたいため、CDNを操作することはコンテンツプロバイダーにとって容易ではありません。代わりに、より典型的な取り決めは、ネットワークサービスプロバイダーがCDNを構築および運用し、多くのコンテンツプロバイダーにコンテンツ配信サービスを提供することです。

A CDN enables a service provider to act on behalf of the content provider to deliver copies of origin server content to clients from multiple diverse locations. The increase in number and diversity of location is intended to improve download times and thus improve the user experience. A CDN has some combination of a content-delivery infrastructure, a request-routing infrastructure, a distribution infrastructure, and an accounting infrastructure. The content-delivery infrastructure consists of a set of "surrogate" servers [3] that deliver copies of content to sets of users. The request-routing infrastructure consists of mechanisms that move a client toward a rendezvous with a surrogate. The distribution infrastructure consists of mechanisms that move content from the origin server to the surrogates. Finally, the accounting infrastructure tracks and collects data on request-routing, distribution, and delivery functions within the CDN.

CDNにより、サービスプロバイダーはコンテンツプロバイダーに代わって行動し、複数の多様な場所からクライアントにOrigin Serverコンテンツのコピーを配信できます。場所の数と多様性の増加は、ダウンロード時間を改善し、ユーザーエクスペリエンスを改善することを目的としています。CDNには、コンテンツ配信インフラストラクチャ、リクエストルーティングインフラストラクチャ、流通インフラストラクチャ、会計インフラストラクチャの組み合わせがあります。コンテンツ配信インフラストラクチャは、ユーザーのセットにコンテンツのコピーを配信する「サロゲート」サーバー[3]のセットで構成されています。リクエストルーティングインフラストラクチャは、クライアントを代理人とのランデブーに向けるメカニズムで構成されています。分布インフラストラクチャは、Origin ServerからSurrogatesにコンテンツを移動するメカニズムで構成されています。最後に、会計インフラストラクチャは、CDN内のリクエストルーティング、配布、および配信機能のためにデータを追跡および収集します。

The following diagram depicts a simple CDN as described above:

次の図は、上記の単純なCDNを示しています。

               ----------          ----------
               |request-|          |request-|
               |routing |          |routing |
               | system |          | system |
               ----------          ----------
                 ^ |
    (1) client's | | (2) response
        content  | |     indicating
        request  | |     location of       -----------
                 | |     content           |surrogate|
                 | |                       -----------
   -----------   | |
   |surrogate|   | |      -----------
   -----------   | |      |surrogate|
                 | |      -----------
                 | |      ^
                 | v     / (3) client opens
                client---      connection to
                               retrieve content
        
2.4.1 Historic Evolution of CDNs
2.4.1 CDNの歴史的進化

The first important use of CDNs was for the distribution of heavily-requested graphic files (such as GIF files on the home pages of popular servers). However, both in principle and increasingly in practice, a CDN can support the delivery of any digital content -- including various forms of streaming media. For a streaming media CDN (or media distribution network or MDN), the surrogates may be operating as splitters (serving out multiple copies of a stream). The splitter function may be instead of, or in addition to, a role as a caching proxy. However, the basic elements defined in this model are still intended to apply to the interconnection of content networks that are distributing streaming media.

CDNSの最初の重要な使用は、重度にリクエストされたグラフィックファイル(人気サーバーのホームページ上のGIFファイルなど)の配布でした。ただし、原則として、また実際にますますますます、CDNは、さまざまな形態のストリーミングメディアを含むデジタルコンテンツの配信をサポートできます。ストリーミングメディアCDN(またはメディア配信ネットワークまたはMDN)の場合、サロゲートはスプリッターとして動作している可能性があります(ストリームの複数のコピーを提供します)。スプリッター関数は、キャッシュプロキシとしての役割であるか、それに加えてである場合があります。ただし、このモデルで定義されている基本的な要素は、ストリーミングメディアを分散しているコンテンツネットワークの相互接続に適用することを目的としています。

2.4.2 Describing CDN Value: Scale and Reach
2.4.2 CDN値の記述:スケールとリーチ

There are two fundamental elements that give a CDN value: outsourcing infrastructure and improved content delivery. A CDN allows multiple surrogates to act on behalf of an origin server, therefore removing the delivery of content from a centralized site to multiple and (usually) highly distributed sites. We refer to increased aggregate infrastructure size as "scale". In addition, a CDN can be constructed with copies of content near to end users, overcoming issues of network size, network congestion, and network failures. We refer to increased diversity of content locations as "reach".

CDN値を与える2つの基本的な要素があります。インフラストラクチャのアウトソーシングとコンテンツ配信の改善です。CDNを使用すると、複数のサロゲートがOrigin Serverに代わって行動できるため、集中サイトから複数の(通常)高度に分散されたサイトにコンテンツの配信を削除できます。総インフラストラクチャサイズの増加を「スケール」と呼びます。さらに、エンドユーザーに近いコンテンツのコピーでCDNを構築し、ネットワークサイズ、ネットワーク輻輳、ネットワークの障害の問題を克服できます。コンテンツの場所の多様性を「リーチ」と呼びます。

In a typical (non-internetworked) CDN, a single service provider operates the request-routers, the surrogates, and the content distributors. In addition, that service provider establishes (business) relationships with content publishers and acts on behalf of their origin sites to provide a distributed delivery system. The value of that CDN to a content provider is a combination of its scale and its reach.

典型的な(インターネットワークの)CDNでは、単一のサービスプロバイダーがリクエストルーター、サロゲート、コンテンツディストリビューターを操作します。さらに、そのサービスプロバイダーは、コンテンツパブリッシャーとの(ビジネス)関係を確立し、オリジンサイトに代わって行動して分散型配信システムを提供します。コンテンツプロバイダーへのそのCDNの値は、そのスケールとリーチの組み合わせです。

3. Content Network Model Terms
3. コンテンツネットワークモデルの用語

This section consists of the definitions of a number of terms used to refer to roles, participants, and objects involved in content networks. Although the following uses many terms that are based on those used in RFC 2616 [1] or RFC 3040 [3], there is no necessary connection to HTTP or web caching technology. Content internetworking and this vocabulary are applicable to other protocols and styles of content delivery.

このセクションは、コンテンツネットワークに関与する役割、参加者、およびオブジェクトを参照するために使用される多くの用語の定義で構成されています。以下は、RFC 2616 [1]またはRFC 3040 [3]で使用されている用語に基づいた多くの用語を使用していますが、HTTPまたはWebキャッシュテクノロジーに必要な接続はありません。コンテンツインターネットワーキングとこの語彙は、他のプロトコルとコンテンツ配信のスタイルに適用できます。

Phrases in upper-case refer to other defined terms.

上部ケースのフレーズは、他の定義された用語を指します。

ACCOUNTING Measurement and recording of DISTRIBUTION and DELIVERY activities, especially when the information recorded is ultimately used as a basis for the subsequent transfer of money, goods, or obligations.

特に記録された情報が、その後のお金、商品、または義務の譲渡の基礎として最終的に使用される場合、流通および配信活動の会計測定と記録。

ACCOUNTING SYSTEM A collection of CONTENT NETWORK ELEMENTS that supports ACCOUNTING for a single CONTENT NETWORK.

会計システム単一のコンテンツネットワークの会計をサポートするコンテンツネットワーク要素のコレクション。

AUTHORITATIVE REQUEST-ROUTING SYSTEM The REQUEST-ROUTING SYSTEM that is the correct/final authority for a particular item of CONTENT.

権威あるリクエストルーティングシステム特定のコンテンツ項目の正しい/最終的な権限であるリクエストルーティングシステム。

CDN Content Delivery Network or Content Distribution Network. A type of CONTENT NETWORK in which the CONTENT NETWORK ELEMENTS are arranged for more effective delivery of CONTENT to CLIENTS. Typically a CDN consists of a REQUEST-ROUTING SYSTEM, SURROGATES, a DISTRIBUTION SYSTEM, and an ACCOUNTING SYSTEM.

CDNコンテンツ配信ネットワークまたはコンテンツ配信ネットワーク。コンテンツネットワーク要素がクライアントへのより効果的なコンテンツの配信のために配置されるタイプのコンテンツネットワーク。通常、CDNは、リクエストルーティングシステム、サロゲート、流通システム、および会計システムで構成されています。

CLIENT A program that sends CONTENT REQUESTS and receives corresponding CONTENT RESPONSES. (Note: this is similar to the definition in RFC 2616 [1] but we do not require establishment of a connection.)

クライアントコンテンツリクエストを送信し、対応するコンテンツ応答を受信するプログラム。(注:これはRFC 2616 [1]の定義に似ていますが、接続の確立は必要ありません。)

CONTENT Any form of digital data, CONTENT approximately corresponds to what is referred to as an "entity" in RFC 2616 [1]. One important form of CONTENT with additional constraints on DISTRIBUTION and DELIVERY is CONTINUOUS MEDIA.

コンテンツ任意の形式のデジタルデータ、コンテンツは、RFC 2616 [1]の「エンティティ」と呼ばれるものにほぼ対応しています。配布と配信に追加の制約を伴うコンテンツの重要な形式の1つは、継続的なメディアです。

CONTENT NETWORK An arrangement of CONTENT NETWORK ELEMENTS, controlled by a common management in some fashion.

コンテンツネットワーク共通の管理者によって何らかの方法で制御されるコンテンツネットワーク要素の配置。

CONTENT NETWORK ELEMENT A network device that performs at least some of its processing by examining CONTENT-related parts of network messages. In IP-based networks, a CONTENT NETWORK ELEMENT is a device whose processing depends on examining information contained in IP packet bodies; network elements (as defined in RFC 3040) examine only the header of an IP packet. Note that many CONTENT NETWORK ELEMENTS do not examine or even see individual IP packets, instead receiving the body of one or more packets assembled into a message of some higher-level protocol.

コンテンツネットワーク要素ネットワークメッセージのコンテンツ関連部分を調べることにより、その処理の少なくとも一部を実行するネットワークデバイス。IPベースのネットワークでは、コンテンツネットワーク要素は、IPパケットボディに含まれる情報の調査に処理するデバイスです。ネットワーク要素(RFC 3040で定義)は、IPパケットのヘッダーのみを調べます。多くのコンテンツネットワーク要素は、個々のIPパケットを調べたり、表示したりしていないため、1つ以上のパケットの本文を、いくつかの高レベルプロトコルのメッセージに組み立てたものを受信することに注意してください。

CONTENT REQUEST A message identifying a particular item of CONTENT to be delivered.

コンテンツは、配信されるコンテンツの特定のアイテムを識別するメッセージを要求します。

CONTENT RESPONSE A message containing a particular item of CONTENT, identified in a previous CONTENT REQUEST.

コンテンツ応答以前のコンテンツリクエストで識別された、特定のコンテンツ項目を含むメッセージ。

CONTENT SIGNAL A message delivered through a DISTRIBUTION SYSTEM that specifies information about an item of CONTENT. For example, a CONTENT SIGNAL can indicate that the ORIGIN has a new version of some piece of CONTENT.

コンテンツ信号コンテンツのアイテムに関する情報を指定する配信システムを介して配信されるメッセージ。たとえば、コンテンツ信号は、Originにいくつかのコンテンツの新しいバージョンがあることを示すことができます。

CONTINUOUS MEDIA CONTENT where there is a timing relationship between source and sink; that is, the sink must reproduce the timing relationship that existed at the source. The most common examples of CONTINUOUS MEDIA are audio and motion video. CONTINUOUS MEDIA can be real-time (interactive), where there is a "tight" timing relationship between source and sink, or streaming (playback), where the relationship is less strict. [Note: This definition is essentially identical to the definition of continuous media in [2]]

ソースとシンクの間にタイミング関係がある連続メディアコンテンツ。つまり、シンクはソースに存在したタイミング関係を再現する必要があります。連続メディアの最も一般的な例は、オーディオおよびモーションビデオです。継続的なメディアは、ソースとシンクの間に「タイトな」タイミング関係がある、またはその関係が厳格ではない「再生)の間に「タイトな」タイミング関係がある場合があります。[注:この定義は、[2]の連続メディアの定義と本質的に同一です]

DELIVERY The activity of providing a PUBLISHER's CONTENT, via CONTENT RESPONSES, to a CLIENT. Contrast with DISTRIBUTION and REQUEST-ROUTING.

配信パブリッシャーのコンテンツをコンテンツ応答を介してクライアントに提供するアクティビティ。配布とリクエストルーティングとは対照的です。

DISTRIBUTION The activity of moving a PUBLISHER's CONTENT from its ORIGIN to one or more SURROGATEs. DISTRIBUTION can happen either in anticipation of a SURROGATE receiving a REQUEST (pre-positioning) or in response to a SURROGATE receiving a REQUEST (fetching on demand). Contrast with DELIVERY and REQUEST-ROUTING.

配布出版社のコンテンツをその起源から1つ以上の代理人に移動するアクティビティ。分布は、リクエストを受け取る代理人(事前配置)を見越して、またはリクエストを受信するサロゲート(オンデマンドフェッチ)に応じて発生する可能性があります。配信とリクエストルーティングとは対照的です。

DISTRIBUTION SYSTEM A collection of CONTENT NETWORK ELEMENTS that support DISTRIBUTION for a single CONTENT NETWORK. The DISTRIBUTION SYSTEM also propagates CONTENT SIGNALs.

配布システム単一のコンテンツネットワークの分布をサポートするコンテンツネットワーク要素のコレクション。分布システムは、コンテンツ信号も伝播します。

ORIGIN The point at which CONTENT first enters a DISTRIBUTION SYSTEM. The ORIGIN for any item of CONTENT is the server or set of servers at the "core" of the distribution, holding the "master" or "authoritative" copy of that CONTENT. (Note: We believe this definition is compatible with that for "origin server" in RFC 2616 [1] but includes additional constraints useful for CDI.)

起源コンテンツが最初に配布システムに入るポイント。コンテンツの任意の項目の原点は、配布の「コア」にあるサーバーまたはサーバーのセットであり、そのコンテンツの「マスター」または「権威ある」コピーを保持します。(注:この定義は、RFC 2616 [1]の「Origin Server」の定義と互換性があると考えていますが、CDIに役立つ追加の制約が含まれています。)

PUBLISHER The party that ultimately controls the CONTENT and its distribution.

パブリッシャーは、最終的にコンテンツとその分布を制御する当事者。

REACHABLE SURROGATES The collection of SURROGATES that can be contacted via a particular DISTRIBUTION SYSTEM or REQUEST-ROUTING SYSTEM.

Reachableは、特定の配信システムまたはリクエストルーティングシステムを介して連絡できるサロゲートのコレクションを発送します。

REQUEST-ROUTING The activity of steering or directing a CONTENT REQUEST from a USER AGENT to a suitable SURROGATE.

リクエストルーティングユーザーエージェントから適切な代理人へのステアリングまたはコンテンツリクエストの指示のアクティビティ。

REQUEST-ROUTING SYSTEM A collection of CONTENT NETWORK ELEMENTS that support REQUEST-ROUTING for a single CONTENT NETWORK.

リクエストルーティングシステム単一のコンテンツネットワークのリクエストルーティングをサポートするコンテンツネットワーク要素のコレクション。

SERVER A program that accepts CONTENT REQUESTS and services them by sending back CONTENT RESPONSES. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program. [Note: this is adapted from a similar definition in RFC 2616 [1].]

サーバーコンテンツの応答を送信することにより、コンテンツリクエストを受け入れ、サービスを提供するプログラム。特定のプログラムは、クライアントとサーバーの両方になることができる場合があります。これらの用語の使用は、プログラムによって実行される役割のみを指します。[注:これは、RFC 2616 [1]の同様の定義から採用されています。]

SURROGATE A delivery server, other than the ORIGIN. Receives a CONTENT REQUEST and delivers the corresponding CONTENT RESPONSE. [Note: this is a different definition from that in RFC 3040 [3], which appears overly elaborate for our purposes. A "CDI surrogate" is always an "RFC 3040 surrogate"; we are not sure if the reverse is true.]

出身以外の配送サーバーをサロゲートします。コンテンツリクエストを受信し、対応するコンテンツ応答を提供します。[注:これは、RFC 3040 [3]の定義とは異なる定義であり、私たちの目的のために過度に精巧に見える。「CDI Surrogate」は常に「RFC 3040 Surrogate」です。逆が真であるかどうかはわかりません。]

USER AGENT The CLIENT which initiates a REQUEST. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. [Note: this definition is identical to the one in RFC 2616 [1].]

ユーザーエージェントリクエストを開始するクライアント。これらは、多くの場合、ブラウザー、編集者、クモ(Webトレーバーロボット)、または他のエンドユーザーツールです。[注:この定義は、RFC 2616 [1]の定義と同じです。]

4. Content Internetworking
4. コンテンツインターネットワーク

There are limits to how large any one network's scale and reach can be. Increasing either scale or reach is ultimately limited by the cost of equipment, the space available for deploying equipment, and/or the demand for that scale/reach of infrastructure. Sometimes a particular audience is tied to a single service provider or a small set of providers by constraints of technology, economics, or law. Other times, a network provider may be able to manage surrogates and a distribution system, but may have no direct relationship with content providers. Such a provider wants to have a means of affiliating their delivery and distribution infrastructure with other parties who have content to distribute.

1つのネットワークのスケールとリーチがどれだけ大きくなるかには、制限があります。スケールまたはリーチのいずれかの増加は、機器のコスト、機器の展開に利用できるスペース、および/またはインフラストラクチャのスケール/リーチの需要によって最終的に制限されます。特定の聴衆は、テクノロジー、経済学、または法律の制約により、単一のサービスプロバイダーまたは少数のプロバイダーに結びついている場合があります。また、ネットワークプロバイダーは、代理人と流通システムを管理できる場合もありますが、コンテンツプロバイダーと直接的な関係がない場合があります。このようなプロバイダーは、配布するコンテンツを持っている他の関係者と配信および流通インフラストラクチャを提携する手段を持っていることを望んでいます。

Content internetworking allows different content networks to share resources so as to provide larger scale and/or reach to each participant than they could otherwise achieve. By using commonly defined protocols for content internetworking, each content network can treat neighboring content networks as "black boxes", allowing them to hide internal details from each other.

コンテンツインターネットワーキングにより、さまざまなコンテンツネットワークがリソースを共有して、各参加者にそれ以外の場合よりも大規模および/またはリーチを提供できます。コンテンツインターネットワーキングに一般的に定義されたプロトコルを使用することにより、各コンテンツネットワークは近隣のコンテンツネットワークを「ブラックボックス」として扱い、内部の詳細を互いに隠すことができます。

5. Content Internetworking Model Terms
5. コンテンツインターネットワークモデル用語

This section consists of the definitions of a number of terms used to refer to roles, participants, and objects involved in internetworking content networks. The purpose of this section is to identify common terms and provide short definitions.

このセクションは、インターネットワーキングコンテンツネットワークに関与する役割、参加者、およびオブジェクトを参照するために使用される多くの用語の定義で構成されています。このセクションの目的は、一般的な用語を特定し、短い定義を提供することです。

ACCOUNTING INTERNETWORKING Interconnection of two or more ACCOUNTING SYSTEMS so as to enable the exchange of information between them. The form of ACCOUNTING INTERNETWORKING required may depend on the nature of the NEGOTIATED RELATIONSHIP between the peering parties -- in particular, on the value of the economic exchanges anticipated.

会計2つ以上の会計システムの会計インターネットワーキングの相互接続により、情報の交換を可能にします。必要な会計インターネットワーキングの形式は、ピアリングパーティー間の交渉された関係の性質、特に予想される経済交流の価値に依存する可能性があります。

ADVERTISEMENT Information about resources available to other CONTENT NETWORKS, exchanged via CONTENT INTERNETWORKING GATEWAYS. Types of ADVERTISEMENT include AREA ADVERTISEMENTS, CONTENT ADVERTISEMENTS, and DISTRIBUTION ADVERTISEMENTS.

コンテンツインターネットワークゲートウェイを介して交換される他のコンテンツネットワークが利用できるリソースに関する広告情報。広告の種類には、エリア広告、コンテンツ広告、および配布広告が含まれます。

AREA ADVERTISEMENT ADVERTISEMENT from a CONTENT NETWORK's REQUEST-ROUTING SYSTEM about aspects of topology, geography and performance of a CONTENT NETWORK. Contrast with CONTENT ADVERTISEMENT, DISTRIBUTION ADVERTISEMENT.

コンテンツネットワークのトポロジ、地理、およびコンテンツネットワークのパフォーマンスの側面に関するコンテンツネットワークのリクエストルーティングシステムからのエリア広告広告。コンテンツ広告、配布広告とは対照的です。

BILLING ORGANIZATION An entity that operates an ACCOUNTING SYSTEM to support billing within a NEGOTIATED RELATIONSHIP with a PUBLISHER.

請求組織出版社との交渉された関係内で請求をサポートするために会計システムを運営するエンティティ。

CONTENT ADVERTISEMENT ADVERTISEMENT from a CONTENT NETWORK's REQUEST-ROUTING SYSTEM about the availability of one or more collections of CONTENT on a CONTENT NETWORK. Contrast with AREA ADVERTISEMENT, DISTRIBUTION ADVERTISEMENT

コンテンツネットワークのリクエストルーティングシステムからのコンテンツ広告広告コンテンツネットワーク上の1つ以上のコンテンツコレクションの可用性について。エリア広告、配布広告とは対照的です

CONTENT DESTINATION A CONTENT NETWORK or DISTRIBUTION SYSTEM that is accepting CONTENT from another such network or system. Contrast with CONTENT SOURCE.

コンテンツの宛先別のそのようなネットワークまたはシステムからコンテンツを受け入れるコンテンツネットワークまたは流通システム。コンテンツソースとは対照的です。

CONTENT INTERNETWORKING GATEWAY (CIG) An identifiable element or system through which a CONTENT NETWORK can be interconnected with others. A CIG may be the point of contact for DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING INTERNETWORKING, and/or ACCOUNTING INTERNETWORKING, and thus may incorporate some or all of the corresponding systems for the CONTENT NETWORK.

コンテンツインターネットワークゲートウェイ(CIG)コンテンツネットワークを他のものと相互接続できる識別可能な要素またはシステム。CIGは、インターネットワーキング、リクエストのインターネットワーク、および/または会計インターネットワークの配信の連絡先である可能性があり、したがって、コンテンツネットワークに対応するシステムの一部またはすべてが組み込まれる場合があります。

CONTENT REPLICATION The movement of CONTENT from a CONTENT SOURCE to a CONTENT DESTINATION. Note that this is specifically the movement of CONTENT from one network to another. There may be similar or different mechanisms that move CONTENT around within a single network's DISTRIBUTION SYSTEM.

コンテンツの複製コンテンツソースからコンテンツの宛先へのコンテンツの動き。これは、特にあるネットワークから別のネットワークへのコンテンツの動きであることに注意してください。単一のネットワークの配信システム内でコンテンツを移動する類似または異なるメカニズムがある場合があります。

CONTENT SOURCE A CONTENT NETWORK or DISTRIBUTION SYSTEM that is distributing CONTENT to another such network or system. Contrast with CONTENT DESTINATION.

コンテンツソース別のそのようなネットワークまたはシステムにコンテンツを配布しているコンテンツネットワークまたは流通システム。コンテンツの宛先とは対照的です。

DISTRIBUTION ADVERTISEMENT An ADVERTISEMENT from a CONTENT NETWORK's DISTRIBUTION SYSTEM to potential CONTENT SOURCES, describing the capabilities of one or more CONTENT DESTINATIONS. Contrast with AREA ADVERTISEMENT, CONTENT ADVERTISEMENT.

配布広告コンテンツネットワークの配信システムから潜在的なコンテンツソースへの広告は、1つ以上のコンテンツの目的地の機能を説明します。エリア広告、コンテンツ広告とは対照的です。

DISTRIBUTION INTERNETWORKING Interconnection of two or more DISTRIBUTION SYSTEMS so as to propagate CONTENT SIGNALS and copies of CONTENT to groups of SURROGATES.

分布インターネットワーキング2つ以上の配布システムの相互接続により、コンテンツのシグナルとコンテンツのコピーを代理グループに伝播します。

ENLISTED Describes a CONTENT NETWORK that, as part of a NEGOTIATED RELATIONSHIP, has accepted a DISTRIBUTION task from another CONTENT NETWORK, has agreed to perform REQUEST-ROUTING on behalf of another CONTENT NETWORK, or has agreed to provide ACCOUNTING data to another CONTENT NETWORK. Contrast with ORIGINATING.

参加者は、交渉された関係の一環として、別のコンテンツネットワークから分布タスクを受け入れ、別のコンテンツネットワークに代わってリクエストルーティングを実行することに同意したか、別のコンテンツネットワークに会計データを提供することに同意したコンテンツネットワークについて説明します。発信元とは対照的です。

INJECTION A "send-only" form of DISTRIBUTION INTERNETWORKING that takes place from an ORIGIN to a CONTENT DESTINATION.

注入原産地からコンテンツの目的地まで行われる「送信専用」の配信インターネットワーク。

INTER-Describes activity that involves more than one CONTENT NETWORK (e.g., INTER-CDN). Contrast with INTRA-.

複数のコンテンツネットワーク(たとえば、CDNなど)を含むアクティビティを説明します。内部とは対照的です。

INTRA-Describes activity within a single CONTENT NETWORK (e.g., INTRA-CDN). Contrast with INTER-.

Intraは、単一のコンテンツネットワーク内(例:CDNなど)内でアクティビティを説明します。インターと対照的です。

NEGOTIATED RELATIONSHIP A relationship whose terms and conditions are partially or completely established outside the context of CONTENT NETWORK internetworking protocols.

交渉された関係契約条件がコンテンツネットワークインターネットワークプロトコルのコンテキストの外で部分的または完全に確立されている関係。

ORIGINATING Describes a CONTENT NETWORK that, as part of a NEGOTIATED RELATIONSHIP, submits a DISTRIBUTION task to another CONTENT NETWORK, asks another CONTENT NETWORK to perform REQUEST-ROUTING on its behalf, or asks another CONTENT NETWORK to provide ACCOUNTING data. Contrast with ENLISTED.

Originatingは、交渉された関係の一環として、分布タスクを別のコンテンツネットワークに送信し、別のコンテンツネットワークに代わってリクエストルーティングを実行するよう求めたり、別のコンテンツネットワークに会計データを提供するように要求するコンテンツネットワークについて説明します。入隊者とは対照的です。

REMOTE CONTENT NETWORK A CONTENT NETWORK able to deliver CONTENT for a particular REQUEST that is not the AUTHORITATIVE REQUEST-ROUTING SYSTEM for that REQUEST.

リモートコンテンツネットワークその要求の権威ある要求ルーティングシステムではない特定のリクエスト用のコンテンツを配信できるコンテンツネットワーク。

REQUEST-ROUTING INTERNETWORKING Interconnection of two or more REQUEST-ROUTING SYSTEMS so as to increase the number of REACHABLE SURROGATES for at least one of the interconnected systems.

相互接続されたシステムの少なくとも1つのリーチ可能なサロゲートの数を増やすために、2つ以上のリクエストルーティングシステムのリクエストルーティングインターネットワーキング相互接続。

6. Security Considerations
6. セキュリティに関する考慮事項

This document defines terminology and concepts for content internetworking. The terminology itself does not introduce any security-related issues. The implementation of content internetworking concepts does raise some security-related issues, which we identify in broad categories below. Other CDI documents will address their specific security-related issues in more detail.

このドキュメントでは、コンテンツインターネットワークの用語と概念を定義しています。用語自体は、セキュリティ関連の問題を導入しません。コンテンツのインターネットワーキングの概念の実装は、いくつかのセキュリティ関連の問題を提起します。これは、以下の幅広いカテゴリで特定しています。他のCDIドキュメントでは、特定のセキュリティ関連の問題にさらに詳しく説明します。

Secure relationship establishment: CONTENT INTERNETWORKING GATEWAYS must ensure that CONTENT NETWORKS are internetworking only with other CONTENT NETWORKS as intended. It must be possible to prevent unauthorized internetworking or spoofing of another CONTENT NETWORK's identity.

安全な関係の確立:コンテンツインターネットワーキングゲートウェイは、コンテンツネットワークが、意図したとおりに他のコンテンツネットワークとのみインターネットワークであることを確認する必要があります。別のコンテンツネットワークのアイデンティティの不正なインターネットワーキングやスプーフィングを防ぐことができる必要があります。

Secure content transfer: CONTENT INTERNETWORKING GATEWAYS must support CONTENT NETWORK mechanisms that ensure both the integrity of CONTENT and the integrity of both DISTRIBUTION and DELIVERY, even when both ORIGINATING and ENLISTED networks are involved. CONTENT INTERNETWORKING GATEWAYS must allow for mechanisms to prevent theft or corruption of CONTENT.

セキュアコンテンツ転送:コンテンツインターネットワーキングゲートウェイは、コンテンツの整合性と流通と配信の両方の整合性の両方を保証するコンテンツネットワークメカニズムをサポートする必要があります。コンテンツインターネットワークゲートウェイは、コンテンツの盗難や腐敗を防ぐためのメカニズムを許可する必要があります。

Secure meta-content transfer: CONTENT INTERNETWORKING GATEWAYS must support the movement of accurate, reliable, auditable ACCOUNTING information between CONTENT NETWORKS. CONTENT INTERNETWORKING GATEWAYS must allow for mechanisms to prevent the diversion or corruption of ACCOUNTING data and similar meta-content.

安全なメタコンテンツ転送:コンテンツインターネットワーキングゲートウェイは、コンテンツネットワーク間の正確で信頼性の高い監査可能な会計情報の動きをサポートする必要があります。コンテンツインターネットワーキングゲートウェイは、会計データおよび同様のメタコンテンツの迂回または腐敗を防ぐためのメカニズムを許可する必要があります。

7. Acknowledgements
7. 謝辞

The authors acknowledge the contributions and comments of Fred Douglis (AT&T), Don Gilletti (CacheFlow), Markus Hoffmann (Lucent), Barron Housel (Cisco), Barbara Liskov (Cisco), John Martin (Network Appliance), Nalin Mistry (Nortel Networks) Raj Nair (Cisco), Hilarie Orman (Volera), Doug Potter (Cisco), and Oliver Spatscheck (AT&T).

著者は、フレッド・ダグリス(AT&T)、ドン・ギレッティ(キャシフロー)、マルクス・ホフマン(ルーセント)、バロン・ハウセル(シスコ)、バーバラ・リスコフ(シスコ)、ジョン・マーティン(ネットワークアプライアンス)、ナリン・ミストリー(ノーテル・ネットワーククスの貢献とコメントを認めています。)Raj Nair(Cisco)、Hilarie Orman(Volera)、Doug Potter(Cisco)、およびOliver Spatscheck(AT&T)。

8. Normative References
8. 引用文献

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

[1] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。

[2] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol", RFC 2326, April 1998.

[2] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル」、RFC 2326、1998年4月。

[3] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, June 2000.

[3] Cooper、I.、Melve、I。およびG. Tomlinson、「インターネットWebレプリケーションとキャッシュ分類法」、RFC 3040、2000年6月。

9. Authors' Addresses
9. 著者のアドレス

Mark Stuart Day Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 US

マークスチュアートデイシスコシステム1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719米国

   Phone: +1 978 936 1089
   EMail: mday@alum.mit.edu
        

Brad Cain Storigen Systems 650 Suffolk Street Lowell, MA 01854 US

Brad Cain Storigen Systems 650 Suffolk Street Lowell、MA 01854 US

   Phone: +1 978 323 4454
   EMail: bcain@storigen.com
        

Gary Tomlinson Tomlinson Group 14324 227th Ave NE Woodinville, WA 98072

ゲイリー・トムリンソン・トムリンソン・グループ14324 227th Ave ne Woodinville、WA 98072

   Phone: +1 425 503 0881
   EMail: gary@tomlinsongroup.net
        

Phil Rzewski 30 Jennifer Place San Francisco, CA 94107 US

Phil Rzewski 30ジェニファープレイスサンフランシスコ、カリフォルニア94107 US

   Phone: +1 650 303 3790
   EMail: philrz@yahoo.com
        
10. 完全な著作権声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。